@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

I tried to upload it with the "Upload button" and got this error" [2026-02-05T15_03_26.704Z - backup NG.json](Invalid file type. Allowed types are: .png, .jpg, .bmp, .txt, .diff, .patch, .jpeg) "

2026-02-05T15_03_26.704Z - backup NG_json.txt

@Danp
WDE

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

@flakpyro
I'm good now!

@stormi I missed it!

@florent

I tried to upload it with the "Upload button" and got this error" [2026-02-05T15_03_26.704Z - backup NG.json](Invalid file type. Allowed types are: .png, .jpg, .bmp, .txt, .diff, .patch, .jpeg) "

2026-02-05T15_03_26.704Z - backup NG_json.txt

@olivierlambert
Hmmmmmmm....good thought and you are right. I had it set at 10 and counted and it crapped out at 10. I just changed it to 100 and it worked fine!

@olivierlambert
Oops...
Amazon S3

Pool Metadata backups to S3 will work for a few days then start having an error that says "The XML you provided was not well-formed or did not validate against our published schema".

I can set up a new backup job which works a few days then starts having the same error.

This running on Xen Orchestra (commit a0e77) complied from source.

Thoughts?

Thanks!

Mystery solved:
There are numerous hosts under one master in the pool. I ran the yum update command on the master first, then rebooted, I then ran yum update on the rest and rebooted all but one. I could not reboot the last one until this morning (Saturday).

I rebooted the last one a few minutes ago and all is well.

Because I think its interesting, I'd love someone smart to explain the process of why other hosts could not do a snapshot because a different host in the pool had not been rebooted.

@Danp
WDE

@MajorP93
My bad....because of the word "rebooting" I took the statement "Were the hosts rebooting after the patches were applied?' to mean 'Were the hosts rebooting while the patches were being applied?'

To recap:
I did reboot after the patches had been applied.

Sorry !!

@MajorP93
I always reboot at the conclusion of the update and did as well this time.

@Danp
Nope!

Yesterday I upgraded to the most recent version of XCP-NG 8.3 via yum update.

Last night's backup is full of this error using the following:
Xen Orchestra, commit 8448b
Xen Orchestra, commit 1de60

I looked at the logs and they pointed to a snapshot error.

For the heck of it , I tried running a snapshot on any of the VM's. Each one fails with this error:

vm.snapshot
{
  "id": "0b65cf83-8309-3dcc-fa94-a511c77c96bd"
}
{
  "code": "NOT_SUPPORTED_DURING_UPGRADE",
  "params": [],
  "task": {
    "uuid": "71b630bb-d299-bab2-c2e9-065cd4bfef5c",
    "name_label": "Async.VM.snapshot",
    "name_description": "",
    "allowed_operations": [],
    "current_operations": {},
    "created": "20251219T14:33:39Z",
    "finished": "20251219T14:33:39Z",
    "status": "failure",
    "resident_on": "OpaqueRef:3ea53cca-30d6-7c19-3f77-3f7eb26c6675",
    "progress": 1,
    "type": "<none/>",
    "result": "",
    "error_info": [
      "NOT_SUPPORTED_DURING_UPGRADE"
    ],
    "other_config": {},
    "subtask_of": "OpaqueRef:NULL",
    "subtasks": [],
    "backtrace": "(((process xapi)(filename ocaml/xapi/xapi_vm_lifecycle.ml)(line 755))((process xapi)(filename ocaml/xapi/xapi_vm_helpers.ml)(line 1653))((process xapi)(filename fun.ml)(line 33))((process xapi)(filename fun.ml)(line 38))((process xapi)(filename ocaml/xapi/helpers.ml)(line 1788))((process xapi)(filename ocaml/xapi/xapi_vm_helpers.ml)(line 1652))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 1740))((process xapi)(filename ocaml/xapi/rbac.ml)(line 229))((process xapi)(filename ocaml/xapi/rbac.ml)(line 239))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 78)))"
  },
  "message": "NOT_SUPPORTED_DURING_UPGRADE()",
  "name": "XapiError",
  "stack": "XapiError: NOT_SUPPORTED_DURING_UPGRADE()
    at Function.wrap (file:///opt/xo/xo-builds/xen-orchestra-202512190914/packages/xen-api/_XapiError.mjs:16:12)
    at default (file:///opt/xo/xo-builds/xen-orchestra-202512190914/packages/xen-api/_getTaskResult.mjs:13:29)
    at Xapi._addRecordToCache (file:///opt/xo/xo-builds/xen-orchestra-202512190914/packages/xen-api/index.mjs:1078:24)
    at file:///opt/xo/xo-builds/xen-orchestra-202512190914/packages/xen-api/index.mjs:1112:14
    at Array.forEach (<anonymous>)
    at Xapi._processEvents (file:///opt/xo/xo-builds/xen-orchestra-202512190914/packages/xen-api/index.mjs:1102:12)
    at Xapi._watchEvents (file:///opt/xo/xo-builds/xen-orchestra-202512190914/packages/xen-api/index.mjs:1275:14)"

I've tried restarting the toolstack on the pool master as well as the hosts.

Any ideas?