Recovering from emergency mode in a XenServer resource pool is critical to maintaining pool stability. When a master node fails, members go into emergency mode, and a well-planned recovery process minimizes downtime. In this case, VM backups become critical to ensure data protection and fast recovery.
Updated by Dan Zeng on 2024/01/05
When you create a resource pool, you typically designate another XenServer server as the master. If this master node is unavailable for some reason, it will cause a number of problems. In addition, the startup and shutdown sequence of XenServer servers in a resource pool requires special attention.
If required, each member of the resource pool will contain all the information needed to act in the role of the master node. If the master node fails, the following sequence of events will occur in sequence:
1. Members realize that communication with the master node has been interrupted and each member retries the connection for 60 seconds.
2. Each member then places itself in emergency mode so that member XenServer hosts will now accept only pool emergency commands
xe pool-emergency-reset-master and xe pool-emergency-transition-to-master
At this point, if the master node recovers, it will reestablish communication with its members, the members exit emergency mode, and operations will return to normal. However, if the master node is disabled, you should select a member and execute the command
xe pool-emergency-transition-to-master
When this member becomes the master node, execute the command
xe pool-recover-slaves
and the other members will now point to this new master node. If you are repairing or replacing a server used as the original master node, you simply boot the server, install the XenServer host software, and then add it to the pool. Since the XenServer hosts in the pool are forced to be one of a kind, you do not actually need to set the replacement server as the master node.
After converting a member XenServer host to a master node, you should also check that the default pool repository is set to the appropriate value. This can be accomplished by verifying that the default-SR parameter points to a valid repository by using
xe pool-param-list uuid=pool uuid
If the master host in the pool fails due to some reason, it will cause the whole pool to enter emergency mode in XenServer, and the recovery steps are as follows:
1. Entering the following command on the member server will shut down the VMs running on the member service：
#xe host-emergency-ha-disable (disable HA) #xe-toolstack-restart
2. If you confirm that the original master host cannot be restored, you need to specify the master host manually. In order to set one of the member servers as the new master host, enter the following command on that server:
#xe pool-emergency-transition-to-master #xe pool-recover-slaves
3. Then type
#xe pool-emergency-reset-master master-address=<IP ADDRESS of the new master>
on the original master host to set it up as a member server of pool.
Howerver, if the original master host is determined to have crashed and can only be reinstalled, it cannot be added to the pool after reinstallation using the original machine name and IP address, and you need to clean out the information on that host before you can add it. Use
#xe pool-eject host uuid=<host_uuid>
to delete the host, and the UUID lookup can be performed with
#xe host-list command
To switch the master host in normal mode, use the following command:
# xe pool-designate-new-master host-uuid=Master host uuid
VM backups are especially important in the context of emergency mode recovery in XenServer. VMs contain an organization's core data and applications, so data protection and business continuity are critical. VM backups not only protect against the risk of data loss or corruption, but also serve as a critical component of a disaster recovery plan to ensure that VMs are restored quickly in the event of an emergency in order to maintain business stability.
Therefore, establishing and regularly updating a VM backup policy is an indispensable step in safeguarding the security and availability of your virtualized infrastructure. Vinchin Backup & Recovery supports a wide range of virtualization platforms such as XenServer, VMware, Hyper-V, etc., providing a wide range of VM backup and recovery options.
At the same time, Vinchin offers flexible options to customise an enterprise backup strategy according to actual needs. Whether you are a small business or a large organization, Vinchin's VM backup solution can provide a reliable safety net for your virtualized environment.
Vinchin Backup & Recovery’s operation is very simple, just a few simple steps. Just select VMs on the host > then select backup destination > select strategies > finally submit the job
Vinchin offers a free 60-day trial for users to experience the functionality in a real-world environment. For more information, please contact Vinchin directly or contact our local partners.
In summary, XenServer resource pool contingency mode recovery is critical to maintaining the stability of the resource pool. When a master node fails, members go into emergency mode in XenServer, and a well-planned recovery process ensures that downtime is minimized. Additionally, VM backups are critical in XenServer emergency mode to protect critical data and enable fast recovery. Vinchin is a powerful solution that simplifies VM backup management and ensures data protection & business continuity in the event of a XenServer emergency mode.
Share on:
