If you want to test, you can switch to the relevant branch, which is fix_replication https://github.com/vatesfr/xen-orchestra/pull/8971 fbeauchamp opened this pull request in vatesfr/xen-orchestra open fix(backups): replication doiing always a full #8971

do you have a default backup network set on the advanced tab of the pool view ? the rrd go through this

@idar21 @idar21 said in Xen Orchestra 5.110 V2V not working: Don't intend to bump in but the new migration tool isn't working as per the release notes. I had similar issues, there is no warm migration. My testing against esxi v7, resulted in: .Abrupt power off of source VM on esxi. .VM disks start copying. I can see disk copy progress in tasks. .Migration tasks fails but multiple disks of the source VM keeps on copying. .when all the disks are copied, there is no VM with the name available in xcp. .All disks are labeled orphaned under health in xo. .Where is the pause/resume function as stated in the release notes. I don't think the tool has been tested properly. The only difference from older migration tool to this one is progress of disk copying. Otherwise nothing new. The old tool could only do cold migrations and had issues with vms with multiple disks. The new can also only do cold migrations and still has issues with multiple disks migrations. First, I would like to say again that latest can be fresh, and that we know that we ask for our users to be more inventive with latest, in exchange for faster features. Even more for users from source. The documentation is still in the work, and will be ready for sure before this reach "xoa stable". The resume part don't have a dedicated interface : you do a first migration without enabling the "stop source", and then, later you launch the same migration with stop source enabled ( or VM stopped ) and it will reuse the already transfered data if the prerequisites are validated. Then debugging an issue with migration is quite complex, since it's involve multiple systems, and we won't have any access, nor control on the vmware part. It's even harder without a tunnel. I will need you to look at your journalctl and check for errors during migration . Also are the failing disks sharing some specific configuration? what storage do they uses ? Is there something relevant on the xcp side ?

@nikade Yeah, that is a far from optimal setup. It will force the data to flow through the management interface before being routed to the storage NICs. Running iostat and xtop should show the load. A better configuration IMO would be putting the storage NICs on the switch and using a separate network or VLAN for the storage I/O traffic. Storage I/O optimization takes some time and effort. The type, number, and RAID configuration of your storage device as well as speed of your host CPUs, eize and type of memory, and configuration of your VMs (if NUMA aware, for example) all will play a role.

Meanwhile until I finish the RBD-native driver which is probably going to take much longer than I anticipated and is probably never going to have "ideal snapshot rollback mechanism", I also decided to create another driver called LVMoRBD which is essentially same as LVMoHBA - it builds LVM-SR on top of RBD block device and is meant to work without need for some complex hacks - https://github.com/benapetr/CephRBDSR/commit/fbde8b49b180d4de60ffea477dffe712f07a4d07 it's really rather a trivial wrapper, it's main benefits as described in the commit message are the ability to auto-mount the RBD image on reboot and to use its own LVM config that enables RBD devices (so no need to modify the default shipped with xcp-ng) and some other things that make creation of LVMSR on top of RBD far easier and natural. Again - it's not production ready yet, I will be doing many tests on it and probably still need to fix some SCSI related false-positive errors that sometimes appear in SM log. I estimate it will be ready much sooner than RBD-native driver. LVM on top of RBD is not ideal as there is some tiny overhead, but still probably better than CephFS when it comes to RAW performance (RBD really is something like LUN from HBA) And yes I do plan to create SMAPIv3 equivalents later when I learn how for now I am still targetting XCP-ng 8.2 as that's what I use in production, and I haven't seen many SMAPIv3 drivers there. 0 benapetr committed to benapetr/CephRBDSR new driver LVMoRBD This is a simple wrapper for LVM on RBD which is something I have experience with from the past - it's actually possible to do this using native LVMSR driver with few hacks - such as modifying the master/lvm.conf to work with RBD devices This SR driver is meant to streamline the access without any need for custom hacks. Its main benefits over using LVMSR: * It automatically maps and unmaps rbd devices for you on reboot * It uses some wrappers to suppress SCSI meta-calls that cause unnecessary false-positive warnings in SM log (rbd devices don't have SCSI ID) * It automatically creates RBD device for you with compatibility settings known to work fine with XCP-ng dom0 kernel * It uses its custom LVM config file, so you don't need to expose RBD LVM structure to hypervisor, or override the default config file

@tmk hi ! Many thanks, your modified python file did the trick, my static IP address is now working as intented. I can confirm this is working on Windows 2025 Server as well.

It's indeed pretty long. I would maybe use a local SR as suspend SR to check if it's very different, that could help to pinpoint the issue.

@TheMonkeyBrain Hi ! Let me find the link I had or reupload the file. I'll give it to you via DM ASAP If you need to uplaod the appliance, you need to replace sda to xvda on this two files: /opt/dell/omc/utilities/tui/bin/ome_disk_config.sh /opt/dell/mcsi/appliance/scripts/appliance_ressource.sh

Hi, Do you have any error message? What's happening? Anything visible or not?

@PaulDCL [image: 1757633451167-9eb17eb5-9a99-4743-9df5-51edcc2b1847-image.png] This benchmark was taken inside the Windows Server VM on that iSCSI device. The iSCSI host is a QNAP NAS with Toshiba 18 TB drives configured in RAID-6. I think this is a decent speed for non-flash storage. Both devices are on a 10Gbit network. If you need more specific details, I'll be happy to help.

@DustinB Yeah I thought about doing something like this, but then we are getting into overkill costs lol. My main point behind this post was to get info on what other people are doing, I presumed most are just relying on config backups and will restore it at the other site if needed, which is fine. I was just also debating about whether or not I wanted the subnets to match between these 2 sites, since that can create some routing headaches, but should still be doable and would make recovery even faster. @olivierlambert yeah I do use that feature, so that's very helpful! Should make this all doable.

Yes! That's a good guide for what you want to achieve

@yann said in New Rust Xen guest tools: @john.c OK, that will be useful when the repo is signed, but for now I don't see what adverse effect it can have. Do I miss something? Also we try to avoid breaking support for older OS versions, so we'll likely continue to advertise the old format for older versions of Debian. @yann From Debian 13.0.0 (code name Trixie) having repository signing is mandatory. Without it apt will straight refuse to install, update or upgrade its packages. Also doing with deb822 format will help to protect the GPG Key, used by Vates from abuse by another repository. Especially if that repository is hosting malware laden deb packages. As only the Vates repository can then use that signing key, as defined in the sources file. Refusing to install, update or upgrade is an adverse effect wouldn’t you say?

@AtaxyaNetwork said in Unbootable VHD backups: @Schmidty86 Try to detach the disk and reattach, it should be xvda in order to be bootable That's what I was thinking as well, but obviously something is off with this VM. @Schmidty86 is the old host still online? If so you might be able to perform a Live Migration or a replication job to copy it from the old host to the new.

I had this tab still open which lets me realize that despite we packaged vmfs6-tools and updated the documentation at https://docs.xcp-ng.org/installation/migrate-to-xcp-ng/#local-migration-same-host, we didn't inform you here. Now it's done

@lsouai-vates we should try to reproduce and if we can, to fix it ASAP. Thanks!

AlmaLinux 8.10