9 mai 2017

Xen : installation d'un invité domU NetBSD

the handlerDans le billet précédent, j'ai abordé la création d'un hyperviseur Xen (dom0) NetBSD. Il est donc temps de s'occuper du système invité NetBSD, le domU.

Création du domU Xen

Pour créer notre domU, nous avons besoin de 3 éléments présents sur le dom0 :

  • un fichier de disque dur (on pourrait utiliser LVM ou une partition, mais cela est moins flexible) ;
  • dans le cas de NetBSD, un fichier de noyau ;
  • et un fichier de configuration.

D'abord, le fichier de disque dur. Pour le créer, il suffit d'utiliser la commande dd. La taille de ce fichier déterminera la taille du disque dur de la machine virtuelle. Créons un fichier de 4 Go (4096 blocs d'1 Mo) :

root@rogue:~# dd if=/dev/zero of=/srv/xen/images/disk/netbsd.img bs=1m count=4096

On peut remarquer que cet exemple remplit notre fichier de zéros, et ne crée pas de fichier sparse. Il semble que la gestion des fichiers sparse ne soit pas parfaite sous NetBSD, d'après le tutoriel officiel.

Ensuite, récupérons les fichiers noyau :

root@rogue:~# mkdir -p /srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64/
root@rogue:~# cd /srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64/
root@rogue:/srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64 # ftp http://cdn.netbsd.org/pub/NetBSD/NetBSD-7.1/amd64/binary/kernel/netbsd-INSTALL_XEN3_DOMU.gz
root@rogue:/srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64 # ftp http://cdn.netbsd.org/pub/NetBSD/NetBSD-7.1/amd64/binary/kernel/netbsd-XEN3_DOMU.gz

On récupère deux fichiers de noyau, car l'un d'entre eux ne sert que pour l'installation. Une fois celle-ci terminée, il faut penser à configurer notre domU avec le noyau "classique".

Nous pouvons enfin créer notre fichier de configuration, /usr/pkg/etc/xen/netbsd :

root@rogue:/usr/pkg/etc/xen# grep -v ^# netbsd | grep -v ^$
name = "netbsd"
uuid = "d0f3e8d3-2f54-11e7-b035-00301bbde894"
kernel = "/srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64/netbsd-INSTALL_XEN3_DOMU.gz"
memory = 256
vcpus = 1
vif = [ 'bridge=bridge0,mac=00:16:3E:00:00:02' ]
disk = [ '/srv/xen/images/disk/netbsd.img,raw,xvda,rw' ]

Les directives du fichier de configuration sont assez explicites, néanmoins il convient de préciser certaines choses :

  • d'abord, le nom de la machine virtuelle ("name") doit être unique ;
  • et en passant, l'uuid aussi (généré via uuidgen), mais il n'est pas obligatoire, la directive peut être vide ;
  • la mémoire est spécifiée en méga-octets ;
  • on peut spécifier plusieurs interfaces réseau ou disques durs.

On peut ajouter bien d'autres options, mais il est préférable de commencer par un fichier simple, qui démarrera une machine en mode texte, avant d'aller plus loin.

Maintenant que notre fichier de configuration est prêt, démarrons notre domU :

root@rogue:/usr/pkg/etc/xen# xl create -c netbsd

L'option -c permet d'attacher la console locale de la machine virtuelle en mode texte, et donc de pouvoir interagir avec (pour, par exemple, effectuer une installation).

Installation de NetBSD dans le domU

L'installation se passe de manière similaire à ce qui est présenté dans le guide officiel, mais à une différence près : une fois l'installation terminée, il faut quitter l'installeur (au lieu de redémarrer), puis éteindre la machine virtuelle :

# shutdown -p now

De retour dans le dom0, il faut alors changer le fichier de noyau pour un démarrage "classique" :

root@rogue:/usr/pkg/etc/xen# vi netbsd
kernel = "/srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64/netbsd-XEN3_DOMU.gz"

On peut ensuite démarrer notre machine virtuelle, dans l'exemple suivant sans attacher la console locale de celle-ci :

root@rogue:/usr/pkg/etc/xen# xl create netbsd

On est vraiment obligé de spécifier sur le noyau ?

Dans le domU d'exemple du billet précédent, le système OpenWrt était démarré grâce à pygrub, un chargeur de démarrage pour Xen. Celui-ci n'est hélas pas capable de lire le système de fichiers FFS utilisé par NetBSD. Cela n'est pas non plus possible pour pv-grub, qui n'est de toute façon pas disponible dans les paquets Xen pkgsrc.

Quelles sont alors les possibilités ? La première consiste à créer une partition /boot en ext2/3/4 au début du disque virtuel, et d'y placer noyau et configuration Grub, comme l'indique ce tutoriel. Une autre consiste à compiler soi-même une version de Grub2, qui semble maintenant gérer Xen, tout du moins d'après ce billet du blog officiel Xen, daté de janvier 2015.

Autres actions possibles

Démarrer sa machine virtuelle, c'est bien, pouvoir effectuer d'autres actions et vérifications, c'est mieux ! Voici donc, en vrac, quelques commandes utiles pour gérer ses domU :

  • xl shutdown <chemin vers le fichier de configuration> permet d'arrêter proprement celui-ci ;
  • besoin d'appuyer sur le bouton Off comme un gros barbare ? xl destroy <nomdudomU> ;
  • lister les domU en fonctionnement : xl list ;
  • et pour avoir cette liste en temps réel, présentée à la manière d'un top, on peut utiliser xl top.

D'autres commandes et paramètres sont disponibles dans la page de manuel de la commande xl.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : ColonelMustard - the handler''

2 mai 2017

Xen : installation d'un hyperviseur dom0 NetBSD

ArmyJ'ai écrit dans le passé quelques billets concernant Xen, mais jamais sur l'installation à proprement parler d'un hyperviseur Xen à base de NetBSD. Il est temps de réparer cela ! Mais avant de commencer, quelques rappels :

  • en terminologie Xen, chaque système invité se nomme un "domaine" ;
  • une machine virtuelle est un domaines non-privilégié, en anglais "unprivileged domain", généralement raccourci en "domU" ;
  • l'OS qui fait fonctionner l'hyperviseur est un domaine privilégié, en anglais "privileged domain", ce qui donne en raccourci "dom0".

Il s'agit donc de détailler l'installation et la configuration de Xen en tant que dom0 sur un système NetBSD amd64. Pour valider son bon fonctionnement, une installation rapide d'un domU OpenWrt sera effectuée à la fin.

Mais avant de démarrer, voici quelques informations sur la configuration qui sera effectuée :

  • comme la machine physique ne dispose pas des instructions de virtualisation (Intel Atom 330), seul le mode "paravirtuel" sera abordé ;
  • la machine physique se verra attribuer 256 Mo de RAM sur ses 2 Go pour son fonctionnement ;
  • la configuration réseau sera en mode "bridge", le dom0 et les domU seront donc sur le même réseau.

Allons-y !

Installation et configuration de NetBSD

Commençons par l'installation du système d'exploitation : NetBSD 7.1 amd64. Il n'y a rien en particulier à signaler sur l'installation, cela dépend avant tout de son usage. Cette machine n'étant pas destinée à devenir un environnement de production, j'ai choisi un partitionnement minimal, à savoir juste un / qui prend tout le disque.

A noter aussi qu'à ce moment, il n'y a besoin de rien en particulier concernant le noyau. J'ai pris l'habitude de ne pas installer les sets de compilation ou source sur une machine sauf si j'en ai expressément besoin. Donc, je me suis limité aux sets suivants :

  • base ;
  • etc ;
  • man ;
  • misc ;
  • modules ;
  • tests ;
  • text ;
  • xbase.

Côté réseau, il sera sans doute plus simple de configurer une adresse IP statique. On va aussi dès maintenant configurer le bridge :

root@rogue:~# cat > /etc/ifconfig.bridge0 
create
!brconfig $int add re0 up

A noter que l'interface de la machine physique est re0, il convient de la modifier selon celle disponible. On va aussi autoriser la retransmission de paquets réseau :

root@rogue:~# cat >> /etc/sysctl.conf
net.inet.ip.forwarding=1

Ces modifications seront prises en compte au prochain démarrage du système, qu'il convient de faire dès maintenant.

Pour les paquets logiciels, j'ai choisi d'utiliser mon propre dépôt pkgsrc de paquets binaires. Là aussi, rien d'exceptionnel, j'ai juste installé mon petit confort personnel. Il est néanmoins possible d'utiliser le dépôt binaire pkgsrc officiel (configuré lors de l'installation) ou d'utiliser pkgsrc depuis les sources.

Installation et configuration de Xen 4.6

Maintenant que notre système est installé et prêt, passons à l'installation de Xen. Rien de compliqué non plus à ce niveau, il suffit d'utiliser pkgin :

root@rogue:~# pkgin in xenkernel46 xentools46

Des messages seront affichés durant l'installation des différents paquets, montrant un certain nombre de messages de conseils et de recommandations.

Pour que Xen fonctionne, il faut d'abord démarrer un noyau spécialisé qui chargera de lancer l'hyperviseur. Le noyau NetBSD dom0 est disponible à côté du noyau générique sur les dépôts :

root@rogue:~# wget http://cdn.netbsd.org/pub/NetBSD/NetBSD-7.1/amd64/binary/kernel/netbsd-XEN3_DOM0.gz
root@rogue:~# mv netbsd-XEN3_DOM0.gz /

Configurons maintenant le chargeur de démarrage. Il suffit d'insérer la ligne suivante au début du fichier /boot.cfg :

menu=Xen:load /netbsd-XEN3_DOM0.gz console=pc;multiboot /usr/pkg/xen46-kernel/xen.gz dom0_mem=256M

Parmi les détails de cette ligne de configuration, on remarquera l'allocation de 256 Mo de mémoire vive pour le dom0.

Par contre, si jamais le partitionnement prévoit un /usr séparé, il vaudra mieux copier /usr/pkg/xen46-kernel/xen.gz dans / et de remplacer les chemins en accord avec la nouvelle localisation du fichier. Une fois que le chargeur de démarrage est modifié, un redémarrage est nécessaire, mais juste avant on peut créer les fichiers spéciaux dans /dev :

root@rogue~# cd /dev && sh MAKEDEV xen

Maintenant on peut redémarrer :)

Mais tout n'est pas encore prêt. Par exemple, le service xencommons doit être activé et démarré. On ajoute alors la ligne suivante au fichier /etc/rc.conf :

xencommons=YES

On peut ensuite lancer le service :

root@rogue~# service xencommons start

Il y a encore un fichier de configuration à modifier avant de commencer à faire joujou avec nos machines (para-)virtuelles : /usr/pkg/etc/xl.conf. Je n'ai fait que deux modifications à ce fichier :

root@rogue:~# grep -v ^# /usr/pkg/etc/xen/xl.conf | grep -v ^$
vif.default.script="vif-bridge"
vif.default.bridge="bridge0"

Il est temps d'effectuer rapidement un test de domU !

Test d'un domU OpenWrt

Un moyen de tester rapidement le fonctionnement de son dom0 Xen est d'utiliser un domU OpenWrt : il s'agit en effet d'un OS léger, non seulement d'un point de vue processeur et mémoire, mais aussi d'un point de vue espace disque. Au moment de la rédaction de cet article, la dernière version stable d'OpenWrt est la 15.05.1 et porte le nom de Chaos Calmer.

Deux éléments sont nécessaires : un fichier qui sera le disque dur de la machine virtuelle, et un fichier de configuration. Dans le premier cas c'est très simple, il suffit d'aller le récupérer sur le site d'OpenWrt, de le placer dans un répertoire, et de le décompresser :

root@rogue:~# mkdir -p /srv/xen/images/disk
root@rogue:~# cd /srv/xen/images/disk
root@rogue:/srv/xen/images/disk# wget https://downloads.openwrt.org/latest/x86/xen_domu/openwrt-15.05.1-x86-xen_domu-combined-ext4.img.gzroot@rogue:/srv/xen/images/disk# zcat openwrt-15.05.1-x86-xen_domu-combined-ext4.img.gz > openwrt.img

Continuons avec le fichier de configuration, basé sur un fichier d'exemple. Il doit se trouver dans /usr/pkg/etc/xen/, et se nomme tout simplement openwrt :

name = "openwrt"
uuid = "26824417-2dde-11e7-a2aa-00301bbde894"
bootloader = "/usr/pkg/bin/pygrub"
extra = "root=/dev/xvda2 rw"
memory = 128
vcpus = 1
vif = [ 'bridge=bridge0,mac=00:16:3E:00:00:01' ]
disk = [ '/srv/xen/images/disk/openwrt.img,raw,xvda,rw' ]

Maintenant que tout cela est en place, il ne reste plus qu'à lancer la machine virtuelle :

root@rogue:~# xl create -c /usr/pkg/etc/xen/openwrt

Une fois OpenWrt démarré, il suffit alors d'appuyer sur la touche entrée pour activer la console locale. Côté tests, il faut vérifier le nombre de processeurs (dans /proc/cpuinfo, il doit n'y en avoir qu'un), ainsi que la quantité de mémoire vive (dans /proc/meminfo, ou via free -m, on doit avoir 128 Mo). Si un serveur DHCP est présent, on peut facilement tester le réseau via udhcpc :

root@OpenWrt:/# udhcpc -i br-lan

On peut désormais vérifier que le réseau est bien connecté.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : Marcos Leal - Army

30 juin 2011

Utilisation de nombreux domU en backend fichiers sur un dom0 NetBSD

Oui, j'utilise des machines virtuelles Xen dans des fichiers. Pas de partition, pas de LVM, non. Un bon vieux fichier qu'on peut effacer sans regrets une fois son domU "jetable" inutile. Pour utiliser ces fichiers, et pour monter des fichiers en tant que disque de manière générale, NetBSD utilise le pilote vnd (4). Et par défaut, il y a 4 fichiers spéciaux vnd. Et lorsqu'on désire lancer 42 machines virtuelles en même temps, chacune ayant besoin d'un fichier vnd pour monter son disque dur, on obient une erreur du genre :

Error: Device 51712 (vbd) could not be connected. Hotplug scripts not working.

Alors on s'affole, on copie-colle le message dans un moteur de recherche bien connu, et on tombe sur ce genre de chose :

How much /dev/vnd*d device do you have ? Maube you need to create more ? e.g.: cd /dev ./MAKEDEV vnd4 vnd5 vnd6 vnd7 vnd8

Donc on applique :

root@arreat:/usr/pkg/etc/xen# cd /dev
root@arreat:/dev# ./MAKEDEV vnd4 vnd5 vnd6 vnd7 vnd8 vnd9 vnd10 vnd11 vnd12 vnd14 vnd15
root@arreat:/dev# cd /usr/pkg/etc/xen
root@arreat:/usr/pkg/etc/xen# xm create vmjetable1 && xm create vmkikoo2 \
&& xm create vmpipeau3 && xm create vmdelire4 && xm create encoreunevmjetable

Maintenant, c'est la RAM qui va commencer à manquer... mais c'est un autre problème ;-)

20 juin 2011

Installation d'un domU Xen Enterprise Linux sur un dom0 NetBSD

Ces derniers temps je m'amuse à faire des installations par le réseau d'un peu tout et n'importe quoi. J'utilise principalement l'outil de virtualisation Oracle VirtualBox, mais il m'arrive aussi de faire joujou avec Xen. Avec un hôte (dom0) CentOS 5 (et sans doute toutes les distribution de type "Enterprise Linux" telles que Red Hat Enterprise Linux ou Scientific Linux), il est très facile de créer d'autres machines virtuelles (domU) Xen de même type grâce à la commande "virt-install". Avec un dom0 NetBSD cependant, point de commande de ce type. Voyons donc comment faire.

Sur un système Enterprise Linux 5, il est possible de trouver une image de noyau d'installation (et l'initrd approprié) spécifique à Xen, comme par exemple sur ce miroir pour CentOS 5 64 bits.

Ce qui me paraît étrange, c'est avec Enterprise Linux 6, tout du moins avec Scientific Linux. Le noyau 2.6.32 dispose à priori des pv-ops, mais SL6 dispose d'un noyau et d'un initrd Xen. Peut-être est-ce par soucis de compatibilité de chemins, car les fichiers font la même taille que dans le répertoire pxeboot. D'ailleurs, lors de ma synchronisation rsync avec le miroir officiel Scientific Linux, le répertoire xen n'apparaît pas. Et je n'en ai pas eu besoin :)

Une fois nos images de noyau et d'initrd en main, il nous reste à créer notre fichier de configuration de domU, mon exemple prend comme exemple de disque dur un fichier et une connexion réseau par bridge :

name = "centosexample"
uuid = ""
maxmem = 512
memory = 512
kernel  = "/srv/www/pub/CentOS/5/os/x86_64/images/xen/vmlinuz"
ramdisk = "/srv/www/pub/CentOS/5/os/x86_64/images/xen/initrd.img"
extra = "vnc"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [  ]
disk = [ "file:/srv/xen/images/disk/centosexample.img,xvda,w" ]
vif = [ "mac=00:16:3a:e2:12:34,bridge=bridge0" ]

Il est possible de faire l'installation en mode texte en supprimant la ligne "extra", et d'ajouter l'url d'un fichier kickstart dans la directive extra, qui devient donc :

extra = "text ks=http://monserveur/pub/cfg/centos5_x86_64.cfg"

La commande "xm create -c centosexample" vous permet de lancer votre domU et de débuter l'installation. Une fois celle-ci faite et votre domU de nouveau éteint, il suffit de commenter les lignes "kernel" et "ramdisk" et de décommenter la ligne "bootloader". Vous pouvez alors démarrer votre domU sans que le noyau de celui-ci soit sur le disque dur du dom0 :)

Lors de mes tests, je me suis limité au partitionnement par défaut (qui utilise LVM), à un détail près : avec Scientific Linux 6, j'ai imposé ext3 à l'installeur. Une fois l'installation terminée, éteindre son domU (proprement de préférence) et modifier la configuration qui devient :

name = "centosexample"
uuid = ""
maxmem = 512
memory = 512
bootloader = "/usr/pkg/bin/pygrub"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [  ]
disk = [ "file:/srv/xen/images/disk/centosexample.img,xvda,w" ]
vif = [ "mac=00:16:3a:e2:12:34,bridge=bridge0" ]

J'ai donc remplacé le noyau et l'initrd d'installation par pygrub, qui me permet de démarrer mon domU sur le noyau et l'initrd installés. De plus, les mises à jour ne nécessitent pas de copier de nouveau le noyau et l'initrd sur le dom0.

Pour finir, si vous souhaitez installer un dom0 NetBSD, je ne peux que vous recommander l'excellent billet de Bsdsx !

Propulsé par Dotclear