We get in return:
|
|
So now we have the uuid for the host that is down (note the live=false): It's uuid a1716dba-7a75-4e99-94f6-27c00b8b122d. Now we enter:
|
|
This command lists the VMs the cluster thinks are running on the downed node. (The is-control-domain=false parameter removes |
We get:
|
|
Both VMs need to be recognized as turned off, so we enter:
|
|
This command forces the nodes in the pool to recognize the VMs associated with this uuid to be off. (The multiple is only necessary if you need to turn off multiple VMs. Be careful, because incorrect usage can force all VMs in the cluster to be powered off.) |
Returning to XenCenter, the console now shows that both the Windows VM and the Linux VM are off. Starting them moves the VMs to a different server (xennode01), and we are back in business.
Final notes
It is not difficult to create a highly available virtual server cluster using XenServer. Given the right approach, the availability can be carried even further. Within the XenServer functionality are methods to bond network cards, so the failure of any given NIC does not bring down a system. Using a different switch for each network card removes the switches from the possible failure list. Failure of the external storage can be overcome with the right RAID environment. And all this is possible with free software!
XenServer is built on a Linux kernel. A few people have suggested that we could script the recovery and even add a cron job to check for downed nodes and execution of the recovery script. This seems very plausible. One would just have to be sure that multiple copies of the script weren't getting executed from the different nodes, and that a node that went down and stayed down didn't prompt recurring script executions. If this were done properly, you would get automatic recovery of downed VMs!
As a starting point we offer the following. (Please note: We have not extensively tested this script.)
|
|