@john.c Indeed, John, and I almost forgot that the backup network on each host was actually on a separate, isolated NIC, and not at all on the VLAN.

Wonderful !

@Emmanuel-V In my opinion, it would make more sense if a standalone disk exported in VMDK format were exported directly as monolithicSparse, so that it would not need to be converted. This makes more sense to me because when only the disk is exported, rather than the entire VM (OVA), it can be assumed that the disk will be attached directly to some VM.

@pierrebrunet Tested and working again, thanks

@johnnezero You can use the docs directly in /rest/v0/docs. You just have to connect and fill in the uuid you need. It will work

@stormi I am glad to hear there is progress, and I never doubted that there was interest and will from the Dev team, it was just stated, by Oliver himself, that the focus was mostly on the classic hypervisor features and that resources for edge cases were scarce. The numbers might not be spot on, but it was something similar.. Anyways I know you care and that the team always take interest in home-lab scenarios. And that, is why I keep recommending XCP-ng. You are good and motivated people, you care and interact with the community and you have a product that is simple in structure and free of most of the technical bureaucracy that the other ecosystems have. And yes, this particular Intel Arc issue, is not only on XCP-ng, The intel toolbox and drivers for this platform is currently a mess for Linux. And you are right to take home-labbers under your wing and prioritize it. As I'm sure you know, although it might not be of direct importance for revenue, they do have a huge impact on popularity. I dont think Proxmox would have had the traction it has, without them Thank you for replying, and thank you to the team for their hard work!

@lem2405 No problem. Let me know if you still encounter any issues.

@fohdeesha Hi all, I apologize that it's taken a while to get all the issues sorted, fixed and properly verified. I have pushed the corrected version up to my GitHub, and everything seems to be working much better (thanks to the efforts of everyone here)! A big shout out to all of you, as this is exactly how open source is supposed to work! Let me know if there are any other issues that arrise - and Happy Day to one and All!

Forwarded to the right team, thanks!

@coolsport00 Sorry about the VMW need for the Cisco product. Sounds like you have a number of constraints, finances being I'm sure one of them! At least you have time on your hands and the means to experiment. You may, als, end up with a number of different platforms to meet your needs. We ran both Sun Microsystems and Red Hat Linux and Microsoft Windows servers, each taking on specific duties. It's far from ideal and probably not very cost-effective, but you do what you have to to get stuff to work.

@FritzGerald Thanks! Running systemctl enable --now ups-driver.service got ups-driver.service going, then following the instructions you provided earlier got the rest of the two services running, even after a reboot. I'm now able to run upsc apc@localhost and get the correct output listing all the properties of the UPS even after a reboot.

@MathieuRA We reverted back to 6.8.2 for now. We can wait for patch, otherwise, I have opened a tunnel #38081.

Thanks a lot for your feeback, folks!

@dinhngtu i've manage to fixed it. Your build adds some extra entries in /var/lib/xcp/state.db that aren't in the version from testing, that broke things when i downgraded the packages. ipv4_dns VIF.ipv6_dns

@poddingue said: Thanks for posting the fix. The same thing came up in an older thread, https://xcp-ng.org/forum/topic/9957, where disabling IPv6 also made xoa check go green. @HamiltonWDS explained a likely reason in https://xcp-ng.org/forum/post/87831: Node tries the addresses with a short timeout and can end up on the IPv6 one. Your curl -6 test helps a lot here, because it shows IPv6 doesn't connect at all on that network, so it's more than a slow path. Turning it off in XOA seems reasonable if you don't use IPv6 there; if you do, I'd guess the router side is where it really needs fixing, though I could be wrong (still haven't migrated to IPv6 myself ). Curious whether it sorts out the Cloud Backup too. XOA is using our management network where ipv6 is not needed and not enabled. Looks like our cloud backup finally ran for the first time in while too.[image: cloudbackup.jpg]

@poddingue Turns out it is all secondary-to-secondary out of sync. So that makes it less intense, though if primary dies I wonder how it will resolve this, or if it will become split brained. Still unsure of how it happened, but the ones I manually cleaned up have not come back. Going to continue to manually clear them up. If it happens again I will have an alert setup to notify me, and I have all the xcp-ng logs and everything to be able to see what happened. If that happens I will post here with details and logs for the resource so we can see how it occurs. [image: image.jpeg]

@herhin2017 said: Yes, your wright! I know about that. As i mentioned, our machines are really working perfect (they can easily be a productive system) I am asking because our school does not have much money (in fact nothing) and i will go on with my lessons in hypervisors with xcp-ng. THANKS TO EVERYONE who works on this project - i like it!! P.S. If you need user tests in grater scale, we can do it (10 machines) and we have time. Welcome to the forums! To answer your question while expanding on @Poddingue's excellent point: it all comes down to the AlmaLinux base chosen for the dom0 control domain. While AlmaLinux 10 does offer an alternative x86_64-v2 compilation option for older processors, relying on a sub-baseline build for a modern hypervisor can limit your performance and future third-party repository support. To truly get the most out of XCP-ng 9.0 when it reaches stable release—and to avoid the hard limitations of the modern EFI and Secure Boot requirements—you will want to target at least generation 9 of HPE servers (Gen9) at a minimum. Since you are dealing with a tight school budget but need to acquire a large number of machines for your network engineering students, here are the most effective ways to source that volume: • Corporate Hardware Donations: Depending on your school's official legal status (such as Gemeinnützigkeit), you might be able to get these machines donated for free. Many large companies in Austria cycle out their enterprise hardware every few years and actively look to donate working Gen9 or Gen10 servers to schools for tax benefits or community goodwill. It is highly worth reaching out to local IT departments or tech companies! • Professionally Refurbished Bulk Batches: Sourcing former enterprise hardware in large, uniform batches is your next best path. Gen9 servers offer excellent performance for a very low price right now. Keeping the hardware identical also makes managing your pool templates significantly easier. • Academic Programs & Vates Discounts: If your rollout scales up and you eventually need official commercial backing, it is well worth reaching out directly to Vates. Let them know you are an educational institution; they are often very supportive of academia and may offer steep volume or academic purchasing discounts for schools. Good luck setting up the lab for your hypervisor lessons! P.S. A quick, friendly tip for your English writing: drop the "w" when you want to agree with someone. If you use "write", it sounds like the action of writing words down on paper (schreiben). To agree with someone, the correct phrases are "You're right" or "You are right" (Du hast recht / Sie haben recht).

@racom.jiristerba Sorry, I missed answering your questions the first time Is the tapdisk QCOW2 commit failure “The device is not writable: Permission denied” a known issue with these package versions on shared LVM/iSCSI storage? Yes, it's a known issue, most of them will be fixed with the latest update, you might need to activate the VDI again but a migration during RPU will be enough Why does rollback attempt to deactivate the active guest LV while tapdisk still holds it open? It's because in the case of VHD, it's the case but with QCOW2 we don't stop the tapdisk process accessing the VDI, it's a change that was missed Is the qcow2OLD_<UUID> naming seen in rollback expected, compared with QCOW2-OLD_<UUID> seen during successful cleanup? It's a pre-existing bug that I already have on my TODO list Is there a supported update, hotfix, or workaround for this configuration? Installing the latest release sm-3.2.12-25.1 during updates (and maybe launching a xe sr-scan uuid=<SR UUI> after updating it so it auto-resolve the undo) should be enough What additional logs are required to identify the original failure of the second QCOW2 VM? I don't think we need any more logs since the errors I'm seeing should already be fixed. If you have any more issues after installing the newest packages, I will take another look What is the recommended recovery procedure without a guest outage, and how should we validate the disk chains before resuming snapshot backups? The sr-scan after updating should do it automatically, it shouldn't need any manipulation. Looking at the storage logs in /var/log/SMlog for any irregularities could help to see problems.