KVM

La machine virtuelle à noyau, ou KVM, est une solution de virtualisation complète pour Linux sur du matériel x86 (64 bits inclus) et ARM contenant des extensions de virtualisation (Intel VT ou AMD-V). Elle se compose d’un module noyau chargeable, kvm.ko, qui fournit l’infrastructure de virtualisation de base et d’un module spécifique au processeur, kvm-intel.ko ou kvm-amd.ko.

Dans Debian, Xen est une alternative à KVM. (VirtualBox n’est pas dans Debian main et pas dans Debian Buster et ne le sera pas dans Debian Buster-Backports, 794466).

Installation

Il est possible d’installer uniquement QEMU et KVM pour une installation très minimale, mais la plupart des utilisateurs voudront également libvirt pour une configuration et une gestion pratiques des machines virtuelles (libvirt-daemon-system – libvirt, virt-manager – une interface graphique pour libvirt). Typiquement, un utilisateur devrait installer :

# apt-get install qemu-system libvirt-clients libvirt-daemon-system

Lors de l’installation sur un serveur, vous pouvez ajouter l’option –no-install-recommends apt, pour empêcher l’installation de paquets graphiques superflus :

# apt-get install --no-install-recommends qemu-system libvirt-clients libvirt-daemon-system

Le démon libvirt-bin démarrera automatiquement au moment du démarrage et chargera les modules KVM appropriés, kvm-amd ou kvm-intel, qui sont livrés avec le paquet Debian du noyau Linux. Si vous avez l’intention de créer des machines virtuelles (VM) à partir de la ligne de commande, installez virtinst.

Pour gérer les machines virtuelles en tant qu’utilisateur ordinaire, cet utilisateur doit être ajouté au groupe libvirt :

# adduser <youruser> libvirt

Vous devriez alors pouvoir lister vos domaines, c’est-à-dire les machines virtuelles gérées par libvirt :

# virsh list --all

Machines virtuelles spécifiques à l’utilisateur et à l’ensemble du système

Par défaut, si virsh est exécuté en tant qu’utilisateur normal, il se connectera à libvirt en utilisant la chaîne URI qemu:///session. Cet URI permet à virsh de gérer uniquement l’ensemble des VM appartenant à cet utilisateur particulier. Pour gérer l’ensemble des VM du système (c’est-à-dire les VM appartenant à root), virsh doit être exécuté en tant que root ou avec qemu:///system URI :

$ virsh --connect qemu:///system list --all

Pour éviter de devoir utiliser le drapeau –connect sur chaque commande, la chaîne URI peut être définie dans la variable d’environnement LIBVIRT_DEFAULT_URI :

$ export LIBVIRT_DEFAULT_URI='qemu:///system'

Créer un nouvel invité

La façon la plus simple de créer et de gérer un invité VM est d’utiliser une application graphique. Par exemple :

• AQEMU aqemu.

• Gestionnaire de machines virtuelles virt-manager.

Alternativement, vous pouvez créer un invité VM via la ligne de commande en utilisant virtinst. Vous trouverez ci-dessous un exemple montrant la création d’un invité Buster avec le nom buster-amd64 :

virt-install --virt-type kvm --name buster-amd64 \--cdrom ~/iso/Debian/debian-10.0.0-amd64-netinst.iso \--os-variant debian10 \--disk size=10 --memory 1000

Comme l’invité n’a pas encore de connexion réseau, vous devrez utiliser l’interface graphique virt-viewer pour terminer l’installation.

Vous pouvez éviter de devoir télécharger l’ISO en utilisant l’option –location :

virt-install --virt-type kvm --name buster-amd64 \--location http://deb.debian.org/debian/dists/buster/main/installer-amd64/ \--os-variant debian10 \--disk size=10 --memory 1000

Pour utiliser une console texte pour l’installation, vous pouvez indiquer à virt-install d’utiliser un port série au lieu de la console graphique :

virt-install --virt-type kvm --name buster-amd64 \--location http://deb.debian.org/debian/dists/buster/main/installer-amd64/ \--os-variant debian10 \--disk size=10 --memory 1000 \--graphics none \--console pty,target_type=serial \--extra-args "console=ttyS0"

Pour une installation entièrement automatisée, regardez dans preseed ou debootstrap.

Configuration de la mise en réseau par pont

Entre les invités VM

Par défaut, QEMU utilise macvtap en mode VEPA pour fournir un accès Internet NAT ou un accès par pont avec d’autres invités. Cette configuration permet aux invités d’accéder à Internet (s’il y a une connexion Internet sur l’hôte), mais ne permettra pas à l’hôte ou aux autres machines sur le réseau local de l’hôte de voir et d’accéder aux invités.

Entre l’hôte VM et les invités

Réseau par défaut de libvirt

Si vous utilisez libvirt pour gérer vos VM, libvirt fournit un réseau ponté NATé nommé « default » qui permet à l’hôte de communiquer avec les invités. Ce réseau n’est disponible que pour les domaines du système (c’est-à-dire les VM créées par root ou en utilisant l’URI de connexion qemu:///system). Les VMs utilisant ce réseau se retrouvent dans 192.168.122.1/24 et DHCP leur est fourni via dnsmasq. Ce réseau n’est pas démarré automatiquement. Pour le démarrer, utilisez :

 virsh --connect=qemu:///system net-start default

Pour faire démarrer automatiquement le réseau par défaut, utilisez :

 virsh --connect=qemu:///system net-autostart default

Pour que les choses fonctionnent de cette façon, vous devez avoir les paquets recommandés dnsmasq-base, bridge-utils et iptables installés.

Accéder aux invités avec leurs noms d’hôte

Après la configuration du réseau par défaut, vous pouvez configurer le serveur DNS de libvirt, dnsmasq, afin de pouvoir accéder aux invités en utilisant leurs noms d’hôte. Ceci est utile lorsque vous avez plusieurs invités et que vous voulez y accéder en utilisant des noms d’hôtes simples, comme vm1.libvirt au lieu de mémoriser leurs adresses IP.

D’abord, configurez le réseau par défaut de libvirt. Exécutez virsh –connect=qemu:///system net-edit default et ajoutez à la configuration la ligne suivante (par exemple, après la balise mac) :

<domain name='libvirt' localOnly='yes'/>

libvirt est le nom du domaine pour les invités. Vous pouvez le définir sur quelque chose d’autre, mais veillez à ne pas le définir sur local, car cela peut entrer en conflit avec mDNS. La définition de hlocalOnly=’yes’ est importante pour s’assurer que les requêtes vers ce domaine ne sont jamais transférées en amont (pour éviter les boucles de requête).

La configuration réseau résultante devrait ressembler à quelque chose comme ceci :

<network connections='1'> <name>default</name> <uuid>66b33e64-713f-4323-b406-bc636c054af5</uuid> <forward mode='nat'> <nat> <port start='1024' end='65535'/> </nat> </forward> <bridge name='virbr0' stp='on' delay='0'/> <mac address='52:54:00:af:9f:2a'/> <domain name='libvirt' localOnly='yes'/> <ip address='192.168.122.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.122.2' end='192.168.122.254'/> </dhcp> </ip></network>

Maintenant, configurez les invités VM avec leurs noms. Par exemple, si vous voulez nommer un invité ‘vm1’, connectez-vous à celui-ci et exécutez :

sudo hostnamectl set-hostname vm1.libvirt

Puis, configurez le NetworkManager de l’hôte, afin qu’il utilise le serveur DNS de libvirt et résolve correctement les noms d’hôtes des invités. Tout d’abord, indiquez à NetworkManager de lancer sa propre version de dnsmasq en créant un fichier de configuration /etc/NetworkManager/conf.d/libvirt_dns.conf avec le contenu suivant :

dns=dnsmasq

Deuxièmement, indiquez au dnsmasq de l’hôte que pour toutes les requêtes DNS concernant le domaine libvirt, l’instance dnsmasq de libvirt doit être interrogée. Cela peut être fait en créant un fichier de configuration /etc/NetworkManager/dnsmasq.d/libvirt_dns.conf avec le contenu suivant :

server=/libvirt/192.168.122.1

libvirt est ici le nom de domaine que vous avez défini dans la configuration du réseau par défaut de libvirt. Remarque, l’adresse IP doit correspondre à l’adresse réseau par défaut de libvirt. Voir l’étiquette ip dans la configuration du réseau ci-dessus.

Maintenant, redémarrez le NetworkManager de l’hôte avec

sudo systemctl restart NetworkManager

À partir de maintenant, on peut accéder aux invités en utilisant leur nom d’hôte, comme ssh vm1.libvirt.

Passerelle manuelle

Pour permettre les communications entre l’hôte VM et les invités VM, vous pouvez configurer une passerelle macvlan au-dessus d’une interface factice similaire à celle ci-dessous. Après la configuration, vous pouvez définir l’utilisation de l’interface dummy0 (macvtap) en mode ponté comme configuration réseau dans la configuration des invités VM.

modprobe dummyip link add dummy0 type dummyip link add link dummy0 macvlan0 type macvlan mode bridgeifconfig dummy0 upifconfig macvlan0 192.168.1.2 broadcast 192.168.1.255 netmask 255.255.255.0 up

Entre l’hôte VM, les invités et le monde

Afin de laisser les communications entre l’hôte, les invités et le monde extérieur, vous pouvez configurer un pont et comme décrit à la page QEMU.

Par exemple, vous pouvez modifier le fichier de configuration réseau /etc/network/interfaces pour configurer l’interface ethernet eth0 à une interface de pont br0 similaire à celle ci-dessous. Après la configuration, vous pouvez définir l’utilisation de l’interface pont br0 comme connexion réseau dans la configuration de l’invité VM.

auto loiface lo inet loopback# The primary network interfaceauto eth0#make sure we don't get addresses on our raw deviceiface eth0 inet manualiface eth0 inet6 manual#set up bridge and give it a static ipauto br0iface br0 inet static address 192.168.1.2 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 bridge_ports eth0 bridge_stp off bridge_fd 0 bridge_maxwait 0 dns-nameservers 8.8.8.8#allow autoconf for ipv6iface br0 inet6 auto accept_ra 1

Une fois que cela est correctement configuré, vous devriez être en mesure d’utiliser le pont sur les nouveaux déploiements de VM avec :

virt-install --network bridge=br0 

Gestion des VM depuis la ligne de commande

Vous pouvez utiliser la commande virsh(1) pour démarrer et arrêter les machines virtuelles. Les VMs peuvent être générées à l’aide de virtinst. Pour plus de détails, consultez la page libvirt. Les machines virtuelles peuvent également être contrôlées à l’aide de la commande kvm de manière similaire à QEMU. Vous trouverez ci-dessous quelques commandes fréquemment utilisées :

Démarrer un invité VM configuré « VMGUEST » :

# virsh start VMGUEST

Notifier l’invité VM « VMGUEST » pour qu’il s’arrête de manière gracieuse :

# virsh shutdown VMGUEST

Forcer l’invité VM « VMGUEST » à s’arrêter au cas où il serait bloqué, c’est-à-dire que l’arrêt gracieux n’a pas fonctionné :

# virsh destroy VMGUEST

Gérer les invités VM avec une interface graphique

En revanche, si vous souhaitez utiliser une interface graphique pour gérer les VM, choisissez l’un des deux paquets suivants :

• AQEMU aqemu.

• Gestionnaire de machines virtuelles virt-manager.

Gestion automatique des invités à l’arrêt/au démarrage de l’hôte

Le comportement des invités à l’arrêt/au démarrage de l’hôte est configuré dans /etc/default/libvirt-guests.

Ce fichier spécifie si les invités doivent être arrêtés ou suspendus, s’ils doivent être redémarrés au démarrage de l’hôte, etc.

Le premier paramètre définit où trouver les invités en cours d’exécution. Par exemple :

# URIs to check for running guests# example: URIS='default xen:/// vbox+tcp://host/system lxc:///'URIS=qemu:///system

Tuning des performances

Voici quelques options qui peuvent améliorer les performances des invités VM.

CPU

• Assigner un cœur de CPU virtuel à un cœur de CPU physique dédié
  • Modifier la configuration de l’invité VM, supposons que le nom de l’invité VM est « VMGUEST » ayant 4 cœurs de CPU virtuels

    # virsh edit VMGUEST

  Ajouter les codes ci-dessous après la ligne « <vcpu … »

  <cputune> <vcpupin vcpu='0' cpuset='0'/> <vcpupin vcpu='1' cpuset='4'/> <vcpupin vcpu='2' cpuset='1'/> <vcpupin vcpu='3' cpuset='5'/></cputune>

  où vcpu sont les identifiants des cœurs de cpu virtuels ; cpuset sont les identifiants des cœurs de cpu physiques alloués. Ajustez le nombre de lignes de vcpupin pour refléter le nombre de vcpu et cpuset pour refléter l’allocation réelle du cœur du processeur physique. En général, la moitié la plus élevée des cœurs de CPU physiques sont les cœurs hyperthreading qui ne peuvent pas fournir la pleine performance du cœur tout en ayant l’avantage d’augmenter le taux de réussite du cache mémoire. Une règle générale pour définir cpuset est :

• Pour le premier vcpu, attribuez un numéro de cpuset de moitié inférieure. Par exemple, si le système a 4 cœurs 8 threads, la valeur valide de cpuset est entre 0 et 7, la moitié inférieure est donc entre 0 et 3.
• Pour le second et l’ensemble des seconds vcpu, attribuez son numéro de cpuset de moitié supérieure. Par exemple, si vous avez affecté le premier cpuset à 0, alors le deuxième cpuset doit être défini à 4.

  Pour le troisième vcpu et plus, vous pouvez avoir besoin de déterminer quel cœur de cpu physique partage le cache mémoire plus au premier vcpu comme décrit ici et l’affecter au numéro de cpuset pour augmenter le taux de réussite du cache mémoire.

L’E/S du disque

L’E/S du disque est généralement un goulot d’étranglement des performances en raison de ses caractéristiques. Contrairement au CPU et à la RAM, un hôte de VM peut ne pas allouer un matériel de stockage dédié à une VM. Pire encore, le disque est le composant le plus lent parmi eux. Il existe deux types de goulots d’étranglement du disque : le débit et le temps d’accès. Un disque dur moderne peut fournir un débit de 100 Mo/s, ce qui est suffisant pour la plupart des systèmes, alors qu’il ne peut fournir qu’environ 60 transactions par seconde (tps).

Une façon d’améliorer la latence des E/S sur disque consiste à utiliser un lecteur à état solide (SSD) petit mais rapide comme cache pour des disques tournants traditionnels plus grands mais plus lents. La page de manuel LVM lvmcache(7) décrit comment configurer cela.

Pour l’hôte VM, vous pouvez évaluer différents paramètres d’E/S de disque pour obtenir les meilleurs tps pour votre disque. Vous trouverez ci-dessous un exemple de tuning et de benchmarking de disque à l’aide de fio :

• # echo mq-deadline > /sys/block/sda/queue/scheduler# echo 1 > /proc/sys/vm/dirty_background_ratio# echo 50 > /proc/sys/vm/dirty_ratio# echo 500 > /proc/sys/vm/dirty_expire_centisecs# /sbin/blockdev --setra 256 /dev/sda# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/opt/fio.tmp --bs=4k --iodepth=64 --size=8G --readwrite=randrw --rwmixread=75 --runtime=60

Pour les hôtes VM Windows, vous pouvez souhaiter basculer entre le pilote IDE intégré à Windows, lent mais multiplateforme, et le pilote VirtIO, rapide mais spécifique à KVM. Par conséquent, la méthode d’installation pour les invités Windows VM fournie ci-dessous est un peu compliquée car elle fournit un moyen d’installer les deux pilotes et d’en utiliser un pour vos besoins. Sous virt-manager :

• Pilote natif pour les invités VM Windows
  • Créer un nouvel invité VM avec la configuration ci-dessous :
    • Déposer un stockage pour le conteneur Windows OS, supposer avec le nom de fichier WINDOWS.qcow2
    • Déposer un CDROM, attacher l’ISO Windows OS au CDROM
  • Démarrer l’invité VM et installer le Windows OS comme d’habitude
  • Arrêter l’invité VM
  • Reconfigurer l’invité VM avec la configuration ci-dessous :
    • Ajouter un stockage factice VirtIO / VirtIO SCSI avec une taille de 100MB, par exemple DUMMY.qcow2

    • Attacher le CD ISO du pilote VirtIO au CDROM IDE

  • Redémarrer l’invité VM
  • Installer le pilote VirtIO à partir du CDROM IDE lorsque Windows demande un nouveau pilote matériel

  .

  • Pour l’invité VM de Windows 10 et supérieur
    • Lancer « cmd » en tant qu’administrateur et exécuter la commande ci-dessous

      > bcdedit /set {current} safeboot minimal

  • Éteindre l’invité VM
  • Reconfigurer l’invité VM avec la configuration ci-dessous :
    • Supprimer le stockage IDE pour l’OS Windows, NE PAS supprimer WINDOWS.qcow2
    • Supprimer le stockage VirtIO pour le stockage factice, vous pouvez supprimer DUMMY.qcow2
    • Supprimer le stockage IDE pour le CD ROM
    • Ajouter un nouveau stockage VirtIO / VirtIO SCSI et attacher WINDOWS.qcow2 à celui-ci
  • Redémarrer l’invité VM
  • Pour l’invité VM de Windows 10 et supérieur
    • Loguer le mode sans échec de Windows 10. VM guest et exécutez la commande ci-dessous

      > bcdedit /deletevalue {current} safeboot

    • Redémarrez le VM guest
• Pilote natif pour Linux. Invités VM
  • Sélectionner le stockage VirtIO / VirtIO SCSI pour les conteneurs de stockage
  • Redémarrer l’invité VM
• Le stockage VirtIO / VirtIO SCSI
  • Le stockage VirtIO SCSI offre des fonctionnalités plus riches que le stockage VirtIO lorsque l’invité VM est attaché avec plusieurs stockages. Les performances sont les mêmes si le VM guest n’était attaché qu’avec un seul stockage.

Disk Cache

• Sélectionnez « None » pour le mode de cache de disque, « Native » pour le mode IO, « Unmap » pour le mode Discard et la méthode Detect zeroes.

Dédiez des threads d’E/S

• Spécifier le thread d’E/S peut réduire le symptôme de blocage pendant l’E/S du disque de manière significative. 1 thread d’E/S est suffisant pour la plupart des cas :
• Modifier la configuration de l’invité VM, supposons que le nom de l’invité VM est « VMGUEST »

  # virsh edit VMGUEST

Après la première ligne « <domain …> », ajouter la ligne « iothreads » :

 <iothreads>1</iothreads>

 <driver iothread='1'/>

Entrées/sorties réseau

Utilisation de virt-manager :

• Pilote natif pour les invités VM de Windows
  • Sélectionner VirtIO pour la carte réseau

  • Attacher le CD ISO du pilote VirtIO au CDROM IDE

  • Redémarrer l’invité VM, Windows a trouvé un nouveau matériel de carte réseau, installez le pilote VirtIO à partir du CDROM IDE
• Pilote natif pour les invités VM Linux
  • Sélectionnez VirtIO pour l’adaptateur réseau.
  • Redémarrer l’invité VM

Mémoire

• Prise en charge de la mémoire des pages énormes
  • Calculer le nombre de pages énormes nécessaires. Chaque page énorme a une taille de 2MB, en conséquence nous pouvons utiliser la formule ci-dessous pour le calcul.

    Huge Page Counts = Total VM Guest Memory In MB / 2

    par exemple, 4 invités VM, chaque invité VM utilisant 1024MB, alors le nombre de pages énormes = 4 x 1024 / 2 = 2048. Notez que le système peut être suspendu si la mémoire acquise est supérieure à celle du système disponible.

  • Configurer le support mémoire ?HugePages en utilisant la commande ci-dessous. Comme la mémoire Huge pourrait ne pas être allouée si elle est trop fragmentée, il est préférable d’ajouter le code à /etc/rc.local

    echo 2048 > /proc/sys/vm/nr_hugepagesmkdir -p /mnt/hugetlbfsmount -t hugetlbfs hugetlbfs /mnt/hugetlbfsmkdir -p /mnt/hugetlbfs/libvirt/binsystemctl restart libvirtd

  • Redémarrer le système pour activer le support de la mémoire des pages énormes. Vérifiez le support de la mémoire de page énorme par la commande ci-dessous.

    # cat /proc/meminfo | grep HugePages_HugePages_Total: 2048HugePages_Free: 2048HugePages_Rsvd: 0HugePages_Surp: 0

  Editer la configuration de l’invité VM, supposez que le nom de l’invité VM est « VMGUEST »

  # virsh edit VMGUEST

Ajouter les codes ci-dessous après la ligne « <currentMemory … »

<memoryBacking> <hugepages/></memoryBacking>

# virsh start VMGUEST# cat /proc/meminfo | grep HugePages_HugePages_Total: 2048HugePages_Free: 1536HugePages_Rsvd: 0HugePages_Surp: 0

Huge Page Counts = Total VM Guest Memory In MB / 2

Migration des invités vers un hôte Debian

Migration des invités depuis RHEL/CentOS 5.x

Il y a quelques petites choses dans les fichiers de configuration XML des invités (/etc/libvirt/qemu/*.xml que vous devez modifier :

• La variable machine dans la section <os> devrait dire pc, et non rhel5.4.0 ou similaire

• L’entrée de l’émulateur devrait pointer vers /usr/bin/kvm, et non /usr/libexec/qemu-kvm

En d’autres termes, les sections pertinentes devraient ressembler à quelque chose comme ceci :

 <os> <type arch='x86_64' machine='pc'>hvm</type> --- snip --- <devices> <emulator>/usr/bin/kvm</emulator>

Si vous aviez configuré un réseau en pont sur l’hôte CentOS, veuillez vous référer à cet article wiki sur la façon de le faire fonctionner sur Debian.

Dépannage

Aucun pont réseau disponible

virt-manager utilise un réseau virtuel pour ses invités, par défaut celui-ci est routé vers 192.168.122.0/24 et vous devriez le voir en tapant ip route en tant que root.

Si cette route n’est pas présente dans la table de routage du noyau, alors les invités ne pourront pas se connecter et vous ne pourrez pas terminer la création d’un invité.

Réparer cela est simple, ouvrez virt-manager et allez dans « Edit » -> « Host details » -> onglet « Virtual networks ». À partir de là, vous pouvez créer votre propre réseau virtuel ou tenter de réparer celui par défaut. Généralement, le problème existe lorsque le réseau par défaut n’est pas démarré.

Impossible de créer le pont ‘virbr0’ : Le fichier existe :

Pour résoudre ce problème, vous pouvez supprimer le virbr0 en exécutant :

brctl delbr virbr0

Ouvrir virt-manager et aller dans « Edit » -> « Host details » -> « Virtual networks » démarrer le réseau par défaut.

Vous pouvez vérifier le netstatus

virsh net-list --all

Optionnellement, vous pouvez utiliser le réseau BridgeNetworkConnections

Windows guest fréquemment hang ou BSOD

Certains invités Windows utilisant certains CPU haut de gamme N-way peuvent trouver fréquemment hang ou BSOD, c’est un bug connu du noyau alors que malheureusement il n’est pas corrigé dans Jessie (TBC dans Stretch). Le contournement ci-dessous peut être appliqué en ajoutant une section <hyperv></hyperv> dans la configuration de l’invité via la commande virsh edit GUESTNAME :

<domain ...> ... <features> ... <hyperv> <relaxed state='on'/> </hyperv> </features> ...

Voir aussi

• libvirt

• QEMU

Vous pouvez trouver un exemple pour tester. Vous ne pouvez pas le faire à distance.

S’il vous plaît, ajoutez des liens vers la documentation externe. Ce n’est pas un endroit pour les liens vers des produits commerciaux non libres.

• https://www.linux-kvm.org/ – Page d’accueil de la machine virtuelle basée sur le noyau ;

• https://www.linux-kvm.org/page/HOWTO – Howto’s

• #kvm – Canal IRC

• https://web.archive.org/web/20080103004709/http://kvm.qumranet.com/kvmwiki/Debian – KVM sur Debian Sid (ancien wiki KVM)

CategorySystemAdministration | CategoryVirtualization | CategorySoftware

.