@nikade said in Every virtual machine I restart doesn't boot.: @DustinB yeah im guessing the VDI isn't attached to the VM for some reason, based on the screenshot. Im also wondering if he ever rebooted the VM's after installing them with PXE Right, it's a likely answer... but even then I would've expected his PXE server to just restart the installation process all over again... assuming that the disk is attached to the VM etc and that PXE boot isn't disabled automatically like it is with an ISO after first boot. haha

@Pa3docypris I also had this problem with one single Debian VM. I would delete the snapshot and they would just keep adding every backup. I have lots of the same VMs and lots of other VMs on the pool. Three VMs were basically exactly the same but only one had an issue. I tried deleting all snapshots on the VM. Changing the CBT state. Doing a full backup up of the VM.... same problem. Snapshots just built up. I found a CD in the VM drive and it would not eject (with a XCP error). So there was something strange with the VM state. I shutdown the VM, cleared the CD, and restarted the VM. After that, backups worked normally for that VM. So I won't blame XCP or XO, it seems the VM was just in a random strange state that caused problems.

@florent since your early patch of my XOA (xo-server restart at the disk activity peak) [image: 1772047222068-3e55ee10-ef90-471e-aec6-967a569c8fa1-f3d3bd6c-ef54-4f5c-9202-5aab25319db9.png] noticing vif0 transmitting a bit on the network and different ram activity on a timespan of 2 hours something has changed, is it for the better ? let the night decide

The issue seems to be synchronizing the network configurations. The pool management is configured for bond1 (eth6+ eth7), that is set for LACP, both switch ports are already configured for LACP. Bond0 (eth0 +1) is created, but bond 1 fails, and management interface is never assigned to Bond1. Network 2 and 3 are active on the pool even if never used.

Aha! I will move to prometheus in the future, but at the moment it is more basic. Thank you!

@benapetr said in Import from VMware err: name: AssertionError: Expected "actual" to be strictly unequal to: undefined: Hello, since this never had a clear resolution, here is explanation of the bug and why it happens: There is a bug in disk iteration in that XO vmware plugin (somewhere in that esxi.mjs I don't remember exact location) - it basically expects that all disks of VM exist in same datastore and if they don't it crashes as the next disk in unexpectedly missing (undefined) Workaround is rather simple - select the VM in vmware, migrate -> storage, disable DRS (important) and then select any DS that no disks current exist on. If you select and DS that is already used by same VM it will sometimes not get fixed! It also may happen even if VM is "apparently" looking like it's on single DS, even if it reports as such, still try to migrate it to another DS, and disable DRS so that really all files, even meta files are in same directory. Then run XO import again, it will magically work. thanks you for the input we were under the assumption that all the disk of a VM are in the same datastore the fix should be too hard now that you did the hard work edit: card created in our backlog, I will take a look after the release to see how hard it is to implement