We have submitted an official support request: Ticket#7758084

The symptom continues to be that it appears the 2+ TB volume fully transfers, but the system disk which is 90GB fails almost immediately.

@Team-Storage

Did you guys have any feedback on this one?
On our side we have tried a handful different forum items we have found, but we have not found anything that appears to work.

Each time we run the V2V migration, the larger qcow2 disk appears to fully transfer but the smaller vhd file does not.

Hey guys,

With qcow support hot off the press we are attempted a V2V with a 2+ TB volume.

The system that we are testing with the system disk is less than 2TB in size and it is showing up as vhd and the data volume is greater than 2TB so it shows qcow

The issue that we are running into is the system volume never transfers any data from what we can tell. Is there any known issues around importing VMs when the disks are different sizes causing one to be vhd and the other qcow?

Looking in the xensource log file we see this which might be a clue as to the issue.

[debug||641 /var/lib/xcp/xapi|VBD.create R:4257b476bd74|vbdops] Checking whether there's a migrate in progress...
[error||628 HTTPS 10.1.1.203->:::80|Importing raw VDI R:b2be45fe8be8|vhd_tool_wrapper] vhd-tool failed, returning VDI_IO_ERROR
[error||628 HTTPS 10.1.1.203->:::80|Importing raw VDI R:b2be45fe8be8|vhd_tool_wrapper] vhd-tool output: vhd-tool: Non-zero size required (either a pre-existing destination file or specified via --destination-size on the command line)\x0A
[error||628 HTTPS 10.1.1.203->:::80|Importing raw VDI R:b2be45fe8be8|import] Caught exception: VDI_IO_ERROR: [ Device I/O errors ]
[error||628 :::80|VDI.import D:476cc7b7bc5e|backtrace] Importing raw VDI R:b2be45fe8be8 failed with exception Server_error(VDI_IO_ERROR, [ Device I/O errors ])
[error||628 :::80|VDI.import D:476cc7b7bc5e|backtrace] Raised Server_error(VDI_IO_ERROR, [ Device I/O errors ])

Hey guys,

Looking for some help at understanding auto power on as the documentation possibly looks to need some refreshing.
https://docs.xcp-ng.org/guides/autostart-vm/

From the Xen Orchestra, the guide does not mention the pool level it is only under the CLI that it mentions the pool level.

Just looking for some clarification.

In order for auto power on to function, we need to enable it on the pool level, and then per VM correct?

If you have auto power on enabled at the VM level and the pool level disabled, the VM level is ignored, correct?

What is actually triggering the power on?
Is it XOA or the host itself?
I am assuming the host itself, just looking for clarification if XOA VM was part of the systems that went offline, should we expect to see it auto power back on if it is set to auto power on.

What determines the start order for auto power on when you have multiple VMs on a host?

Thank you!!

@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

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