On Mon 16 May 2022, 10:10 Michal Prívozník, <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>> 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
