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