@Danp Ah yes, I hadn't taken a fresh snapshot. And per your recommendation restarting xo fixed the problem as well. Brilliant, thanks!

The problem has solved itself. XCP-ng installer can't even be run on my PC (with UEFI). Some core-dump pops up and resets. For a test, I tried the installation on an old but problem-free laptop (in BIOS mode). Installation without a problem, but does not boot (OS not found). I have to look for another hypervisor. If the installer is already causing problems, then I don't want to know what to expect next. So the topic can be closed and even deleted.

@ItsAlwaysDNS said in Migrated Linux machine won't start: @DustinB I can try to give that a go. Is there any particular reason as to why we think this will work? I'm totally fine with the thought of "its worth a try". I'm just curious if there is some known compatibility issue that is leading you to suggest trying this as a solution. Normally these older systems were required to use the ESXI drivers, these drivers are also normally very out of date and cause issues. Most of the time, when these issues occur, it's because of incompatible drivers. Cloning the VM and removing the drivers from the clone and then trying to migrate the VM is the safest way to confirm the issue is with the drivers without impacting your production system.

@psylo xensource.log and daemon.log will usually give more information about failed operations. It could also be an issue in XOA's warm migration code in specific cases.

I might have hard time to give you a confirmation, but worth checking on the VMware side, yes

@Cygace XO is not directly tied to XCP. So the versions have nothing to do with each other. You can look at the XO master commits and pick one that lists feat: release 5.xxx.x and that will line up with a XOA release. You can pick a version that is the same as the current XOA release and it will be the same tested base code.

Thanks, that's very useful info! @florent will take a look when he can!

I don't think that's going to be an issue with Vates, they have ppl in different parts of the world and they're very helpfull. Reach out to them and link this forum thread, im sure they will be able to get you going even tho you're in Australia.

@ph7 said in Error starting network UPS tools (NUT) driver for TrippLite USB-passthrough: @waveguide I used the PCI passthrough for my zigbee USB Dongle and it has been working perfectly since I installed it 2½ month ago [image: 1738063996972-c349c774-c4bb-4dde-97f9-887521e2a871-bild.png] Interesting idea. I am running on a Dell R710 and the USB controller is not listed as an available PCI device that I can passthrough to the guest VM. It does come up on the host as a PUSB device. The ESXi server was also an R710. [image: 1738113146366-525ece0c-93c4-4cd0-8ce5-c001961959c2-image.png]

@TheLastOtter Strange. I think you touch nothing on your side?

You can deploy multiple XOA if it's your question, one to export in OVA, one to import the OVA.

Not looking to revive this topic but wanted to post this documentation I found in case anyone else searching for answers stumbles here like I did. There are too links on this site that address some limitations that are not readily documented in the standard migration documentation. https://help.vates.tech/kb/en-us/37-import-export-migration

@Don-Gould-NZ I wonder if this system got cloned as intended. I see 2 devices in XO, that will be xvda and xvdb. Yet earlier you listed it was one device with two partitions. The 512M size of the 2nd device makes me wonder if the migration turned the disk partitions into devices with partition/swap signature and nothing else. As such since the system looks for xvda's 2nd partition for root, there's no partitions so naturally it fails. You could get SystemRescueCD, boot off that and investigate the devices.

@Andrew I did not see a serial port listed. I'll just get a USB version and plug in to server and see if I can pass thru it. If it works, I can get rid of another Destop server and be fully virtual. Thanks for your hellp.

@Danp @olivierlambert so I'm going to build this out next week and how can I do the build out with the trials and after that how much would a 4 node xoa managed HCI with XOSTOR run for licensing? Also are there any guides for best practices for deployment of above configuration? IE what type of network configs for the XOSTOR and the pools. Also the vmware has a citrix deployment on it so do you have a connection aspect for citrix to interface with the pool same as vmware has? My R730 servers have 8 10gb fiber ports each so take that into consideration for the xostor configuration.

The workaround I have found at this point is to rebuild grub after migrating to XCP-NG. Adds a few minutes to each VM but I don't have that many. Boot to live iso in UEFI mode (I used Debian12 given it was a Debian12 vm) sudo su - mount /dev/mapper/????? /mnt mount /dev/xvda2 /mnt/boot mount /dev/xvda1 /mnt/boot/efi for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars chroot /mnt grub-install /dev/xvda update-grub exit shutdown now I'm using LVM so adjust the first mount to match your root partition. I shutdown so that I can remove iso and boot when I'm ready. Hope this saves somebody a bunch of frustration in the future.

So....................... it is dynamic memory causing me problems. I have have set the min/max and static memory to the be same. The system stays up fine. Now to figure our how/if I need dynamic memory to work on a Windows VM. I do not seem to be having problems with linux based workloads.

I recommend indeed Warm migration that doesn't need any 3rd party vendor tooling that are pushed by some shady accounts

A few things you could do -- Share the full error message (see entry in Setting > Logs) Switch to the "latest" release channel to see if issue also occurs there Review our Vmware migration checklist -- https://help.vates.tech/kb/en-us/37/133 HTH, Dan