Hi,
On Sat, 14 May 2022 at 23:42, Darragh Bailey <daragh.bailey@xxxxxxxxx> wrote:
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:
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
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
