Hi,
On Thu 12 May 2022, 21:34 Laine Stump, <la...@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
>
