libvirt users - May 2022 - Updating domains definitions via API

On Mon, 16 May 2022 at 12:30, Michal Pr?vozn?k <mprivozn at redhat.com>
wrote:
> I mean, fixing this particular problem is trivial. But what's not as
> trivial is fixing ALL occurrences of this problem (where an
> attribute/element is ignored because of something we've parsed
earlier).
> Mostly because we don't know what those are.
>
tbf, this is the clarification I needed. I was previously operating under
the
assumption that given the description define_domain_xml was checking
if the resulting XML for the domain matched what was passed in.

> BTW: Have you spotted the other demonstration of this problem (in the
> same function)? Yes, if fw autoselection is enabled (<os
> firmware='something'>) then <nvram template=''/>
is ignored.
>
No, I think it was probably a bit of a fluck that I hit the issue as I was
looking
at trying to avoid the special handling around nvram with the current code
undefining a domain before creating the new definition. Could easily have
missed it altogether.

> Anyway, there used to be an unwritten agreement with users that they get
> XML of a domain they just defined to see if it contains everything they
> want. This is used to be because different drivers support different
> features. But I guess it's hard to argue with an unwritten rule esp. if
> it's not known to everybody.
>
> Michal
>
I had started to lean towards checking the XML for the domain returned as
a final validation step.Perhaps the API docs for
https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainDefineXML and
https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainDefineXMLFlags
could mention that it doesnot guarantee that the entire XML document has
been applied to the domain?

So perhaps this is less a bug with the loader/nvram XML element handling
and more a documentation bug and a possible enhancement that possibly
the virDomainDefineXMLFlags could consider accepting a flag to verify the
returned domain XML is equivalent as a general fix for those applications
that would find this useful?
--
Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool"
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/libvirt-users/attachments/20220516/7a340a2d/attachment.htm>

On 5/16/22 14:52, Darragh Bailey wrote:
> So perhaps this is less a bug with the loader/nvram XML element handling
> and more a documentation bug and a possible enhancement that possibly
> the virDomainDefineXMLFlags could consider accepting a flag to verify the
> returned domain XML is equivalent as a general fix for those applications
> that would find this useful?
Yes to the first part, but no the second. Comparing XMLs is not as easy
as you would think. For instance:

<domain id='1' type='kvm'>
  <uuid>123456</uuid>
  <name>myGuest</name>
</domain>

<domain type='kvm' id='1'>
  <name>myGuest</uuid>
  <uuid>123456</uuid>
</domain>

The former is just an example of possible user input, the latter is how
libvirt would format it. Obviously, these XMLs are equivalent, but not
stcmp() equal.

Michal