Thanks Olivier!

That is what we assumed, but with how the 3 hosts per pool was in there under the essentials licenses it was up for debate

Hey guys,

Got a licensing question.
Want to ensure we understand the terminology and intent correctly.

When looking at the Vates website pricing, and essential license clearly states "maximum 3 hosts"
Then under Core Features it says Maximum hosts per pool "3 hosts"

This is causing a bit of client confusion as to what the Max is referencing.

Does this mean that a XOA appliance can have multiple pools, and the Essentials license is limiting it to 3 hosts per pool, and not the hosts under management?

So, a client could purchase Qty:1 of the Essentials license, and Qty:1 Pro and have 2 pools managed by the same XOA?

Or does the 3 hosts max mean there can only be 3 hosts under management by the XOA when using the essentials license regardless of pool count?

For reference:
The scenario is if a client has 3-hosts at the datacenter, and 1 host offsite (DR), so 4 hosts' total. Are they able to purchase an Essentials license to cover the data center, and a Pro license to cover the DR system and manage them all from the same XOA?

Or would they have to purchase Qty:4 of the pro license to be in compliance.

Thanks!

@florent
Thank you very much for your quick help on this one.
The patch resolved the issue for both migrations we were struggling on.

It is fantastic to see the teamwork and a resolution developed so quickly.
Really makes us feel confident in knowing we made the right decision with going to XCP-ng for our clients.

Thank you

Did some more testing over the weekend and got some cleaner logs that are fully matched up.

We ran the command 'journalctl -u xo-server -f -n 50' and see these to entries:

Nov 15 14:26:10 xoa xo-server[552]: 2025-11-15T19:26:10.935Z xo:vmware-explorer:esxi INFO nbdkit logs of [WE-DS] WE-FS1/WE-FS1.vmdk are in /tmp/xo-serverGKTRzl
Nov 15 14:26:10 xoa xo-server[552]: 2025-11-15T19:26:10.943Z xo:vmware-explorer:esxi INFO nbdkit logs of [WE-DS] WE-FS1/WE-FS1_1.vmdk are in /tmp/xo-serverCFf19t

The log files were fairly large, wouldn't allow me to attach them, so i have provided them in a zip on dropbox if you want to take a look.

From what I can pick out in the log files it appears that the transfer from VMware is complete or so it looks that way.

After that I ran these two commands against the import tasks:
xo-cli rest get tasks/0mi0ogg5f
xo-cli rest get tasks/0mi0ogg5g

The output for those is also attached.
The one thing that stands out is in the "importing vms 17" is that WE-FS1.vmdk shows 'success' and WE-FS1_1.vmdk shows 'pending'

Finally, I attached the logs from the host as well.
I'm not seeing anything that jumps out at me as being wrong there either.

Zip file of logs:
https://www.dropbox.com/scl/fi/glxm5tvebf5vjizpnfvmx/Package-of-Logs.zip?rlkey=uyl0kltxhfnfcq0carbrg0lrv&e=1&dl=0

Hey Guys.

Got a general question about the V2V conversion.
We have two different clients that we are working on VMware to XCP migrations. Both clients have a half dozen VMs, and in both cases all the VMs migrated fine except for the file servers, which are around 1.5TB each.

Again, completely separate clients.

When running the import, everything appears to be running fine, but the import hangs at 99% and never gets past that.

I'm curious what is the import doing at 99%?
Thinking back to the VMware Converter days, the data move was actually finished at 97% and the last couple percent was configuration stuff. So if a conversation was to fail at 97% you could actually attach the VMDK to a VM and it would still be usable.

I'm curious if the same holds true with XCP if the import would be finished moving data at 99% and something else might be causing them to hang where we could create a new VM and attach the vhd.

(We do have a support ticket open on this issue)

Thanks

@florent

I have read through the guide you have provided but I'm struggling with it.

The guide does not appear to be a full sync and then a delta sync.
The guide appears to be for a per-migration test, which you then delete the test sync and re-run a migration.

This is the step that seems to suggest this:
"Remove the test copy
Once you’ve finished your checks and taken notes, delete the test VM. This will free up resources and prevent any confusion before the final migration."

Hey guys,

We are ramping up our VMware to Vates migrations.

One item that has come up is we would like to be able to use the Warm Migration method mentioned here: https://docs.xcp-ng.org/installation/migrate-to-xcp-ng/

The feedback I have got from our guys is that once you start the warm migration you really lose control. What I mean by this is on the final snapshot, shutdown of the VMware side. This happens when the initial copy is completed.

Without having some form of control, the options cannot be leveraged properly as the shutdown could happen mid-day when the server is being utilized.

Is there possibly via CLI any way to control the final step?
It would be really nice if the final step did not happen automatically, and once the initial sync is completed we had a button or such to trigger final sync and shutdown. That way we could arrange for it to happen after hours.

Just an idea if there is no way from CLI.

Thanks