On Mon, 16 May 2022 at 12:30, Michal Prívozník <mprivozn@xxxxxxxxxx> 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
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"
"Nothing is foolproof to a sufficiently talented fool"
