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.
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: 29.03.2025 um 11:03 Uhr
8 Kommentare
Neuester Kommentar
Uff gute Frage. Nested irgendwas?
https://www.redpill-linpro.com/techblog/2021/04/07/nested-virtualization ...
So die Richtung?
https://www.redpill-linpro.com/techblog/2021/04/07/nested-virtualization ...
So die Richtung?
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.
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
Viele Grüße, commodity
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 Screenshotkvm: 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
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.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 Screenshotkvm: 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
HansDampf06
Klingt plausibel. Dann wollen wir mal sehen, was die konkrete Untersuchung des Kollegen @StefanKittel ergibt 
Viele Grüße, commodity
Viele Grüße, commodity