@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

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

@florent PM sent with backup job log. Nothing is showing up for VDI_IN_USE in the xo-server logs. One thing I just noticed is that past two jobs have both been full backups when one should have been a full and then a delta.

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

@pilow As I am completly new to this scripting and such I did reach out to Ai for assistance and believe the license check should be bypassed now. Again not suggested to use in production. Use at your own risk. still has its own branch for more testing before merging to main branch.