On 5/16/22 12:46, Darragh Bailey wrote:
On Mon 16 May 2022, 10:10 Michal Prívozník, <mprivozn(a)redhat.com
<mailto:mprivozn@redhat.com>> wrote:
On 5/14/22 21:23, Darragh Bailey wrote:
>
> On Fri, 13 May 2022 at 00:17, Darragh Bailey
<daragh.bailey(a)gmail.com <mailto:daragh.bailey@gmail.com>
> <mailto:daragh.bailey@gmail.com
<mailto:daragh.bailey@gmail.com>>>
wrote:
>
> Unfortunately trying to call this via ruby-libvirt doesn't appear to
> behave as expected. It appears that if I add an nvram element
without a
> loader element to the os block, the following code block will execute
> without issue but also without changing the domain XML:
I think that's kind of expected. If you take a look how libvirt parses
that part of XML:
https://gitlab.com/libvirt/libvirt/-/blob/master/src/conf/domain_conf.c#L...
<
https://gitlab.com/libvirt/libvirt/-/blob/master/src/conf/domain_conf.c#L...
if no <loader/> is found then the function exits early without looking
at <nvram/> at all. It kind of makes sense - what good does nvram do
without loader?
I don't know, I realised that there was a bug in our vagrant-libvirt in
that it should be checking for both loader and NVRAM config settings to
be passed in if the end user was updating the machine config. And
subsequently set both elements or neither.
However I was not expecting the silent discarding of the XML element and
instead to get an error saying that an nvram XML element without a
loader XML element is invalid and for the entire request to be rejected.
Basically that the provided XML domain definition was invalid.
Based on the previous explanation of how the define_domain_xml should
work along with the response on the example reproducer this seems like a
bug.
Does your reply mean this is expected behaviour? Or were you looking for
clarification on what I expected to see?
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.
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.
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