@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

@Andrew

Thank you Andrew

Such a noob here when it comes to XCP, learning as we go.
I couldn't find any guide out there for configuration of CR so was shooting from the hp on how it worked.

You were correct that NBD Connection was not setup on the Pool network.

Since you seem to be an expert in this CR field. Mind if I ask a question.
For the Full backup interval what do you typically set this to?
In our case we have around 4TB of data (Approx 25VMs) we are going to have on CR over a 1Gbps link between locations, so we can't be doing full copies to often.

@kraken89
Sorry, didn't mean to hijack your post

@Andrew

But at the bottom it has Type: Delta
Which I took as running a delta?

Yes, I have NBD enabled. Should I try disabling it?
Here a side-by-side comparison.

I do see the message at the top saying "backup fell back to a full"
Does this imply that the delta function didn't work, and it is truly a full again?

I thought I was having a similar issue but mine might be slightly different.

This is the first time I am trying to configure CR so it's very possible I am not setting things correctly. I have two separate pools currently.

When I run the replication job, it shows type: Delta
However, the size is the full size the VM each time which is 200GB.

Since it is a delta shouldn't the size just be showing the change data?

The two pools are physically at different sites, so the throughput is not optimal, but i never expected a delta run to take 8 hours. the full took the same 8 hours.

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?

@TeddyAstie

Attached is the output you requested

xen-cpuid -p.txt

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

@Pilow said:

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