On 12/13/18 8:29 AM, Michal Privoznik wrote:
On 11/29/18 2:55 AM, John Ferlan wrote:
> Support for nested KVM is handled via a kernel module configuration
> parameters values for kvm_intel, kvm_amd, kvm_hv (PPC), or kvm (s390).
> While it's possible to fetch the kmod config values via virKModConfig,
> unfortunately that is the static value and we need to get the
> current/dynamic value from the kernel file system.
>
> So this patch adds a new API virHostKVMSupportsNesting that will
> search the 3 kernel modules to get the nesting value and check if
> it is 'Y' (or 'y' just in case) or '1' to return a true/false
whether
> the KVM kernel supports nesting.
>
> We need to do this in order to handle cases where adjustments to
> the value are made after libvirtd is started to force a refetch of
> the latest QEMU capabilities since the correct CPU settings need
> to be made for a guest to add the "vmx=on" to/for the guest config.
Ah, so if nested KVM is not enabled that qemu might report vmx:false and
if it is enabled it reports vmx:true?
Right... If I followed the breadcrumbs in the bz (private/locked
1645139) the kernel parameter was changed after libvirtd was started.
Then a L0 guest was created using virt-manager and started. When looking
at that guest the 'vmx' was not on, thus no nesting allowed. Even
restarting libvirtd didn't help because none of the conditions used to
determine whether we should re-read the capabilities was present. Only
after clearing the capabilities cache did the "proper" thing happen (see
comment 14 in the bz - thanks to Pavel for the details - I'm not sure I
would have come up with that given the details I saw in the case).
John
ACK in that case.
Michal