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

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!!!

I'm the president of a general contractor in the South. I've also been our IT person for 30+ years.

Last fall, when the winds of change at VMware began blowing, I started looking into alternatives for esxi. I happened upon videos about XCP-NG from Tom at Lawrence Systems and I decided to install it on a test system.

Its a great product and I've enjoyed getting to know it!

@supportcphl

Many, many happy hours have since transpired

I ended up wiping out the XO vm that was running the process and making a new one. That seems to have fixed it.

With all that said, I got one again last night with backing up the same VM that has caused an issue in the past. I just told the backup to restart so lets see what happens.

FWIW...having the same issue with Server 2025.

Another weird thing I've noticed with Windows Server 2025 on XCP-ng.

The network keeps resetting itself to "Public" (vs domain). This only happens when the VM is a domain controller and it only happens with Server 2025. If you go into the VM's console and disable the NIC and then re-enable it, it returns to a domain network. I've tried the usual trick of change the "Network location awareness" to delayed start but it doesn't help.

@Chemikant784
So with this being patch Tuesday, two updates got installed:

2024-11 Cumulative Update for Microsoft server operating system version 24H2 for x64-based Systems (KB5046617)
2024-11 Cumulative Update for .NET Framework 3.5 and 4.8.1 for Microsoft server operating system version 24H2 for x64 (KB5045934)

For whatever reason, those processes are no longer showing up and I can run things from the scheduler??

If you updated tonight, did yours go away?

@Greg_E
For the heck of it, I set up a new VM with 2025 and made it a domain controller complete with AD DS. It seems to work fine but, like yours, there are thirty something conhost processes running.

I recently upgraded from 8.3 RC2 to 8.3 final. Ever since then I've had a terrible time getting backups...especially delta backups (going to NFS server).

1. Under tasks in XO (Xen Orchestra, commit ff118), it says "[XO] Exporting content of VDI blahblah-drive3 using NBD (on host1) 34%". I have tried rebooting the XO VM (after disabling teh backup task) as well as those that has VM with the data. The task will not go away. I've tried restarting the toolstack on every host....its still stuck.

2. If you go to the backup activity, it says interrupted and then "download logs" you get this:

{
  "data": {
    "mode": "delta",
    "reportWhen": "always"
  },
  "id": "1730477627182",
  "jobId": "7863cc0b-601e-440a-8328-1d1ef2a09972",
  "jobName": "HOST1-VM1-delta",
  "message": "backup",
  "scheduleId": "59590d78-6809-4eb8-97fe-ba938a68939e",
  "start": 1730477627182,
  "status": "interrupted",
  "infos": [
    {
      "data": {
        "vms": [
          "5e01568d-3fa9-11f8-e293-e576f15d5cdb"
        ]
      },
      "message": "vms"
    }
  ],
  "tasks": [
    {
      "data": {
        "type": "VM",
        "id": "5e01568d-3fa9-11f8-e293-e576f15d5cdb",
        "name_label": "HOST1-VM1 (20241014T050050Z)"
      },
      "id": "1730477630143",
      "message": "backup VM",
      "start": 1730477630143,
      "status": "interrupted",
      "tasks": [
        {
          "id": "1730477630162",
          "message": "clean-vm",
          "start": 1730477630162,
          "status": "success",
          "end": 1730477630497,
          "result": {
            "merge": false
          }
        },
        {
          "id": "1730477630164",
          "message": "clean-vm",
          "start": 1730477630164,
          "status": "success",
          "end": 1730477630537,
          "result": {
            "merge": false
          }
        },
        {
          "id": "1730477631151",
          "message": "snapshot",
          "start": 1730477631151,
          "status": "success",
          "end": 1730477648388,
          "result": "e252e0e8-7c26-cd1c-3365-e519829f41e3"
        },
        {
          "data": {
            "id": "0d6da7ba-fde1-4b37-927b-b56c61ce8e59",
            "isFull": true,
            "type": "remote"
          },
          "id": "1730477648389",
          "message": "export",
          "start": 1730477648389,
          "status": "interrupted",
          "tasks": [
            {
              "id": "1730477651581",
              "message": "transfer",
              "start": 1730477651581,
              "status": "interrupted"
            }
          ]
        },
        {
          "data": {
            "id": "656f82d9-5d68-4e26-a75d-b57b4cb17d5e",
            "isFull": true,
            "type": "remote"
          },
          "id": "1730477648390",
          "message": "export",
          "start": 1730477648390,
          "status": "interrupted",
          "tasks": [
            {
              "id": "1730477651599",
              "message": "transfer",
              "start": 1730477651599,
              "status": "interrupted"
            }
          ]
        }
      ],
      "infos": [
        {
          "message": "Transfer data using NBD"
        }
      ]
    }
  ]
}

That happens to me about once every six weeks on one of the XO installs. For what its worth, if I just kill the XO vm and let it reboot, as long as its not out of disk space, it always works the second time.

@stormi
Just rebooted the problematic host. All the VMs autostarted just fine.

Odd!

@stormi
Yes

I've not had a chance to reboot the host since then to see if something else is going on. Will do so tonight.

@stormi
FWIW...one of the boxes where I installed the latest updates (from a few days ago) did not autostart any of the VMs. I had to manually start each of them.