L0 KVM un Win10 L1 ligzdotā virtualizācija nedarbojas (Windows sāknēšanas cilpa)

Man ir grūti iegūt ligzdotu virtualizāciju savā Win10 Pro viesī, kas darbojas KVM resursdatorā. Iespējojot Windows Hypervisor hypervisorlaunchtype auto , tiek sāknēšanas cilpa / sāknēšana uz Automātisko labošanu.

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

Viesis:

Microsoft Windows [Version 10.0.19041.508]

Esmu izmēģinājis vairākas konfigurācijas, migrēju Windows no BIOS uz UEFI, mēģināju tīru Windows instalāciju, atspējoju / pārstartēju / iespējoju / pārstartēju Hypervisor funkcijas utt., kas vēl nedarbojas.

Mana pašreizējā konfigurācija:

  <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>

Ņemiet vērā pēdējo funkciju hipervizoru : Ja atspējojiet , Windows sāknēšana un ziņo, ka Hyper-V darbojas sistēmas žurnāli ziņo, ka hipervizors nedarbojas. Iestatot funkciju pieprasīt , sāknēšanas cilpa / sāknēšana tiek novirzīta uz Automātisko remontu.

Un, tā kā šajā kontekstā ir mazliet grūti google meklēt šo opciju:

  • Ko dara hipervizors iezīme tieši darīt? Kur tas ir dokumentēts?

Man šķiet, ka Windows hipervizors, palaižot, avarē ar iespējotu funkciju un ar atspējotu funkciju, vienkārši nevar sākt un turpināt sāknēšanas procesu.

Tagad man nav ideju, ko vēl es varētu izmēģināt un arī ticēt ka esmu pārbaudījis gandrīz visus meklēšanas rezultātus par šo tēmu. Bet varbūt es kaut ko esmu palaidis garām, tāpēc, lūdzu,

  • Vai kāds var ziņot par šādu veiksmīgu iestatīšanu? Un, ja tā, viesa konfigurācijas koplietošana būtu lieliska!
  • Vai ir kādas citas idejas, kuras man vajadzētu mēģināt padarīt šo darbu?

Paldies!

PS: Pati virtualizācija darbojas lieliski un ātri, tāpēc esmu diezgan pārliecināts, ka viss no aparatūras puses ir OK, bet varbūt ir lietas, kuras arī man vajadzētu pārbaudīt?!

1
задан 2 October 2020 в 12:23
2 ответа

Несколько месяцев назад я установил два хоста KVM, используя CentOS 8.1.1911 с виртуальной машиной Hyper-V в качестве вложенного гостя, и все работало нормально.

Пару месяцев спустя я установил третий хост KVM с почти идентичной аппаратной и программной конфигурацией. Единственная разница заключалась в материнской плате с тем же чипсетом, но под маркой Gigabyte, а не под маркой ASUS, как в первых двух. Я установил этот хост на CentOS 8.2.2004 и испытал то же, что и вы - бутлупы. Я попробовал последнюю версию Fedora на тот момент, и она тоже загрузилась. Поскольку вложенная виртуализация на этом хосте была не нужна, я просто не использовал ее и предположил, что виновата плата Gigabyte.

Перенесемся в сегодняшний день, когда я решил обновить свои хосты 8.1 до 8.2. После завершения обновления и перезагрузки - вложенная виртуальная машина Hyper-V начала загрузку.

Я откатился до версии 8.1.1911, используя отмену истории yum, и сразу после этого гость Hyper-V снова заработал.

TL;DR: может быть проблема с последней версией CentOS (8.2.2004). Попробуйте установить 8.1 (8.1.1911) и посмотрите, как у вас пойдет.

2
ответ дан 4 October 2020 в 08:09

[EDIT]

Ядро 4.18.0-259.el8.x86_64 решает проблему и работает с последней версией qemu 4.2.0-34.module_el8.3.0+613+9ec9f184 .1.x86_64

Таким образом, нет необходимости понижать версию пакетов qemu до CentOS 8.1 больше

[/EDIT]

поскольку @grabueschel дал нам правильный ответ, я копнул немного больше.

Действительно, пакеты CentOS 8.1 работают для вложенных Hyper-V L1 на виртуализацию kvm L0, а пакеты CentOS 8.2+ — нет. Я сделал полный отчет об ошибке здесь

Не уверен, что это поможет. Глядя в журнал изменений RPM, возможно, - Решает: bz # 1689270 (вложенный KVM: ограничение функций VMX в соответствии с моделями ЦП - Slow Train) может быть виновником.

В любом случае, чтобы заставить вложенную виртуализацию работать с Hyper-V (версия Win10 2009H2), мне пришлось сделать следующее:

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

Изменить /etc/yum.repos.d/CentOS-Linux- AppStream.repo, добавьте exclude=qemu*

Измените /etc/yum.repos.d/CentOS-Linux-AppStream81.repo, чтобы указать на хранилище CentOS

[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*

Затем переустановите qemu

dnf install qemu-kvm

. Это сделало возможной вложенную виртуализацию после того, как используемый ЦП был настроен на сквозную передачу, как это было предложено Redhat здесь.

Тем не менее, я столкнулся со множеством проблем со стабильностью и, следуя совету, данному здесь, я модифицировал ЦП, чтобы он игнорировал TSX.

В моем случае я изменил myVM на следующее

  <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>

После того, как эта пользовательская модель ЦП была установлена, мой Hyper-V под управлением KVM стал стабильным.

Тестовой машиной был процессор Intel(R) Xeon(R) E3-1275 v6 @ Skylake с тактовой частотой 3,80 ГГц с микрокодом sig=0x906e9, pf=0x2, ревизия=0xde

0
ответ дан 8 January 2021 в 09:32

Теги

Похожие вопросы