@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
We have been doing a fair bit of testing on our side with this client, and we have discovered it appears to be an ISP issue of some kind.
What we are finding is utilizing iperf utility a single TCP stream appears to be capping out around 40Mbps on a 1Gbps fiber circuit.
In iperf if we run multiple streams, each stream will be right around 40Mbps, so 4 streams we will get around 160Mbps throughput to our DR location.
Testing on the clients' secondary providers fiber circuit we run just fine.
Little outside of XCP-ng and XOA here and battling that out with our ISP 
But that does lead me to a general question about replication.
Is the data mover process a single TCP stream per disk?
If so, is there any way to do a multi stream per disk?
Thanks
When speaking to our Veeam sources, we were told end of July is the target date for 13.1. That is what we are hoping for as Veeam is an important one for us.
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
We have been doing a fair bit of testing on our side with this client, and we have discovered it appears to be an ISP issue of some kind.
What we are finding is utilizing iperf utility a single TCP stream appears to be capping out around 40Mbps on a 1Gbps fiber circuit.
In iperf if we run multiple streams, each stream will be right around 40Mbps, so 4 streams we will get around 160Mbps throughput to our DR location.
Testing on the clients' secondary providers fiber circuit we run just fine.
Little outside of XCP-ng and XOA here and battling that out with our ISP
But that does lead me to a general question about replication.
Is the data mover process a single TCP stream per disk?
If so, is there any way to do a multi stream per disk?
Thanks
Looking for some feedback from the community on performance around continuous replication and what the expected speeds should be.
The two environments I am testing on both have SSD storage on the source and target side.
We have is two local hosts, and an offsite host for "DR".
The sites are VPN tunnel with 1Gbps fiber internet at both sites.
We are constantly seeing 30-50Mbps speeds transfer speeds.
Far below the capacity of the link between sites.
We have checked the resource consumption on XOA and everything seems good.
Are these speeds we should be expecting to see and if not any ideas on possible bottle necks? We don't really have a good base line to compare against on what we should be expecting.
Thanks
When speaking to our Veeam sources, we were told end of July is the target date for 13.1. That is what we are hoping for as Veeam is an important one for us.
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.
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!!
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
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?
