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