On Mon, 16 May 2022 at 12:30, Michal Prívozník <mprivozn@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"