If you want to test the pending fix, you need to deploy a separate instance of XO from sources. Otherwise, just wait for it to be officially released in XOA.
@Danp
No, I am not familiar with many of the "manual" commands. I have to figure out how to use that with LVM over iSCSI.
Meanwhile, I stopped the VM, did a SR scan and it coalesced successfully. Offline always works fine....
XAPI doesn't tell us if the transfer is complete or just cut. We just stop to receive chunks, and after a bit, we decide that's it, there's no more data to send (that's the normal behavior even when it works!)
XVAs are hard to validate, depending on various factors. We do a VHD validation (so for delta backup) but XVAs are another thing
On the remote side, right? It won't be "dedup" if it's your question 🙂 (for now at least).
We are thinking on a smart way to dedup it efficiently 🙂 It's not trivial because we don't have a lot of control on the host itself, but we might find solutions.
@nraynaud well i just used the datastore browser to download the vmdk. i did the same thing with some other (smaller) VMs without any problems. All of this from the same ESXi host.
Thanks for looking into it though, i will try the export VM way next but have to find the right time for a shutdown ...
We use a VHD chain on destination so it's equivalent to get "snapshots" of a VM 🙂 So it's delta everywhere with the same full parent for the same original VM.
@slynch OK, that's very good news then! Debian was still having issues where any configuration applied via cloud-init would just be added to the existing default DHCP config, unless you took care to build the VM without the default interfaces config beforehand.
IOMMU should be enable in the BIOS. Double check that 🙂
Also please share your grub config to see if it's correctly written.
After playing with it more, the issue appears to be passing multiple devices of the same type. In this case RADEON WX7100. If I take it down to one card it works as expected. If I add more than 1, pick any quantity, then I run into the issue.
The issue goes away once I reboot the host, and then I can assign a card, but the second the VM reboots the error comes back
This can happen from time to time on master (despite we do every "broken" code in dedicated branches), sometimes you can have a surprise.
That's why it's important, before anything, to get the latest commit and rebuild, to see if the issue persist. If it's the case, then reporting the problem will be helpful 🙂
The best way would be to use XO Proxies as "Reverse HTTP proxies" (or any reverse proxy in each DC) and then tell XO to connect to those proxies.
This way, each DC will have only one entry point exposed to the outside, and you could manage that with your central XO.
This is a subject we planned to work in the next months. If you have a support subscription, please open a ticket so we can do initial test inside your infrastructure 🙂