@olivierlambert Well, you were right, I was totally in the wrong folder without realizing it. However, after the rebuild it now won't start at all. Rebuilding the VM and restoring config is easy though (thanks to XO being so easy to use) so I might just do that to avoid confusion as this VM has some other issues unrelated to XO anyway.

@julien-f I think someone should update the doc with a real example

@Danp Good catch, can't believe I missed that. Unfortunately, that produced a new error; Error code: SR_BACKEND_FAILURE_77 Error parameters: , Logical Volume group creation failed, From some googling around it appears the issue is that the disks still have a zfs_member tag on them. lsblk -f produces this: NAME FSTYPE LABEL UUID MOUNTPOINT sdd zfs_memb ├─sdd2 zfs_memb data 305869021769108511 └─sdd1 zfs_memb sdb linux_ra localhost:127 1d7d1927-dfdb-c8a8-4af1-b25c2b355a7a └─md127 zfs_memb boot-pool 17799519329276801846 ├─md127p5 ext3 logs-efkbam 0deeb614-6788-45f9-92b7-0f6acc05da6d /var/log ├─md127p3 zfs_memb boot-pool 17799519329276801846 ├─md127p1 ext3 root-efkbam 62e0f462-29f8-4c2a-8df7-bed45c144a4a / ├─md127p6 swap swap-efkbam 26a6ce99-d4fd-43d1-8a27-79bddafb8707 [SWAP] ├─md127p4 vfat BOOT-EFKBAM 0B9B-C4C7 /boot/efi └─md127p2 sde zfs_memb ├─sde2 zfs_memb data 305869021769108511 └─sde1 zfs_memb sdc linux_ra localhost:127 1d7d1927-dfdb-c8a8-4af1-b25c2b355a7a └─md127 zfs_memb boot-pool 17799519329276801846 ├─md127p5 ext3 logs-efkbam 0deeb614-6788-45f9-92b7-0f6acc05da6d /var/log ├─md127p3 zfs_memb boot-pool 17799519329276801846 ├─md127p1 ext3 root-efkbam 62e0f462-29f8-4c2a-8df7-bed45c144a4a / ├─md127p6 swap swap-efkbam 26a6ce99-d4fd-43d1-8a27-79bddafb8707 [SWAP] ├─md127p4 vfat BOOT-EFKBAM 0B9B-C4C7 /boot/efi └─md127p2 sda └─sda1 So it appears my next step is sorting that out. Unfortunately the only way of clearing these tags that I've found so far seems to be wiping the drives completely and starting over? If so that's going to suck as I don't have physical access to the machine right now. If anyone has any suggestions for removing errant zfs_member tags (this machine previously hosted a TrueNAS install) without wiping the whole damn machine, I'd be eager to hear them. If not it'll have to wait until I'm back in the office I guess. Thank you again @Danp for your help.

You need to set a default sr with this command: xe pool-param-set uuid=<pool-uuid> default-SR=<sr-uuid>

Well, it seems like it works if I create a snapshot and create a new VM from the snapshot on the new server. Should be workable for my need.

That's really weird

@florent It looks like the restore test failed because the connection stream failed (and did not retry). It's hard to test this particular one because it is rather large. A good reminder to have more than one backup method (I do). I'll look for a XO update and see what changes. It is scheduled to do a full backup soon (as normal) to make sure issues like this are not a long term problem.

@wahla Hello ! In XO you can search "power_state:halted", select all VMs, and start If you want to do it automatically, I think you can script it with xe, but the best way is to understand why VM are shutting down or doesn't restart

Try with xe then.

@Andrew all that was okay. The proxy string was incorrect, now working. Thanks

If you want to login manually without any SSH key, you have to add a password for the account (passwd). Then you can log in with your Debian user with this password.

Updated to Master build, a66ae, xo-server 5.92.0, xo-web 5.96.0. Consoles seem to work fine again. thanks all!

@Danp I'll do some more digging on this once I have some time and see if I can find anything in the logs. I didn't have a chance to look yesterday when I was working on this. It might be worth noting that I was trying to setup an S3 remote, not sure if it would happen with another one and maybe it has something to do with timing out (was trying to hook into Backblaze which doesn't seem to be working right either, works fine on all my other machines running TrueNAS and stuff but can't get it connected with XCP-ng, other S3 places like Wasabi and Amazon work fine though). I'll update this thread with more info once I do some more testing, might have time this weekend but not sure yet, and this is in a production environment, so I do want to be careful about causing potential issues.

Click on "More details" to get it

Zstd is for XVA file format compression. There's no compression on delta, because we need to merge them on destination, when retention is reached (inside the backup repository). So it doesn't really worth it (since you'll have to decompress them to do the merge).

Hello, mtill ! In this situation, you may try to recover the stored data on the RAM because, in your case, the data was overwritten in the RAM. The number of recovered files by this method depends on the RAM size, the size of files that was overwritten by this way and by the time running this process. I can suggest you use a specialized recovery service like raid recovery service to ensure that you will restore more data you can. I wish you a bit of good luck.

I agree, I don't think it's a technical limitation, just a use case not "covered"

The DNS cache has been merged, keep us posted if you have any issues.

@Darkbeldin Got ya, thanks!