L’autre jour je me suis décidé à utiliser KVM pour mes machines virtuelles, en lieu et place de VirtualBox.
Je n’étais pas totalement satisfait de la solution proposée par Oracle : d’abord parce qu’il y avait soit la version intégrée à Ubuntu mais toujours en retard, soit la version proposée par Oracle mais à installer à la main, mais aussi à cause des « Guest additions », qu’il fallait réinstaller à chaque nouvelle version. C’était assez lourd, ça ne fonctionnait pas toujours, et VirtualBox me faisait penser à une belle usine à gaz. Le copier/coller ne fonctionnait pas nativement, etc…
KVM a l’avantage d’être intégré de base au noyau Linux, alors pourquoi s’en priver ? Il faut par contre installer une interface graphique pour gérer les machines virtuelles, et pour cela, virt-manager est là. Au final, on dispose d’une solution totalement open-source, mieux intégrée, qui m’a l’air plus performante en terme d’utilisation CPU que VirtualBox (mais ce n’est peut-être qu’une impression), et qui répond à mes besoins assez basique en terme de machines virtuelles.
Voyons voir comment installer tout ça, migrer les machines VirtualBox que j’avais, et faire les premiers pas avec ce nouvel environnement.
J’ai dans un premier temps suivi ce tutoriel pour installer KVM. Il y a quelques changements avec Ubuntu 19.10, notamment le package libvirt-bin qui n’existe plus. Il n’y a plus besoin non plus de créer un groupe libvirtd. Voilà donc les instructions mises à jour :
Vérification système
Il faut d’abord s’assurer que votre processeur supporte bien la virtualisation. Taper cette commande :
pascal@pascal-SH87R:~$ egrep -c '(vmx | svm)' /proc/cpuinfo
8
Si vous obtenez « 0 » comme résultat, c’est qu’aucun de vos CPU ne supporte la virtualisation. Dans mon cas, j’ai un processeur physique, 4 cores, 8 threads : les 8 threads supportent donc la virtualisation, tout va bien.
En cas de réponse « 0 », penser tout de même à aller vérifier dans le BIOS de la carte mère que l’option de virtualisation est bien activée. Dans mon, j’ai ceci (on voit que j’ai aussi activé la technologie HT, Hyper-Threading, ce qui explique les 8 threads observés plus haut) :
Installation
Il faut maintenant installer les packages nécessaires :
sudo apt-get install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virt-manager
Reste à vérifier que tout est bon avec la commande suivante :
pascal@pascal-SH87R:~$ sudo kvm-ok
[sudo] Mot de passe de pascal :
INFO: /dev/kvm exists
KVM acceleration can be used
Il faut ensuite fermer et ré-ouvir la session pour finir. À priori, tout est bon, on peut le vérifier avec la commande suivante :
virsh -c qemu:///system list
Id Name State
--------------------
Voilà, cette fois c’est terminé, tout est prêt pour la création et la gestion de machines virtuelles, il suffit de lancer le gestionnaire de machines virtuelles :
Migration VirtualBox
Il va maintenant falloir migrer mes machines virtuelles Virtualbox, afin de ne tout recommencer de zéro. J’ai suivi ce tuto. Cette opération se fait en deux temps : d’abord on migre la VM VirtualBox (fichier .vdi) dans un format .raw, puis on migre ce format .raw en format .qcow2, le format par défaut utilisé par KVM. Ce qui donne, en se plaçant dans le bon répertoire de VirtualBox :
pascal@pascal-SH87R:$ VBoxManage clonehd Neon_KDE_User_Edition.vdi NeonKDE.raw --format raw
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Clone medium created in format 'raw'. UUID: 214aa827-5d9b-4832-b5ef-f44f0bcd677e
pascal@pascal-SH87R:~$ pascal@pascal-SH87R:$ qemu-img convert -f raw NeonKDE.raw -O qcow2 NeonKDE.qcow2
Le format .raw étant assez gourmand en espace disque, penser à effacer le fichier une fois la conversion en .qcow2 effectuée.
Gestionnaire de machines virtuelles
Maintenant il va falloir s’organiser un peu : j’ai déjà un répertoire Images ISO que j’utilise pour stocker les images des OS que je récupère sur le net. Je vais également créer un répertoire KVM où je vais stocker mes VMs, c’est-à-dire les fichiers .qcow2. J’y copie tout de suite le fichier créé précédemment :
pascal@pascal-SH87R:$ mv NeonKDE.qcow2 /Toshiba3/KVM/
Il faut ensuite ajouter ces répertoires dans le gestionnaire de machines virtuelles, histoire de simplifier l’utilisation de la console. Il va falloir pour cela créer des « pools« . À partir du gestionnaire de machines virtuelles, je choisis « Créer une nouvelle machine virtuelle », puis « Importer une image disque existante », et bouton « Parcourir ». À cette étape, on peut créer un « pool » pour indiquer où aller chercher le fichier, soit le dossier où les fichiers .qcow2 ont été placés. Cliquer sur le « + » en bas à gauche de la fenêtre :
Puis donner un nom à ce pool (KVM par exemple), et aller pointer sur le dossier des fichiers .qcow2. Faire la même opération si vous comptez créer une VM à partir d’une image ISO.
À terme, voilà ce que j’ai : le pool par défaut (qui est dans la partition système, et qu’il vaut mieux éviter d’utiliser pour stocker de gros fichiers au risque de remplir la partition), et les deux pools que j’ai créé. Je peux donc sélectionner le fichier NeonKDE.qcow2 précédemment créé :
Ensuite, on indique l’OS s’il fait partie de la liste, sinon on laisse « Generic default », ce n’est pas important, puis on choisit la mémoire et le nombre de processeurs, et enfin on donne un nom à la VM que l’on va créer. Pour le réseau, je laisse NAT par défaut, c’est suffisant pour mon usage.
Quelques minutes plus tard, la machine Neon KDE migrée de VirtualBox est lancée, prête à être utilisée :
Une fois toutes mes machines VirtualBox migrées, voilà ce que me donne le Gestionnaire de machines virtuelles :
Ajout de périphérique
La gestion des périphériques a l’air plus simple qu’avec VirtualBox. Le son fonctionne sans aucune manipulation. Pour ajouter un périphérique USB, j’ai regardé ce tuto : la manière la plus simple est de passer par le gestionnaire de machines virtuelles.
Je souhaite par exemple connecter une clef USB à ma VM. Je la branche sur le port USB de mon PC, puis, machine virtuelle arrêtée, ouvrir la console de la machine concernée, puis cliquer sur le bouton « Afficher les détails du matériel virtuel » en haut à gauche. Puis en bas à gauche, je clique sur « Ajouter un matériel » :
Sélectionner « Périphérique hôte USB » à gauche, puis la clef qui est listée dans la partie droite :
Et c’est tout ! Au démarrage de la VM, la clef USB est bien présente comme périphérique :
Réseau
Par défaut, le réseau est de type NAT, c’est-à-dire que c’est la machine hôte (le PC) qui s’occupe de tout. C’est en général suffisant pour des usages de base.
Mon seul besoin est de pouvoir transférer des fichiers de la machine hôte vers la machine virtuelle, et réciproquement. Pour ce faire, il suffit d’utiliser le répertoire Public dans le répertoire /home/pascal/Public/ sur la machine hôte. À partir de la machine virtuelle, il suffit d’aller dans le voisinage réseau où la machine hôte apparaît, et d’accéder au répertoire Public en s’identifiant avec le nom d’utilisateur et le mot de passe.
J’ai eu un seul problème depuis, c’était l’erreur suivante au démarrage : »Error starting domain: Requested operation is not valid: network ‚default‘ is not active« . J’avais du faire une mauvaise manip…
Une rapide recherche sur le net m’a fourni la réponse. Il fallait définir le réseau « default » en automatique au démarrage. L’occasion de découvrir les commandes virsh :
$ virsh net-start default
$ virsh net-autostart default
$ virsh net-list --all
Name State Autostart Persistent
--------------------------------------------
default active yes yes
La dernière commande affiche comment on doit être configuré.
Copier/coller
Si le copier/coller ne fonctionne pas nativement (notamment pour les machines virtuelles Windows), il faut se tourner vers spice. Vérifier d’abord que la VM (côté Hôte Ubuntu) est bien configurée pour utiliser spice, ce qui doit être le cas par défaut avec virt-manager :
Dans la VM Linux
Il faut installer l’agent spice :
sudo apt install spice-vdagent
Et pour s’assurer que le service démarrera automatiquement :
sudo systemctl enable spice-vdagentdDans la VM Windows
Il va falloir installer les spice-guest-tools, que l’on peut trouver ici.
Une fois installés, le copier/coller fonctionne immédiatement, dans les deux sens.
Agrandir le disque
À un moment ou à un autre, vous serez peut-être amené à devoir agrandir le disque. Il faudra procéder en trois étapes, en agrandissant d’abord la taille du disque virtuel de la VM. On vérifie d’abord sa taille actuelle, machine arrêtée :
pascal$ sudo qemu-img info fedora30.qcow2
image: fedora30.qcow2
file format: qcow2
virtual size: 20 GiB (21474836480 bytes)
disk size: 20 GiB
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: true
refcount bits: 16
corrupt: false
Puis on agrandit le disque virtuel (10G dans l’exemple), et on vérifie dans la foulée :
pascal$ sudo qemu-img resize fedora30.qcow2 +10G
Image resized.
[/Toshiba/KVM]
pascal$ sudo qemu-img info fedora30.qcow2
image: fedora30.qcow2
file format: qcow2
virtual size: 30 GiB (32212254720 bytes)
disk size: 20 GiB
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: true
refcount bits: 16
corrupt: false
Il faut maintenant amorcer la VM sur une image de GParted-Live pour aller étendre la partition du disque :
On démarre sur le CD, et on arrive sur GParted, et on étend la partition du disque de la VM :
Mais ce n’est pas encore fini : il faut maintenant redémarrer la VM en mode normal et aller étendre le volume logique !
Voilà comment vérifier dans l’ordre la taille du disque physique (pvs), du groupe de volume (vgs), et du volume logique (lvs) :
[pascal@localhost ~]$ sudo pvs
PV VG Fmt Attr PSize PFree
/dev/vda2 fedora_localhost-live lvm2 a-- <29,00g 10,00g
[pascal@localhost ~]$ sudo vgs
VG #PV #LV #SN Attr VSize VFree
fedora_localhost-live 1 2 0 wz--n- <29,00g 10,00g
[pascal@localhost ~]$ sudo lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root fedora_localhost-live -wi-ao---- <17,00g
swap fedora_localhost-live -wi-ao---- 2,00g
On voit que le "pvs" et le "vgs" sont bien à 30G, mais pas le "lvs". Il faut donc étendre ce dernier, mais aussi étendre le système de fichier :
[pascal@localhost ~]$ sudo lvextend -L +10G /dev/fedora_localhost-live/root
Size of logical volume fedora_localhost-live/root changed from <17,00 GiB (4351 extents) to <27,00 GiB (6911 extents).
Logical volume fedora_localhost-live/root successfully resized.
[pascal@localhost ~]$ sudo resize2fs /dev/fedora_localhost-live/root
resize2fs 1.45.5 (07-Jan-2020)
Le système de fichiers de /dev/fedora_localhost-live/root est monté sur / ; le changement de taille doit être effectué en ligne
old_desc_blocks = 3, new_desc_blocks = 4
Le système de fichiers sur /dev/fedora_localhost-live/root a maintenant une taille de 7076864 blocs (4k).
Notez bien la syntaxe pour le chemin du volume, sous la forme /dev/VG/LV que l'on obtient des commandes précédentes.
Voilà, c'est terminé, vous pouvez le vérifier avec une commande $ df -H, ou toute autre façon de votre choix.
Conclusion
Voilà, après quelques semaines d'utilisation, KVM convient parfaitement à mes besoins, et est beaucoup mieux intégré au système. J'en suis très satisfait, j'ai l'impression que les performances sont meilleures, et que KVM est moins gourmand en ressources.
Je peux maintenant désinstaller VirtualBox. 😎