OpenBSD fournit l'hyperviseur vmm(4) et le service vmd(8). Des machines virtuelles peuvent être orchestrées avec le contrôleur vmctl(8), utilisant les paramètres de configuration enregistrés dans le fichier vm.conf(8).

Les fonctionnalités suivantes sont disponibles :

• accès à la console série des machines virtuelles
• interfaces tap(4)
• appartenance VM par utilisateur ou groupe
• séparation des privilèges
• images raw, qcow2 et dérivées de qcow2
• sauvegarde et restauration de la mémoire système invité
• gestion des commutateurs virtuels
• mettre en pause et redémarrer les VM

Les fonctionnalités suivantes ne sont pas disponibles actuellement :

• graphiques
• instantanés
• support SMP invité
• passthrough matériel
• migration en direct sur plusieurs hôtes
• changement matériel en direct

Les systèmes d'exploitation invités supportés sont actuellement limités à OpenBSD et Linux. Comme il n'y a pas encore de support du VGA, l'OS invité doit prendre en charge la console série.

Un CPU avec la prise en charge de la pagination imbriquée est requis pour utiliser vmm(4). Le support peut être vérifié en cherchant les drapeaux de fonctionnalités de processeur : SLAT pour AMD ou EPT pour Intel. Dans certains cas, les capacités de virtualisation doivent être activées manuellement dans le BIOS du système. Assurez-vous d'exécuter la commande fw_update(1) après afin d'obtenir le paquet vmm-firmware requis.

La compatibilité processeur peut être vérifiée par la commande suivante :

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

Avant d'aller plus loin, activez et démarrez le service vmd(8).

# rcctl enable vmd
# rcctl start vmd

Dans l'exemple suivant, une VM doit être créée avec 50 Go d'espace disque et 1 Go de RAM. Elle sera démarrée avec le fichier image installXX.iso.

# vmctl create -s 50G disk.qcow2
vmctl: qcow2 imagefile created
# vmctl start -m 1G -L -i 1 -r installXX.iso -d disk.qcow2 example
vmctl: started vm 1 successfully, tty /dev/ttyp8
# vmctl show
   ID   PID VCPUS  MAXMEM  CURMEM     TTY        OWNER NAME
    1 72118     1    1.0G   88.1M   ttyp8         root example

Pour voir la console d'une VM nouvellement créée, attachez-la à sa console série :

# vmctl console example
Connected to /dev/ttyp8 (speed 115200)

La séquence d'échappement ~. est nécessaire pour quitter la console série. Lors de l'utilisation d'une console série vmctl au-travers de SSH, le caractère ~ (tilde) doit être échappé pour empêcher ssh(1) de supprimer la connexion. Pour sortir d'une console série depuis SSH, utilisez ~~.

La VM peut être arrêtée en utilisant vmctl(8).

# vmctl stop example
stopping vm: requested to shutdown vm 1

Les machines virtuelles peuvent être démarrées avec ou sans le fichier vm.conf(5) à sa place. L'exemple suivant de /etc/vm.conf répliquerait la configuration ci-dessus :

vm "example" {
    memory 1G
    enable
    disk /home/user/disk.qcow2
    local interface
}

Certaines propriétés de configuration dans vm.conf(5) peuvent être rechargées par vmd(8) à la volée. D'autres changements, tel que l'ajustement de la quantité de RAM ou de l'espace disque, requiert que la VM soit redémarrée.

Les accès réseaux aux invités vmm(4) peuvent être configurés de différentes manières, quatre d'entre elles sont détaillées dans ce chapitre

Dans les exemples ci-dessous, des ensembles d'adresses IPv4 variés seront mentionnés pour différents cas d'utilisation :

• Les adresses privées (RFC1918) sont celles réservées pour les réseaux privés tels que 10.0.0.0/8, 172.16.0.0/12, et 192.168.0.0/16 et ne sont généralement pas routables.
• Les adresses partagées (RFC6598) sont similaires aux adresses privées dans le fait qu'elles ne sont pas généralement routables, mais elles sont destinées à être utilisées sur un équipement qui peut assurer une traduction d'adresses. L'espace d'adresse est 100.64.0.0/10.

Pour ce paramétrage, vmm utilise les local interfaces : interfaces qui utilisent l'espace d'adressage partagé défini ci-dessus.

L'utilisation du drapeau -L de vmctl(8) crée une interface locale dans l'invité qui recevra une adresse depuis vmd via DHCP. Ce qui crée essentiellement deux interfaces : une pour l'hôte et l'autre pour la VM.

Cette configuration s'appuie sur la précédente et permet aux VM de se connecter en-dehors de l'hôte. La redirection d'IP est requise pour fonctionner.

La ligne suivante dans /etc/pf.conf activera la Traduction d'Adresses Réseaux et redirigera les requêtes DNS vers le serveur spécifié :

match out on egress from 100.64.0.0/10 to any nat-to (egress) 
pass in proto { udp tcp } from 100.64.0.0/10 to any port domain \
	rdr-to $dns_server port domain

Rechargez le jeu de règles PF et les VM peuvent maintenant se connecter à Internet.

Parfois, vous voudrez peut être un contrôle supplémentaire sur le réseau virtuel depuis vos VM, tel que le fait d'être capable de mettre certaines sur votre propre commutateur virtuel. Ce qui peut être fait en utilisant un bridge(4) et une interface vether(4).

Créez une interface vether0 qui aura une adresse IPv4 privée telle que définie ci-dessus. Dans cet exemple, nous utiliserons le réseau 10.0.0.0/8.

# echo 'inet 10.0.0.1 255.255.255.0' > /etc/hostname.vether0
# sh /etc/netstart vether0

Créez l'interface bridge0 avec l'interface vether0 en tant que pont :

# echo 'add vether0' > /etc/hostname.bridge0
# sh /etc/netstart bridge0

Assurez-vous que le NAT soit paramétré correctement si les invités sur le réseau virtuel doivent accéder au-delà de la machine physique. Et, ajustez la ligne NAT dans /etc/pf.conf qui pourrait ressembler à cela :

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

Les lignes suivantes dans vm.conf(5) peuvent être utilisées pour s'assurer que le commutateur virtuel soit défini :

switch "my_switch" {
    interface bridge0
}

vm "my_vm" {
    ...
    interface { switch "my_switch" }
}

À l'intérieur de l'invité my_vm, il est maintenant possible d'assigner à vio0 une adresse du réseau 10.0.0.0/24 et de paramétrer la route par défaut à 10.0.0.1.

Par convenance, vous souhaiterez paramétrer un serveur DHCP sur vether0.

Dans ce scénario, l'interface VM sera attachée au même réseau que l'hôte ainsi elle peut être configurée comme si elle était connectée physiquement au réseau de l'hôte. Cette option fonctionne seulement pour les périphériques Ethernet, puisque la norme IEEE 802.11 empêche les interfaces wifi de participer aux ponts réseaux.

Créez l'interface bridge0 avec l'interface réseau de l'hôte comme pont pour l'interface vether0 nouvellement créée. Dans cet exemple, l'interface réseau de l'hôte est em0 - vous devriez substituer le nom de l'interface par celui que vous souhaitez pour connecter la VM à :

# echo 'add em0' > /etc/hostname.bridge0
# sh /etc/netstart bridge0

Tout comme nous l'avons fait dans l'exemple précédent, créez ou modifiez le fichier vm.conf(5) pour assurer que le commutateur virtuel soit défini :

switch "my_switch" {
    interface bridge0
}

vm "my_vm" {
    ...
    interface { switch "my_switch" }
}

L'invité my_vm peut maintenant participer au réseau de l'hôte comme si elle était physiquement connectée.

Note : Si l'interface de l'hôte (em0 dans l'exemple ci-dessus) est aussi configurée pour utiliser DHCP, dhclient(8) fonctionnant dessus cet interface peut bloquer les requêtes DHCP venant des VM invités. Dans ce cas, vous devez choisir une interface d'hôte différente n'utilisant pas DHCP, ou terminer tout processus de dhclient(8) assigné à l'interface avant de démarrer les VM, ou utiliser des adresses IP statiques pour les VM.

Cette page est la traduction officieuse de la page “Virtualization” de la FAQ officielle d'OpenBSD.
En cas de doute, merci de vous y référer !

Si vous voulez participer à l'effort de traduction, merci de lire ce topic.

Contribut(rice|eur)s :