I wasn't even aware about this being a Windows limitation by itself

@ronan-a Unfortunately, the same issue persists even with a reduced MTU. We are experimenting with alternative solutions to replace a "commercial solution" on HCI infrastructure, and I am afraid that issues like this are unacceptable. I used Xen a long time ago and thought XCP-ng would be an excellent solution—and it very likely is, when used with a traditional storage system.

@jr-m4 Hi there... A warm VMware V2V migration should indeed start up by itself, so I'm not sure what you are experiencing is normal. This is documented, as you've probably seen, at: https://xcp-ng.org/blog/2022/10/19/migrate-from-vmware-to-xcp-ng/ That said, in addition, if you want your imported VMs to start up automatically every time your XCP-ng server or pool boots up, you have to enable the Auto Power On / Auto Start configuration. For this to work, it must be enabled at both the Pool level and the individual VM level. Method using Xen Orchestra (Recommended): Go to the VM tab, select your imported VM, and navigate to the Advanced view. Toggle the Auto power on switch to ON. (XO will handle configuring both the host pool and the VM flags for you). Or alternatively, via the bash shell: --> Get your Pool UUID xe pool-list --> Set the auto_poweron parameter to true xe pool-param-set uuid=<POOL_UUID> other-config:auto_poweron=true Enable Autostart on the Imported VM: --> Get your VM UUID xe vm-list name-label="Your_Imported_VM" --> Set the VM param to true xe vm-param-set uuid=<VM_UUID> other-config:auto_poweron=true

@FritzGerald Thank you for taking the time to write up the install procedure. I was able to follow it on my end and it seems to be working. What commands do you use to set the three services to start up automatically at boot up? Right now if I reboot and run upsc apc@localhost it throws an error until I manually do: upsdrvctl start systemctl start nut-server.service systemctl start nut-monitor.service

@carloum70 Sorry, that option was deprecated. You may need to be more specific in the reset, something like the following with is just an example: xe-reset-networking -m IP_of_Master --device=eth0 --mode=static --ip=192.168.1.50 --netmask=255.255.255.0 --gateway=192.168.1.1 --dns=192.168.1.254 Check the options and see which ones you actually need in your case. Worst case, you could possibly dissolve the bond, redo the PMI and then re-create the bond. WHy eth4 shows up is hard to guess. I have seen before that on some hosts in a pool that the NIC order was not the same, even though the hardware and OS versions were identical. In that case, you have to shut down the NICs and use interface-rename to reassign specific NIC names to the corresponding MAC addresses.