On 5/16/22 12:46, Darragh Bailey wrote:>
> On Mon 16 May 2022, 10:10 Michal Pr?vozn?k, <mprivozn at redhat.com
> <mailto:mprivozn at redhat.com>> wrote:
>
> On 5/14/22 21:23, Darragh Bailey wrote:
> >
> > On Fri, 13 May 2022 at 00:17, Darragh Bailey
> <daragh.bailey at gmail.com <mailto:daragh.bailey at
gmail.com>
> > <mailto:daragh.bailey at gmail.com <mailto:daragh.bailey at
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#L18257
>
<https://gitlab.com/libvirt/libvirt/-/blob/master/src/conf/domain_conf.c#L18257>
>
> 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