@ataxyanetwork hey, thanks for sharing this. I am new to the forum so maybe i am not looking in the right place. Your Blog seems to be offline, so did you link the Appliance here in the forum or is it only available on the blog thx

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

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

Thanks, @Jonathon !

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

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

Wonderful !

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

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

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

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.