I am feeling kind of dumb here and hoping someone can set me straight.
I have a client who had a XOA trail going, and they had bound the trial license to the pool.
They have since purchased license; we can see the license under XOA | Licenses.
It says "This license is active on this XOA (Not Installed).
I for the life of me cannot figure out how to remove the Pool binding to the trail license and bind it to the purchased license.
Any simple thoughts on this? Maybe a CLI way of doing it?
Hot damn!!
@flakpyro
For kicks and giggles I tried what you had sent
xe vm-param-add uuid=VM_UUID param-name=platform msr-relaxed=true
And sure enough it worked!!
Not exactly sure the technical details on what setting msr-relaxed=true does but hey if it works it works 
I tried bcdedit /set hypervisorlaunchtype off
This did not make any difference.
Attached is the output form the "xl dmesg"
Not 100% sure what I would expect to see in here.
One thing i thought was odd and maybe it isnt but the fact is asy VIRIDIAN even though i turned that off under the advanced settings for the VM in question.
xl dmesg.txt
bcdedit /debug off
Thank you @pilow fir the ideas but neither were fruitful 
I have disabled VIRIDIAN and set the debug to off and both resulted in the system crashing and rebooting.
For anyone who is smarter than I am here is the Stack Text from the crash dump. From what I can decipher it has something to do with the CPU debug registers
STACK_TEXT:
ffffde00fd2bc128 fffff806500b449e : 00000000000001aa 000000000009ed00 0000000000000003 ffffde00fd2bc900 : nt!KeBugCheckEx
ffffde00fd2bc130 fffff8064fee3d88 : 000000000009ed00 fffff8065003f0d2 0000000000000000 0000000000000000 : nt!RtlpGetStackLimitsEx+0x1d0cfe
ffffde00fd2bc180 fffff8064fee8294 : fffffb02e3ca2300 ffffde00fd2bce00 fffffb02e3ca2300 0000000000000000 : nt!RtlDispatchException+0x508
ffffde00fd2bc8d0 fffff8065002f442 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiDispatchException+0x304
ffffde00fd2bcfb0 fffff8065002f410 : fffff80650043d47 0000000000000000 0000000000000000 ffff9508e2b7b080 : nt!KxExceptionDispatchOnExceptionStack+0x12
fffffb02e3ca2118 fffff80650043d47 : 0000000000000000 0000000000000000 ffff9508e2b7b080 fffffb02e3ca1930 : nt!KiExceptionDispatchOnExceptionStackContinue
fffffb02e3ca2120 fffff8065003edf0 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiExceptionDispatch+0x107
fffffb02e3ca2300 fffff8065002e847 : fffff8065003f0d2 ffff9508e2b70000 0000000000000006 000000000009fda0 : nt!KiGeneralProtectionFault+0x330
fffffb02e3ca2498 fffff8065003f0d2 : ffff9508e2b70000 0000000000000006 000000000009fda0 ffff950800000000 : nt!KiSaveDebugRegisterState+0xc7
fffffb02e3ca24a0 00000000771416e5 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiPageFault+0x2d2
000000000009ed00 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x771416e5
Hey guys,
Running into what we feel is a very unique situation we have never seen with any hypervisor before.
What we have is an application that if it is installed on a VM running on XCP-ng host, it will cause the VM to BSOD with EXCEPTION_ON_INVALID_STACK every time the application is launched.
Doing the exact same setup on an identical physical hardware host running VMware with a brand-new Server 2022 VM the application installs just fine. (We are in the process of migrating from VMware to XCP-ng which is how we have these two hosts with different hypervisors at the moment)
We have done a bunch of testing and have narrowed it down to something about XCP the application does not like or something unique about how the VM appears when installed on XCP-ng compared to VMware.
The application is being installed on a Server 2022 OS.
We have tested with PV tools installed and without PV tools installed.
Looking for any possible ideas on what else we could try as possible fixes or what identifying what about the VM could be presenting different.
The application I am guessing is a unique one that I would not expect others to know. It is called RemitServer. It is a software that is used for processing checks and online deposits. I think the actual software package is called RemitPlus which is owned by a banking software company called Jack Henry.
Thanks
Hey guys,
Couldn't find anything on this and wondering if anyone has ran into it before.
We had a XOA deployed and setup on a trail license, let's just say trial@domain.com
The client purchased a license, but the purchased license was done under a different email address.
We cannot figure out how to change the registration email address on the XOA appliance to the correct one with the license.
Any ideas on this?
When it comes to the feature to disable time sync.
If you had previously installed a version of PV that did not have it, then install the newest version and enable the option to disable time sync.
Should that remove it or do you have uninstall the old version first and install the new version?
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
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