oVirt Nested Virtualization

Hi! I'd like to try the HCI Rollout https://ovirt.org/documentation/gluster-hyperconverged/chap-Deploying_Hyperc... on my oVirt Infrastructure. The hosts have "nested virtualization" active, but when starting the Hosted Engine deployment from cockpit an the error "Hardware virtualization is not supported on this host" occurs. cat /sys/module/kvm_intel/parameters/nested Y Any ideas on this?

On the three VMs for the HCI rollout: virt-host-validate QEMU: Checking for hardware virtualization : FAIL (Only emulated CPUs are available, performance will be significantly limited) QEMU: Checking if device /dev/vhost-net exists : PASS QEMU: Checking if device /dev/net/tun exists : PASS QEMU: Checking for cgroup 'memory' controller support : PASS QEMU: Checking for cgroup 'memory' controller mount-point : PASS QEMU: Checking for cgroup 'cpu' controller support : PASS QEMU: Checking for cgroup 'cpu' controller mount-point : PASS QEMU: Checking for cgroup 'cpuacct' controller support : PASS QEMU: Checking for cgroup 'cpuacct' controller mount-point : PASS QEMU: Checking for cgroup 'cpuset' controller support : PASS QEMU: Checking for cgroup 'cpuset' controller mount-point : PASS QEMU: Checking for cgroup 'devices' controller support : PASS QEMU: Checking for cgroup 'devices' controller mount-point : PASS QEMU: Checking for cgroup 'blkio' controller support : PASS QEMU: Checking for cgroup 'blkio' controller mount-point : PASS WARN (Unknown if this platform has IOMMU support) LXC: Checking for Linux >= 2.6.26 : PASS LXC: Checking for namespace ipc : PASS LXC: Checking for namespace mnt : PASS LXC: Checking for namespace pid : PASS LXC: Checking for namespace uts : PASS LXC: Checking for namespace net : PASS LXC: Checking for namespace user : PASS LXC: Checking for cgroup 'memory' controller support : PASS LXC: Checking for cgroup 'memory' controller mount-point : PASS LXC: Checking for cgroup 'cpu' controller support : PASS LXC: Checking for cgroup 'cpu' controller mount-point : PASS LXC: Checking for cgroup 'cpuacct' controller support : PASS LXC: Checking for cgroup 'cpuacct' controller mount-point : PASS LXC: Checking for cgroup 'cpuset' controller support : PASS LXC: Checking for cgroup 'cpuset' controller mount-point : PASS LXC: Checking for cgroup 'devices' controller support : PASS LXC: Checking for cgroup 'devices' controller mount-point : PASS LXC: Checking for cgroup 'blkio' controller support : PASS LXC: Checking for cgroup 'blkio' controller mount-point : PASS LXC: Checking if device /sys/fs/fuse/connections exists : FAIL (Load the 'fuse' module to enable /proc/ overrides) [root@hci1 ~]# cat /sys/module/kvm_intel/parameters/nested cat: /sys/module/kvm_intel/parameters/nested: No such file or directory [root@hci1 ~]# modprobe kvm_intel modprobe: ERROR: could not insert 'kvm_intel': Operation not supported

On Tue, Dec 11, 2018 at 2:09 PM Markus Schaufler < markus.schaufler@digit-all.at> wrote:
On the three VMs for the HCI rollout:
virt-host-validate QEMU: Checking for hardware virtualization : FAIL (Only emulated CPUs are available, performance will be significantly limited)
What is your L0 platform, so your used virtualization platform used on physical host(s)?
[root@hci1 ~]# cat /sys/module/kvm_intel/parameters/nested cat: /sys/module/kvm_intel/parameters/nested: No such file or directory [root@hci1 ~]# modprobe kvm_intel modprobe: ERROR: could not insert 'kvm_intel': Operation not supported _______________________________________________
Can you resemble your L0 OS/ virtualization sw and L1 OS too? Gianluca

Centos 7.5, ovirt 4.2.7 it works when pinpointing the vm's to a host and enable cpu-passthrough. but i presume it should work without this workaround too.

On Tue, Dec 11, 2018 at 3:29 PM Markus Schaufler < markus.schaufler@digit-all.at> wrote:
Centos 7.5, ovirt 4.2.7 it works when pinpointing the vm's to a host and enable cpu-passthrough. but i presume it should work without this workaround too. _______________________________________________
If I remember correctly there is no support/consistence for the L2 systems, that are guests inside an L1 system that is migrated. So perhaps this limitation drove to force host pinning and prevent having unpredictable results for L2 guests See also here: https://www.linux-kvm.org/page/Nested_Guests HIH, Gianluca

On 11 Dec 2018, at 16:10, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Tue, Dec 11, 2018 at 3:29 PM Markus Schaufler <markus.schaufler@digit-all.at <mailto:markus.schaufler@digit-all.at>> wrote: Centos 7.5, ovirt 4.2.7 it works when pinpointing the vm's to a host and enable cpu-passthrough. but i presume it should work without this workaround too. _______________________________________________
If I remember correctly there is no support/consistence for the L2 systems, that are guests inside an L1 system that is migrated. So perhaps this limitation drove to force host pinning and prevent having unpredictable results for L2 guests
it’s not really done because of that - it’s rather that by default none of the named CPU models are adding vmx and so the guest doesn’t look like capable of virtualization. Cpu passthrough does, because it passes all the flags, but it also enforces host pinning. Which is then a nice coincidence because indeed the migration wouldn’t work anyway:) And it’s something to keep in mind now in later 4.2.z and 4.3 where we now allow migration of VMs with cpu passthrough. But it’s not for this use case and there nested environment still doesn’t support migration properly and you need to make sure not to migrate.
See also here: https://www.linux-kvm.org/page/Nested_Guests <https://www.linux-kvm.org/page/Nested_Guests>
HIH, Gianluca _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/Y2T3RXLPTMB2S7...

Hi Markus, What's the out put of egrep "vmx|svm" "/proc/cpuinfo" When the out put does not return any thing you will get "Hardware virtualization is not supported on this host" On Thu, Dec 13, 2018 at 7:50 PM Michal Skrivanek < michal.skrivanek@redhat.com> wrote:
On 11 Dec 2018, at 16:10, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Tue, Dec 11, 2018 at 3:29 PM Markus Schaufler < markus.schaufler@digit-all.at> wrote:
Centos 7.5, ovirt 4.2.7 it works when pinpointing the vm's to a host and enable cpu-passthrough. but i presume it should work without this workaround too. _______________________________________________
If I remember correctly there is no support/consistence for the L2 systems, that are guests inside an L1 system that is migrated. So perhaps this limitation drove to force host pinning and prevent having unpredictable results for L2 guests
it’s not really done because of that - it’s rather that by default none of the named CPU models are adding vmx and so the guest doesn’t look like capable of virtualization. Cpu passthrough does, because it passes all the flags, but it also enforces host pinning. Which is then a nice coincidence because indeed the migration wouldn’t work anyway:) And it’s something to keep in mind now in later 4.2.z and 4.3 where we now allow migration of VMs with cpu passthrough. But it’s not for this use case and there nested environment still doesn’t support migration properly and you need to make sure not to migrate.
See also here: https://www.linux-kvm.org/page/Nested_Guests
HIH, Gianluca _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/Y2T3RXLPTMB2S7...
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/I4VT2YVVO6HX5A...
-- Thanks, Gobinda
participants (4)
-
Gianluca Cecchi
-
Gobinda Das
-
Markus Schaufler
-
Michal Skrivanek