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

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

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

@johnnezero Hi, Sorry, it seems it is only in Rest API for now: You can check it here: <xoa-url>/rest/v0/docs/#/backup-repositories/ReclaimSpaceBackupRepository

@acebmxer said: @john.c We currently dont use ipv6 internally. No network changes were made at this location other then moving the proxy to the correct network for nbd connections. With that move some how made the ipv6 issue appear. So it was just easy to disable ipv6 in the proxy. I guess if we ever switch to ipv6 (no plans too) then i guess i will have to look back into it. If any of your VMs are facing the public internet, completing your IPv6 Readiness compliance is vital. With regional internet registries completely exhausted of free-pool IPv4 space, modern endpoints and cloud architectures are increasingly deploying IPv6-only infrastructure. If you are referring to an internet access proxy, disabling IPv6 introduces significant architectural risk. If any upstream transit provider, carrier, or edge CDN in the path to your target FQDN transitions to an IPv6-only topology, your access path will break, causing a hard outage. If you are specifically utilizing a transit provider like XO Proxy, transitioning to dual-stack or IPv6-only transport is even more critical to ensure deterministic routing across the wider internet footprint. From an architecture and security standpoint, IPv6 introduces critical enterprise enhancements: • SLAAC Privacy Extensions: Enables temporary, rotating addresses to mitigate device fingerprinting and endpoint tracking. • Native IPSec Integration: While RFC 8200 technically shifted IPSec from a hard protocol requirement to an optional component, it remains a native architectural element of the IPv6 stack. Unlike IPv4—where IPSec must be bolted on as an awkward overlay—IPv6 accommodates encryption headers natively, simplifying the deployment of secure end-to-end transport encryption across enterprise and government domains. If you need to pitch this network-wide transition to leadership for project approval, I highly recommend framing it around business continuity and risk mitigation. Pointing out the looming vulnerability of upstream IPv6-only transit paths—combined with the compliance advantages of native architectural security—should give you the exact leverage needed to get this budgeted, planned, and implemented.

@dinhngtu No i did not. Right now I'm running as is...seems to work fine.

@Kajetan321 I looked into my server and I think I forget some points. First and foremost I have to say, modifying the systemd files can make you system unbootable! It should not happen, but there is chance since we are also modifying some "natively shipped files". So an update can break your working configuration again and that is not the fault of XCP-NG!!! That said I assume that after a reboot (prior to any of any input of yours) if you enter: systemctl status ups-driver.service nut-server.service nut-monitor.service you will see that "ups-driver.service" is loaded and active, but the 2 other services are not. If thats the case I think I can help you since it is related to a dependency problem during boot up. Please do the following: Remove "nut-driver.target" dependency from "nut-server.service" by calling nano /lib/systemd/system/nut-server.service and remove nut-driver.target from routine. I prefer to duplicate and comment the to be modified rows to keep the original code. It then should look like this. DO NOT COPY AND PASTE, read, compare and modify carefully! [Unit] Description=Network UPS Tools - power devices information server #After=local-fs.target network.target nut-driver.target After=local-fs.target network.target # We don't Require drivers to be successfully started! This would be # a change of behavior compared to init SysV, and could prevent from # accessing successfully started, at least to audit a system. #Wants=nut-driver.target Wants= # The `upsd` is a networked service (even if bound to a `localhost`) # so it requires that the OS has some notion of networking already. # Extending the unit does not require *this* file to be edited, you # can instead drop in an additional piece of configuration, e.g. add # a `/etc/systemd/system/nut-server.service.d/network.conf` with: # [Unit] # Requires=network-online.target # After=network-online.target Requires=network.target Before=nut-monitor.service PartOf=nut.target [Service] EnvironmentFile=-/etc/ups/nut.conf SyslogIdentifier=%N # Note: foreground mode by default skips writing a PID file (and # needs Type=simple); can use "-FF" here to create one anyway: ExecStart=/usr/sbin/upsd -F ExecReload=/usr/sbin/upsd -c reload -P $MAINPID [Install] WantedBy=nut.target Afterwards enable nut.target: systemctl enable nut.target Then call: systemctl daemon-reload systemctl start nut.target systemctl start nut-monitor.service Now it should work even after reboot

I didn't know, so I went and looked at the code. XO prunes that list in a cleanup step: backup runs are kept for 31 days, and other tasks are kept by count, the newest 1000 (https://github.com/vatesfr/xen-orchestra/blob/b59c8f3d20954aa1d72e92c1e8f2db635d74fcba/@xen-orchestra/mixins/Tasks.mjs#L119-L127). You can change both with tasks.gc.keep and tasks.gc.backupKeepDuration in the xo-server config. As far as I can tell the cleanup runs when xo-server starts, not on a timer, so a long-running XO can collect quite a few before the next restart. My guess for the Cloud Backup entries @acebmxer still sees after 30 days is that they're kept by count rather than by age.

@poddingue Our HA-pool is a 3 host system, yes. I'll add a note about our plans to go paid in that feedback-item. Thanks for the tip. In the meantime, I'm testing and reporting as much as I can. In order to hopefully help the product be better for all. Cheers!

@poddingue Thanks for taking a look. Yes it is this part that tells me that it should start the VM automatically once the import has completed. "After the transfer, the VM on XCP-ng side is started:" Followed by, "This process is fully automated, without any human intervention after it starts on step 1." [image: image.jpeg] https://docs.xcp-ng.org/installation/migrate-to-xcp-ng/ But my findings/experience is that the VM does not start once the import/transfer has completed. So either the docs are wrong. Or the function is not behaving as intended. I'm acctually fine either way. As long as I know what to expect. However, I would like to have it auto-start the VMs after transfer completion. Which would make the procedure "Fully automated". Update: Am I assuming correctly that "the XO V2V guide says to start the VM yourself once the migration is complete " you're reffering to, is part of the "test migration"-procedure? Not the acctual production mgiration? Because: "Final migration Run the production migration When you're ready for the final migration: Shut down the source VM completely. Start the V2V migration in Xen Orchestra with the Stop source option enabled. This ensures the final sync happens while the VM is powered off, and prevents any inconsistencies." In my mind doesn't state that the VM should be started manually post-transfer. Great thanks in advance for discussing! Cheers!

@mpiton Thanks for a fantasticly quick answer, and detailed as well. I will test this immediately!

I tried it on a lab host (XCP-ng 8.3, xapi 26.1.16): calling VM.pool_migrate on a halted VM gives me your error, VM_BAD_POWER_STATE with running, halted, so the two values are the state XAPI wanted and the one it found. On the XO side, a migration inside the same pool with no SR or network mapping goes straight to VM.pool_migrate without checking the power state first: https://github.com/vatesfr/xen-orchestra/blob/b59c8f3d20954aa1d72e92c1e8f2db635d74fcba/packages/xo-server/src/xapi/index.mjs#L942-L981. So a stopped VM in that batch would give this, which fits what you remember. I haven't tried the batch migrate from the UI itself though, so I don't know if the UI is supposed to filter halted VMs out before that. It's a good concrete example for the feedback post anyway, XO could just say "this VM is halted" instead of passing XAPI's raw code through.

A short label on that step would've saved you the ghost hunt, yes. Since it's a UI change more than a bug, I think https://feedback.vates.tech is where it'd get picked up, ideally with your two screenshots showing "All (8)" against seven VMs.

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

The update candidates posted yesterday on the 8.3 testing thread might help here: https://xcp-ng.org/forum/post/108803. One of the sm fixes in that batch reads "a failed live leaf coalesce of a QCOW2 image on a slave host caused the SRs to remain in an SR_FAILURE_1200 error state until the VM using the VDI was stopped or tapdisk was manually paused", and to me (could be wrong, though), that looks a lot like your second case. You're also on the versions it replaces (sm 23.5 and blktap 9.5, going to 25.1 and 11.1). I'm less sure about the qcow2_commit: The device is not writable error from the first VM. The blktap notes mention reworking the pause/commit code, but I can't tell if that's the same path. If you have a test pool, trying the candidates there would tell a lot.

@trelane Hello, the bug affects Xen drivers of any 9.0 series (considering the upstream code, it goes back to circa September 2019). 9.2.385 contains the fix, which was merged upstream just this month. The bug also impacts network connections, however to a lesser extent due to its nature. I believe that the bug is also present in XenServer VM Tools 9.6.0 and by extension, older versions of it. We recommend that you switch to the XCP-ng tools whenever possible, also due to its other benefits (fully open source, validated for XCP-ng and optimized for Xen Orchestra).

@ronan-a For testing purposes, I did the following: I created a VM on the local SR of a host, installed Linux on it, and configured an ISCSI target. I then added that ISCSI target as an ISCSI SR within xcp-ng pool, and created a small VM on that repository, using XO. While the machine was running, I performed a migration without losing a single ping.I assume this confirms my previous assertion regarding the use of a standard storage system.

I wasn't even aware about this being a Windows limitation by itself

@anthoineb, Thanks for the fix! We plan to install blktap-3.55.5-11.1.xcpng8.3 on all three hypervisors tomorrow. We will fully shut down and start the data VMs one at a time, then verify that all running tapdisk processes use the updated binary. As the stalls are intermittent, we will monitor for recurrence and report back with the results.