[libvirt] [RFC] Question regarding the validity of QEMU capabilities
Hi all, the actual capabilities of QEMU are depending on the host. This includes dependencies like which kernel modules are loaded or which kernel parameters are used (e.g. kvm.nested). Therefore, after a restart we cannot be sure that the QEMU capabilities remain the same. How can we solve this problem? I have come up with two ways: - reprobe the capabilities with every host reboot - check for every possible change in virQEMUCapsIsValid... (this is already done for KVM). In my opinion this is not the way to go. Thanks. Marc
On Fri, Oct 20, 2017 at 12:59:51PM +0200, Marc Hartmayer wrote:
Hi all,
the actual capabilities of QEMU are depending on the host. This includes dependencies like which kernel modules are loaded or which kernel parameters are used (e.g. kvm.nested). Therefore, after a restart we cannot be sure that the QEMU capabilities remain the same.
How can we solve this problem?
Hi, thanks for bringing up this issue, we kind of already know about it but it's good idea to discuss it publicly.
I have come up with two ways: - reprobe the capabilities with every host reboot
This is the solution that was agreed on but nobody was motivated enough to write the code :).
- check for every possible change in virQEMUCapsIsValid... (this is already done for KVM). In my opinion this is not the way to go.
Pavel
On Fri, Oct 20, 2017 at 01:10 PM +0200, Pavel Hrdina <phrdina@redhat.com> wrote:
On Fri, Oct 20, 2017 at 12:59:51PM +0200, Marc Hartmayer wrote:
Hi all,
the actual capabilities of QEMU are depending on the host. This includes dependencies like which kernel modules are loaded or which kernel parameters are used (e.g. kvm.nested). Therefore, after a restart we cannot be sure that the QEMU capabilities remain the same.
How can we solve this problem?
Hi,
thanks for bringing up this issue, we kind of already know about it but it's good idea to discuss it publicly.
I have come up with two ways: - reprobe the capabilities with every host reboot
This is the solution that was agreed on but nobody was motivated enough to write the code :).
First - thank you for the quick answer :) Would it be okay if the solution depends on systemd?
- check for every possible change in virQEMUCapsIsValid... (this is already done for KVM). In my opinion this is not the way to go.
Pavel
-- Beste Grüße / Kind regards Marc Hartmayer IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
On Fri, Oct 20, 2017 at 13:15:41 +0200, Marc Hartmayer wrote:
On Fri, Oct 20, 2017 at 01:10 PM +0200, Pavel Hrdina <phrdina@redhat.com> wrote:
On Fri, Oct 20, 2017 at 12:59:51PM +0200, Marc Hartmayer wrote:
Hi all,
the actual capabilities of QEMU are depending on the host. This includes dependencies like which kernel modules are loaded or which kernel parameters are used (e.g. kvm.nested). Therefore, after a restart we cannot be sure that the QEMU capabilities remain the same.
How can we solve this problem?
Hi,
thanks for bringing up this issue, we kind of already know about it but it's good idea to discuss it publicly.
I have come up with two ways: - reprobe the capabilities with every host reboot
This is the solution that was agreed on but nobody was motivated enough to write the code :).
First - thank you for the quick answer :)
Would it be okay if the solution depends on systemd?
Not really. It may of course use systemd if it's present, but it should work even on systems without systemd. Jirka
On Fri, Oct 20, 2017 at 01:10:14PM +0200, Pavel Hrdina wrote:
On Fri, Oct 20, 2017 at 12:59:51PM +0200, Marc Hartmayer wrote:
Hi all,
the actual capabilities of QEMU are depending on the host. This includes dependencies like which kernel modules are loaded or which kernel parameters are used (e.g. kvm.nested). Therefore, after a restart we cannot be sure that the QEMU capabilities remain the same.
How can we solve this problem?
Hi,
thanks for bringing up this issue, we kind of already know about it but it's good idea to discuss it publicly.
I have come up with two ways: - reprobe the capabilities with every host reboot
This is the solution that was agreed on but nobody was motivated enough to write the code :).
Reprobing QEMU is quite heavy. I wonder if we should change slightly. Make our capabilities cache *only* contain stuff reported by the QEMU binary. For other stuff we detect from the host, never cache it. That way we can just revalidate the host stuff on every libvirtd startup, but keep the slow/heavy QEMU cache untouched
- check for every possible change in virQEMUCapsIsValid... (this is already done for KVM). In my opinion this is not the way to go.
Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Fri, Oct 20, 2017 at 13:12:59 +0100, Daniel P. Berrange wrote:
On Fri, Oct 20, 2017 at 01:10:14PM +0200, Pavel Hrdina wrote:
On Fri, Oct 20, 2017 at 12:59:51PM +0200, Marc Hartmayer wrote:
Hi all,
the actual capabilities of QEMU are depending on the host. This includes dependencies like which kernel modules are loaded or which kernel parameters are used (e.g. kvm.nested). Therefore, after a restart we cannot be sure that the QEMU capabilities remain the same.
How can we solve this problem?
Hi,
thanks for bringing up this issue, we kind of already know about it but it's good idea to discuss it publicly.
I have come up with two ways: - reprobe the capabilities with every host reboot
This is the solution that was agreed on but nobody was motivated enough to write the code :).
Reprobing QEMU is quite heavy. I wonder if we should change slightly.
Make our capabilities cache *only* contain stuff reported by the QEMU binary. For other stuff we detect from the host, never cache it.
This is what we've always been doing. But some stuff we get from QEMU actually depends on the host. In other words, it's QEMU probing the host and reporting the results to us. Jirka
participants (4)
-
Daniel P. Berrange -
Jiri Denemark -
Marc Hartmayer -
Pavel Hrdina