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

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

I'm a VMware user (currently v8.0.1) looking to leave the platform. Evaluating XCP-NG 8.3.0 and XO Community (currently at commit f9de5 from this morning).

I stood up a new Ubuntu Server 24.04 test instance on the ESXi system. I uninstalled tools from it

sudo apt remove open-vm-tools
sudo rm -r /etc/vmware-tools
sudo rm /etc/systemd/system/open-vm-tools.service 
sudo rm /etc/systemd/system/vmtoolsd.service 
sudo rm -r /etc/systemd/system/open-vm-tools.service.requires 
sudo apt autoremove

Then I shut down the instance and used XO to pull it over. No VMware snapshots were taken beforehand. I chose "Ubuntu Jammy Jellyfish 22.04" for the "Original Template". The XO import process went smoothly.

I will say that the details of the Import job (expanding the section at the bottom of the Import setup screen) did mention "Guest Tools status: The tools are installed" even though I had uninstalled them and powered off the machine. Maybe that should just say "unknown" if the machine is powered off? How is that status determined? ESXi acknowledged that the tools were not present prior to shutdown. That's not a huge deal at any rate.

I checked the "Advanced" settings once the VM was imported and noted that "Secure Boot" was disabled, which was to be expected as the original VMware VM never had it enabled.

When I actually went to start up the imported VM on XCP-NG, the UEFI boot process told me the following:

BdsDxe: loading Boot0001 "UEFI Misc Device" from PciRoot (0x0) /Pci (0x3,0x0) /VenHu (3D3CA290-B9A5-11Е3-B75D-B8AC6F7D65E6, 01000003)
BdsDxe: failed to load Boot0001 "UEFI Misc Device" from PciRoot (0x0) /Pci (0x3,0x0) /VenHw (3D3CA290-B9A
5-11E3-B75D-B8AC6F7D65E6,01000003) : Access Denied

I force stopped the VM, went back into its Advanced settings, and found the "Secure Boot" toggle was on. I turned it off and the VM booted correctly.

After booting the VM, I found its networking non-functional, so I created a /etc/netplan/00-installer-config.yaml file for the new enX0 interface:

network:
  version: 2
  renderer: networkd
  ethernets:
    enx0: # make sure this is the name of the interface using 'ip a' first
      dhcp4: true

And applied it, which fixed the connectivity:

sudo chmod 600 /etc/netplan/00-installer-config.yaml
sudo netplan apply
sudo networkctl renew enX0

I stopped the XCP-NG VM and tried to start the VMware VM again just to make sure it was still working. Unfortunately, I found that it no longer worked after the XO import had touched it. VMware threw the error

Failed to lock the file Failed to start the virtual machine. Module Disk power on failed. Cannot open the disk '/vmfs/volumes/5b2423e8-08a605f9-a539-00e0ed0be246/Ubuntu migration test clone/Ubuntu migration test clone.vmdk' or one of the snapshot disks it depends on.

Again, I had not created any snapshots of the VMware VM, and none were available to delete / consolidate.

Here is what the VM contents looked like on the VMware filesystem prior to the migration

[root@vm01:/vmfs/volumes/5b2423e8-08a605f9-a539-00e0ed0be246/Ubuntu migration test clone] ls
 -alh
total 4363456
drwxr-xr-x    1 root     root       72.0K Mar 24 15:24 .
drwxr-xr-t    1 root     root       96.0K Mar 24 15:23 ..
-rw-r--r--    1 root     root         528 Mar 24 15:23 Ubuntu migration test clone-6290bd80.hlog
-rw-------    1 root     root       25.0G Mar 24 15:24 Ubuntu migration test clone-flat.vmdk
-rw-------    1 root     root      264.5K Mar 24 15:23 Ubuntu migration test clone.nvram
-rw-------    1 root     root         567 Mar 24 15:23 Ubuntu migration test clone.vmdk
-rw-r--r--    1 root     root           0 Mar 24 15:23 Ubuntu migration test clone.vmsd
-rwxr-xr-x    1 root     root        3.2K Mar 24 15:24 Ubuntu migration test clone.vmx
-rw-r--r--    1 root     root        8.0K Mar 24 15:24 Ubuntu migration test.scoreboard
-rw-r--r--    1 root     root      138.7K Mar 24 15:24 vmware.log

And here is what they looked like afterward:

[root@vm01:/vmfs/volumes/5b2423e8-08a605f9-a539-00e0ed0be246/Ubuntu migration test clone] ls -laht
total 4365568
drwxr-xr-x    1 root     root       76.0K Mar 24 15:46 .
-rw-------    1 root     root       25.0G Mar 24 15:46 Ubuntu migration test clone-flat.vmdk
-rwxr-xr-x    1 root     root        3.2K Mar 24 15:46 Ubuntu migration test clone.vmx
-rw-r--r--    1 root     root        8.0K Mar 24 15:46 Ubuntu migration test.scoreboard
-rw-r--r--    1 root     root      140.6K Mar 24 15:46 vmware.log
-rw-------    1 root     root      264.5K Mar 24 15:45 Ubuntu migration test clone.nvram
-rw-------    1 root     root         567 Mar 24 15:45 Ubuntu migration test clone.vmdk
-rw-r--r--    1 root     root        8.0K Mar 24 15:24 Ubuntu migration test-1.scoreboard
-rw-r--r--    1 root     root      138.7K Mar 24 15:24 vmware-1.log
-rw-r--r--    1 root     root         528 Mar 24 15:23 Ubuntu migration test clone-6290bd80.hlog
-rw-r--r--    1 root     root           0 Mar 24 15:23 Ubuntu migration test clone.vmsd
drwxr-xr-t    1 root     root       96.0K Mar 24 15:23 ..

No .lck files to speak of.

My question is this:

What is XO doing to the original VM during the import procedure? Is it not a read-only process, especially if the source VM is not running during the import?

I did try the entire process again with another test VM. This time I used VMware to snapshot it once prior to uninstalling vmtools. But the XO import still broke it, and trying to revert to the snapshot didn't bring it back to life either. Very scary.

Per an AI chatbot recommendation, I ran this command as well

[root@vm01:/vmfs/volumes/5b2423e8-08a605f9-a539-00e0ed0be246/Ubuntu migration test clone] vmkfstools -D /vmfs/volumes/5b2423e8-08a605f9-a539-00e0ed0be246/Ubuntu\ migration\ test\ clone/Ubuntu\ migration\ test\ clone.vmdk
Lock [type 10c00001 offset 430571520 v 9888, hb offset 3276800
gen 143, mode 0, owner 00000000-00000000-0000-000000000000 mtime 142724999
num 0 gblnum 0 gblgen 0 gblbrk 0]
Addr <4, 41, 24>, gen 9868, links 1, type reg, flags 0, uid 0, gid 0, mode 600
len 567, nb 0 tbz 0, cow 0, newSinceEpoch 0, zla 4305, bs 65536
affinityFD <4,0,16>, parentFD <4,0,16>, tbzGranularityShift 20, numLFB 0
lastSFBClusterNum 0, numPreAllocBlocks 0, numPointerBlocks 0

Here is the chatbot's explanation, I'm regurgitating it here

From the vmkfstools -D output, it looks like the .vmdk file is being locked. The details indicate that there's a "type 10c00001" lock, but there's no owner information listed (the owner is 00000000-00000000-0000-000000000000). This suggests that the lock might be leftover from a previous operation or could be an orphan lock that didn’t get cleared properly.

The chatbot suggested that I try

services.sh restart

But I have not done that yet as this is a production server and it was a test VM at any rate.