libvirt users - May 2022 - Updating domains definitions via API

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>

On Fri, 13 May 2022 at 00:17, Darragh Bailey <daragh.bailey at gmail.com>
wrote:
> 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.
>>
>
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:

# Apply XML changes directly
if descr_changed
  begin
    env[:ui].info("Updating domain definition due to configuration
change")
    new_descr = String.new
    xml_descr.write new_descr
    # env[:machine].provider.driver.connection.client provides access to
the ruby-libvirt connection object
    libvirt_domain
env[:machine].provider.driver.connection.client.define_domain_xml(new_descr,
1)
    domain
env[:machine].provider.driver.connection.servers.get(env[:machine].id.to_s)
  rescue Fog::Errors::Error => e
    raise Errors::UpdateServerError, error_message: e.message
  end
end

I've by-passing the fog-libvirt to call the ruby-libvirt connection object
directly to try and avoid any unexpected interference when testing the API
call out e.g.
https://libvirt.org/ruby/api/Libvirt/Connect.html#method-i-define_domain_xml

So not only is there no exception thrown if the XML change is ignored, I've
noticed there doesn't appear to be an easy way to check using the API
either, in that
https://libvirt.org/ruby/api/Libvirt/Domain.html#method-i-updated-3F
doesn't indicate that the domain has been updated whether I call it on the
libvirt_domain object returned, or an instance from before the
define_domain_xml call is made.

It appears that the only way is to perform a call to get the xml definition
of the libvirt_domain object returned in the above block and see if that
matches the xml that was sent, if not, error.

Is this the expected usage of the API? Or should the call to
define_domain_xml raise an exception if it cannot update the domain XML? as
opposed to a schema validation error which does appear to be detected when
I did something stupid.

--
Darragh
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/libvirt-users/attachments/20220514/2c15847c/attachment.htm>