Passer à virt-manager

Contexte

Depuis que je suis entré dans le monde de Linux, je me suis rendu compte qu'il existait ces
divers "trous de lapin" (comme j'aime l'appeler) dans lesquels je pouvais m'introduire. je
définissez ces "trous de lapin" comme la période où vous passez votre temps à adopter
une certaine technologie dans votre flux de travail. La plupart de ces workflows sont parfois
très peu commun. Par exemple, l'un de mes premiers "trous de lapin" était de passer à un
gestionnaire de fenêtres en mosaïque. Il n'y a déjà pas un grand pourcentage de personnes qui utilisent
Linux sur leurs ordinateurs de bureau, sans parler d'avoir une configuration de gestionnaire de fenêtres en mosaïque. Un des
les "trous de lapin" dans lesquels je me suis récemment plongé - d'où le titre de ce
article - passe de VirtualBox à virt-manager. j'avais déjà vu
déjà beaucoup de vidéos et d'articles sur ce truc QEMU/KVM. Donc c'était ça
prévisible pour moi de finir par comprendre.

Présentation

Dans un blog précédent, nous avons couvert les gnome-boxes. Cependant, il y a
également un autre gestionnaire de machines virtuelles très populaire nommé
virt-manager. Bien que très facile à utiliser, j'ai trouvé que gnome-boxes
ne nous fournit pas une tonne de configurations par rapport à virt-manager .
De plus, virt-manager offre également de meilleures performances car
par rapport à VirtualBox puisque nous utilisons KVM. Dans cet article, je souhaite
partager certaines de mes expériences et ce que j'en ai appris
terrier de lapin.

Avant d'entrer dans le vif du sujet, cependant, je tiens à clarifier quelques points :

• Hyperviseur :Un hyperviseur est un logiciel qui nous permet d'exécuter et
  gérer plusieurs systèmes d'exploitation différents sur une seule machine. Type 1
  l'hyperviseur s'exécute directement sur le matériel tandis que les hyperviseurs de type 2 s'exécutent sur
  dessus d'un système d'exploitation installé sur le matériel.
• KVM – C'est le module noyau de bas niveau qui est responsable de la traduction
  les instructions CPU des systèmes d'exploitation invités en quelque chose que l'hôte
  noyau peut comprendre. C'est essentiellement ce qui permet au noyau Linux d'agir
  en tant qu'hyperviseur (de type 1)[1].
• QEMU – QEMU signifie Quick Emulator. Il émule divers matériels et CPU
  architectures. QEMU peut fonctionne avec KVM mais peut aussi être utilisé seul
  [2]. Cependant, cela impose divers problèmes de performances au fur et à mesure que l'émulation se fait
  entièrement par logiciel. Maintenant, KVM par lui-même ne peut pas non plus émuler beaucoup de
  Matériel. Par conséquent, la pile QEMU+KVM est le plus souvent utilisée comme hyperviseur.
• libvirt – libvirt est une API qui peut être utilisée pour gérer des machines virtuelles via QEMU.
  Il a un démon appelé libvirtd et un utilitaire de ligne de commande appelé virsh [3].
  Cependant, je n'ai pas commencé à utiliser virsh donc c'est un autre terrier de lapin pour moi.
• virt-manager – Enfin, c'est le programme GUI pour la gestion des machines virtuelles. Il utilise
  libvirt pour interagir avec les composants de niveau inférieur de notre pile de virtualisation.
  Nous allons principalement interagir avec cela en tant qu'utilisateur.
  

Installer virt-manager

Normalement, essayer d'installer virt-manager devrait automatiquement extraire les composants libvirt comme
dépendances. Cependant, qemu est une dépendance facultative, nous devons donc la spécifier explicitement.
Sur Arch Linux, je n'avais besoin que de ces deux packages :

Assurez-vous de vérifier que les packages requis indiqués dans la capture d'écran ci-dessus
sont extraits lors de l'installation sur votre système.

Utiliser virt-manager

virt-manager est un programme GUI. En tant que tel, son interface utilisateur ne devrait pas vraiment nécessiter beaucoup d'explications.

Une chose à noter est que vous devez avoir le libvirtd service en cours d'exécution afin d'utiliser virt-manager.

# systemctl start libvirtd

Sur une petite note, en commençant libvirt démarre également quelques autres services, donc je lance ce qui suit
commande quand j'ai fini d'utiliser mes machines virtuelles :

# systemctl stop "libvirt*" "virt*"

Disques virtuels

virt-manager utilise le qcow2 format de stockage pour ses disques virtuels. Depuis cela
l'article concerne la migration vers virt-manager, nous avons probablement des
machines avec leurs disques remplis. Heureusement, nous avons le qemu-img utilitaire.

Par exemple, pour convertir une image de vdi formater en qcow2 :

qemu-img convert -O qcow2 -f vdi <image.vdi> <output_file.qcow2>

D'autres formats sont également pris en charge et peuvent être visualisés en invoquant :

qemu-img --help

Les images VirtualBox sont également disponibles en ova format. Et vous ne trouverez pas ce format
répertorié dans la sortie d'aide de la commande précédente.
Cependant, lors de l'inspection d'un ova fichier :

C'est évidemment juste une archive tar - qui peut être facilement extraite en utilisant tar :

Là, nous avons notre vmdk disque virtuel qui peut facilement être converti en qcow2 .

SSH dans les VM

Chaque fois que je créais une machine virtuelle dans VirtualBox, je la configurais pour avoir un pont
adaptateur. De cette façon, la machine virtuelle serait également sur mon réseau local domestique et je pourrais m'y connecter en SSH comme n'importe quel autre
autre appareil. Cependant, par défaut, les VM dans virt-manager seront connectées au
réseau virtuel (NAT). Les IP seront attribuées en interne par l'hyperviseur auquel votre
routeur domestique ne saura pas. Ainsi, lorsque vous essayez de ssh dans la machine virtuelle à l'aide de cette adresse IP,
la passerelle n'aura aucune idée de ce qu'est cette IP et donc cela ne fonctionnera pas.

La façon dont j'ai pu faire en sorte que le routeur attribue également une adresse IP à ma machine virtuelle
consiste à créer d'abord un pont réseau, puis à modifier la configuration réseau du
VM comme indiqué dans la capture d'écran pour être de la source Bridge et lorsque la VM démarre
il obtient une adresse IP accessible aux autres appareils sur le réseau local.

La mise en place d'un pont réseau est bien documentée sur des sites comme Arch Wiki [4].
J'utilise Network Manager et la procédure était aussi simple que d'entrer quelques
commandes. Le nom du pont est br0 et l'interface assignée comme esclave à celle-ci
le pont est eth0 .

nmcli connection add type bridge ifname br0 stp no
nmcli connection add type bridge-slave ifname eth0 master br0
nmcli connection down eth0
nmcli connection up bridge-br0

De cette façon, je peux facilement copier des trucs collés vers et depuis la VM et je n'ai pas non plus
pour échapper constamment au clavier/souris lors de l'utilisation de la VM et de mon hôte à la fois à
en même temps.

Après avoir compris tout cela, j'ai enfin pu utiliser virt-manager comme principal
gestionnaire de machines virtuelles. Donc c'est tout pour le moment, j'espère que vous avez trouvé cet article utile.

Références

1. Machine virtuelle basée sur le noyau
2. KVM contre QEMU
3. FAQ Libvirt
4. Pont réseau | Arch Wiki