@TestForEcho No ETA for now. Even before supporting QCOW2 on LINSTOR, we have several points to robustify (HA performance, potential race conditions, etc.). Regarding other important points: Supporting volumes larger than 2TB has significant impacts on synchronization, RAM usage, coalesce, etc. We need to find a way to cope with these changes. The coalesce algorithm should be changed to no longer depend on the write speed to the SR in order to prevent potential coalesce interruptions; this is even more crucial for LINSTOR. The coalesce behavior is not exactly the same for QCOW2, and we believe that currently this could negatively impact the API impl in the case of LINSTOR. In short: QCOW2 has led to changes that require a long-term investment in several topics before even considering supporting this format on XOSTOR.

@bogikornel said in Cannot migrate a vmdisk: @ashinobi Known issue ... https://xcp-ng.org/forum/topic/11538/failed-to-migrate-vdi-two-local-sr/5?_=1763186433370 Thank you so much for letting me know. I'll follow your post so I can update that if they need more info on what is happening.

@Danp My apologies for not being more specific. I’m encountering an issue with XOA deployment on a home lab environment. Environment Details: Installation source: USB Hardware: 16GB RAM, 1TB NVMe HDD Initial install: Completes successfully Dashboard: Displays expected status Steps Taken: Installed XCP-NG from USB — installation and setup completed without errors. Verified dashboard — all components appeared healthy. Deployed XOA to the existing HDD — process executed as expected. Observed Behavior: After deployment, XOA appears healthy overall, but the final item labeled “NEW” does not appear in the interface. Expected Behavior: The “NEW” item should be visible after deployment. Mark

@olivierlambert Yes I previously was. now back on VHD. This was in my home lab, not work enviorment.

@Chico008 I think it's not a bug, it's a feature.

Ping @Team-Documentation-Knowledge-Management

Hi @jshiells, After some tests, I don't think it can be caused by the load balancer. If the load balancer tries to migrate a VM that is being backed up, the migration instantly fails and nothing happens. Reversely, if a backup job starts when a VM is being migrated by the load balancer, the backup will fail for that VM with error "cannot backup a VM currently being migrated".

I think it's planned for XO 6 adding @gregoire in the loop

@florent Sorry for the late reply, yes, we had previously tried that setting and found that it did not provide any speed increase in our case. One thing to note is that we do have our backup jobs configured to merge backups synchronously, we're starting to test some of our jobs with that setting disabled. We had originally turned it on because we experienced a lot of backup failures due to locking errors. We've since added additional proxies as we've found that the amount of data that a single proxy can backup in a nightly window was the primary bottleneck in our environment. Since adding the additional proxies we've started disabling the synchronous backup merge for several of our jobs and so far it has been working pretty well and our backup times have been running faster (obviously since the final merge was the vast majority of the time that we observed in our backup steps).

Starting from Other install media with BIOS (not uefi) is the only combo that is working with Terraform

xe pool-enable-tls-verification Was exactly what I needed, thanks! Worked after that.

@Joe_dev I have a MF unit with similar igpu. I was not able to get it working under any virtualization platform. There is something about amd igpu that makes passing it hard. I believe some have had it working under proxmox with custom kernel and video bios. I never bothered trying all that out so i just gave up on the unit.

Maybe that's my issue ? Investing this part # journalctl -k | grep -i nvidia [image: 1763219509282-aaed86b6-1384-434e-ac5d-bca510405f33-image.png]

Small warning: XenTools are still a clusterfuck. On (allmost) all machines without our main environment it keeps the ip-configuration within the Realtek emulated NIC and never transfers it to the Xen device. It's fucked for long now - but doesn't matter if all VMs are getting their IPs via DHCP. Currently struggling with: Windows Server 2016 + XenTools/Management 9.4.2. At least it didn't break the whole VM by destroying the disk device drivers this round. tl;dr: Snapshot your VMs and have a documentation at hand, when upgrading the tools/drivers.

Hello, Thanks for your work ! We have some hypervisors of tests at Gladhost, we can use them with pleasure to test your work on xcp-ng 8.3 ! Best regards