Updating domains definitions via API
Laine Stump
laine at redhat.com
Sun May 15 14:45:27 UTC 2022
On 5/14/22 6:42 PM, Darragh Bailey wrote:
> Hi,
>
> On Sat 14 May 2022, 21:11 Laine Stump, <laine at redhat.com
> <mailto:laine at redhat.com>> wrote:
>
> Caveat - I'm completely unfamiliar with ruby and the libvirt-ruby API
> bindings.
>
> If there is a problem that causes the domain config to not be updated,
> libvirt will return an error. So I would suspect one of the two things
> is happening:
>
>
> Thanks, that's what I was expecting should happen, just wanted to be
> sure that there wasn't some other behaviour in place for compatibility
> reasons.
>
> 1) there may be a problem in the libvirt-ruby bindings that causes the
> error reported by the call (in whatever C code is behind the ruby
> bindings) to libvirt to be properly propagated to ruby. I would hope
> this isn't the case, but "bugs happen", so it should be considered as a
> possibility.
>
>
> A quick look suggests that the code looks to raise an exception if the
> dom pointer returned is NULL, so I think the bindings are correct. But I
> will check that what version of ruby-libvirt I have installed matches
> the source code I'm looked at.
>
> 2) As I said in my earlier mail, any changes that are made will take
> effect the next time the domain is destroyed and restarted. This also
> means that the changes won't be reflected in the "live/status" XML of
> the domain until that time. If you want to see the new configuration
> after you've made changes, you should add the VIR_DOMAIN_XML_INACTIVE
> flag when requesting the domain XML. Possibly you haven't included this
> flag, and that's why you think that your change hasn't taken effect?
>
>
> Ah, I forgot to outline where in the lifecycle the update is taking
> place. The domain isn't running when the code attempts to update the
> definition.
>
> Does that still mean that the VIR_DOMAIN_XML_INACTIVE flag is needed? I
> was assuming when the domain is inactive the XML changes would be
> reflected immediately.
No, your thinking was correct - if the domain isn't active, then the
change should take effect immediately, and there is no difference
whether or not you have VIR_DOMAIN_XML_INACTIVE.
I've never done anything directly with the nvram setting (just accepted
whatever virt-manager put in there), but from your other message, it
sounds like you've found a bonafide libvirt bug (either that, or I just
don't know enough about how the nvram settings work :-)). Can you file
an issue at https://gitlab.com/groups/libvirt/-/issues ?
>
> Oddly I thought during some experiments when the added NVRAM XML element
> was ignored, the updated number of CPUs which was in the same XML
> definition passed in was applied.
Another indication that it's a bug - updates to the domain config are
always an all-or-nothing thing.
> Will dig further tomorrow or Monday on the version of ruby-libvirt
> installed into my rvm dev env as well as checking passing in the flag.
>
> I'm sure it'll turn out to be something obvious that I'm overlooking.
>
> Thanks,
> --
> Darragh
>
More information about the libvirt-users
mailing list