Re: Updating domains definitions via API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/16/22 12:46, Darragh Bailey wrote:
> 
> On Mon 16 May 2022, 10:10 Michal Prívozník, <mprivozn@xxxxxxxxxx
> <mailto:mprivozn@xxxxxxxxxx>> wrote:
> 
>     On 5/14/22 21:23, Darragh Bailey wrote:
>     >
>     > On Fri, 13 May 2022 at 00:17, Darragh Bailey
>     <daragh.bailey@xxxxxxxxx <mailto:daragh.bailey@xxxxxxxxx>
>     > <mailto:daragh.bailey@xxxxxxxxx <mailto:daragh.bailey@xxxxxxxxx>>>
>     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




[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux