Hi,
On Sat, 14 May 2022 at 23:42, Darragh Bailey <daragh.bailey(a)gmail.com
wrote:
Hi,
On Sat 14 May 2022, 21:11 Laine Stump, <laine(a)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:
Looks like I've stumbled across an edge case here
regarding domain config
not being fully updated but also not returning an error.
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.
I decided to test the behaviour slightly more directly
via virsh rather
than through the ruby bindings and based on replicating the same there, and
a review of the ruby binding API code, I believe the binding code is
working fine, the problem is unexpected behaviour in libvirt.
It appears that if the XML passed in contains an nvram XML tag without a
corresponding loader tag, then the nvram tag will be dropped without an
error. In fact if you change any other information such as the vcpu
definition in the same update, that will still be applied while the nvram
tag is ignored.
Simply the reason the ruby code isn't raising an exception is that libvirt
thinks nothing went wrong and is returning a non null pointer.
Put together a gist to make it easier to show what I'm seeing
https://gist.github.com/electrofelix/6f66714c14a0d6e3b1078037aadae398
I'm assuming at this point that this is a bug, the domain XML in
test_with_nvram.xml should be rejected because it's not all applied.
--
Darragh