@peo without deleting, the CBT can fail, but XO can still compute the changed blocks before previous release, the fallback was hidden if you didn't look at the size the CBT issue is on the hypervisor storage side . But at least , the replication issue is fixed, we are back to the good old issues

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

@lsouai-vates Great! Thanks for addressing this

AlmaLinux 8.10

so it seems like when i make the igpu pass through, i see the starting lines of xcp-ng but it never gets to the console screen. which is what i expect. When I add the pcie devices (igpu/hdmi audio) to a vm and start it up, I get and update to the screen and it shows a red number counting which is part of the console. So it seems that when the VM re-initializes the igpu, dom/xcp retakes it over. I confirmed that by using the keyboard to move around and it reshowing the console and filling the missing details as i move around. So why is the dom/xcp retaking the video device over again when it should be blocked from accessing it? [image: 1756568880819-img_3348.jpeg]

@Greg_E Ah, ok..yeah...guess I did Yep, agree. Really needs more functions...like networking (and elsewhere) ha

@utopianfish Mikrotik CRS304-4XG-IN or CRS312-4C+8XG-RM https://mikrotik.com/products/group/switches

looks good Xen Orchestra, commit 384bb Master, commit 384bb thanks for quick fix

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

@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

@Andrw0830 I am using paid version of ESXi / vSphere. The free version of ESXi has so many limitations that I consider it pretty much unusable / only usable for very limited basic tests. It would not suprise me if your issue is due to the license limitations within ESXi.

Partly, I will see when back from vacation Anyway, unrelated to XO

Thanks everyone for their help. I believe I have a way forward now.

Excellent news!

@AlbertK said in XCP-ng - XOA vs. XOCE: @Danp , Is it possible to add the comparison of the XOCE together wit XO in this page?. https://vates.tech/pricing-and-support/#features-matrix XOCE is a term that I came up with when I originally started writing the deployment script that exists today. It's stuck around. Vates uses the terms XOA and "XO from Sources" as their unique products. XOCE would be "you used a github script to deploy" (my github) XO. XO from Sources is a completely manual process where you're following the documentation to deploy XO. This approach gets you the same thing that XOCE does, but takes longer to complete since you're finishing each step over SSH rather than running a single bash command on a Ubuntu/Debian VM.

@Kptainflintt Hey! XO team dev is doing a fix on it: https://github.com/vatesfr/xen-orchestra/pull/8979 FYI @pdonias pdonias opened this pull request in vatesfr/xen-orchestra open fix(xo-server/resource-sets): only edit limits if `limits` is passed #8979

@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

@Greg_E thanks for the clarification.