@stormi
Fantastic and way to go...thanks for all your hard work!

I moved four sites from Esxi to XCP-NG (there are about twenty ish virtual machines).

Once I figured out how to make XCP-NG work, it was relatively easy. I began by installing it on an unused old Dell.

My comments are from that standpoint of a general contractor (construction) that also does IT work so take some of my terminology with a grain (boulder) of salt.

Things that gave me some pause:

• Figuring out how XOA works vs XO was somewhat confusing. I ended up watching two of Tom's videos at Lawrence Systems (shown below) to get me started.
  https://lawrence.technology/xcp-ng-and-xen-orchestra-tutorials/
  https://lawrence.technology/virtualization/getting-started-tutorial-building-an-open-source-xcp-ng-8-xen-orchestra-virtualization-lab/

• NIC fallover - this was much easier in Esxi. It took me a night to figure out how to do the bonding thing.

• The whole "NIC2:" has to be the same "NIC2:" on every machine was a pain in the a##. Again the way esxi does it is easier.

• Figuring our the proper terminology to properly create a local repository
  Find the disk ID of the “sdb” or “cciss/c0d1”disk
  ll /dev/disk/by-id

use gdisk to create partions
"xe sr-create host-uuid=c691140b-966e-43b1-8022-1d1e05081b5b content-type=user name-label="Local EXT4 SR-SSD1" shared=false device-config:device=/dev/disk/by-id/scsi-364cd98f07c7ef8002d2c3c86296c4242-part1 type=ext"

• Expanding an existing drive (i.e. after you grow a raid drive) was a tough (I have post on this site that shows how I did it).

• Moving a VM from esxi to XCP-NG was just long and a few vomited in the process and had to be re-done. In some cases I used the built in XCP-NG migration and, in others (the huge VMs) I figured out how to do it via Clonezilla (much, much faster once I got the hang of it).

• list item Having to shut down a running VM to increase the disk size is a bit of a PITA but its not that big of a deal.

• Over committing memory...I still don't have a great grasp on the one.

Before I made the move, I did a ton of speed tests of esxi vs XCP-NG. About 60% were slightly faster on Esxi and 40% were faster on XCP-NG. In the end, the differences were negligible.

With all that said, I think XCP-NG is much easier to use than esxi and I like it better. Vcenter seemed to last about six months and then always died and had to be rebuilt (and the restore utility was about as reliable as gas station sushi). With XOA, it always works and is much faster than Vcenter.

The backup is awesome. With esxi I was using Nakivo.

Just my two cents!

@florent
I's running it right now!

@archw
Ignore that entire post...user error. I have two networks that are spelled very close to the same thing and I was using the wrong one.

@Danp
80 to 84! Building science...never saw Bo but Lionel "Little Train" James was in the class I went to (he was leaving as I was walking in...nice dude!!!).

@florent
For the heck of it, I made a new VM in esxi and pointed it to the vmdk file. At that point, xcp-ng would perform the loading conversion process using the new VM setup.

I have no idea what was wrong with the original vmx setup file in esxi.

@stormi I missed it!

11 hosts and thirty something VMs (windows, linux, bsd mix) and update went fine.

@stormi
Sorry...I cliked reply to teh wrong post.

Yes, I ran "yum update edk2 --enablerepo=xcp-ng-testing,xcp-ng-cii" and let it install. I then rebooted the VM (several of them) and tried to start them and none worked. I then ran "yum downgrade edk2-20180522git4b8552d-1.5.1.xcpng8.3" and the VM's fired right up.

@olivierlambert
Done!!!

In the jobs function, there is a function to re-start a virtual machine called "vm.restart". It has a series of options. Is there anywhere that shows what the various options do?

The three options are shown below:

timeout
force (seems obvious but what if it not checked?)
bypassBlockedOperation

Thanks!

@flakpyro
I've found a similar issue with all VMs I update. After I update and reboot, it stays at "Management agent detected" with no version shown.

Once I reboot a second time, it stays at "Management agent detected" with "Management agent 9.4.1-160 detected"

@AshleyDe
In the last few days, I've had these same issues with a few Server2025 virtual machines (I assume are close ish to Win11 24h2).

I updated the master pool...all went well. I updated one of the other hosts. After it rebooted, I got lots of messages about "Async.VM.clean_shutdown: 8%" on the various VMs.

My bad....XO was a two builds behind and well as XO was not up to date.

I updated to commit 95e72 and updated XOA version to 5.106.2 and all is well.

User error on my part but I hope this helps someone.

@AtaxyaNetwork
I do!

@AtaxyaNetwork
BTW...how in the world did you add the guest tools? I messed around with that while watching two movies a few Sundays ago and finally gave up!

@flakpyro
I'd love to see what you did!
On the GRUB password thing, I cheated and opened it with another instance os SLES and jacked around with the menus from a working system. I tried a million things but could never get the tools installation to work!

3. Mount up basically any linux installer or system rescue ISO.

4. Boot into that (If using SLES, go to other options and select "RESCUE MODE" and wait).... get a shell...
   This will let you ssh into it
   sudo ssh-keygen -A
   sudo service ssh --full-restart
   ip addr # so I can know how to get in from putty
   cat $PATH
   passwd (makes a new password so you can ssh inot it)
   /sbin/sshd

lvdisplay
mkdir -p /mnt/sysimage/boot
mount /dev/xvda2 /mnt/sysimage/boot
mount /dev/OMCAppVG/LVRoot /mnt/sysimage
mount -t proc none /mnt/sysimage/proc
mount -o bind /dev /mnt/sysimage/dev
mount -o bind /run /mnt/sysimage/run
/mnt/sysimage
for x in sys proc run dev tmp; do mount --bind /$x /mnt/sysimage/$x; done
chroot /mnt/sysimage

I saw these instructions somone where but I coudl not figure out these steps ?

8 ) Enable root logins in /etc/ssh/sshd_config

9. Enable sshd via: systemctl enable sshd

10. Set a temporary password for root via passwd

11. Exit the chroot and the installer/rescue image... let it boot back into OME

12. Cache your ssh key in root's keystore via whatever method you like... my preferred is ssh-copy-id

13. Remove root's temporary password...

@olivierlambert
Since I'm having the same issue, can I give that suggestion a shot? If so, how do you do it from the command line (with xe CLI)?

@stormi I missed it!

@Hex
Ditto
https://xcp-ng.org/forum/topic/10532/backup-failed-with-body-timeout-error/8

I have it happen on almost every large backup. I had to give up. In the VMs that would not backup, I moved to delta backups.

FWIW, here were my results:

Regular backup to TrueNas, “compression” set to “Zstd”: backup fails.
Regular backup to TrueNas, “compression” set to “disabled”: backup is successful.
Regular backup to vanilla Ubuntu test VM, “compression” set to “Zstd”: backup is successful.
Delta backup to TrueNas: backup is successful.