GNU/Linux >> Tutoriels Linux >  >> Linux

Pourquoi OpenStack signale-t-il le type d'hyperviseur comme QEMU alors que libvirt_type est KVM ?

J'ai installé OpenStack Mitaka et j'étais curieux de vérifier diverses fonctionnalités dans le tableau de bord horizon. Par exemple, le Système> Hyperviseurs Le menu du tableau de bord fournit un résumé des différents hôtes de calcul, son type d'hyperviseur et les détails d'utilisation - où j'ai été surpris de voir le type d'hyperviseur signalé comme QEMU et non KVM, bien que les nœuds de calcul aient été configurés pour utiliser KVM. Le même type d'hyperviseur a été signalé lors de l'utilisation de nova hypervisor-show |grep hypervisor_type commande également.

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

Le nova.conf le fichier est configuré pour utiliser  libvirt_type=kvm

[libvirt]
libvirt_type=kvm
compute_driver=libvirt.LibvirtDriver

J'ai recherché ce problème sur Google et compris que la commande client OpenStack utilise le type de connexion libvirt pour déterminer le type d'hyperviseur au lieu d'utiliser l'attribut libvirt_type dans nova.conf . Voici un rapport détaillé sur ce bogue.

Cependant, je voulais savoir si les instances sont démarrées sur l'hyperviseur KVM au lieu de QEMU. Heureusement, il existe plusieurs façons de procéder.

J'ai exécuté toutes ces commandes sur le nœud de calcul.

Vérifier si les modules KVM sont chargés

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

Vérifier si /dev/kvm existe

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

Vérifier si /dev/kvm est accessible à QEMU

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

La sortie ci-dessus signifie que QEMU utilise peut-être l'accélérateur KVM.

Vérifier si l'accélérateur KVM est utilisé par QEMU

[compute_node]# ps -aef|grep kvm

Exemple de résultat :

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

Dans la sortie ci-dessus, vous pouvez voir le processus qemu-system-x86_64 utilisant l'accélérateur kvm . Selon cette page, si votre nœud de calcul exécute qemu processus avec l'accélérateur KVM, alors l'hyperviseur est QEMU avec KVM.

Vérifier libvirt.xml d'une instance

[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"/>

Dans le libvirt.xml recherche de fichier pour type=kvm et driver=qemu , ce qui signifie que l'hyperviseur est QEMU avec KVM.

Vérifier console.log de l'instance

[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

Vider le xml d'instance pour vérifier le type d'hyperviseur

Lancez virsh comme indiqué ci-dessous :

# virsh

Répertoriez les instances :

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

Copiez l'identifiant d'une instance - dites "instance-00000021" et videz son xml comme indiqué ci-dessous :

virsh # quit

Vider le xml d'une instance :

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

Les sorties ci-dessus confirment que QEMU utilise l'accélérateur KVM.

Bonus…

Vous pouvez également vous connecter à n'importe quelle instance et effectuer quelques techniques de détection de virtualisation pour identifier le type d'hyperviseur sous-jacent, comme indiqué ici .

Conclusion

Bien que le tableau de bord OpenStack et les commandes client signalent le type d'hyperviseur comme QEMU, il s'agit en fait de QEMU avec accélérateur KVM et pas seulement de QEMU (qui n'est qu'un émulateur logiciel). La conclusion est donc qu'il peut s'agir d'un bogue dans OpenStack qui signale le type d'hyperviseur comme QEMU lorsque QEMU avec KVM est activé ou c'est simplement la façon dont OpenStack signale. Peu de forums affirment qu'il s'agit d'un bogue dans la documentation d'OpenStack qui ne mentionnait pas clairement le type d'hyperviseur pris en charge (bien que je vois une page répertoriant le type d'hyperviseurs pris en charge dans OpenStack, il manque la différence entre QEMU et KVM).


Linux
  1. Pourquoi rsync n'utilise-t-il pas delta-transfer pour les fichiers locaux ?

  2. Pourquoi `find` sous Linux ignore-t-il les résultats attendus lorsque `-o` est utilisé ?

  3. Pourquoi clang génère-t-il du texte inintelligible lorsqu'il est redirigé ?

  4. Pourquoi `xdg-mime query filetype ...` ne parvient-il pas à trouver un nouveau type de fichier ajouté ?

  5. Pourquoi slabtop -o ne renvoie-t-il que les 23 premières lignes lorsque la commande est canalisée ?

Pourquoi Sudo ignore-t-il les alias ?

Pourquoi le curseur saute-t-il lors de la frappe ?

Pourquoi "/var/log/messages" signale-t-il des paquets martiens

Pourquoi ce pipeline shell sort-il ?

Bash :Pourquoi le script parent ne se termine-t-il pas sur SIGINT lorsque le script enfant piège SIGINT ?

Quand un signal est-il traité et pourquoi certaines informations se bloquent-elles ?