Was für eine Virtualisierung ist dies? KVM+Hyper-V?

Moin,

kann mir Jemand sagen was hier für eine Virtualisierung verwendet wird?
Ich tippe mal auf QEMU mit KVM unter einem Hyper-V.

lscpu
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         40 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  2
  On-line CPU(s) list:   0,1
Vendor ID:               AuthenticAMD
  Model name:            AMD Opteron 62xx class CPU
    CPU family:          21
    Model:               1
    Thread(s) per core:  1
    Core(s) per socket:  1
    Socket(s):           2
    Stepping:            2
    BogoMIPS:            5599.99
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall
                         nx mmxext pdpe1gb rdtscp lm rep_good nopl cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 cx16 sse4_1
                          sse4_2 x2apic popcnt aes xsave avx hypervisor lahf_lm cmp_legacy svm abm sse4a misalignsse 3dnowprefetch
                         osvw ssbd ibpb vmmcall virt_ssbd arat npt nrip_save
Virtualization features:
  **Virtualization:        AMD-V**
  **Hypervisor vendor:     Microsoft**
  **Virtualization type:   full**
Caches (sum of all):
  L1d:                   128 KiB (2 instances)
  L1i:                   128 KiB (2 instances)
  L2:                    1 MiB (2 instances)
NUMA:
  NUMA node(s):          1
  NUMA node0 CPU(s):     0,1
Vulnerabilities:
  Itlb multihit:         Not affected
  L1tf:                  Not affected
  Mds:                   Not affected
  Meltdown:              Not affected
  Mmio stale data:       Not affected
  Retbleed:              Mitigation; untrained return thunk; SMT disabled
  Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl and seccomp
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Retpolines, IBPB conditional, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected
  Srbds:                 Not affected
  Tsx async abort:       Not affected

dmidecode | grep -i -e manufacturer -e product -e vendor
        Vendor: SeaBIOS
        Manufacturer: QEMU
        Product Name: Standard PC (i440FX + PIIX, 1996)
        **Manufacturer: QEMU**
        Manufacturer: QEMU
        Manufacturer: QEMU
        Manufacturer: QEMU

 grep -i -e virtual -e vbox -e xen /var/log/dmesg
[    0.123652] kernel: **Booting paravirtualized kernel on KVM**
[    3.199133] kernel: input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input4
[    3.267346] kernel: input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input3
[    4.811839] systemd[1]: **Detected virtualization microsoft**.
[    7.134978] kernel: **kvm: Nested Virtualization enabled**

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 54217049219

Url: https://administrator.de/forum/was-fuer-eine-virtualisierung-ist-dies-kvm-hyper-v-54217049219.html

Ausgedruckt am: 23.04.2025 um 06:04 Uhr

8 Kommentare

Neuester Kommentar

Moin,

das sieht nach KVM mit merkwürdigen VM Einstellungen aus.
Steck ich aber nicht so tief drin.

Gruß
Spirit

Uff gute Frage. Nested irgendwas?

https://www.redpill-linpro.com/techblog/2021/04/07/nested-virtualization ...

So die Richtung?

Ich tippe ja mal auf KVM in einem QEMU zur Verwaltung und das ganze auf einem Hyper-V.
Das ist ein Hochverfügbarer Server von IONOS (ex. Profitbricks).

Stefan

Moin,

ggf. ein Docker-Container, der per QEMU bereitgestellt wird und selbst auf einem Hyper-V Cluster läuft?
Mal so ganz blind geraten...

Das ist ein Hochverfügbarer Server von IONOS (ex. Profitbricks).

Ist garantiert, dass du einen vollwertigen Server hast?

Also einmal meine Mutmaßung:

KVM/QEMU hat eine Besondertheit, weil es eigentlich ein Hypervisor Typ 1 ist, aber mittels QEMU erweiterte Möglichkeiten bietet, die in Richtung Hypervisor Typ 2 gehen. So kann bei QEMU aus einer größeren Zahl von CPU's ausgewählt werden. Aktuell unter Debian sind das beispielsweise AMD Opteron Generation 1 bis 4. Eine AMD-CPU Opteron 62xx würde ich aus der Zeit von 2010 bis 2013/4 der Generation 2 zuordnen. Neben der CPU kommt auch eine eher sehr kleine Auswahlmöglichkeit von Chipsätzen hinzu.

Es kann daher sein, dass bei der Erstellung der betreffenden VM eine CPU-Chipsatz-Wahl getroffen wurde, die von dem Gastsystem als Microsoft kompatibler Hypervisor (fehl)interpretiert wird. Läuft das Hostbetriebssystem auf einer AMD-Basis und wird seitens KVM/QEMU die physische Architektur standardmäßig an die VM weitervermittelt, werden nicht nur der Prozessor, sondern auch der Hypervisor mit "KVM" richtig angezeigt. Die beiden "x" in der Modellnummer "62xx" legen das sehr deutlich nahe.
Meines Wissens nach ist Hyper-V (jedenfalls bis 2012R2) nativ nicht in der Lage, eine CPU oder einen Chipsatz der VM als Emulation anzubieten.

Ich glaube vorerst eher nicht, dass es bei dem Anwendungsfall eine kaskadierte Virtualisierung handelt, wenn es sich nicht um ein Testszenario dreht.

Viele Grüße
HansDampf06

ERGÄNZUNG: Sowohl bei einem AMD-Host als auch bei einem Intel-Host mit KVM/QEMU, bei denen die Prozesserarchitektur durchgereicht wird, stimmen die hier diskutierten Angaben mit der physischen Realität überein. Jedoch unterstützen diese Prozessoren (noch) nicht Nested Virtualisation, so dass sich folgerichtig keine Angabe dazu findet.

Könnte auch das hier sein:
https://www.qemu.org/docs/master/system/i386/hyperv.html

When any set of the Hyper-V enlightenments is enabled, QEMU changes hypervisor identification (CPUID 0x40000000..0x4000000A) to Hyper-V.

Allerdings spricht das hier aus Deinem Screenshot

kvm: Nested Virtualization enabled

ja für Nested Virtualization. Du solltest ja vom Host aus schrittweise vorgehen können, die erste (erstrangige) VM herausfinden und dann schauen, ob da eine weitere Virtualisierungsschicht läuft.

Viele Grüße, commodity

Zitat von @commodity:
Könnte auch das hier sein:
https://www.qemu.org/docs/master/system/i386/hyperv.html

When any set of the Hyper-V enlightenments is enabled, QEMU changes hypervisor identification (CPUID 0x40000000..0x4000000A) to Hyper-V.

Allerdings spricht das hier aus Deinem Screenshot

kvm: Nested Virtualization enabled

ja für Nested Virtualization. Du solltest ja vom Host aus schrittweise vorgehen können, die erste (erstrangige) VM herausfinden und dann schauen, ob da eine weitere Virtualisierungsschicht läuft.

Das bestätigt eher meine Mutmaßung, dass als Hypervisor-Meldung etwas vorgegaukelt wird und dass gerade keine Nested Virtualisation stattfindet. Lediglich die Funktion ist wie mitgeteilt verfügbar und die VM selbst könnte auch wieder als Hypervisor auftreten. So würde ich das jedenfalls interpretieren.

Viele Grüße
HansDampf06