Please update on the latest commit available on master, rebuild and try again 🙂

Thanks for your feedback @Andrew !

@olivierlambert Yea, I have bonded networks. I do rename them so that I know what they are for. It seems that the bond number (bond 1 and bond 0) changes on different servers, as I asked about before, so the name and description is needed here to make it easier.

@pdonias yep I can confirm that works as expected, cloud-init uses the base VM name specified in the top of the create VM page, not the numbered VM names that result after creation. Nevermind!

Hi @RaHu! No, at the moment, we don't synchronize hosts' information. I'm not even sure where that information could go as there isn't such a thing as a host object in Netbox, AFAIK.

@olivierlambert No, it does not. Still, sometimes badge with patches blink... funny.

VIM 😆

@olivierlambert Thanks - request raised.

Next UI will be FAR more easier to manage those things 🙂

👍

Hello there!

If you think some extra doc would be important to avoid searching for the solution, please do so 🙂

@Andrew Wanted to go ahead and add that it didn't seem slow to me to do the export, it was only 2GB, but still. It did take a bit to ramp up speed though, I got 4.5KB downloaded and then it sat there for a few minutes, but once it started downloading more data it sped up and the whole 2GB download was done in like 1-2 minutes, not crazy fast but not super slow either.

I will try and test this with a bigger VM when I get the chance to see how it behaves.

@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.

It's hard to know exactly: is it something we can see on XO's side or not? I can't tell. Maybe SMlog got more info at the time the VM snapshot is removed.