Xen Orchestra State when Master Node Reboots/Shuts down

Hi All,

I’m new to this forum so hopefully I’ve posted this in the right category.

I’m also new to XCP-NG and XO. I’ve installed both successfully and everything works fine, however I was wondering if a certain behaviour is normal and expected.

This is a two-node pool with no HA obviously, connected to TrueNAS iSCSI share as the shared VM storage.

When I shutdown or reboot the master node, XO will basically go back to an uninitialized or first time setup state until the master node comes back online. I’m just wondering if this is normal behaviour and why?


The Master node has all the information needed for the pool and unless you promote a slave node to be master then XO can on talk to it.

Thanks Tom. Is there an easy way to switch the master when there is an unexpected failure for example?

Also is there a specific reason that it was designed this way and whether this is a better way compared to other virtualization platforms?

When you restart master all the VM’s stay up and running on all the non master hosts. Having one master is a way to keep all the hosts in sycn from one place. In the event that a master has a complete failure any other member of the pool can be promoted as they all have the last known config from the master.

It has been a while since I played with HA, but I think I remember that you can designate another host to become master in an HA pool when the primary fails. I’d have to revisit this to be sure.

Otherwise I haven’t seen an issue during software updates with my 3 host “regular” pool. The “new” rolling update function works great and migrates your VM’s automatically to be able to reboot the hosts. Click it and watch the magic happen, they did a good job on that feature (in my opinion).

And all that said, I only ever have a few VM’s on my system because it is a lab system, trying to pry the money out of my employer so I can build my production network around XCP-NG and gain a little bit of failure tolerance. Even if it takes a few minutes for a VM to boot back up if a host fails, that’s better than having to fix the hardware before it can boot!