Updating domains definitions via API

[Darragh Bailey]

On Mon 16 May 2022, 10:10 Michal Prívozník, <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>> 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
>
> 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?
--
Darragh Bailey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20220516/59396a59/attachment-0001.htm>