3

I'm having a hard time getting nested virtualization inside my Win10 Pro guest running on KVM host working. Enabling Windows Hypervisor hypervisorlaunchtype auto results in a boot loop/boot to Automatic Repair.

Host:

CentOS Linux release 8.2.2004 (Core)

Intel(R) Xeon(R) E-2176G CPU @ 3.70GHz

# cat /sys/module/kvm_intel/parameters/nested
1

flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d

Guest:

Microsoft Windows [Version 10.0.19041.508]

I've tried multiple configurations, migrated my Windows from BIOS to UEFI, tried a clean Windows installation, disabled/rebooted/enabled/rebooted the Hypervisor features, etc. nothing working yet.

My current configuration:

  <os>
    <type arch='x86_64' machine='pc-q35-rhel7.6.0'>hvm</type>
    <loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
    <nvram>/var/lib/libvirt/qemu/nvram/win10_VARS.fd</nvram>
  </os>
  <features>
    <acpi/>
    <apic eoi='on'/>
    <hyperv>
      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='8191'/>
    </hyperv>
    <kvm>
      <hidden state='on'/>
    </kvm>
    <vmport state='off'/>
    <smm state='on'/>
  </features>
  <cpu mode='host-passthrough' check='partial'>
    <topology sockets='1' cores='4' threads='2'/>
    <feature policy='require' name='ds'/>
    <feature policy='require' name='acpi'/>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='ht'/>
    <feature policy='require' name='tm'/>
    <feature policy='require' name='pbe'/>
    <feature policy='require' name='dtes64'/>
    <feature policy='require' name='monitor'/>
    <feature policy='require' name='ds_cpl'/>
    <feature policy='require' name='vmx'/>
    <feature policy='require' name='smx'/>
    <feature policy='require' name='est'/>
    <feature policy='require' name='tm2'/>
    <feature policy='require' name='xtpr'/>
    <feature policy='require' name='pdcm'/>
    <feature policy='require' name='osxsave'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='clflushopt'/>
    <feature policy='require' name='intel-pt'/>
    <feature policy='require' name='md-clear'/>
    <feature policy='require' name='stibp'/>
    <feature policy='require' name='ssbd'/>
    <feature policy='require' name='xsaves'/>
    <feature policy='require' name='pdpe1gb'/>
    <feature policy='require' name='invtsc'/>
    <feature policy='disable' name='hypervisor'/>
  </cpu>

Note the last feature hypervisor: If disable, Windows boots and reports Hyper-V as working (systeminfo reports Hyper-V Requirements as available, TaskManager shows Virtualization enabled, etc.), but Hyper-V cannot launch any VM, system logs report that hypervisor is not running. Setting the feature to require brings me in the boot loop/boot to Automatic Repair.

And since it's a bit hard to google this option in this context:

  • What does the hypervisor feature exactly do? Where is it documented?

It seems to me that the windows hypervisor crashes on launch with the feature enabled and with the feature disabled just cannot start and continues the boot process.

I'm now out of ideas what else I could try and also believe that I've checked pretty much every search result on the topic. But maybe I've missed something, so please

  • Can anyone report a successful setup like this? And if so, sharing the guest config would be great!
  • Any other ideas I should try to make this work?

Thanks!

PS: Virtualization itself works great and fast, so I'm pretty sure everything from hardware side is OK, but maybe there're things I should check for as well?!

grasbueschel
  • 208
  • 2
  • 8

2 Answers2

2

A few months ago I set up two KVM hosts using CentOS 8.1.1911 with a Hyper-V VM as a nested guest and it all worked fine.

A couple of months later, I set up a third KVM host with a near identical hardware and software configuration. The only difference was the motherboard, which had the same chipset, but was Gigabyte branded not ASUS branded as per the first two. I set this host up on CentOS 8.2.2004 and experienced the same as you - bootloops. I tried the latest Fedora version at the time and it also bootlooped. As the nested virtualization on this host was not necessary, I just didn't use it and assumed the Gigabyte board was at fault.

Fast forward to today, when I decided to do an upgrade of my 8.1 hosts to 8.2. After the upgrade completed and I rebooted - the hyper-V nested VM's started bootlooping.

I rolled back to 8.1.1911 using yum history undo, and just like that, the hyper-v guest started working again.

TL;DR: might be a problem with the latest version of CentOS (8.2.2004). Try installing 8.1 (8.1.1911) and see how you go.

user3129594
  • 176
  • 3
  • Thanks for this promising information! Will defenitley try that, but will take me a few days before I can reinstall the host (it was a fresh 8.2 install, not an update) and can come back with info if this helped my case as well... – grasbueschel Oct 04 '20 at 16:04
  • 2
    Thank you so much! Indeed it was a problem with newer packages and I could pinpoint it to the `qemu-kvm` package. I've added a `AppStream` repo from 8.1, with `includepkgs=qemu*` and `exclude=qemu*` in the system provided repo and after removing/installing qemu was then able to successfully run nested virtualization under CentOS 8.2. – grasbueschel Oct 08 '20 at 09:31
  • I'm on a fresh installation of Ubuntu 20.04. Is there any information on this topic? I compiled qemu from git and this problem is still present. Where to start looking? – Alex Oct 22 '20 at 18:19
  • @grasbueschel Having the same issue here with CentOS 8.3. Could you give details on the appstream repo you used ? Thanks – Orsiris de Jong Jan 07 '21 at 18:35
  • @OrsirisdeJong I guess one could use `mirrorlist.centos.org` in the repofile (`mirrorlist` parameter) with a correctly set `releasever`, but I happened to use the next best server as `baseurl` in the repo file with a value of `https://ftp.tugraz.at/mirror/centos/8.1.1911/AppStream/x86_64/os`. So I copied the AppStream repo file, renamed the repo to `AppStream-81`, added the `includepkgs` line as stated above, removed `mirrorlist` key, added `baseurl` key. Hope this helps! – grasbueschel Jan 07 '21 at 20:32
  • @Alex sorry, haven't seen your comment earlier. I guess you could try the same for Ubuntu (which I'm not that familiar with): find the `apt.sources` from an older distribution and add that repository with just the `qemu-kvm` package (and exclude the package from the current repository). It's definitely a change in the `qemu-kvm` package, so for now, finding and installing an older version should do the trick. – grasbueschel Jan 07 '21 at 20:36
  • @OrsirisdeJong forgot to mention the exclude line within the current (8.3) AppStream repo file: `exclude=qemu-kvm qemu-kvm-common qemu-kvm-core` – grasbueschel Jan 07 '21 at 20:38
  • @grasbueschel I struggled to get things to work properly, posted my experience below ;) Thanks for your help. – Orsiris de Jong Jan 08 '21 at 10:33
2

[EDIT]

Kernel 4.18.0-259.el8.x86_64 resolves the issue and works with latest qemu 4.2.0-34.module_el8.3.0+613+9ec9f184.1.x86_64

So there's no need to downgrade qemu packages to CentOS 8.1 anymore

[/EDIT]

since @grabueschel got us a valid answer, I digged a bit more.

Indeed, CentOS 8.1 packages work for nested Hyper-V L1 on kvm L0 virtualization, CentOS 8.2+ packages don't. I've made a full bug report here

Not sure whether this will help. Looking into the RPM changelog, maybe - Resolves: bz#1689270 (Nested KVM: limit VMX features according to CPU models - Slow Train) could be the culprit.

Anyway, in order to get nested virtualization to work with Hyper-V (Win10 2009H2 version), I had to do the following:

dnf remove qemu-kvm
cp /etc/yum.repos.d/CentOS-Linux-AppStream.repo /etc/yum.repos.d/CentOS-Linux-AppStream81.repo

Modify /etc/yum.repos.d/CentOS-Linux-AppStream.repo, add exclude=qemu*

Modify /etc/yum.repos.d/CentOS-Linux-AppStream81.repo to point to the CentOS vault

[appstream81]
name=CentOS Linux 8.1 - AppStream
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=AppStream&infra=$infra
#baseurl=http://mirror.centos.org/$contentdir/$releasever/AppStream/$basearch/os/
baseurl=http://vault.centos.org/8.1.1911/AppStream/$basearch/os/
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial
include=qemu*

Then reinstall qemu

dnf install qemu-kvm

This made nested virtualization possible, once the CPU used was set to passthrough as suggested by Redhat here.

Nevertheless I encountered a lot of stability problems, and following advice given here, I modified the CPU to ignore TSX.

In my case I virsh edit myVM to the following

  <cpu mode='custom' match='exact' check='partial'>
    <model fallback='allow'>Skylake-Client-noTSX-IBRS</model>
    <feature policy='require' name='hypervisor'/>
    <feature policy='require' name='vmx'/>
  </cpu>

Once this custom CPU model was set, my Hyper-V under KVM got stable.

Test machine was Intel(R) Xeon(R) CPU E3-1275 v6 @ 3.80GHz skylake processor with microcode sig=0x906e9, pf=0x2, revision=0xde

Orsiris de Jong
  • 213
  • 1
  • 10
  • This should probably be the accepted answer at this point. The xml snippet is some internet gold. Ty Orsiris! – stevens Apr 14 '22 at 18:32
  • 2
    Thanks, glad to see my post helps ;) – Orsiris de Jong Apr 14 '22 at 20:20
  • Just the XML (in my case with `Haswell-noTSX-IBRS`) did the trick. As said above pure gold. Btw. here is a list of all cpu models supported by qemu: https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html – Blightbuster Jun 15 '22 at 19:56