Updating domains definitions via API

[Darragh Bailey]

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>