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: > > Hi, > > On Thu 12 May 2022, 21:34 Laine Stump, <laine at redhat.com > <mailto:laine at redhat.com>> wrote: > > The virDomainDefineXMLFlags API (and also the older/deprecated > virDomainDefineXML API) doesn't require that the domain first be > undefined (with one notable exception - see below[*]). If you > define a > domain that already exists with the same name and uuid, then the > effect > is to "redefine" (or "update" if you prefer) the existing domain > of that > name. If the domain is currently active, then the changes will take > effect the next time the domain is shut down ("Destroy"ed in > libvirt API > parlance) and re-started. > > > 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? Michal
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>