On 5/14/22 6:42 PM, Darragh Bailey wrote:
Hi,
On Sat 14 May 2022, 21:11 Laine Stump, <laine@xxxxxxxxxx
<mailto:laine@xxxxxxxxxx>> 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
