@jubin3 As this is totally unrelated to XOA and XCP-ng, you'll (hopefully) get a better response in the cloud-init community, as it's their project which has (once again) been broken by an OS update. I gave up chasing them some time ago, especially with brand new OS releases.

@MathieuRA Thanks for doing the fix, I have tested this and I confirm it is working. I am able to migrate VMGuest to a different host by ticking the check box in the vmlist. [image: 1709761883728-29d4f92f-f074-488d-b2b3-27b74c2e0ae4-image.png] [image: 1709761905422-0b61a637-4dac-41a4-9aba-ba7c6db85c8b-image.png]

If other people get the UNABLE_TO_VERIFY_LEAF_SIGNATURE error, check that your XMPP server provides the correct certificate chain. You can use OpenSSL for this: $ openssl s_client -connect $domain:$port -starttls xmpp -showcerts </dev/null CONNECTED(00000003) depth=0 CN = $domain verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = $domain verify error:num=21:unable to verify the first certificate verify return:1 depth=0 CN = $domain verify return:1

@olivierlambert Thank you very much Olivier, this is exactly what I want to do!

Hi, You can use the warm migration in your case, yes To me, that's one of the use case where it's safer than a live/hot one.

Hi, Thanks for the feature request This is very very likely a request for a production environment (this level of Netbox customization). It's almost taking 100% of @pdonias' time, so we need to start rationalizing stuff in order to keep some resources to move forward on XO 6. If you have a pro subscription, can you open a feature request ticket? If you don't, it might worth to create an issue on our public Github repo (with all the details) so we can see/discuss there Thank you!

@pdonias ok I get a correct answer from inside but from outside I'm getting this bad request. The curl gets to the ssl certificate on the net box host, but throws the 400 bad request, when doing from outside the firewall. When testing locally, it works. Let me look this over! Thanks!

Hopefully someone in the community will guide you, personally I never played with jobs

Hi! In theory, you just need to get the Kubernetes key to connect with whatever tool you want to play with the k8s cluster, that's pretty much everything What do you have in mind exactly?

@pdonias thanks for the update! I took a look at the latest commit and apparently I was right even though it didn't feel right. Thanks again to you all for this amazing set of FOSS tools!

@olivierlambert weird, I tried the restart, because I'm doing that a lot now since I have some backup issues. Need to move my old (very old) datacenter to the new XCP-NG Server and after that I can get to upgrading XO.

Not something we want to fix in XO5, I've added it to our roadmap for XO6

Hi @christianuhlmann, we actually already did that for interfaces. Make sure you're up to date and interfaces that you added manually shouldn't get deleted in Netbox anymore. However, for IPs, we can't do that because IPs don't have a UUID in XO/XAPI. We get a list of IPs for each VIF and we have to decide what to do with that.

@pdonias said in Xen Orchestra netbox sync error: So if XAPI isn't supposed to return space-delimited IPs in x/ipv4/x fields, better make sure it's fixed upstream, but from XO's point of view, we're supporting it anyway, now Yes I'd think XAPI should not blindly forwarding information from guest without a minimum of sanitation.

It finally work with latest version of xo-server 5.85.

Good news! Keep us posted

@johnnyorange Glad I could help! Took me weeks to figure that out lol....I would caution using that in production though, not sure the security implications for accepting the older key type.