@Andrew @peo are you using purge snapshot data ? In both case, can you try disabling it and disabling CBT on the relevant VMs ?

@cgasser are the backup job running normally (if any ) ? can you disable temporary the backup network ? the rrd stats should be visible immediately afte if this is the root cause

Alright I finally got it to work. I think the trick was to put "Ethernet 2" in quotations. I also perfected the YAML spacing and bracketed the two nameserver addresses. Thanks for the help gentlemen. Final working network config: #network: version: 2 ethernets: "Ethernet 2": dhcp4: false addresses: - 192.168.1.30/24 gateway4: 192.168.1.1 nameservers: addresses: [192.168.1.5, 8.8.8.8]

@tjkreidl I think the issue is that he's got no 10G switch, hence the direct connection But you live and you learn, best would be to pick up a cheap 10G switch and make it right!

@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.

@edisoninfo Great! This warning is a life saver and did perfectly its job, allowing you to discover a hidden issue Glad you found the root cause!

Hmm could the module causing the crash if the device isn't accessible? @TeddyAstie any opinion?

@Cygace Someone from the community may jump in and help troubleshoot this. The best approach would be to not modify the Dom0 installation by installing Zabbix via a community post, as you're customizing the installation. The vates team and XCP-ng specifically need to include these packages to ensure you're able to get support. Best of luck

That's because you are using DMC (dynamic memory control). Try on a VM with static == dynamic.

@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 ?

@benapetr This is driven by hacky logic from 16 years ago: on revert, unserialize the previous state, and update the VM record with its saved values. As we do not want to modify that each time we add a field in the datamodel, use some low-level database functions to iterate over the fields of a record. Not very nice as it makes some assumptions on the database layer, but seems to work allright and I don't think that database layer will change a lot in the future. I think it might be a good idea to add a revert rpc call to the storage interface that xapi can call to, with a backup to use the current logic if necessary; xapi should be able to clean up the database afterwards. I'll ask other maintainers about this or possible alternatives, but since SMAPIv1 is considered deprecated, I doubt it will happen. I have to say that SMAPIv3 was finally fixed upstream on June by Xenserver (migrations were finally done!) and XCP-ng should get the update that fixes it in the coming weeks. Given this, I would encourage you to take all the learnings you've acquired while doing the driver and porting it to SMAPIv3. SMAPIv1 just simply has too many problems, some of them are architectural, so in general xenserver and xcp-ng maintainers would like to see it finally go away. 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. 8.2 is out of support for xenserver, and for xcp-ng yesterday was the last day it was supported, you really should update

What about the browser console?

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

@Pilow did you try tcp?

@Berrick Ah cool, I was anticipating that doing it live would've caused boot issues but I think I've just got a bug in my head about how it actually works, I'm conflating two separate things based on an incorrect interpretation of a previous experience I had once with XCP. Thanks!

@abudef Got it, the agent was not changed since the last version so the build number was not bumped. I'll keep that in mind for the next release.

@olivierlambert I am asking XO Team about this issue.

@AtaxyaNetwork Did try to change those files and add the missing drivers, but couldn't get it to work with plugins. I think I will just have a look at you image when I have it and see what I am missing

@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.