Différences entre les versions de « Kvm »

De BlaxWiki
Aller à la navigationAller à la recherche
 
(40 versions intermédiaires par 2 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
__FORCETOC__
__FORCETOC__
[https://{{SERVERNAME}}/BENPERSO/doc-manuel/system/virtualisation/best_practice_kvm_IBM_us.pdf Best pratice KVM](de IBM, tiré de ce [http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/topic/liaat/liaatbestpractices_pdf.pdf lien])
'''/!\/!\ Sur les vm il faut que le process acpid tourne, sinon on ne pourra pas les arreter proprement avec la commande virsh shutdown /!\/!\'''
'''Il peut arriver que le demon libvrtd ne tourne plus (donc impossible de lancer la commande virsh), mais cela n'empeche pas les vm de tourner avec qemu. On peut relancer libvirtd sans impacter les vm qui tournent'''
=== Présentation ===
<pre>
KVM est l'hyperviseur libre supporté par RedHat. Il est extrêmement simple et facile d'utilisation. Par rapport à Xen, il n'oblige pas de faire tourner un kernel linux spécifique et
se présente sous la forme de modules kernel. Chaque VM est vu comme un process lambda sur l'hyperviseur et un "ps" permet de voir les VM qui tournent.
Par défaut, il n'existe pas de commande equivalente au "xm" de Xen. Afin d'agir sur les VM KVM, il faut passer par libvirtd qui est un daemon d'abstraction multi-hyperviseur.
La configuration des VM se fait par l'intermédiaire d'un fichier de configuration XML. Les fichiers de configuration se trouvent dans /etc/libvirt/qemu/. Virsh est un utilitaire
permettant d'interroger le daemon libvirtd est interagir avec les VMs. Comme libvirtd est multi-hyperviseur, certaines commandes ne fonctionnent car non supportées
par KVM.
</pre>
=== /etc/sysctl.conf ===
<pre>
Afin de forcer le kernel à ne pas mettre en SWAP les VM : vm.swappiness = 1
</pre>


=== Démarrage auto des vm ===
=== Démarrage auto des vm ===
<pre>
<pre>
Pour que les vm soient lancées automatiquement au démarrage, on peut utiliser virsh autostart nom_de_la_vm. Si on a un message d'erreur il suffit de creer des liens symboliques dans
Pour que les vm soient lancées automatiquement au démarrage, on peut utiliser virsh autostart nomvmvm. Si on a un message d'erreur, c'est que lorsqu'on fait un virsh dominfo $nomvm,
/etc/libvirt/qemu/autostart/ :
la vm est en mode Persistent: No (mais parfois elle est en mode Persistent Yes et ca ne passe pas non plus). On peut passer en mode Persistent à yes, en faisant un virsh define
$nomvm.xml (faire un stop avant, pas obligé, le define passe bien sans que la vm soit arrétée) mais attention cela va modifier quelques parametres dans le fichier xml. Cela va juste
rajouter des lignes "<address type='pci' domain='0x0000' " (si elles n'étaient pas présentes) au niveau des "disk type", "controller type", "interface type", "model type". On peut
backuper avant l'original. On peut faire alors faire un virsh autostart $nomvm.
 
Sinon il suffit de creer des liens symboliques dans /etc/libvirt/qemu/autostart/ : lg2.infra.agarik.com.xml -> /etc/libvirt/qemu/lg2.infra.agarik.com.xml


lg2.infra.agarik.com.xml -> /etc/libvirt/qemu/lg2.infra.agarik.com.xml
La vm ne sera démmarrée au reboot que si elle tournait lorsque le serveur a redémarré.
</pre>
</pre>


Ligne 16 : Ligne 41 :
#!/bin/sh
#!/bin/sh
exec /usr/libexec/qemu-kvm `echo "$@" | sed 's|virtio-net-pci|virtio-net-pci,tx=timer|g'`
exec /usr/libexec/qemu-kvm `echo "$@" | sed 's|virtio-net-pci|virtio-net-pci,tx=timer|g'`
</pre>
=== Virbr0 ===
Par défaut kvm monte une interface virbr0 avec une ip en 192.168.122 qui sert à natter les vm, la plus part du temps on ne s'en sert pas. Pour la désactiver :
<pre>
virsh net-list
Sample outputs:
Name                State      Autostart
-----------------------------------------
default              active    yes
To disable virbr0, enter:
# virsh net-destroy default
# virsh net-undefine default
# service libvirtd restart
# ifconfig
</pre>
</pre>


=== Commande virsh ===
=== Commande virsh ===
<pre>
<pre>
virsh nodeinfo : info cpu & mémoire
* virsh nodeinfo : info cpu & mémoire total sur l hyperviseur
virsh capabilities : info plus précise sur le cpu (id cpu, nombre, capacité...)
* virsh freecell : mémoire restant de libre
virsh vcpuinfo domain : info cpu au niveau du domaine
* virsh capabilities : info plus précise sur le cpu (id cpu, nombre, capacité...)
 
* virsh vcpuinfo syslog1.infra.agarik.com : info cpu au niveau du domaine
syslog1.infra.agarik.com
syslog1.infra.agarik.com
VCPU:          0
VCPU:          0
Ligne 30 : Ligne 74 :
CPU time:      10.6s
CPU time:      10.6s
CPU Affinity:  y---
CPU Affinity:  y---
Ici cela signifie que la vm utilise le cpu id 0 uniquement (car au niveau cpu affinity le "y" est au début, si on a le "y" sur les 4 cases cela signifie que la vm peut utiliser
indifféremment n'importe lequel des cpu). Le nombre de cpu affiché par cat /proc/cpuinfo est toujours le même (celui qu'a reellement le serveur), meme lorsque les vm sont lancées


Ici cela signifie que la vm utilise le cpu id 0 uniquement (car au niveau cpu affinity le "y" est au début, si on a le "y" sur les 4 cases cela signifie que la vm peut utiliser
* virsh domiflist syslog1.infra.agarik.com (en complément de brctl show)
indifféremment n'importe lequel des cpu)
Interface  Type      Source    Model      MAC
-------------------------------------------------------
vnet4      bridge    front619  virtio      52:54:00:9f:9f:e5
vnet5      bridge    back276    virtio      52:54:00:b1:27:16
 
* uuidgen (pas une commande virsh) : génère des uuid
 
</pre>
 
=== Console sur les VM ===
Pour avoir la main sur la vm pendant le démarrage (avec la commande virsh console $nomvm)


* Debian
<pre>
- Editer /etc/default/grub et, ajouter console=ttys0 à la ligne GRUB_CMDLINE_LINUX.
- Mettre à jour GRUB : update-grub
- Editer etc/inittab et décommenter la ligne T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
</pre>
</pre>


* Centos
<pre>
# Pour voir les messages au boot et prendre la main avant la fin du démarrage (avec la commande virsh console $nomvm)
- Editer le fichier /boot/grub/grub.conf, et, ajouter à la ligne kernel les éléments suivants : console=ttyS0,115200 (supprimer "quiet" et "rhgb" si ils sont présent)
# Pour prendre la main en console une fois le boot terminé
- Editer /etc/securetty et ajouter ttyS0
- Pour avoir accès à la console après l'amorçage, créer le fichier /etc/init/Stty.conf avec le contenu suivant :
    stop on runlevel [016]
    start on runlevel [345]
    respawn
    instance /dev/ttyS0
    exec /sbin/mingetty /dev/ttyS0
</pre>


[[Catégorie:Virtualisation]]
[[Catégorie:Virtualisation]]

Version actuelle datée du 8 novembre 2013 à 16:47

Best pratice KVM(de IBM, tiré de ce lien)

/!\/!\ Sur les vm il faut que le process acpid tourne, sinon on ne pourra pas les arreter proprement avec la commande virsh shutdown /!\/!\

Il peut arriver que le demon libvrtd ne tourne plus (donc impossible de lancer la commande virsh), mais cela n'empeche pas les vm de tourner avec qemu. On peut relancer libvirtd sans impacter les vm qui tournent

Présentation[modifier]

KVM est l'hyperviseur libre supporté par RedHat. Il est extrêmement simple et facile d'utilisation. Par rapport à Xen, il n'oblige pas de faire tourner un kernel linux spécifique et
se présente sous la forme de modules kernel. Chaque VM est vu comme un process lambda sur l'hyperviseur et un "ps" permet de voir les VM qui tournent.
Par défaut, il n'existe pas de commande equivalente au "xm" de Xen. Afin d'agir sur les VM KVM, il faut passer par libvirtd qui est un daemon d'abstraction multi-hyperviseur.
La configuration des VM se fait par l'intermédiaire d'un fichier de configuration XML. Les fichiers de configuration se trouvent dans /etc/libvirt/qemu/. Virsh est un utilitaire 
permettant d'interroger le daemon libvirtd est interagir avec les VMs. Comme libvirtd est multi-hyperviseur, certaines commandes ne fonctionnent car non supportées 
par KVM. 

/etc/sysctl.conf[modifier]

Afin de forcer le kernel à ne pas mettre en SWAP les VM : vm.swappiness = 1

Démarrage auto des vm[modifier]

Pour que les vm soient lancées automatiquement au démarrage, on peut utiliser virsh autostart nomvmvm. Si on a un message d'erreur, c'est que lorsqu'on fait un virsh dominfo $nomvm,
la vm est en mode Persistent: No (mais parfois elle est en mode Persistent Yes et ca ne passe pas non plus). On peut passer en mode Persistent à yes, en faisant un virsh define 
$nomvm.xml (faire un stop avant, pas obligé, le define passe bien sans que la vm soit arrétée) mais attention cela va modifier quelques parametres dans le fichier xml. Cela va juste 
rajouter des lignes "<address type='pci' domain='0x0000' " (si elles n'étaient pas présentes) au niveau des "disk type", "controller type", "interface type", "model type". On peut 
backuper avant l'original. On peut faire alors faire un virsh autostart $nomvm.

Sinon il suffit de creer des liens symboliques dans /etc/libvirt/qemu/autostart/ : lg2.infra.agarik.com.xml -> /etc/libvirt/qemu/lg2.infra.agarik.com.xml

La vm ne sera démmarrée au reboot que si elle tournait lorsque le serveur a redémarré.

Problème perf réseau[modifier]

Avec une centos 6.0 il y avait de gros problème de perf réseau (perte de paquets, coupure réseau)
Au lieu d'avoir : <emulator>/usr/libexec/qemu-kvm</emulator>, il faut mettre     <emulator>/usr/libexec/qemu-kvm.txtimer</emulator>
Ce fichier contient en fait : 
#!/bin/sh
exec /usr/libexec/qemu-kvm `echo "$@" | sed 's|virtio-net-pci|virtio-net-pci,tx=timer|g'`

Virbr0[modifier]

Par défaut kvm monte une interface virbr0 avec une ip en 192.168.122 qui sert à natter les vm, la plus part du temps on ne s'en sert pas. Pour la désactiver :

virsh net-list
Sample outputs:

Name                 State      Autostart
-----------------------------------------
default              active     yes

To disable virbr0, enter:

# virsh net-destroy default
# virsh net-undefine default
# service libvirtd restart
# ifconfig 

Commande virsh[modifier]

* virsh nodeinfo : info cpu & mémoire total sur l hyperviseur
* virsh freecell : mémoire restant de libre
* virsh capabilities : info plus précise sur le cpu (id cpu, nombre, capacité...)
* virsh vcpuinfo syslog1.infra.agarik.com : info cpu au niveau du domaine
syslog1.infra.agarik.com
VCPU:           0
CPU:            0
State:          running
CPU time:       10.6s
CPU Affinity:   y---
Ici cela signifie que la vm utilise le cpu id 0 uniquement (car au niveau cpu affinity le "y" est au début, si on a le "y" sur les 4 cases cela signifie que la vm peut utiliser 
indifféremment n'importe lequel des cpu). Le nombre de cpu affiché par cat /proc/cpuinfo est toujours le même (celui qu'a reellement le serveur), meme lorsque les vm sont lancées

* virsh domiflist syslog1.infra.agarik.com (en complément de brctl show)
Interface  Type       Source     Model       MAC
-------------------------------------------------------
vnet4      bridge     front619   virtio      52:54:00:9f:9f:e5
vnet5      bridge     back276    virtio      52:54:00:b1:27:16

* uuidgen (pas une commande virsh) : génère des uuid

Console sur les VM[modifier]

Pour avoir la main sur la vm pendant le démarrage (avec la commande virsh console $nomvm)

  • Debian
 - Editer /etc/default/grub et, ajouter console=ttys0 à la ligne GRUB_CMDLINE_LINUX.
 - Mettre à jour GRUB : update-grub
 - Editer etc/inittab et décommenter la ligne T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
  • Centos
# Pour voir les messages au boot et prendre la main avant la fin du démarrage (avec la commande virsh console $nomvm)
 - Editer le fichier /boot/grub/grub.conf, et, ajouter à la ligne kernel les éléments suivants : console=ttyS0,115200 (supprimer "quiet" et "rhgb" si ils sont présent)

# Pour prendre la main en console une fois le boot terminé
 - Editer /etc/securetty et ajouter ttyS0
 - Pour avoir accès à la console après l'amorçage, créer le fichier /etc/init/Stty.conf avec le contenu suivant :
    stop on runlevel [016]
    start on runlevel [345]
    respawn
    instance /dev/ttyS0
    exec /sbin/mingetty /dev/ttyS0