--- categories: ['OpenBSD','Système','Base'] date: 2022-11-28T17:36:21+01:00 description: "Virtualiser Debian Bullseye (11.x) sous OpenBSD grâce à vmd" draft: false include_toc: true show_comments: false tags: ['OpenBSD','Virtualisation','Debian','Bullseye','vmd'] title: "[OpenBSD :: Virtualisation] Debian Bullseye (11.x)" translationKey: 'openbsd-vm-debian-bullseye' --- ## 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 {{< note warning >}} **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 : ``` ksh $ dmesg | egrep '(VMX/EPT|SVM/RVI)' ``` La réponse du système doit être : ⇒ pour CPU Intel : ```ksh vmm0 at mainbus0: VMX/EPT ``` ⇒ pour CPU Amd : ```ksh 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. {{< note info >}} De même, en rapport avec les failles CPU relatives à Meltdown, Spectre, certains CPU Intel sont patchés pour remédier à [L1TF](https://www.intel.fr/content/www/fr/fr/architecture-and-technology/l1tf.html). 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. ```sh # 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 :
```sh $ 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`. ```cfg 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 {{< anchor "interfaces réseaux" "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 {{< anchor "traduction d'adresses réseaux" nat >}}, et aussi des {{< anchor "règles du parefeu" pf >}}… ### 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 : ```sh # 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*… ```sh # 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 : ```cfg (…) 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](https://www.fdn.fr/actions/dns/). *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 {{< anchor "précisions réseaux" "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](http://daemonforums.org/showthread.php?t=11628) - *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](https://www.openbsd.org/faq/faq16.html)), ou sa traduction officieuse [FR](https://wiki.openbsd.fr.eu.org/doku.php/openbsd.org/faq/faq16). ### manpage - {{< man vmctl 8 >}}, {{< man vmd 8 >}}, {{< man vm.conf 5 >}}, {{< man 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 : {{< inside "sys/openbsd/vmd-hote-invite-meme-reseau" >}} 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 {{< anchor NAT 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!*** ---