[OpenBSD :: Virtualisation] Debian Bullseye (11.x)

Article publié, le 28 Novembre 2022 et modifié le 3 Novembre 2023
7 minutes de lecture

Cet article contient 1382 mots.
Source brute de l'article :
Commit version : 319887c

Description

La virtualisation de machine virtuelle sous OpenBSD est officiellement disponible nativement dans le système de base depuis OpenBSD 5.9.

Version : native
OS : OpenBSD 7.0 → 7.2

Pour rappel : utiliser le virtualisateur vmd d’OpenBSD a quelques restrictions, dont celles de ne pas pouvoir utiliser d’interface graphique, …

Pré-requis

Attention

ATTENTION : Ce tutoriel ne documente pas dans les moindres détails les phases d’installation, voire de configuration.

Il est VRAIMENT nécessaire de faire preuve de réflexion, discernement et d’avoir un minimum de compétences, pour comprendre les liens entre les différentes briques !

Merci de votre compréhension…

Il est nécessaire que votre machine sur laquelle vous souhaitez virtualiser ait un CPU compatible avec les fonctions adéquates. Pour le vérifier, tapez dans votre terminal/console la commande suivante :

$ dmesg | egrep '(VMX/EPT|SVM/RVI)'

La réponse du système doit être :

⇒ pour CPU Intel :

vmm0 at mainbus0: VMX/EPT

⇒ pour CPU Amd :

vmm0 at mainbus0: SVM/RVI

Si aucune ligne n’apparaît, aucune virtualisation ne sera possible. Par acquis de conscience, vérifiez votre BIOS|UEFI que celle-ci ne soit pas désactivée.

Info

De même, en rapport avec les failles CPU relatives à Meltdown, Spectre, certains CPU Intel sont patchés pour remédier à L1TF. Sous OpenBSD, ces CPU reçoivent un correctif approprié. Malheureusement, cela impacte la virtualisation et rend celle-ci difficile pour certains, voire impossible. Vous pouvez vous retrouver dans la situation où vous auriez un CPU compatible, mais dans les faits, la virtualisation ne pourrait être pleinement fonctionnelle.

Préférez AMD, en attendant ARM… voire RISC V.

Il est nécessaire d’installer le firmware vmm pour que le kernel gère.

# fw_update vmm

Par convention, créons un répertoire ‘‘vm’’ dans notre répertoire personnel, et nous travaillerons à partir de celui-ci : $ mkdir vm && cd vm

Précisions réseaux

L’interface vether0 de l’hôte aura pour adresse IPv4 : 192.168.0.1, cette adresse IP sera l’adresse de la passerelle pour l’interface réseau de la VM.
L’interface enp0s3 de la VM Debian aura pour adresse IPv4 : 192.168.0.2
Dans les deux cas, le masque de réseau est de 24 bits.
La passerelle de la VM sera l’adresse IP de l’interface vether ;)
Les serveurs DNS renseignés dans le fichier /etc/resolv.conf de la VM sont les serveurs publics de la FDN, respectueux de la confidentialité…
Ces même serveurs DNS peuvent être renseignés dans la règle PF de redirection de flux DNS vers la VM.
Cet article ne montre rien concernant, ou si peu, le fonctionnement avec le protocole IPv6, mais les principes ci-dessus s’appliquent, pourvu que vous comprenez ce que vous faites.

Création de l’image qcow2

Dans les deux cas présentés, nous commencerons par créer la VM, très simplement avec l’outil natif à OpenBSD, nommé vmctl :

$ vmctl create -s 50G ~/vm/bullseye.qcow2

Téléchargement de l’iso Debian

Téléchargeons l’iso Debian :

$ ftp https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/{debian-11.5.0-amd64-netinst.iso,SHA512SUMS}

Une fois téléchargée, vérifions sa somme de contrôle :

$ sha512 -C SHA512SUMS debian-10.1.0-amd64-netinst.iso
(SHA512) debian-10.1.0-amd64-netinst.iso: OK

Si OK, alors c’est bon… sinon, re-téléchargez !

Configuration

Le fichier de configuration : /etc/vm.conf.

switch "sw" {
	interface bridge0
}

vm "bullseye" {
	disable
	memory 1G
	cdrom /home/id/vm/debian-11.5.0-amd64-netinst.iso
	disk /home/id/vm/bullseye.qcow2
	interface { switch "sw" }
	owner votre-identifiant
}

Bien sûr, remplacez :

/home/id par votre répertoire home
votre-identifiant par votre identifiant de session

Vérifiez la configuration à l’aide de l’option -n de vmd :

$ vmd -n

Après avoir configuré les interfaces réseaux , il faut maintenant démarrer le service de gestion des VMs : # rcctl enable vmd && rcctl start vmd

puis il faut s’occuper de la traduction d'adresses réseaux , et aussi des règles du parefeu …

Interfaces réseaux

Créons les interfaces réseaux nécessaires que sont vether0 et bridge0 qui permettront un contrôle fin de l’adressage IP et des règles PF.

bridge0

Le fichier relatif est /etc/hostname.bridge0 :

# echo "add vether0" > /etc/hostname.bridge0

vether0

Le fichier relatif est /etc/hostname.vether0 :

# echo "inet 192.168.0.1 255.255.255.0" > /etc/hostname.vether0

Une fois les fichiers d’interfaces créés, donnez des droits 0600 dessus, puis démarrez les deux interfaces :

# chmod 0600 /etc/hostname.{bridge,vether}0
# sh /etc/netstart {bridge,vether}0

NAT

Dans ce contexte où la VM invitée est sur un segment réseau différent de l’hôte, il faut autoriser la redirection des paquets IP, pour que la VM puisse communiquer sur Internet - ne serait-ce que pour faire les mises à jour…

# sysctl net.inet.ip.forwarding=1
# sysctl net.inet6.ip6.forwarding=1

La première ligne est pour IPv4, la seconde pour IPv6.

Puis, pour garder les paramètres au redémarrage, modifiez le fichier /etc/sysctl.conf pour ajouter : net.inet.ip.forwarding=1 net.inet6.ip6.forwarding=1

PF

le fichier de configuration /etc/pf.conf

Ajouter au moins les règles suivantes :

(…)
domain = "80.67.169.12 80.67.169.40"

match out on egress from (vether0:network) to any nat-to (egress)

(…)

pass in quick proto { udp tcp } from (vether0:network) to any port domain rdr-to { $domain } port domain
pass on vether0 from 127.0.0.1 to any
pass on vether0 from (vether0:network) to any

(…)

La première règle indique que tout ce qui vient du réseau lié à l’interface vether0 doit être traduit (NATé) vers les adresses IP faisant partie du groupe egress.
La deuxième règle demande à ce que tout flux entrant qui vient du service domain (port 53) sur les protocoles udp et tcp depuis le réseau lié à l’interface vether0 soit redirigée vers le service en question. Les adresses IPv4 80.67.169.12 et 80.67.169.40 sont celles des serveurs DNS publics de la FDN. Elles peuvent être très bien celle de tout autre serveur DNS.
La troisième règle autorise tout ce qui passe en entrée et en sortie sur l’interface vether0 depuis l’interface locale vers ailleurs…
Quant à la quatrième, elle autorise tout du réseau, en entrée et en sortie, lié à l’interface vether0 vers partout !

Installation

Démarrer la VM pour l’installation : $ vmctl start -c bullseye
Choisir le menu “Install” - NE PAS APPUYEZ sur la touche ENTRÉE ; appuyez sur la touche TAB pour éditer le menu. Il va falloir corriger la ligne : > /install.amd/vmlinuz vga=788 initrd=/install.amd/initrd.gz --- quiet en > /install.amd/vmlinuz vga=off initrd=/install.amd/initrd.gz --- quiet console=ttyS0,115200n8 ; une fois, transformée, appuyez sur la touche ENTRÉE !

Le reste de l’installation de Debian se fait comme tout autre installation…

Lors de la configuration réseau, pensez bien à paramétrer la VM correctement, si nécessaire, revoyez le chapitre sur les précisions réseaux .

Une fois l’installation terminée, ne redémarrez pas par le biais de l’installateur, choisissez d’exécuter le shell, puis écrivez la commande : # halt afin d’arrêter la VM proprement !

Pour finir

Une fois que vous avez fini l’installation de Debian dans votre VM, que vous avez fait les derniers réglages nécessaires pour son bon fonctionnement, pensez à éditer à nouveau le fichier /etc/vm.conf :

Supprimer/commenter toute écriture relative à la déclaration cdrom…
Remplacer le mot clé disable par enable pour la VM Debian - si vous désirez que la VM correspondante démarre, soit lors du démarrage de votre machine, si et seulement si le service vmd est bien actif et démarré lors du processus de démarrage machine, soit lorsque vous redémarrez le service vmd par vos soins.

Voilà !

Dépannage

vmctl vmm bios firmware not found

Vous n’avez tout simplement pas installé le firmware vmm !

vmx_fault_page: uvm_fault returns 14, GPA=0xffffca78, rip=0xfbd49

Si vous avez ce message d’erreur ou similaire dans dmesg, de fait malheureusement, vous ne pourrez pas faire de la virtualisation ! :(

Voici un exemple - en anglais - de CPU Intel patché L1TF où le média de démarrage n’était pas trouvé.

Documentations

FAQ

Merci de lire la documentation officielle FAQ Virtualisation (EN), ou sa traduction officieuse FR.

manpage

vmctl(8) , vmd(8) , vm.conf(5) , vmm(4)

VM guest sur le même réseau que l’hôte.

Oui, il est possible que la VM invitée fasse partie du même segment IP que celui de votre hôte.

J’explique le propos dans cet article : [OpenBSD :: Virtualisation] Hôte et invité(s) sont sur le même bateau

Si jamais vous vous y essayer après cet article, comprenez bien :

le fonctionnement réseau, IP, les interfaces virtuelles bridge, vether, mais aussi et surtout tap.
que les règles du parefeu sont de fait différentes et son fonctionnement, aussi !
et que non, dans ce cas, il n’y a pas besoin de la redirection NAT , donc il vous faudra supprimer/commenter les modifications sysctl.

Mais tout est fait dans l’article, pour que vous compreniez bien le propos.

Enjoy-IT! Enjoy-ID!