Hi,
On Thu 12 May 2022, 21:34 Laine Stump, <laine@xxxxxxxxxx> 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
"Nothing is foolproof to a sufficiently talented fool" - unknown
