NetBSD est un bon point de départ pour commencer avec Xen : Xen est directement pris en compte par les développeurs de NetBSD. Les dernières versions de NetBSD sont livrées avec des noyaux compatibles avec Xen, à la fois pour la partie machine hébergeante (Domaine 0 dans le jargon Xen) et pour les machines hébergées (Domaines U pour Xen).
Ce paragraphe décrit l'installation de Xen en utilisant NetBSD comme OS du domaine 0 (il est fortement inspiré du howto officiel http://www.netbsd.org/Ports/xen/howto.html).
La mise en place de Xen commence par une installation de NetBSD "normal", sans Xen.
Pour pouvoir bénéficier des dernières
innovations
de Xen 2.0.7, il faut utiliser une
version récente de NetBSD
dans sa version -Current (la branche de développement qui
deviendra NetBSD 4.x). L'installation est
réalisée à
partir d'un snapshot :
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-daily/HEAD/200508030000Z/i386
L'installation est réalisée en démarrant sur une disquette et en téléchargeant les binaires depuis Internet (via FTP).
L'installation de NetBSD est basique : tous les composants sont sélectionnés, sauf X-Windows et les sources (l'espace nécessaire pour cette configuration est inférieur à 300Mo).
Tout le disque maître (wd0/hda) est
dédié
à NetBSD :
Une seule partition primaire "hda4" de 6Go est divisée en :
L'outil utilisé dans NetBSD pour partitionner le disque est "disklabel" (XXX : dans "disklabel", les partitions wd0g à wd0j ont un type 4.2BSD, qui devrait être réservé aux "vraies" partitions wd0a et wd0e, utilisées par NetBSD pour stocker les fichiers du domaine 0).
Une seule partition wd0a de 400Mo est utilisée pour NetBSD. Une deuxième partition wd0b de 128Mo est utilisée pour le swap. Deux partitions supplémentaires sont réservées (wd0e 1,5Go et wd0f 400Mo) par exemple pour stocker des images disques utilisées pour les machines virtuelles DomU. Le reste du disque est découpé en quatre partitions de 900Mo, destinées à devenir des disques virtuels de domaines Xen (avec un disque plus grand, il serait possible de monter à 16 partitions pour wd0, dont 10 pour des domaines U).
Synthèse du partitionnement
Les paramètres de configuration de NetBSD dans le dom0 :
dans /etc/rc.conf :
hostname=netbsd-dom0.mydomain
defaultroute="192.168.1.1"
wscons=YES
sshd=YES
newsyslog=YES
dans /etc/resolv.conf (configuration du service DNS) :
search mydomain
nameserver 192.168.1.4
dans /etc/ifconfig.ne0 :
up
192.168.1.3 netmask
0xffffff00 media autoselect
On vérifie que l'installation est correcte en se connectant sur le serveur dom0 via ssh depuis une autre machine du réseau.
Pour utiliser Xen, il faut installer, en plus de NetBSD, les packages grub (boot-manager) et xentools20.
Les applicatifs supplémentaires sont installés à partir des sources, depuis l'arbre des packages (pkgsrc).
La dernière version des pkgsrc est disponible
à l'adresse :
ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz
(désarchivage sous /usr par la commande : tar -C
/usr -xzvf
pkgsrc.tar.gz )
Comme
pour tous les autres packages représentés
dans l'aborescence pkgsrc, l'installation de grub se fait par les
commandes :
netbsd-dom0: {1} cd
/usr/pkgsrc/sysutils/grub
netbsd-dom0: {2} make
install && make
clean
La configuration de grub se fait avec les commandes
(lancées dans shell root) :
netbsd-dom0: {3} grub
--no-floppy
GNU GRUB version 0.97 (640K lower / 3072K upper
memory)
[ Minimal
BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists
the possible
completions of a device/filename. ]
grub> root
(hd0,3,a)
grub>
setup (hd0)
grub>
quit
netbsd-dom0: {4}
NB : l'option --no-floppy
interdit
à grub de tester la présence du lecteur de
disquette (puisqu'on installe le boot manager sur disque dur).
Une première version du fichier de configuration de grub est là. Sous NetBSD, le fichier de configuration de grub est stocké dans /grub/menu.lst (plus d'information sur grub sur cette page)
Vérification de l'installation et de la bonne
configuration de grub : pour redémarrer, la
commande est shutdown -r now. Le PC
redémarre et grub affiche un menu. En
sélectionnant la seule option NetBSD, le PC
démarre et NetBSD prend le contrôle.
De même, les xentools permettant de gérer
les
machines virtuelles Xen sont installées à partir
de l'arbre des pkgsrc :
netbsd-dom0: {1} cd
/usr/pkg/sysutils/xentools20
netbsd-dom0: {2} make install
&& make clean
xend est un démon écrit en Python qui
gère le
dialogue entre la machine hébergeante et les machines
hébergées. Le démarrage automatique de
xend est
autorisé par la variable xend=YES
dans /etc/rc.conf.
(il manque le script "xendomains" de la distribution Linux, qui démarre et arrête les domaines U).
Il faut copier le script /usr/pkg/share/examples/rc.d/xend dans /etc/rc.d pour que xend soit démarré et arrêté automatiquement au boot et au shutdown de la machine (les scripts installés dans le répertoire /usr/pkg/etc/rc.d ne sont pas utilisés pendant le démarrage automatique de la machine ; l'explication est dans le manuel NetBSD).
Quand les outils grub et xentools sont installés, il est possible d'installer Xen pour créer le premier domaine (dom0). Le domaine 0 gère la machine "physique" : il a accès à tous les périphériques de la machine (disques, cartes réseau, ports série, ...).
Dans le domaine 0, Xen s'exécute en parallèle au noyau de l'OS de la machine virtuelle dom0 (ici, Xen s'exécute en parallèle à NetBSD).
L'installation est simple :
Modification du fichier de configuration de grub menu.lst :
top que le swap
n'est pas utilisé)Une nouvelle version du fichier de configuration de grub est là.
Reboot vers NetBSD/Dom0 : pour redémarrer, la
commande est shutdown -r now Le PC
redémarre et affiche le menu de grub (une
deuxième option permet de choisir NetBSD/Xen0 en plus de
l'option précédente avec uniquement NetBSD).
Un exemple de menu de démarrage affiché par grub est là.
Les paramètres de configuration de NetBSD (/etc/rc.conf,
/etc/fstab,/etc/resolv.conf,/etc/sysctl.conf,
...) sont identiques
que la machine tourne sous NetBSD "natif" ou NetBSD/Dom0.
On vérifie que l'installation du nouveau kernel Xen0 est correcte en se connectant sur le serveur dom0 via ssh depuis le PC "console".
On vérifie que xend est correctement démarré avec la commande xm list :
netbsd-dom0: {1} xm list
Name
Id Mem(MB) CPU State
Time(s) Console
Domain-0
0
63 0
r---- 37.4
Avec NetBSD/Xen0, le réseau virtuel entre le Domaine 0 et les Domaines U est routé : chaque domaine U dispose de son réseau IP dédié, schématisé dans le dessin précédent par les traits pointillés entre le Domaine 0 et chaque Domaine U (plus d'explications ici, chaque dom U a un réseau /28).
Le script
/usr/pkg/etc/xen/vif-bridge
installé par
les xentools n'est pas utilisable sous NetBSD (c'est un script shell
qui utilise iptable, donc
exécutable uniquement sous Linux). Le howto
officiel donne
un autre
script, adapté à NetBSD.
Le Domaine
0 est configuré pour router les
paquets
de/vers les domaines U : net.inet.ip.forwarding=1
dans /etc/sysctl.conf sur le PC/Dom0.
Le disque dur alloué à NetBSD comporte quatre partitions réservées pour l'installation des Domaines U (voir le tableau de synthèse) : une partition NetBSD hda4 pour plusieurs partitions internes (partitionnement réalisé par disklabel).
Au vu de la capacité mémoire du PC/Xen, une allocation de 32Mo pour chacun des DomU est prévue (juste suffisant pour faire tourner un serveur Apache).
NetBSD / XenU est installé dans une des partitions de 928Mo prévues (en commençant par wd0g, vu de NetBSD/Xen0). Pour NetBSD/XenU, cette partition est vue comme un disque xbd0 complet (de 928 Mo) :
xbd0 at hypervisor0: Xen Virtual Block Device 928 MB
Searching for RAID components...
boot device: xbd0
root on xbd0a dumps on xbd0b
Ce "disque" de 928 Mo est lui-même partitionné (800 Mo pour les fichiers et 128 Mo pour le swap).
L'association entre le disque virtuel et la partition wd0g est
définie dans le fichier
de configuration de la machine virtuelle : disk = [ 'phy:/dev/wd0g,wd0d,w' ].
XXX explications des paramètres du fichier de configuration + liaison avec script "network"
L'installation proprement dite est
réalisée grace au noyau d'installation :
netbsd-INSTALL_XENU, téléchargeable par exemple :
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-daily/HEAD/200508030000Z/i386/binary/kernel/netbsd-INSTALL_XENU.gz
Le noyau netbsd-INSTALL_XENU contient un ramdisk avec sysinst (outil d'installation NetBSD) et permet de réaliser complètement une installation NetBSD/XenU depuis une source réseau (serveur FTP, HTTP ou NFS).
Quelques paramètres d'installation de NetBSD dans ce fichier (plus d'information sur la procédure d'installation directement sur le site de NetBSD).
L'installation est démarrée avec la
commande xm create -c /usr/pkg/etc/xen/dom1.netbsd
dans une
session shell exécutée dans NetBSD/Xen0
(dans le domaine 0). Le noyau d'installation de NetBSD est
démarré par cette commande en
décommentant la ligne kernel = "/home/herbelot/Xen/netbsd-INSTALL_XENU-200508030000Z-3.99.7"
du fichier de configuration dom1.netbsd.
L'option -c de la commande xm
create ouvre une console "texte" vers la machine virtuelle
qui démarre : cette console affiche les messages de
démarrage et permet de passer des commandes au programme
d'installation sysinst.
A la fin de l'installation, il faut arrêter
proprement la
machine virtuelle (commande halt dans la
console de configuration de
la machine XenU puis xm destroy dans un shell
du domaine 0).
la dernière opération pour l'installation est de changer le noyau à exécuter dans le fichier de configuration dom1.netbsd et redémarrer avec le kernel "standard" (netbsd-XENU). La machine virtuelle redémarre. Il est alors possible de terminer la configuration de la machine virtuelle en mettant au clair les derniers paramètres de la machine (démarrage sshd) :
En synthèse, les paramètres réseau pour un domaine U sont :
dans /etc/rc.conf :
hostname="dom1.mydomain"
sshd=YES
newsyslog=YES
nfs_client=YES
defaultroute="192.168.2.14"
ifconfig_xennet0="inet 192.168.2.1 netmask 255.255.255.240"
et dans /etc/resolv.conf :
domain mydomain
nameserver 192.168.1.4
fin de la configuration de dom1 :
netbsd-domU: {1} useradd -m guest
netbsd-domU: {2}
passwd guest
(le compte est alors utilisable à travers ssh)
ajout aussi dans /etc/group:wheel
(configuration de /etc/mail/aliases)
vérification de connexion par ssh depuis
réseau "normal" vers la nouvelle machine "dom1" (puis
vérification que l'utilisateur "guest" peut passer "root").
NetBSD peut aussi être installé dans un fichier "image" monté par vnconfig (intérêt : manipulation plus facile des images : sauvegarde, copie, transfert d'une machine à une autre)
L'installation commence avec le montage manuel de l'image
disque dans dom0 :
vnconfig vnd0 /usr/src/xen-images/dom1-image
D'où le changement dans le fichier de config Xen (nouvelle version):
disk=['phy:/dev/vnd0d,wd0d,w']
La suite de l'installation est identique au cas où
le DomU est installé dans une partition "réelle" :
voir le paragraphe Installation
dans une partition dédiée.
A voir : les performances d'une machine virtuelle installée dans une image disque sont-elles identiques à celles d'une machine virtuelle installée dans sa propre partition wd0g ?
XXX powerd ?
Il faut une version -Current de NetBSD dans le domaine 0 pour utiliser la dernière version Xen 2.0.7, mais les domaines U peuvent utiliser une version moins "expérimentale" : la branche 3 en cours de finalisation.
La procédure d'installation du domaine U est
identique à celle utilisée pour un domaine U en
version -Current : seul le répertoire
d'installation change - par exemple :
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-daily/netbsd-3/200508120000Z/i386/binary/kernel
Le fichier de configuration est similaire à celui utilisé pour un domaine U en -Current. Les modifications concernent le noyau à utiliser et la partition d'installation (parmi 4 partitions de 1Go préparées pour des installations de NetBSD : wd0g à wd0j).
L'installation est aussi possible dans une image disque (en
pré-montant l'image disque avec vnconfig).
La branche de développement NetBSD 2 a été la première à avoir un support Xen (DomU). toutefois, la version de Xen visée était Xen 1.x, et NetBSD 2 n'a pas été mis à jour pour être compatible avec Xen 2.x. Il n'est donc pas possible d'utiliser NetBSD 2 dans un domaine U ("Xen2 DomU support isn't in the official NetBSD 2.0.x sources.").
L'installation d'un domaine U Linux sous NetBSD/Xen0 est l'illustration de l'intérêt de Xen pour consolider sur une seule machine des environnements divers BSD, Linux, bientôt Solaris, ...).
Un point favorable dans la cohabitation NetBSD/Linux est la possibilité de monter les partitions Ext2/Ext3 d'une installation Linux depuis NetBSD et de pouvoir lire et écrire dans ces partitions depuis NetBSD (par comparaison, le montage de partitions UFS depuis Linux reste hasardeux).
NB : Attention pour voir les partitions étendues
sous NetBSD (passage par mbrlabel pour
connaître la désignation "NetBSD" des partitions
hdb5 à hdb11 = wd1l à wd1o).
Ceci étant, il n'existe pas avec Linux/XenU d'équivalent au noyau d'installation netbsd-INSTAL-XENU : il n'est pas possible d'installer un DomU Linux à partir d'une seule machine NetBSD.
J'ai donc installé en dual-boot sur la même machine une partition Linux "natif", pour constituer la base des installations des DomU Linux (en fait, n'importe quelle machine Linux suffit - un dual-boot permet d'économiser un PC). L'installation de Linux/Debian est décrite au paragraphe suivant.
La première étape est de préparer complètement depuis Linux/Dom0 des machines virtuelles dans des partitions logiques (partition, formattage, installation), puis de rebooter vers NetBSD/Dom0 et de lancer ces machines virtuelles depuis NetBSD/Dom0.
Sous Linux, j'ai préparé 3 partitions logiques dans hdb pour booter trois domU Debian : hdb7, hdb9 et hdb11 (avec 3 partitions de swap hdb6, hdb8 et hdb10 - hdb5 est réservée pour installation "native" de Linux, hdb6 est utilisée à la fois comme swap quand Linux/Dom0 est booté de hdb5 et comme swap de la machine virtuelle DomU stockée dans hdb7, quand elle est démarrée depuis NetBSD/Dom0).
Les trois domaines U sont ensuite installés et configurés sous Debian/Xen0 (voir le paragraphe suivant).
Cette méthode permet d'évacuer le problème du bootstrap des machines virtuelles DomU sous Linux : comment charger les binaires ?
La première tentative est un échec. En
rebootant sous NetBSD/Xen0, la commande xm create dom5.debian
donne un message d'erreur :
attempt to access beyond end of device
sda1: rw=0, want=3572498436, limit=3951927
Buffer I/O error on device sda1, logical block 893124608
xbd backend: attach device wd1l (size 3951927) for domain 1
xbd backend: attach device wd1j (size 385497) for domain 1
xbd backend 0 for domain 1 using event channel 14
xvif1.0 using event channel 15
xbd backend: detach device wd1l for domain 1
xbd backend: detach device wd1j for domain 1
Une recherche rapide sur Internet montre que le problème est connu (voir par exemple ce message) et qu'un contournement est de formatter la partition depuis NetBSD au lieu de Linux.
La deuxième tentative est hybride :
Le formattage est réalisé avec le
package sysutils/e2fsprogs :
netbsd-dom0: {1} mkfs.ext3
/dev/wd1l
mke2fs 1.32 (09-Nov-2002)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
247296 inodes, 493991 blocks
24699 blocks (5.00%) reserved for the super user
First data block=0
16 block groups
32768 blocks per group, 32768 fragments per group
15456 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked
every 25 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to
override.
(reboot sous Debian/Dom0)
installation/configuration
des DomU sous Debian/Dom0 :
remplissage des partitions : debootstrap
puis
base-config dans le premier
démarrage du domU
(reboot vers NetBSD/Dom0)
Le fichier de configuration utilisé est dom5.debian.
La partition formattée par NetBSD démarre correctement en tant que DomU de NetBSD. Comme la configuration réseau de NetBSD/Dom0 est routée et que celle de Debian/Dom0 est bridgée, des ajustements dans les paramètres réseau sont nécessaires.
NB : je suis tombé sur un problème
de formattage entre NetBSD et Debian : les partitions n'ont
pas
la même taille. Vue de Debian, la partition a cette
géométrie :
/dev/hdb8: The filesystem size (according to the superblock) is 493991 blocks
The physical size of the device is 493990 blocks
Either the superblock or the partition table is likely to be corrupt!
Le contournement est de modifier la taille de la partition hdb8 sous Debian (diminuer la taille d'un bloc) et de la reformatter sous NetBSD.
Le basculement de NetBSD/Dom0 à Debian/Dom0 pour l'installation des DomU/Linux est fastidieux.
Une méthode plus efficace est de mieux utiliser le
programme debootstrap, utilisé par
Debian pour remplir une partition Linux avec les programmes minimaux
qui permettent d'installer et de configurer une machine Debian.
debootstrap n'est pas
porté sous NetBSD comme sysutils/e2fsprogs, il
faut donc rebooter une dernière fois vers Debian/Dom0.
Sous Debian/Dom0, debootstrap est
utilisé pour créer une arborescence
"de référence" :
debian-dom0: {1} cd ~herbelot/Xen
debian-dom0: {2} apt-get install debootstrap
debian-dom0: {3} mkdir bootstrap.tree
debian-dom0: {4} debootstrap --arch i386 sarge bootstrap.tree/ http://ftp.fr.debian.org/debian
Le répertoire (sous Debian/Linux) ~herbelot/Xen/bootstrap.tree
contient alors une arborescence d'installation de Debian/Linux
: cette arborescence va être utilisée
pour installer Linux/Debian depuis NetBSD
avec un noyau Linux/XenU.
Après redémarrage vers NetBSD / Domaine
0 : montage des partitions Debian/Linux /dev/hdb5 (qui contient
l'arborescence bootstrap.tree) et /dev/hdb7
(qui va accueillir l'installation dom5.debian).
installation de Linux/DomU dans une partition logique (hdb7) pour permettre montage ext2fs depuis NetBSD et recopie dans cette partition de l'arborescence de bootstrap :
netbsd-dom0: {1} mkdir /hdb5
netbsd-dom0: {2} mkdir -p /usr/xen-parts/hdb7
netbsd-dom0: {3} mount_ext2fs /dev/wd1i /hdb5
netbsd-dom0: {4} mkfs.ext3 /dev/wd1k
netbsd-dom0: {5} mount_ext2fs /dev/wd1k /usr/xen-parts/hdb7
netbsd-dom0: {6} cp -rp /hdb5/home/herbelot/Xen/bootstrap.tree /usr/xen-parts/hdb7
(modifier les fichiers de configuration : /etc/fstab
/etc/hosts /etc/network/interfaces)
netbsd-dom0: {16} umount /usr/xen-parts/hdb7
netbsd-dom0: {17} xm create -c dom5.debian
(ouverture d'un shell single-user exécuté dans le
nouveau domaine U avec un Linux debian minimal)
lancement de la fin de la configuration de la machine
virtuelle avec la commande base-config :
debian-dom5# base-config
(répondre aux questions)
(à la fin de l'installation, redémarrer la
machine virtuelle avec init 6)
L'installation s'est déroulée correctement : le domaine U sous Debian/Linux est complètement opérationnel. Il n'est donc plus nécessaire de rebooter sous Debian/Linux/Dom0 pour créer un domaine U Linux "neuf" (le fichier de configuration est identique à celui utilisé au paragraphe précédent : dom5.debian)
A voir aussi une installation en Ext3 dans une partition "disklabel" wd0g.
explications sur les paramètres du fichier de configuration
Cette méthode d'installation fonctionne aussi avec
une image disque montée par vnconfig.
NB : comme pour les ext2fs, si debootstrap était porté vers NetBSD, celà permettrait de s'affranchir complètement de la présence d'une installation native de Debian/Linux (on reviendrait à une situation similaire au kernel netbsd-INSTALL-XENU).
Voir aussi l'annexe Installing Debian GNU/Linux from a Unix/Linux System du manuel d'installation de Debian/Linux.
Au vu des difficultés dans l'utilisation de
partitions "physiques" (limitations à quatre partitions
primaires dues au BIOS, correspondance "bizarre" entre les noms de
partitions selon les OS, ...) une simplification vient de l'utilisation
d'images disque au lieu de vraies partitions (cf. vnconfig
sous BSD, montage -o loop sous Linux).
Le premier essai est réalisé en copiant une image disque préparée initialement sous Debian/Dom0. Ce premier essai est un échec :
Un deuxième esai est concluant, en utilisant la méthode avec arborescence de référence présentée plus haut (avec un kernel récent = 200508030000Z).
Le nouveau fichier de configuration est XXX.
exemples d'images Linux dans /usr/xen-parts (dans wd0e)
pb sur le montage automatique des images : la commande vnconfig XXX n'est pas prévue dans les scripts de démarrage standard.
(vérifier avec le swap aussi dans une image)
A faire : démarrer une image
préparée sous Debian, stockée dans une
partition ext2fs.
Il existe des patches permettant de compiler le noyau FreeBSD pour être compatible avec Xen. Pour l'instant, une partition de 2Go est réservée pour FreeBSD 5.3 (configuration dans le menu de grub).
NB : problème de partage de partitions FreeBSD/NetBSD : NetBSD ne veut pas monter les partitions de FreeBSD et NetBSD ne veut pas non plus monter les partitions NetBSD - dommage, il faut donc passer par une partition Linux en ext2 !! (=> pb pour recycler une partition "native" FeeBSD en domaine U pilotée par NetBSD/Dom0).
L'administration d'une machine virtuelle est similaire
à celle d'un
serveur "headless" (sans écran ni clavier) : l'essentiel est
fait sur
une connxion réseau par ssh. Pour les opérations
nécessitant une
connexion "console", la commande xm console
depuis le domaine 0 permet de se connecter sur la console de la machine
virtuelle (et par exemple passer en mode single-user).
Connexion via ssh sous un compte utilisateur puis su
(exemple avec un NetBSD dans un domU)
connexion par "console" depuis le domaine 0 :
domaine-0: {8} xm console nbsd-dom1
************ REMOTE CONSOLE: CTRL-] TO QUIT ********
NetBSD/i386 (dom1.mydomain) (console)
login:
vérification de bon fonctionnement de DomU par compilation en boucle du noyau de NetBSD
(vérification du bon fonctionnement du scheduler Xen)
Après 11 jours de compilation en boucle dans 4
domaines NetBSD / XenU en parallèle :
xm list
Name
Id Mem(MB) CPU State
Time(s) Console
Domain-0
0 63
0 r---- 54351.3
dom1
7
31 0 -----
230516.8 9607
dom2
12
31 0 -----
230439.8 9612
dom3
14
31 0 -----
226714.1 9614
dom4
16
31 0 -b---
225525.9 9616
Le séquenceur interne à Xen est donc particulièrement "équitable".
Pendant l'exécution
de la commande xm create, la machine
virtuelle DomU peut être
contrôlée depuis un shell
exécuté par la machine virtuelle
elle-même : une commande halt
stoppe la machine virtuelle (mais la machine virtuelle reste
déclarée dans le Domaine 0).
Elle peut aussi
être
contrôlée depuis la machine hébergeante
Dom0 : une commande xm destroy ou xm shutdown
vont arrêter brutalement la machine virtuelle
(suppression de la machine virtuelle dans Domaine 0).
Pour arrêter proprement une machine virtuelle depuis
Dom0 : xm shutdown -H
(avec des versions récentes de NetBSD et Debian).
Sous Linux 2.6-XenU, la commande init 0
arrête la
machine virtuelle (elle n'apparaît plus dans xm list).
Chaque DomU gére ses packages (avec la commande pkg_info).
Une méthode pour installer les packages est de les compiler depuis un arbre des pkgsrc. L'arbre pkgsrc est monté par NFS depuis un disque partagé vers les domU :
dom1: {8} ping serveur
PING serveur.mydomain (192.168.1.4): 56 data bytes
64 bytes from 192.168.1.4: icmp_seq=0 ttl=63 time=0.846 ms
64 bytes from 192.168.1.4: icmp_seq=1 ttl=63 time=0.991 ms
^C
----serveur.mydomain PING Statistics----
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.846/0.918/0.991/0.103 ms
dom1: {9} mount serveur:/share /mnt
dom1: {10} ls /mnt
distfiles
pkgsrc
dom1: {11}
Puis installation des packages sur une machine virtuelle :
cd /usr/pkgsrc/www/apache ; make install
&&
make clean