Backup Error: 302 Found
-
Okay so interestingly. If I detach a host from the pool and have it in it's own pool. Migrate a VM to that pool/host. Backups go through without issue.
The only time I have an issue is when trying to backup a vm on a host that isn't classified as a master of my primary pool. Not familiar enough with the workings to really guess at what's going on, but any guesses? Maybe just kill the pool, reinstall on the current master and recreate the pool?
-
Just to double check to see if it's something awry with the xcp-ng install, I did a full clean install of xcp-ng. Added the two other machines (tc2 and tc3) to the pool and I'm getting the exact same issue. When backing up any vm's on tc2 and tc3, if part of a pool, I get an Error: 302 Found. As soon as i migrate the vms off, detach tc2/3, and migrate the vms back onto those machines as their own pool... backups go through just fine.
-
Have you tried doing the following?
- Edit the backup job
- Remove the target remote
- Readd the target remote
- Save changes
-
Yep I've edited, removed, and readded the backup job.
I've nuked the xcp-ng install, resinstalled, xcp-ng, created a brand new debain 11 vm, compiled xo from source using latest master, added hosts to the pool, migrated vms to pool.
I've nuked the remote vdev, created a new vdev, added new vdev as new remote, setup a new backup job using new vdev.
I've detached all the hosts and left them in their own pool, used existing and new backup tasks.
The only time backups go through are when the vm is on a master, whether it be in one bit pool or three seperate pools (one for each host). If the vm is on a master it goes... if it isn't... Error: 302 Found
-
There's a problem with the redirection on the slave host.
-
@olivierlambert
Any suggestions to try? I had a similar suspicion, leading me to disconenct and reconnect the slave hosts using IP, https://<hostname>, and <hostname>... but all methods result in the same outcome a working pool, but unable to backup an VM on the slave hosts.Not sure where else to go other than nuking everything and starting from scratch. Which means running backups on everything while the hosts are all masters and then playing 3 card monty with the vms in the process.
-
First thing is to see if someone can reproduce the issue first
-
@olivierlambert When I get a bit of time I'll do a bit of a more comprehensive write up outlining initial migration, actions taken, etc in a more cohesive manner. I'll also spin up a few non-critical spare hosts I have on hand and see if I can replicate it or not myself with different equipment.
As it stands now, all the hosts are on their own pool and in the process of running a comprehensive backups for everything to give me a bit of piece of mind. Once that's done, I'll get a bit more aggressive in my efforts!
-
I was counting on the community to see if someone with a similar setup could report
-
-
@stucamp I finally had time to investigate this, it should now be fixed
Thanks for your report!
https://github.com/vatesfr/xen-orchestra/commit/24cac9dcd5d83c3170175c9c874d0a3ae51f4e6d
-
@stucamp you were just the first to discover the issue congrats and thanks for the report!
-
@julien-f @olivierlambert
Heyo... good stuff guys. I have recompiled on latest and can happily confirm that the fix has resolved the issue!!Thanks!
-
-