GNU/Linux >> LINUX-Kenntnisse >  >> Linux

Warum meldet OpenStack den Hypervisor-Typ als QEMU, wenn libvirt_type KVM ist?

Ich habe OpenStack Mitaka installiert und war neugierig, verschiedene Funktionen im Horizont-Dashboard zu überprüfen. Zum Beispiel die System> Hypervisors Das Menü im Dashboard bietet eine Zusammenfassung verschiedener Rechenhosts, ihres Hypervisortyps und Nutzungsdetails – wobei ich überrascht war, dass der Hypervisortyp als QEMU und nicht als KVM gemeldet wurde, obwohl die Rechenknoten für die Verwendung von KVM konfiguriert waren. Derselbe Hypervisor-Typ wurde bei Verwendung von nova hypervisor-show |grep hypervisor_type gemeldet auch befehlen.

# nova hypervisor-show 1 |grep hypervisor_type
| hypervisor_type | QEMU

Die nova.conf Datei ist für die Verwendung von  libvirt_type=kvm konfiguriert

[libvirt]
libvirt_type=kvm
compute_driver=libvirt.LibvirtDriver

Ich habe dieses Problem gegoogelt und verstanden, dass der OpenStack-Client-Befehl den libvirt-Verbindungstyp verwendet, um den Hypervisor-Typ zu bestimmen, anstatt das libvirt_type-Attribut in nova.conf zu verwenden . Hier ist ein detaillierter Bericht zu diesem Fehler.

Ich wollte jedoch wissen, ob die Instanzen auf dem KVM-Hypervisor anstelle von QEMU gestartet werden. Glücklicherweise gibt es dafür nur wenige Möglichkeiten.

Ich habe alle diese Befehle auf dem Rechenknoten ausgeführt.

Überprüfen Sie, ob KVM-Module geladen sind

[compute_node]# lsmod |grep kvm
kvm_intel 172032 9
kvm 536576 1 kvm_intel
irqbypass 16384 7 kvm

Überprüfen Sie, ob /dev/kvm existiert

[compute_node]# ls -l /dev/kvm
crw-rw---- 1 root kvm 10, 232 Jun 14 11:01 /dev/kvm

Überprüfen Sie, ob /dev/kvm für QEMU zugänglich ist

[compute_node]# virt-host-validate |grep kvm
 QEMU: Checking if device /dev/kvm exists : PASS
 QEMU: Checking if device /dev/kvm is accessible

Die obige Ausgabe bedeutet, dass QEMU möglicherweise den KVM-Beschleuniger verwendet.

Überprüfen Sie, ob der KVM-Beschleuniger von QEMU verwendet wird

[compute_node]# ps -aef|grep kvm

Beispielausgabe:

/usr/bin/qemu-system-x86_64  -name instance-00000021 -S  -machine pc-i440fx-wily,accel=kvm,usb=off -cpu Nehalem

In der obigen Ausgabe sehen Sie den Prozess qemu-system-x86_64 unter Verwendung des Beschleunigers kvm . Laut dieser Seite, wenn Ihr Rechenknoten qemu ausführt Prozess mit KVM-Beschleuniger, dann ist der Hypervisor QEMU mit KVM.

Libvirt.xml einer Instanz prüfen

[compute_node]# cd /var/lib/nova/instances/<instance_id>
[compute_node]# cd /var/lib/nova/instances/b127f332-c631-4bd0-bde0-e90626d8bc27
[compute_node]# grep type libvirt.xml
<domain type="kvm">
<nova:root type="image" uuid="2cfff576-95e8-45cf-814a-63b695cb32e5"/>
<sysinfo type="smbios">
<type>hvm</type>
<disk type="file" device="disk">
<driver name="qemu" type="qcow2" cache="none"/>
<interface type="bridge">
<model type="virtio"/>
<serial type="file">
<serial type="pty"/>
<input type="tablet" bus="usb"/>
<graphics type="vnc" autoport="yes" keymap="en-us" listen="0.0.0.0"/>
<model type="cirrus"/>

In der libvirt.xml Dateisuche nach type=kvm und driver=qemu , was bedeutet, dass der Hypervisor QEMU mit KVM ist.

Console.log der Instanz prüfen

[compute_node]# cd /var/lib/nova/instances/<instance_id>
[compute_node]# cd /var/lib/nova/instances/b127f332-c631-4bd0-bde0-e90626d8bc27
[compute_node]# grep KVM console.log
[ 0.000000] Booting paravirtualized kernel on KVM
[ 0.000000] KVM setup async PF for cpu 0

Instanz-XML ausgeben, um den Hypervisortyp zu überprüfen

Starten Sie virsh wie unten gezeigt:

# virsh

Listen Sie die Instanzen auf:

virsh # list
 Id Name State
 ----------------------------------------------------
 4 instance-00000021 running
 5 instance-00000023 running
 6 instance-00000024 running

Kopieren Sie die ID einer der Instanzen – sagen Sie „instance-00000021“ und sichern Sie ihre XML-Datei wie unten gezeigt:

virsh # quit

Dump-XML einer Instanz:

# virsh dumpxml instance-00000021 | grep kvm
 <domain type='kvm' id='4'>
# virsh dumpxml instance-00000021 | grep driver
 <driver name='qemu' type='qcow2' cache='none'/>
# virsh dumpxml instance-00000021 | grep emulator
 <emulator>/usr/bin/qemu-system-x86_64</emulator>

Die obigen Ausgaben bestätigen, dass QEMU den KVM-Beschleuniger verwendet.

Bonus…

Sie können sich auch bei einer der Instanzen anmelden und einige Techniken zur Virtualisierungserkennung durchführen, um den zugrunde liegenden Hypervisortyp wie hier gezeigt zu identifizieren .

Schlussfolgerung

Obwohl das OpenStack-Dashboard und die Client-Befehle den Hypervisor-Typ als QEMU melden, ist es eigentlich QEMU mit KVM-Beschleuniger und nicht nur QEMU (das nur ein Software-Emulator ist). Die Schlussfolgerung ist also, dass es sich möglicherweise um einen Fehler in OpenStack handelt, der den Hypervisor-Typ als QEMU meldet, wenn QEMU mit KVM aktiviert ist, oder es ist nur die Art und Weise, wie OpenStack meldet. Nur wenige Foren argumentieren, dass es sich um einen Fehler in der OpenStack-Dokumentation handelt, der den Typ des unterstützten Hypervisors nicht klar erwähnt hat (obwohl ich eine Seite sehe, die den Typ des in OpenStack unterstützten Hypervisors auflistet, fehlt der Unterschied zwischen QEMU und KVM).


Linux
  1. Warum ist die Windows10-VM auf OpenStack langsam?

  2. Warum überspringt `find` unter Linux erwartete Ergebnisse, wenn `-o` verwendet wird?

  3. Warum generiert Clang bei der Weiterleitung unverständlichen Text?

  4. Warum findet `xdg-mime query filetype ...` keinen neu hinzugefügten Dateityp?

  5. Warum gibt slabtop -o nur die ersten 23 Zeilen zurück, wenn der Befehl weitergeleitet wird?

Warum funktioniert `exit &` nicht?

Warum springt der Cursor beim Tippen?

Warum meldet „/var/log/messages“ Marspakete?

Warum wird diese Shell-Pipeline beendet?

Warum muss stdout explizit geleert werden, wenn es in eine Datei umgeleitet wird?

Wann wird ein Signal behandelt und warum frieren einige Informationen ein?