libvirt users - May 2022 - Updating domains definitions via API

On 5/12/22 4:03 PM, Darragh Bailey wrote:
> Hi,
> 
> 
> Looking into a bug in vagrant-libvirt where an error during the update 
> will cause the domain to be completely discarded.
> 
> https://github.com/vagrant-libvirt/vagrant-libvirt/issues/949 
> <https://github.com/vagrant-libvirt/vagrant-libvirt/issues/949>
> 
> Basically I think it stems from doing an undefine -> create with XML new
> process, which if there is an issue with the new XML due to KVM module 
> not loaded or something similar it will be rejected, but unfortunately 
> it is also unlikely to allow the old definition to be restored either.
> 
> I'm looking around to try and see if there is an API (specfically in 
> ruby-libvirt) for updating the domain definition, so that if the new XML 
> is rejected at least the old definition remains, and so far I'm drawing
> a blank.
> 
> Is the only option here to write using a temporary domain name, then 
> remove the old domain and rename the new definition to the old domain?
> 
> Or have I missed the obvious API analogous to the edit functionality?
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.

If any error is encountered during this redefinition, then no changes 
are made to the existing domain definition.

[*]The exception to this - if you attempt to Define a domain that has 
the same name or uuid as an existing domain, but the uuid/name is 
different, that is an error.

Hi,

On Thu 12 May 2022, 21:34 Laine Stump, <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.
>
That makes it much easier, and makes what the code was previously doing
rather stupid. Probably a case that I never thought to read the API doc for
virDomainDefineXML

If any error is encountered during this redefinition, then no
changes
> are made to the existing domain definition.
>
That is the ideal behaviour
>
> [*]The exception to this - if you attempt to Define a domain that has
> the same name or uuid as an existing domain, but the uuid/name is
> different, that is an error.
>

Are there any gotchas/limitations dealing with NVRAM when redefining
domains that I should be aware of? Typically setting some flags to allow
the undefine to work as expected, just not clear whether a NVRAM file could
be orphaned by updating the domain XML, or if a reference will be
maintained so if a domain once had NVRAM it's necessary to pass the flag to
remove on undefine. Hopefully nget to test around some of this later, just
not sure I know enough to ensure I check all behaviours.

--
Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool" - unknown
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/libvirt-users/attachments/20220513/75acb564/attachment.htm>