Hi,
it didn't let me calm down that we had the qemu QMP reporting VMX as off.
I mean I have heard (there never was an Ubuntu bug, but people on IRC have run
into it) of issues that people needed to regen capabilities.
After checking the logs of yesterday I found the trap that you laid for me :-)
When checking QMP we were on a system that really had
$ cat /sys/module/kvm_intel/parameters/nested
N
So the bit in the cpuid was off.
But when we made the cross check with the cpuid tool we were on a different
system, probably with
$ cat /sys/module/kvm_intel/parameters/nested
Y
But the caps cache not regenerated. Hence there the tool reported the bit to be
set.
That red herring put aside I can let go my confusion and focus on what is
ahead, as discussed on IRC we might want to look into :
a) verifying the triggers for a reload today properly working (e.g. new qemu
binary)
b) consider adding more triggers (maybe: libvirtd restart, module load times,
surely: reboot)
Not sure if that will be today or next week.
But with manually cleaning the /var/cache/libvirt/qemu/capabilities/ gives you
a workaround until then.
** Changed in: libvirt (Ubuntu)
Status: New => Triaged
** Changed in: libvirt (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1830268
Title:
libvirt caches nested vmx capability (in domcapabilities)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1830268/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
