Backup does not work if one host in the pool is offline
-
Hi,
I moved all VMs to the poolmaster and shut down the other host. Now XOA won't perform any backups because it is checking if the other host is up first. Can this be fixed so it doesn't check other hosts in the pool before doing a backup?
-
Hi,
I think this is not a Xen Orchestra limitation. Can you paste the error please?
-
The only backups that work are the Pool Metadata backups.
-
Do you have VMs to backup that are only available on a halted host?
Is the IP address displayed is available?
-
@olivierlambert said in Backup does not work if one host in the pool is offline:
Do you have VMs to backup that are only available on a halted host?
Is the IP address displayed is available?
The IP address is the one of the halted host, so it is not available/pingable. The halted host has no VMs on it except a powered off ubuntu test vm on local storage. This VM is not included in any of the backup schedules.
-
If XO got a timeout on this IP, it's because the master host is probably redirecting XO to it. So it's not XO, it's redirected there for a reason. It's hard to tell why without digging further.
-
@olivierlambert said in Backup does not work if one host in the pool is offline:
If XO got a timeout on this IP, it's because the master host is probably redirecting XO to it. So it's not XO, it's redirected there for a reason. It's hard to tell why without digging further.
I see that the server in XO Settings->Server was still pointing to the old host. It used to be the pool master before. I had forgotten to change this.
When changing pool masters, could XO add the new pool master here automatically?
-
And how could it guess that?
Right now, if you target a slave, XO will connect to it, but XAPI will answer: "I'm not the master, here is master's IP" and then XO will redirect to the master.
But since the slave is down, XO has no meaning to "know" anything, so it will fail.
-
@olivierlambert said in Backup does not work if one host in the pool is offline:
And how could it guess that?
Right now, if you target a slave, XO will connect to it, but XAPI will answer: "I'm not the master, here is master's IP" and then XO will redirect to the master.
But since the slave is down, XO has no meaning to "know" anything, so it will fail.
I thought it might be able to detect when the pool master is changed. But maybe you are right. Could we perhaps have a "Current Pool Master" info in the servers list. Also a warning in XOA health screen mentioning that the current server is not pool master?
-
When you connect to a working, machine, yes it does
But XAPI connection isn't persistent: it means, when the pool is disconnected, XO has no recollection whatsoever on who was the "real" master the last time it was connected. The only info we store is the IP address you entered in Settings/server.
I agree, functionally speaking, it can be limiting in your case. A viable option would be to save all existing hosts IPs in the XO database, as fallback if we can't connect to the IP you entered. This is not a very common case, that's why it wasn't done before
-
-
@olivierlambert said in Backup does not work if one host in the pool is offline:
When you connect to a working, machine, yes it does
But XAPI connection isn't persistent: it means, when the pool is disconnected, XO has no recollection whatsoever on who was the "real" master the last time it was connected. The only info we store is the IP address you entered in Settings/server.
I agree, functionally speaking, it can be limiting in your case. A viable option would be to save all existing hosts IPs in the XO database, as fallback if we can't connect to the IP you entered. This is not a very common case, that's why it wasn't done before
Looks like a good suggestion. Thanks.
In my case I migrated everything from the poolmaster to the second host, then changed the second host to pool master, waited an hour and then shut down the old pool master (now just a pool member). XOA was online during the entire process and I had forgotten to check the server list.