On 11/07/2025 13:53, Daniel P. Berrangé wrote:
On Fri, Jul 11, 2025 at 01:49:28PM +0100, Mark Cave-Ayland wrote:
(snip)
This probably takes us back to needing to have another element at the top level in the XML.
<uuid>....</uuid> <hwuuid>...</hwuuid>
where <uuid> is mandatory as today, and <hwuuid> can optionally be used to override what is exposed to the guest, defaulting to <uuid> if omitted.
Thanks for the update, I'll take a look at implementing something along these lines. Would it be slightly easier to add the guest-visible UUID as an attribute to the existing uuid element e.g.
<uuid guest-uuid="....">....</uuid>
since then it should already be accessible at the places where we already have an existing reference to the uuid element?
We already have the 'genid' UUID as a separate element, so I figure we just carry on that practice with 'hwuuid'.
Thanks for the hints! I've been looking at the various drivers within libvirt, and from what I can see not all virtualisation platforms will allow a separate UUID to be provided in this way.
Would the best way forward be to add a new capability to represent this ability, and then follow up with a QEMU implementation?
I think its probably overkill to add capability. Just define the XML and wire up QEMU.
I see, I wasn't sure if it would be an issue for other drivers to silently ignore the new element. That's actually quite helpful from a QEMU implementation perspective since I can easily add the new field into virDomainPtr and go from there. ATB, Mark.