Hi,
On Sat 14 May 2022, 21:11 Laine Stump, <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.
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.
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
