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.
