@JorisK said: fix/update-transfer-size-calculation Confirming that the branch fixes it

@carloum70 If you are willing to try this, you can reset the primary management interface (PMI) on a bond, WIthin the bash shell: : xe pif-list This will show the PIFs and their current network associations. Identify the bond master PIF If you have a bonded network, the master PIF is the one that represents the bond. You can list it with: xe pif-list network-uuid=<bond-uuid> The master PIF is the one that will be used as the primary interface for the bond. Reset the management interface to the bond master Use the xe-reset-networking command with the --reset-primary option: xe-reset-networking --reset-primary This will move the management interface to the bond master PIF, which is the correct way to reassign it when the bond is created or reconfigured.

Got a response Yes, sorry, this was not properly pointed out in the release message. This comes from using https://github.com/piraeusdatastore/linstor-csi/releases/tag/v1.13.0 So you can still use the new operator, but you have to downgrade the LINSTOR CSI version until you upgrade the cluster. So doing that for now with the following helm values --- operator: resources: requests: cpu: 250m memory: 500Mi limits: memory: 1Gi installCRDs: true imageConfigOverride: - base: quay.io/piraeusdatastore components: linstor-satellite: image: piraeus-server tag: v1.33.1 linstor-csi: image: piraeus-csi tag: v1.12.0 tls: certManagerIssuerRef: name: pp-step-issuer kind: StepClusterIssuer group: certmanager.step.sm

@jerry1333 @poddingue First of all, XO and XCP-ng are running very well on all hosts and VMs, and I am using XO-5 without any issues. I have been noticing the same exact issue jerry1333 had, or may still have, with an annoying message that appears just after 30 seconds of connecting to the Xen Orchestra version 6 initial home screen with a Chrome browser (version 153) on my Windows 11 PC. In the past, the error message at the top of the window used to cycle on and off, over and over every 30 seconds. Now, if I don't click on "Retry", the "Unable to connect" message remains indefinitely. Xen Orchestra is up to date: Master, commit fc571 [image: image.jpeg] I consider this to be a mere annoyance, but if I am the only one experiencing this, perhaps someone can give me a suggestion on where to look for a solution. Thank you.

hmm primary, xen02 [13:30 ovbh-pprod-xen02 ~]# drbdsetup status xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 --verbose --statistics xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 node-id:1 role:Primary suspended:no force-io-failures:no write-ordering:flush volume:0 minor:1013 disk:UpToDate backing_dev:/dev/linstor_group/xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1_00000 quorum:yes open:yes size:315195168 read:233813750 written:1173974506 al-writes:758189 bm-writes:361 upper-pending:0 lower-pending:0 al-suspended:no blocked:no ovbh-pprod-xen01 node-id:0 connection:Connected role:Secondary tls:no congested:no ap-in-flight:0 rs-in-flight:0 volume:0 replication:Established peer-disk:UpToDate resync-suspended:no received:0 sent:1173974894 out-of-sync:0 pending:1 unacked:0 ovbh-pprod-xen05 node-id:2 connection:Connected role:Secondary tls:no congested:no ap-in-flight:0 rs-in-flight:0 volume:0 replication:Established peer-disk:UpToDate resync-suspended:no received:0 sent:1146927724 out-of-sync:0 pending:1 unacked:0 xen01 [13:31 ovbh-pprod-xen01 ~]# drbdsetup status xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 --verbose --statistics xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 node-id:0 role:Secondary suspended:no force-io-failures:no write-ordering:flush volume:0 minor:1013 disk:UpToDate backing_dev:/dev/linstor_group/xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1_00000 quorum:yes open:no size:315195168 read:1242 written:1181073258 al-writes:819172 bm-writes:349703 upper-pending:0 lower-pending:0 al-suspended:no blocked:no ovbh-pprod-xen02 node-id:1 connection:Connected role:Primary tls:no congested:no ap-in-flight:0 rs-in-flight:0 volume:0 replication:Established peer-disk:UpToDate resync-suspended:no received:1174048714 sent:0 out-of-sync:0 pending:0 unacked:0 ovbh-pprod-xen05 node-id:2 connection:Connected role:Secondary tls:no congested:no ap-in-flight:0 rs-in-flight:0 volume:0 replication:Established peer-disk:UpToDate resync-suspended:no received:0 sent:0 out-of-sync:111291800 pending:0 unacked:0

I ran into the same problem with DR replicas. Ignoring VMs by tag would solve the problem, but so would excluding the ip address information.

@samuelolavo Hello, Could the fact that this is a local LVM SR on a non-master host be relevant to how make_chain_rw is being handled? Yes, it's indeed what's happening. The check for the SRMaster (for a shared SR it's the master but for a local it's supposed to be done on the host directly) is failing and always saying False. I'll fix this. Thank you for the help

@JamesG, Yea i ended up having to go with a bare metal ubuntu install + docker containers for everything and have been off to the races, I would still like a hypervisor but unfortunately had to move on. The software stack on these intel's gpus is still maturing but i'm running some pretty impressive models on them and for the money it has been a good investment, hopefully these will gain some popularity and get better support all around. GPU hosting definitely deserves some attention from xcpng. I would buy some licenses for some production use cases but things like this and nested virtualization (completely unrelated but also something i ran into this past week) needs attention.

Just recieved another update from veeam... Regarding the general earlier errors: Warning : Failed to use CBT: [Task e75c4247-2ee1-7b51-088c-b970ace60f3d (Async.VDI.list_changed_blocks) failed: . SR_BACKEND_FAILURE_460. . Failed to calculate changed blocks for given VDIs. [opterr=Source and target VDI are unrelated] Our QA team did hear back from Vates support, who says its tied to a recent bug they've found with blktap calls: https://github.com/xapi-project/blktap/pull/444 Our QA engineer hasn't heard back yet on ETA when it will be pushed out in a general release yet though

@poddingue Thank you!!!

@poddingue This was fixed a number of weeks ago via a ticket. I believe @florent may know the exact fix.

You already spotted this over on 12468, so this is just to close the loop here. That one's fixed: Pierre Brunet put the fix on a branch, @Andrew and @abudef both tested it, and it's merged now. Since you're running from source on master, you should be able to pull past that merge rather than wait for a release. One thing to keep in mind, though: the same error string showed up in 11875 for a completely different cause, so if it comes back after you update, it's probably not this bug again. I'd let 12468 be the thread to follow since that's where the people who fixed it are.

You're not blind, and your fingerprint is right. I pulled packer-plugin-xenserver_v0.11.4_SHA256SUMS.sig off the GitHub release and ran gpg --list-packets on it, and it reports issuer fpr v4 0DD2E92A7A0F682BC29F87073084D82948625D89, which is exactly what you pasted. It doesn't match the XCP-ng key because it isn't ours. The plugin our docs point at is ddelnano/packer-plugin-xenserver, maintained outside Vates, so it's signed with the maintainer's key while 34AC2EB6... only signs XCP-ng RPMs. I couldn't find that key published anywhere either. It's not on keys.openpgp.org or keyserver.ubuntu.com, it isn't in the repo, and it isn't among the 11 keys at github.com/ddelnano.gpg. That looks like something worth raising on the plugin's own issue tracker, and you'd file it better than I would since you're the one trying to verify a download. I'd also say our IaC docs could stand to mention the plugin isn't ours, which is what sent you looking at the wrong key in the first place.

Thanks for doing that, @john.c. The sponsorship side isn't mine to speak to; I forwarded to the right person The CFP I can say something about: nor(DEV):con is already in the conference pipeline I keep an eye on, and their Sessionize call closes on 30 September, so your timing is better than you probably realised. I can't promise you'll see us in Norwich, but the nudge landed in front of the right people.

Forwarded to the right team, thanks!

Small update — I split the custom plugins out of this project into their own repo, for anyone who just wants the plugins without pulling in the whole install script: https://github.com/acebmxer/xo-plugins Same deal as always — use at your own risk, review the code before running it on anything that matters. The two plugins in there are also still shipped inside this install script's Custom Plugins menu, kept in sync automatically — this repo just exists for people who don't want the rest of the project. xo-server-nanokvm This one's probably the more useful of the two for a lot of people. If you've got a host with no iLO/DRAC/IPMI — most consumer/prosumer boards, a lot of homelab gear — and you've wired up a Sipeed NanoKVM to the power header, this plugin lets Xen Orchestra power that host back on through the NanoKVM's own API. Same interface the NanoKVM web UI itself uses to press the button, just done from XO. On its own it doesn't decide when to turn a host on, it just gives XO a way to do it. Pairs with the other plugin below for that, or you could call it from your own automation if you wanted. Worth knowing: it can only press the button, it has no way to know if the host is actually on or off, so it only handles power-on. Powering off goes through XO's normal shutdown, which is a clean OS shutdown and evacuates VMs first — no reason to route that through the NanoKVM. Setup is a config entry per host: label, the NanoKVM's URL, a login, and which XO host it's wired to. Recommend making it a dedicated user-role account on the NanoKVM rather than admin — that role already has power/reset access without giving the plugin anything to storage/network settings on the KVM itself. xo-server-host-power-manager This is the one that actually decides when to act. Point it at an "extra" host in the pool and give it CPU and/or memory thresholds — when the rest of the pool is under pressure it powers that host on, and once things calm down for a while it powers it back off. Power-on can go through XO's built-in methods or through the NanoKVM plugin above, your choice per rule. Powering off always goes through XO's own host shutdown — it evacuates the running VMs first, and if HA is on and doesn't have room to cover it, XAPI just refuses and the plugin backs off and tries again later rather than forcing anything. It's deliberately quick to scale up and slow to scale down (needs both CPU and memory comfortable for a full cooldown period before it'll power a host off) so it's not flapping a host on and off over a short spike. Both have a Test button in their config page that actually tells you something useful, unlike XO's own generic "test plugin" popup — check journalctl -u xo-server right after clicking it to see what it found. As always, happy to hear feedback or find out I've broken something.

Have there been any updates to this? I'm haven't seen any activity here for a while.