En 2011 dans l'article XenServer : le Xen facile je présentais la solution XenServer de Citrix qui est un serveur Xen prêt à l'emploi doté d'une console de gestion graphique similaire à vsphere : XenCenter. Puis en 2014 j'ai découvert que Xen installé à la main sur Debian n'était pas si méchant que ça : Découverte de XEN sur Debian Wheezy. Eh bien il parait que l'on peut marier les deux. Installer une debian, Xen, puis la couche Xapi qui permet ensuite de se connecter soit avec Xencenter, soit avec openxenmanager.

Sur papier l'installation est rapide et simple, mais en pratique elle est plutôt laborieuse car il y a beaucoup de bugs qui font que ça ne marche pas du premier coup et qu'il faut chercher des solutions. Voilà donc étape par étape comment installer Xapi sur Debian 7 et s'y connecter avec XenCenter.

Installation de Xen

Jusque là, rien de compliqué. Il faut installer le paquet xen-hypervisor :

# apt-get install xen-hypervisor

Puis on va dire à grub de booter en priorité sur Xen :

# dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen
# update-grub

Puis, on reboote afin de démarrer sur Xen, c'est très important sinon la suite ne fonctionnera pas.

# reboot

Installation de xapi

Après avoir démarré en Xen, installez xcp-xapi :

# apt-get install xcp-xapi

Notez que des paquets de développement comme linux-image sont installés comme dépendances. C'est pour pouvoir compiler les modules d'openvswitch. Cette étape est faite avec dkms, elle est donc automatique et suivra les montées de version du kernel sans action de la part du sysadmin. Pour le gestionnaire de réseau XCP, il est plus simple de laisser bridge.

Note : vous allez obtenir quelques messages de fail, ignorez-les pour le moment.

On va spécifier à Xen d'utiliser xapi comme backend. Editez le fichier /etc/defaults/xen :

TOOLSTACK="xapi"

Maintenant on va configurer notre bridge. Editez le fichier /etc/network/interfaces et modifiez-le comme ceci :

auto lo
iface lo inet loopback

# allow-hotplug eth0
# iface eth0 inet dhcp

auto xenbr0
iface xenbr0 inet dhcp
  bridge_ports eth0

Note : oui, eth0 est désactivé. Mais xenbr0 va prendre le relai.

Maintenant, rebootez le serveur.

# reboot

Connexion XenCenter

Si votre système ne boote pas et bloque sur la configuration du réseau Xen, vous devez alors forcer le redémarrage puis booter en mode de dépannage sur grub. Puis refaites la configuration du réseau ci-dessus.

Maintenant que votre système est booté, ouvrez la console XenCenter sur une autre machine et tentez de vous connecter à votre serveur Debian :

Au bout de quelques instants on obtient l'erreur suivante :

Après avoir bataillé et surtout ragé parce que visiblement personne n'avait jamais rencontré ce problème alors que je le reproduits à volonté, j'ai enfin trouvé une solution sur ce thread d'un forum citrix. Il s'agit en fait d'un fichier .pem qui ne fonctionne pas bien et qu'il faut donc détruire :

# rm /etc/xcp/xapi-ssl.pem

Puis relancez le service xcp-xapi pour regénérer ce fichier :

# service xcp-xapi restart

Maintenant, tentez à nouveau de vous connecter avec Xencenter, cela doit fonctionner.

Et voilà !

Il faut savoir cependant que xencenter ne révèle son potentiel que sur une infrastructure composée de plusieurs serveurs. Les VM et les ISO ne peuvent pas être stockées sur l'hyperviseur il faut obligatoirement un datastore externe (iSCSI, CIFS ou NFS).

Dans l'article Aperçu de bhyve - Episode 1 vmrun.sh nous avons vu que bhyve est intéressant mais que le script vmrun.sh est trop limité pour pouvoir se faire plaisir. Nous allons voir si vmrc nous offre plus de possibilités ou non.

Installation de vmrc

Voyons si vmrc est disponible dans les dépôts pkgng :

# pkg search vmrc

Arf non :( ! Et visiblement il n'est pas non plus dans les ports. Il va falloir l'installer à la main. Bon, commençons par installer git :

# pkg install git

Puis récupérons les sources du projet :

# git clone https://github.com/michaeldexter/vmrc.git

Entrons dans le répertoire et installons le tout à l'aide des script install-vmrc.sh et install-templates.sh :

# cd vmrc
# ./install-vmrc.sh
# cd templates
# ./install-templates.sh

La documentation de vmrc recommande sysutils/grub2-bhyve pour les guest Linux :

# pkg install grub2-bhyve

Utilisation de vmrc

Création d'un guest FreeBSD

Dans le répertoire de vmrc récupéré par git (/root/vmrc dans notre exemple) se trouve le script mkvm.sh qui permet de choisir le type de vm dont on a besoin et d'en automatiser la création et l'installation. Exécutons mkvm.sh :

# cd /root/vmrc
# ./mkvm.sh

Nous pouvons alors choisir le type de VM que nous souhaitons créer :

Listing templates in /usr/local/vmrc/templates/

t_centos65              t_freebsd92stablezfs    t_pfsense-fetch.sh
t_freebsd10             t_freebsd92zfs          t_ubuntu1304
t_freebsd10malloc       t_freenas               t_ubuntu1310
t_freebsd10zfs          t_freenas-fetch.sh      virtio21pf
t_freebsd11current      t_master_template       virtio83
t_freebsd11currentzfs   t_openbsd               virtio83pf
t_freebsd92             t_openbsd-fetch.sh      virtio84
t_freebsd92stable       t_pfsense               virtio91

Enter a template to use:

Ici comme je veux une VM Freebsd classique j'ai sélectionné t_freebsd10 et validé. Ensuite on donne un nom à la vm, j'ai mis freebsd.

Enter a custom name without ID or leave blank to keep vm2
freebsd

Le script va créer un disque virtuel de 2G puis télécharger les différents sets (base.txz et kernel.txz) de FreeBSD pour les installer. Voyons maintenant si on peut booter. Pour cela on va utiliser le service vm qu'on doit activer dans le /etc/rc.conf.local :

vm_enable="YES"

Puis on démarre la vm :

# service vm start freebsd
vm: starting freebsd
vm: freebsd: no configuration file found: Skipping...

Wow ! Cela ne fonctionne pas ! Étrange. Jetons un œil au /usr/local/vmrc/vm :

# ls /usr/local/vmrc/vm/
freebsd2        openbsd01       vm0

Il semble qu'il ait décidé de nommer ma vm freebsd2. Je sens venir les confusions quand on commence à avoir beaucoup de vm, mais peut-être que j'aurais du choisir un autre nom. Bon, soit, utilisons freebsd2 :

# service vm start freebsd2
vm: starting freebsd2
starting freebsd2
Entering f_load()
Entering f_eptcheck()
Entering f_vmmcheck()
f_vmmcheck: vmm.ko kernel module not loaded. Loading...
f_netstart: bridgestp.ko kernel module not loaded. Loading...
f_netstart: if_bridge.ko kernel module not loaded. Loading...
f_netstart: if_tap.ko kernel module not loaded. Loading...
net.link.tap.up_on_open: 0 -> 1
Creating the bridge0 network interface.
Associating em0 with bridge0.
Running: ifconfig bridge0 addm em0 up
f_load: Attaching raw image /usr/local/vmrc/vm//freebsd2/freebsd2.img for fsck
f_load: DEBUG: disk image is /usr/local/vmrc/vm//freebsd2/freebsd2.img; vm_device is md1
f_load: fsck_ufs -y md1p2
** /dev/md1p2
** Last Mounted on /usr/local/vmrc/vm/freebsd2/mnt
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
13303 files, 139007 used, 368296 free (208 frags, 46011 blocks, 0.0% fragmentation)

***** FILE SYSTEM MARKED CLEAN *****
Entering f_mddestroy()
f_mddestroy: Destroying all memory devices associated with freebsd2
f_mddestroy: Destroying mdconfig device: md0
mdconfig: ioctl(/dev/mdctl): Device busy
f_mddestroy: Destroying mdconfig device: md1
f_load: Running the bhyveload command:
/usr/sbin/bhyveload -m 1024 -d /usr/local/vmrc/vm//freebsd2/freebsd2.img freebsd2
Consoles: userboot

FreeBSD/amd64 User boot, Revision 1.1
(root@snap.freebsd.org, Thu Jan 16 22:18:02 UTC 2014)
Loading /boot/defaults/loader.conf
can't find 'kernel'
-
can't load 'kernel'

Type '?' for a list of commands, 'help' for more detailed help.
OK

Bon, ça ne marche toujours, cependant je remarque les points suivants :

• vmrc va monter les modules si nécessaires, comme vmm
• vmrc vérifier le système de fichiers du disque virtuel avant de le monter
• vmrc créé un bridge sur l'hôte, et ça c'est cool

Bon, changeons de tty (ctrl+alt+f2 ou alt+f2 pour vmware) et arrêtons la vm :

service vm stop freebsd2

Ensuite retournons en tty1 et voyons ce qui s'est passé. Analysons le contenu de /usr/local/vmrc/vm/freebsd2/mnt pour voir si le kernel est effectivement manquant (on remarque au passage que vmrc a la délicatesse de faire un point de montage, afin de voir depuis l'hôte ce qu'il y a dans le fichier freebsd2.img) :

# ls /usr/local/vmrc/vm/freebsd2/mnt/
.cshrc          bin             lib             proc            sys
.profile        boot            libexec         rescue          tmp
.snap           dev             media           root            usr
COPYRIGHT       etc

Hum, à première vue tout semble correct, mais il semble qu'un fichier kernel soit manquant dans boot/kernel.

Faisons une autre machine virtuelle pour voir, que nous nommons freetest :

# cd /root/vmrc
# ./mkvm

Bon on remarque qu'il la nomme freetest3. Aucune importance, démarrons cette VM

# service vm start freetest3
  ______               ____   _____ _____
 |  ____|             |  _ \ / ____|  __ \
 | |___ _ __ ___  ___ | |_) | (___ | |  | |
 |  ___| '__/ _ \/ _ \|  _ < \___ \| |  | |
 | |   | | |  __/  __/| |_) |____) | |__| |
 | |   | | |    |    ||     |      |      |
 |_|   |_|  \___|\___||____/|_____/|_____/    ```                        `
                                             s` `.....---.......--.```   -/
 +------------Welcome to FreeBSD-----------+ +o   .--`         /y:`      +.
 |                                         |  yo`:.            :o      `+-
 |  1. Boot Multi User [Enter]             |   y/               -/`   -o/
 |  2. Boot [S]ingle User                  |  .-                  ::/sy+:.
 |  3. [Esc]ape to loader prompt           |  /                     `--  /
 |  4. Reboot                              | `:                          :`
 |                                         | `:                          :`
 |  Options:                               |  /                          /
 |  5. Configure Boot [O]ptions...         |  .-                        -.
 |                                         |   --                      -.
 |                                         |    `:`                  `:`
 |                                         |      .--             `--.
 |                                         |         .---.....----.
 +-----------------------------------------+


Booting...
f_load: freetest3 appears to have loaded.
Entering f_boot()
f_boot: Starting VM Networking. "File exists" warnings are okay.
Running: ifconfig tap8030 create
ifconfig: create: bad value
Running: ifconfig bridge0 addm tap8030 up
ifconfig: BRDGADD tap8030: File exists
Checking for preflight script /usr/local/vmrc/vm//freetest3/freetest3.
preflight.sh

f_boot: Running the bhyveload command:
/usr/sbin/bhyveload -m 1024 -d /usr/local/vmrc/vm//freetest3/freetest3.img freetest3
f_boot: nmdm.ko is loaded.
f_boot: Booting freetest3 on console /dev/nmdm3A
root@FreeBSD:~/vmrc #

Cette fois, cela fonctionne. Donc pour une raison inconnue, la dernière fois l'installation du kernel ne s'est pas terminée correctement.

Connectons-nous à la console de freetest3 :

# service vm attach freetest3

On voit alors toute la séquence de démarrage, puis on arrive au login :

Thu Jul 24 07:21:19 PDT 2014

FreeBSD/amd64 (bhyve) (console)

login:

Question idiote : quel est le mot de passe root défini par mkvm ? Apparemment ce n'est pas root, ce n'est pas vide, ce n'est pas le nom de la vm. Et les instructions ne disent rien à ce sujet. Passons sur le tty2 (ctrl+alt+f2 ou alt+f2) et jetons un œil au script lui-même :

# cat /usr/local/vmrc/templates/t_freebsd10 | grep password
vm_password="bsd" # VM password (clear text for now) (FreeBSD only)

Voilà ! Le mot de passe root est bsd !

Voyons si la connexion à internet fonctionne :

# ping 8.8.8.8

Hum ! Apparemment non ! Essayons de voir pourquoi :

# cat /etc/rc.conf
[...]
ifconfig_vtnet0="192.168.2.210 netmask 255.255.255.0"
defaultrouter="192.168.2.1"
[...]

Hum, ce sous-réseau ne correspond pas au réseau de l'hôte (192.168.232.0/24), donc à moins qu'il y ait du NAT cela ne peut pas marcher aussi facilement. Sur l'hôte, la commande pfctl -sr m'indique que pf ne fonctionne pas. Donc pas de NAT. Jetons un œil au /usr/local/vmrc/vm/freetest3/freetest3.conf :

[...]
vm_ipv4="192.168.2.210"  # VM IPv4 address (blank for DHCP) (FreeBSD only)
vm_gw="192.168.2.1"      # VM IPv4 gateway (FreeBSD only)
[...]

Donc modifions cela pour spécifier une adresse sur la même plage que l'hôte, en partant du principe que vmrc active un bridge :

[...]
vm_ipv4="192.168.232.210"  # VM IPv4 address (blank for DHCP) (FreeBSD only)
vm_gw="192.168.232.1"      # VM IPv4 gateway (FreeBSD only)
[...]

Puis redémarrons la VM :

# service vm restart freetest3

Entrons dans la VM et modifions son /etc/rc.conf :

ifconfig_vtnet0="192.168.232.210 netmask 255.255.255.0"
defaultrouter="192.168.232.1"

Relançons le réseau :

# service netif restart

Lançons maintenant un ping vers internet :

# ping 8.8.8.8

Hum, encore une fois, cela ne marche pas. Essayons un ping vers 192.168.232.1, la passerelle vmware :

 # ping 192.168.232.1
PING 192.168.232.1 (192.168.232.1): 56 data bytes
64 bytes from 192.168.232.1: icmp_seq=0 ttl=128 time=2.127 ms

Cette fois ça fonctionne !

Donc dans mon cas pas d'accès à internet, mais j’émets l'hypothèse suivante : c'est VMware qui refuse les paquets venant de mon bridge.

Le bilan est déjà beaucoup plus positif qu'avec vmrun.sh. Nous sommes parvenus à installer - très facilement - et à faire fonctionner un guest FreeBSD10. Nous n'avons pas pu utiliser le réseau, mais nous n'étions pas loin.

Guest Linux

Reprenons notre ISO de debian, debian-7.6.0-amd64-netinst.iso, et voyons si vmrc va réussir à la booter et à installer un système invité debian. Jetons un œil aux templates :

 # ls /usr/local/vmrc/templates/
t_centos65              t_freebsd92stablezfs    t_pfsense-fetch.sh
t_freebsd10             t_freebsd92zfs          t_ubuntu1304
t_freebsd10malloc       t_freenas               t_ubuntu1310
t_freebsd10zfs          t_freenas-fetch.sh      virtio21pf
t_freebsd11current      t_master_template       virtio83
t_freebsd11currentzfs   t_openbsd               virtio83pf
t_freebsd92             t_openbsd-fetch.sh      virtio84
t_freebsd92stable       t_pfsense               virtio91

Pas de template pour debian :( mais comme je suis fou, je vais prendre le template t_ubuntu1304 et le modifier pour Debian. Je commence par le dupliquer :

# cd /usr/local/vmrc/templates
# cp t_ubuntu1304 t_debian76

Puis j'édite mon template :

# My awesome debian template

vm_cpus="1"              # Number of VM virtual CPUs (max 16)
vm_ram="256"            # VM RAM Allocation in MB
vm_console="nmdm"       # stdio, nmdm, tmux or tmux-detached (sysutils/tmux)
vm_os_type="linux"       # freebsd, openbsd, or linux
vm_os_ver="debian7.6"  # Exact OS version if auto-fetching
vm_dev_layout="gpt"      # "gpt" or "mbr" volume layout (FreeBSD only)
vm_dev_type="img"        # "img" for image, "zvol" or blank for other device
vm_device=""             # An existing device (sans /dev/) i.e. "ada1"
vm_dev_size="10G"         # M or G for raw "img" volumes
vm_hostname=""           # VM hostname (FreeBSD only)
vm_timezone=""           # VM timezone (FreeBSD only)
vm_ipv4_addr=""          # Experimental for jail use
vm_searchdomain=""       # (FreeBSD only) Commented out below
vm_dns_addr=""           # (FreeBSD only) Commented out below
dist_site=""             # Hostname and directory for binary distribution sets
iso_site="http://cdimage.debian.org/debian-cd/7.6.0/amd64/iso-cd/"
                         # Hostname and directory for ISO image
iso_img="debian-7.6.0-amd64-netinst.iso"
                         # ISO filename for remote fetch
grub_boot_cmd="/usr/local/sbin/grub-bhyve -r hd0,msdos1 -m ${host_vmroot}/${vm_name}/device.map -M $vm_
ram $vm_name"
                         # grub-bhyve command to boot from IMG
grub_iso_cmd="/usr/local/sbin/grub-bhyve -r cd0 -m ${host_vmroot}/${vm_name}/device.map -M $vm_ram $vm_
name"
                         # grub-bhyve command to boot from ISO
vm_hostbridge=""         # "amd_" for the AMD hostbridge
bhyve_flags=""           # Additional bhyve(8) flags
virtio_type="virtio-blk" # "ahci-hd" or "virtio-blk"

Ensuite on lance la création de la vm que je vais nommer debian:

# cd /root/vmrc
# ./mkvm.sh

Durant la création de la VM, j'obtiens beaucoup d'erreurs de ce type :

No such file or directory

Je remarque que le template semble se comporter comme pour un guest FreeBSD car je vois passer du loader.conf. Même problème si j'utilise les templates ubuntu fournis. Sont-ils bugués ? Bon, la documentation dit qu'après avoir provisionné la vm, il faut utiliser une commande particulière pour la démarrer vu qu'on utilise une iso. On va partir du principe que le provisionnement est fait et lancer la fameuse commande :

# /usr/local/etc/rc.d/vm iso debian0
vm: booting the ISO for VM  debian0
Entering f_grubcheck()
Entering f_tmuxcheck()
Entering f_eptcheck()
Entering f_vmmcheck()
f_vmmcheck: vmm.ko is loaded.
f_netstart: bridgestp.ko is loaded.
f_netstart: if_bridge.ko is loaded.
f_netstart: if_tap.ko is loaded.
f_netstart: bridge0 exists.
        member: em0 flags=143
f_netstart: em0 is assoc. with host0.
Entering f_iso()
f_iso: /usr/local/vmrc/vm//debian0/debian0.img found.
f_iso: Checking for /usr/local/vmrc/distributions//debian7.6/
f_iso: Checking for /usr/local/vmrc/vm//debian0/debian0.iso
f_iso: Fetching debian-7.6.0-amd64-netinst.iso
/usr/local/vmrc/distributions//debian7.6//debi100% of  222 MB 2520 kBps 01m30s
f_iso: Copying debian-7.6.0-amd64-netinst.iso to /usr/local/vmrc/vm//debian0/debian0.iso
Copying debian-7.6.0-amd64-netinst.iso to /usr/local/vmrc/vm//debian0/debian0.iso
f_iso: Creating /usr/local/vmrc/vm//debian0/device.map
(hd0) /usr/local/vmrc/vm//debian0/debian0.img
(cd0) /usr/local/vmrc/vm//debian0/debian0.iso
f_iso: Running the ISO grub command:
/usr/local/sbin/grub-bhyve -r cd0 -m /usr/local/vmrc//debian0/device.map -M 256 debian0
Could not create VM debian0
Error in initializing VM
funcname: Calling f_boot
Entering f_boot()
f_boot: debian0 is not loaded. Skipping...

Fail... encore une fois, pas moyen de démarrer Linux. Mais j'ai l'impression que cette fois le problème est localisé sur grub2-bhyve, car vmrc a bien téléchargé l'iso et commandé l'exécution de la vm.

L'article étant assez long, on va s'arrêter là.

Crashes et incidents

J'ai observé plusieurs crashes ou comportements étranges avec FreeBSD. J'ai rencontré des freezes du système, mais le bug le plus ennuyeux et le plus fréquent est celui de l'auto-démarrage des vm. En effet, puisqu'on a ajouté vm_enable="YES" au rc.conf.local , les vm sont lancées au démarrage de l'hôte. En soit ce n'est pas grave, sauf que les vm se lancent au premier plan, et bloquent systématiquement sur le bootloader. A ce stade aucune frappe clavier ne peut être prise en compte. Il faut donc redémarrer FreeBSD directement dans la console vmware et appuyer sur CTRL+c au boot pour annuler le lancement des vm. C'est un bug critique et très embêtant qui retire toute possibilité d'utiliser vmrc en production pour le moment. J'ai également fait face à un autre problème étrange : le mot de passe root de l'hôte qui saute. Parfois, après un reboot ou le lancement d'une vm, je suis dans l'incapacité de me logger en root sur l'hote, que ce soit en direct ou en SSH, car le mot de passe est refusé. Je n'ai pas d'autre solution que de me réinitialiser ou charger un snapshot VMware pour revenir en arrière.

Conclusion

vmrc apporte beaucoup par rapport au script vmrun.sh puisqu'il permet d'automatiser l'installation des vm, à la manière de lxc ou ezjail, ce qui nous facilite assez la vie. Cependant seuls les templates FreeBSD semblent fonctionnels et je n'ai toujours pas pu démarrer un guest Linux. Pas d'accès au réseau non plus mais je ne tire pas de conclusions sur ce point. Enfin on sent le côté expérimental de vmrc avec des bugs critiques au démarrage de l'hôte notamment, qui empêchent toute utilisation en production pour le moment. J'essaie de contacter l'auteur de vmrc pour obtenir de l'aide sur ce point. vmrc est un projet intéressant à suivre.

Dans le prochain

bhyve est un hyperviseur pour FreeBSD qui utilise les capacités de virtualisation du CPU (VT-x + EPT chez Intel et AMD-V + RVI chez AMD) et fourni des périphériques virtuels VirtIO aux systèmes invités. En un sens c'est une alternative à Linux-KVM pour FreeBSD. Cette solution vient en complément des jails qui se limitent à faire tourner du FreeBSD. bhyve supporte déjà des systèmes invités Linux, FreeBSD et OpenBSD. On ne sait pas encore si Windows sera supporté, mais c'est très probable. bhyve n'émule pas encore de bios ni de carte VGA, ce qui signifie que vous allez devoir travailler en mode texte, exactement comme pour les jails.

Il est intéressant de noter que bhyve est déjà pris en charge par libvirt, ce qui vous permet de gérer et piloter vos VM grâce à cette API, en local ou via une console distante (virt-manager). Je testerai cela probablement dans un prochain article.

Du virtuel dans du virtuel

Je n'ai pas de machine physique libre ayant les pré requis pour bhyve, c'est à dire avec un processeur suffisamment récent pour supporter à la fois VT-x et EPT. J'ai donc utilisé mon ordinateur portable de 2012 équipé d'un i5, sur lequel tourne Windows 7 (pour le travail) et sur lequel j'installe VMware Workstation. Pourquoi VMware ? Parce qu'il fourni une fonctionnalité intéressante : le support de nested VT-x. En gros la machine virtuelle que vous faites tourner peut elle-même faire tourner des machines virtuelles. Donc je vais pouvoir créer dans VMware une machine virtuelle FreeBSD, puis exécuter bhyve dans cette dernière afin de faire tourner d'autres VM dedans.

A noter que VirtualBox ne supporte pas le nested VT-x, ce qui signifie que votre VM FreeBSD ne pourra pas exécuter bhyve car absence d'accès aux instructions VT-X + EPT du CPU hôte.

Allons-y

Le site du projet bhyve fourni un lien vers un fichier texte contenant les instructions. Donc je me contente de les suivre pour le moment.

Charger les modules

Pour charger les modules de manière volatile :

# kldload vmm
# kldload if_tap

Note : Si une erreur s'affiche au chargement du module vmm, il est probable que votre processeur ne soit pas supporté, ou qu'il ne dispose pas des instructions VT-x ou EPT.

Pour charger les modules de manière persistante (au reboot), éditez le fichier /boot/loader.conf

vmm_load="YES"
if_tap_load="YES"

Récupérer le script d’exécution

Le script d’exécution devrait être présent dans /usr/share/examples/bhyve/vmrun.sh mais il est également possible de le récupérer à cette adresse :

# fetch http://people.freebsd.org/~neel/bhyve/vmrun.sh

Ce script va gérer la création de la VM, le montage de l'iso ,d'un périphérique de stockage et d'une interface réseau. Rendons-le exécutable :

# chmod +x vmrun.sh

Guest FreeBSD

Récupérer une ISO de FreeBSD 10 :

fetch http://people.freebsd.org/~neel/bhyve/release.iso.iso

Démarrer la VM :

./vmrun.sh vm1

Le bootloader du FreeBSD invité devrait alors s'afficher.

Après le chargement du kernel, on obtient une magnifie erreur de point de montage root non trouvé :

J'ai trouvé ce fil de discussion qui explique une solution de contournement, mais le problème c'est que je ne peux rien saisir au clavier, les caractères ne sont pas pris. Bug ? Limitation due à l'utilisation de VMware ? Il semblerait plutôt que ce soit un problème de console non adaptée.

Bon, faisons un deuxième essai. La FAQ de Bhyve mentionne l'existence d'images RAW de FreeBSD11-CURRENT conçues exprès pour démarrer dans Bhyve. Commencez par visiter le FTP avec l'adresse suivante : http://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/11.0-CURRENT/amd64/Latest/ afin de repérer le nom de l'image. Ensuite récupérez cette image avec fetch (commande non détaillée car l'URL est trop longue).

Ensuite supprimons le fichier release.iso pour ne pas qu'il soit capturé par vmrun.sh, décompressons notre image RAW, et démarrons le tout :

# rm release.iso
# unxz FreeBSD-11.0-CURRENT-amd64-20140714-r268622.raw.xz
# ./vmrun.sh -d FreeBSD-11.0-CURRENT-amd64-20140714-r268622.raw vm1

Et cette fois ça marche. On arrive au login, il suffit d'entrer "root" sans mot de passe, et on accède à notre système virtuel FreeBSD 11 :

Pas d'accès au réseau pour le moment, mais c'est normal car la carte tap0 crée par le script vmrun.sh n'est reliée à rien (ni bridge ni routage). Il ne semble pas possible pour le moment de "sortir" de la vm ou de l'éteindre avec la commande shutdown. Cette dernière commande ne fera qu'arrêter le système guest, mais bhyve continuera de fonctionner. La solution constite à passer sur un autre tty (ALT+F2) et utiliser la commande suivante :

# bhyvectl --destroy --vm=vm1

Bhyve fonctionne plutôt bien mais est extrêmement basique, beaucoup de choses se font manuellement et l'émulation d'un CDROM ne semble pas vraiment au point puisque FreeBSD10 n'a pas réussi à booter. L'utilisation d'une image FreeBSD-11 toute prête a permis de contourner le problème, le boot s'est déroule bien et le clavier est pris en charge.

J'ai expliqué mon problème de FreeBSD10 qui ne boote pas sur irc (#bhyve), on m'a recommandé d'utiliser vmrc. Cela fera peut-être l'objet d'un prochain article.

Guest Linux

bhyve affirme supporter les guest Linux. Faisons donc un essai avec Debian Wheezy.

# fetch http://cdimage.debian.org/debian-cd/7.6.0/amd64/iso-cd/debian-7.6.0-amd64-netinst.iso

Ensuite démarrons cette VM à l'aide du script vmrun.sh mais en spécifiant cette fois l'emplacement de l'ISO :

# ./vmrun.sh -I debian-7.6.0-amd64-netinst.iso vm2

Le test va être rapide car cela ne marche pas du tout :

En l'absence de BIOS ou UEFI, bhyve n'est pas capable de booter tout seul. La FAQ de bhyve indique la nécessité d'utiliser sysutils/grub2-bhyve. On va s'arrêter là et miser sur vmrc dans un prochain article car il parait que tout ceci est alors automatisé.

Conclusion

Cette première découverte de bhyve est très intéressante. L'idée est bonne, utiliser la virtualisation matérielle VT-x + EPT et VirtIO pour les périphériques, ce qui assure en théorie le maximum de performances. Malheureusement son utilisation n'est vraiment pas évidente, on sent le côté expérimental de la chose. bhyve est un produit encore brut qu'il faudra exploiter avec de meilleurs outils.

XEN n'est pas nouveau pour moi, j'en parlais sur ce blog en 2011. Mais à l'exception de la solution XenServer, c'était relativement obscur, compliqué, et déprécié par les distributions Linux au profil de solutions alternatives (KVM et LXC). Je pensais vraiment que Xen allait disparaitre ou sombrer dans l'oubli. En fait non car en 2014 non seulement XEN est toujours très utilisé (par exemple chez AWS, le cloud Amazon), mais il est en plus upstream dans le kernel Linux et géré par la Linux Fundation. Il est donc revenu en force dans toutes les distributions Linux. J'ai été surpris de constater que maintenant on peut l'installer et l'utiliser très facilement sur Debian Wheezy, je vais partager mon expérience sur cet article ;)

Notions Dom0 et DomU

Sur des hyperviseurs comme Hyper-V ou VMware nous sommes habitués à exécuter des machines virtuelles depuis l'hôte. Or sur XEN cette notion est différente, l'hôte devient une machine virtuelle XEN avec des privilèges d'administration nommée Dom0. Donc au démarrage votre serveur doit démarrer XEN et ensuite le Dom0 sur lequel vous vous connectez. On peut limiter la RAM et les vcpus de Dom0 comme pour les autres.

Les autres VMs que l'on va faire tourner sur XEN, et qui elles n'ont pas de privilèges particuliers, sont nommés DomU. Voici un schéma pour récapituler :

Dans le cas de cet article, le Dom0 est Debian Wheezy. Cela peut paraître assez abstrait comme ça, mais si vous le mettez en oeuvre, vous comprendrez !

Installation de Debian

L'installation se fait à partir d'une ISO tout à fait normale de Debian. Personnellement je suis parti sur une Wheezy amd64 en netinstall, donc la debian-7.4.0-amd64-netinst.iso. Il est possible d'utiliser LVM avec XEN, mais je préfère faire simple pour le moment, je choisis donc un partitionnement assisté avec tout dans une même partition.

Installation de XEN

Sur une Debian Wheezy fraichement installée, il suffit d'installer le paquet xen-hypervisor :

# apt-get install xen-hypervisor

Boot automatique sur Xen

Passer Xen en priorité dans grub :

# dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen
# update-grub

Configuration du réseau (bridge)

Il suffit de modifier le fichier /etc/network/interfaces pour avoir un Bridge. Exemple pour moi qui suis en DHCP :

#The loopback network interface
auto lo
iface lo inet loopback

iface eth0 inet manual

auto xenbr0
iface xenbr0 inet dhcp
   bridge_ports eth0

Note : Si comme moi vous faites vos essais dans VirtualBox, méfiance. Si on utilise déjà un pont dans VirtualBox, xenbr0 ne fonctionnera pas correctement (les domU peuvent pinger dom0 mais pas internet). J'ai pas mal bloqué sur ce problème et finalement la solution consiste à laisser VirtualBox en NAT.

Installation des Xen Tools

Xen-tools permet de créer facilement des domU à partir de templates, et c'est la solution la plus simple :

# apt-get install xen-tools

Configuration du template Xen Tools

On édite le fichier /etc/xen-tools/xen-tools.conf. Voici les lignes à modifier pour notre cas :

dir = /home/xen
size   = 10Gb      # Disk image size.
fs     = ext4     # use the EXT4 filesystem for the disk image.
bridge = xenbr0
ext4_options     = noatime,nodiratime,errors=remount-ro

Et voilà.

Déploiement d'un DomU Debian

Note : Il faut prendre soin de rebooter après les manipulations précédentes, afin d'avoir Xen et le Dom0 opérationnels avant d'aller plus loin.

Voici la commande pour créer un hôte de type Debian Wheezy qui sera nommé Wheezy :

# xen-create-image --hostname wheezy --dhcp --vcpus 1 --pygrub --dist wheezy

WARNING
-------

  You appear to have a missing vif-script, or network-script, in the
 Xen configuration file /etc/xen/xend-config.sxp.

  Please fix this and restart Xend, or your guests will not be able
 to use any networking!


General Information
--------------------
Hostname       :  wheezy
Distribution   :  wheezy
Mirror         :  http://ftp.fr.debian.org/debian/
Partitions     :  swap            128Mb (swap)
                  /               10Gb  (ext4)
Image type     :  full
Memory size    :  128Mb
Kernel path    :  /boot/vmlinuz-3.2.0-4-amd64
Initrd path    :  /boot/initrd.img-3.2.0-4-amd64

Networking Information
----------------------
IP Address     : DHCP [MAC: 00:16:3E:EB:96:45]


Creating swap on /dev/vg0/wheezy-swap
Done

Creating ext4 filesystem on /dev/vg0/wheezy-disk
Done
Installation method: debootstrap
Done

Running hooks
Done

No role scripts were specified.  Skipping

Creating Xen configuration file
Done

No role scripts were specified.  Skipping
Setting up root password
Generating a password for the new guest.
All done


Logfile produced at:
	 /var/log/xen-tools/wheezy.log

Installation Summary
---------------------
Hostname        :  wheezy
Distribution    :  wheezy
IP-Address(es)  :  dynamic
RSA Fingerprint :  83:21:28:49:d9:93:38:ae:5a:11:41:23:fa:3a:6e:05
Root Password   :  UzNRAZe4

Pour démarrer notre DomU :

# xm create wheezy.cfg 
Using config file "/etc/xen/wheezy.cfg".
Started domain wheezy (id=2)

Pour se connecter à ce DomU, deux possibilités : avec SSH si on connaît l'IP, ou avec la commande xm console :

# xm console wheezy

Pour en sortir, arrêter la VM, ou utiliser la combinaison CTRL+]

Pour arrêter le DomU depuis le Dom0, utiliser la commande xen-delete-image :

# xm destroy wheezy

Note : la commande xm destroy va provoquer l'arrêt brutal du domU.

Déploiement d'un DomU NetBSD

Bon un DomU en Debian c'était facile parce qu'on peut utiliser xen-tools qui automatise tout. Maintenant la même chose avec NetBSD, qu'il va falloir installer à la main. Tout d'abord, on télécharge et on extrait la version installable et la version normale de NetBSD version Xen :

# wget ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.1.3/amd64/binary/kernel/netbsd-INSTALL_XEN3_DOMU.gz
# wget ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.1.3/amd64/binary/kernel/netbsd-XEN3_DOMU.gz
# gunzip netbsd-INSTALL_XEN3_DOMU.gz
# gunzip netbsd-XEN3_DOMU.gz

Ensuite on doit créer un fichier une image qui servira de support de stockage pour le DomU :

# mkdir -p /home/xen/domains/netbsd
# dd if=/dev/zero of=/home/xen/domains/netbsd/disk.img bs=1 count=0 seek=10G

Création d'un fichier de configuration pour notre domU NetBSD (il est possible de copier celui du domU Wheezy précédemment créé pour aller plus vite puis le modifier) :

# vi /etc/xen/netbsd.cfg
kernel = "/root/netbsd-INSTALL_XEN3_DOMU"
memory = '128'
disk = [
'file:/home/xen/domains/netbsd/disk.img,xvda1,w';
]
name = 'netbsd'
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:EB:96:41,bridge=xenbr0' ]

On démarre notre domU NetBSD créé (cette fois l'argument c va directement connecter la console) :

# xm create -c netbsd.cfg

On obtient ceci :

Il faut maintenant procéder à une installation personnalisée, en sélectionnant uniquement base et system (pas besoin du kernel qui ne sera pas utilisé car GENERIC) et une source HTTP ou FTP (l'équivalent du netinstall) pour récupérer les paquets.

Si tout se passe bien :

Une fois l'installation terminée, il faut modifier le netbsd.cfg pour utiliser l'autre kernel :

# vi /etc/xen/netbsd.cfg
kernel = "/root/netbsd-XEN3_DOMU"

Il est maintenant possible de booter sur NetBSD :

# xm create -c netbsd.cfg

Conclusion

Xen est relativement simple à utiliser sur Debian Wheezy, grâce à Xen-tools qui facilite la création de domU à partir d'un template. Quand il s'agit de créer un domU "exotique" comme NetBSD, la procédure est un peu plus longue mais reste simple et logique. Il se positionne donc comme une solution intéressante pour les serveurs n'ayant pas le support de la virtualisation complète (Intel VT-X / AMD-V). Néanmoins lorsque ces instructions sont disponibles, les solutions alternatives telles que KVM ou ses concurrents propriétaires (Hyper-V, VMware...) me semblent toujours beaucoup plus simples à administrer et offrent des performances excellentes. Y a-t-il toujours un avenir à la paravirtualisation, qui est à mi chemin entre les containers (LXC, jails...) et la virtualisation complète ? A voir...

Mon bilan est positif sur l'utilisation, mais je me questionne toujours sur la pertinence de Xen en 2014.

Ressources

• How to install a NetBSD domU on a Linux host
• Xen on Debian - Wiki

Un P2V (Physical to Virtual) est une opération qui consiste à transférer le système d'exploitation d'un ordinateur physique vers une machine virtuelle. C'est très pratique lorsque le hardware est défaillant ou sous-dimensionné et que vous souhaitez redonner un peu de patate à un serveur ou un poste de travail. Dans mon cas il s'agit d'un poste sous Windows XP que je souhaite virtualiser afin de l'utiliser sur une autre machine plus récente équipée de Windows 7. Voici la procédure.

Etape 1 : Génération du fichier VHD

Téléchargez l'utilitaire Disk2vhd sur la machine cible et exécutez-le en administrateur. Pensez à stopper l'antivirus et tous les services pouvant ralentir l'opération. Sélectionnez votre disque C:\ puis décochez la case "Use VhdX" (VirtualBox supporte mal) et sélectionnez l'emplacement du fichier cible (qui peut très bien être en local).

Exécutez l'opération, et patientez. Pour information, 40GB de vhd prennent à peu près 1 heure. Lorsque le fichier est complète généré, transferez-le sur votre machine qui va exécuter VirtualBox. Privilégiez un réseau 1000Mbps sinon cela risque d'être long (quasiment 1h20 pour mon fichier vhd de 40GB!).

Etape 2 : Création de la VM

Sur la machine qui exécute VirtualBox cliquez sur le bouton pour créer une nouvelle VM. Donnez-lui un nom, sélectionnez le type d'OS adapté dans la liste, allouez de la RAM (2GB pour XP 32 bits est suffisant) et sélectionnez "Utiliser un fichier de disque dur virtuel existant" et allez chercher votre fichier vhd. Pour finir, cliquez sur "créer".

Etape 3 : Configuration

Pour ma machine virtuelle en Windows XP j'ai du activer IO-APIC et PAE/NX. Pour cela sélectionnez votre VM puis cliquez sur "Configuration". IOi-APIC se situe dans la catégorie "Système" puis onglet "Carte mère". PAE/NX se situe dans l'onglet "Processeur".

Exécuter la VM

Plus qu'à cliquer sur le bouton "Démarrer" ! Attention si votre Windows XP était enregistré sur un domaine, pensez à le renommer pour éviter les conflits sur l'A.D.