OBSD4* : wiki

Version de traduction basée sur la 6.4 officielle (v1.11 : 09/11/2018)


FAQ - Virtualisation

Introduction

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'exploitations 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.

Pré-requis

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 virtualiation 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

Démarrer une VM

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 disk.qcow2 -s 50G
vmctl: qcow2 imagefile created
# vmctl start example -m 1G -L -i 1 -cdrom installXX.iso -d disk.qcow2
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 1
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 1 
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.

Administration réseau

Les accès réseaux aux invités vmm(4) peuvent être configurées 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ées 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.

Option 1 - Les VM n'ont besoin de parler qu'à l'hôte et entre elles

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 vmm via DHCP. Ce qui crée essentiellement deux interfaces : une pour l'hôte et l'autre pour la VM.

Option 2 - NAT pour les 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 :

match out on egress from 100.64.0.0/10 to any nat-to (egress) 

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

Option 3 - Contrôle supplémentaire sur la configuration réseau des VM

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.

Option 4 - VM en tant qu'hôtes réels sur le même réseau

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ée 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.