@astrugatch At this point, I'd submit your ova to the Vates team as they requested to have them look inside it to verify you're exporting what is needed to be able to import into XO

@Andrew Gggrrr...you know what's funny about your response?...I was actually just in the Advanced tab and glossed right over that! hahaha Thanks Andrew

So it looks like it was a browser cache problem, solved by deleting it.

@TeddyAstie Thanks for confirming it's not supported, that saves me some head scratching! I'd based the assumption of it working post boot on the stats for memory usage being low and free -m showing < 48 GiB but guess I just misunderstood. Do you know if this is a fixed limitation or is it a feature that can be added in the future?

@AlexQuorum Nice to hear it In the meantime I've made a bugfix which will soon be available so you can edit the monitors instead of recreating them.

@gduperrey Ok, thank you. Appreciate the explanation.

@blackliner Honestly I never had this use case, but I would imagine terraform has a feature for this. I'll look into it, it's got me curious

Hi, Thanks for your report. Ideally, move XOA VM on another SR than the one doing the maintenance mode. Alternatively, you can do it manually with the CLI or XO Lite. You raised a valid question: XOA should have detected it was itself on the target SR and prevent it. However, even if it sounds simple, it might not be trivial. Anyway, I'm adding @lsouai-vates in the loop so we can improve this in the future

That's a security problem, due to Spectre/Meltdown, it's very dangerous to run a VM that could have more vCPUs than pCPUs on a host.

@Byte0 The json: makes the rest of the value interpreted as JSON, otherwise it is interpreted as a plain string. It is therefore required for all non-string values. Some method params (like memory for vm.set) accept both integers and strings, that's why it was working.

I mean I agree with the idea that sounds good, I need to be reviewed again to see if we could do better than we did

Dual stack support for IPv4 + IPv6 on the management interface in XCP-ng 8.3: requires reinstalling to define both IPv4 and IPv6 for the management interface is still experimental, there are a few known issues CC @BenjiReis @gthvn1 @andriy.sultanov

Hi, Indeed, the pre requisite section is pretty clear about it: https://docs.xen-orchestra.com/installation#packages-and-pre-requisites And the error message was clear too: The engine "node" is incompatible with this module. Expected version ">=20.18". Got "18.19.1" However, if you think there's a way to improve this, let us know, we'll be happy to assist

@olivierlambert Just to be sure. Thanks.

Looks to be correct on the current release of XO from Source and reads as "Prevent Migration"

@olivierlambert Ok, will do. Thanks!

@ronan-a Any more information about RawISCSISR usage? I can't seem to find any good match on the web.

@olympicgreg Hello! And thanks for your feedback on the ACL subject. I note this on our XO-6 next features, so we will discuss on it and see what we can improve. Indeed the ACL subject is quite not trivial and we keep on working on it. Have a good day and don't hesitate to give us feedbacks on XO features.

@NathanO Hello there! We have a feature on the isPubKeyTooShort spamming on the XO next sprint priority, so to me it should be available on May 2025 XO release. Check at the next blogspots to keep informed. Hope my comment responds to your questions, have a good day!

@Tomcatter yes it was already implemented in XO-Lite [image: 1744189947925-f1dc4d66-3ffc-43cc-baca-56f934901f99-image.png] You can find it from the pool view. (click on a pool on the treeview and then on the VM tab) It is also planned for XO-6, it is in our backlog for next features. Does it respond to your questions?