Xen

Transcription

1 Xen 1 Présentation 1.1 Qu'est ce que Xen? notions Différences avec d'autres outils de virtualisation Machine Virtuelle Hyperviseur 1.2 Objectif de cette page 2 Requis 3 Paramètrage de xend 4 Création d'un DomU avec les xen-tools 4.1 étape 1 : configuration des xen-tools 4.2 étape 2 : création de l'image du DomU 5 Création d'un DomU "manuellement" - METHODE OBSOLETE! 5.1 étape 1 : création des partitions avec LVM 5.2 étape 2 : installation du système 5.3 étape 3 : création du fichier de configuration du DomU 6 Exploitation des DomU 6.1 démarrer un DomU 6.2 finalisation de l'installation 6.3 commandes / admin 7 Configuration avancées 7.1 mettre en place le bonding pour les DomU 8 HVM : virtualisation matérielle 8.1 Qu'est ce que le HVM? 8.2 Création d'un DomU étape 1 : préparatif étape 2 : installation étape 3 : post-installation 9 Exploitation 9.1 Modification de la taille d'une partition d'un DomU 1 of 26 07/17/ :40 AM

2 9.1.1 Agrandir une partition Rétrécir une partition 9.2 Bonnes pratiques Migration de machine virtuelle Supervision 10 Liens Présentation Qu'est ce que Xen? Xen est un logiciel libre de virtualisation, plus précisément un hyperviseur de machine virtuelle. Il est développé par l'université de Cambridge au Royaume-Uni. Xen permet de faire fonctionner plusieurs systèmes d'exploitation virtuels (invités) sur une seule machine hôte. Le principe de l'hyperviseur est de faire tourner les OS dans le noyau (kernel) même, et non-pas de les émuler, ce qui permet de conserver des performances proches des natives. Architecture Xen Logiciels de contrôle Xen Espace utilisateur Espace utilisateur Espace utilisateur Espace utilisateur Xeno-Linux Linux NetBSD FreeBSD Plan 9 Pilotes Xen Pilotes Xen Pilotes Xen Pilotes Xen Pilotes Xen Xen Matériel : processeur, mémoire, stockage, réseau, etc. notions Avant de commencer il faut bien comprendre la différence entre un Dom0 et un DomU, voici une explication de Wikipedia : A Xen system is structured with the Xen hypervisor as the lowest and most privileged 2 of 26 07/17/ :40 AM

3 layer. Above this layer are one or more guest operating systems, which the hypervisor schedules across the physical CPUs. The first guest operating system, called in Xen terminology "domain 0" (dom0), is booted automatically when the hypervisor boots and given special management privileges and direct access to the physical hardware. The system administrator can log into dom0 in order to manage any further guest operating systems, called "domain U" (domu) in Xen terminology. D'autres informations et "vulgarisation" sur Xen sur ce lien : xen pour les nuls Différences avec d'autres outils de virtualisation source : Machine Virtuelle Une machine virtuelle est un logiciel (généralement assez lourd) qui tourne sur l'os hôte. Ce logiciel permet de lancer un ou plusieurs OS invités. La machine virtualise ou/et émule le matériel pour les OS invités, ces derniers croient dialoguer directement avec ledit matériel. Cette solution est très comparable à un émulateur, et parfois même confondue. Cependant l unité centrale de calcul, c'est-à-dire le microprocesseur, la mémoire de travail (ram) ainsi que la mémoire de stockage (via un fichier) sont directement accessible aux machines virtuelles, alors que sur un émulateur l unité centrale est simulée, les performances en sont donc considérablement réduites par rapport à la virtualisation. Emulateur Cette solution isole bien les OS invités, mais elle a un coût en performance. Ce coût peut être très élevé si le processeur doit être émulé, comme cela est le cas dans l émulation. En échange cette solution permet de faire cohabiter plusieurs OS hétérogènes sur une même machine grâce à une isolation complète. Les échanges entre les machines se font via les canaux standards de communication entre systèmes d exploitation (TCP/IP et autres protocoles réseau), un tampon d échange permet d émuler des cartes réseaux virtuelles sur une seule carte réseau réelle. 3 of 26 07/17/ :40 AM

4 Exemples : QEMU : émulateur de plateformes x86, PPC, Sparc Kernel-based Virtual Machine kvm]] : version modifiée de QEMU tirant parti des instructions de virtualisation des processeurs Intel et AMD (Intel VT ou AMD-V) bochs : émulateur de plateforme x86 Lismoresystems Guest PC : propriétaire, émulateur de plateforme x86 sur matériel PC MacOnLinux : émulateur de plateforme Mac OS sur Linux PPC Microsoft VirtualPC et Microsoft VirtualServer : propriétaire, émulateur de plateforme x86 Parallels Desktop : propriétaire PearPC : émulateur de plateforme PPC sur matériel x86 Plex86 : émulateur de plateforme x86 VirtualBox : émulateur de plateforme x86 VMware : propriétaire, émulateur de plateforme x86 (produits VMware Server, VMware Player et VMware Workstation) Hercules : émulateur qui permet l'émulation d'un mainframe z/os sur PC Windows ou Linux avec émulation des disques Hyperviseur Un hyperviseur est comme un noyau système très léger et optimisé pour gérer les accès des noyaux d'os invités à l'architecture matérielle sous-jacente. Si les OS invités fonctionnent en ayant conscience d'être virtualisés et sont optimisés pour ce fait, on parle alors de para-virtualisation (méthode indispensable sur Hyper-V de Microsoft et qui augmente les performances sur ESX de VMware par exemple). Actuellement l hyperviseur est la méthode de virtualisation d'infrastructure la plus performante mais elle a pour inconvénient d être contraignante et onéreuse, bien que permettant plus de flexibilité dans le cas de la virtualisation d'un centre de traitement informatique. Hyperviseur Plusieurs solutions sont présentes sur ce marché, il est intéressant d en faire un léger aperçu. Xen est un hyperviseur initialement développé par l'université de Cambridge au Royaume-Uni et actuellement propriété de Citrix, il utilise un noyau léger supportant des noyaux Linux, Plan9, NetBSD, etc. VMware a un produit mature, ESX qui fait partie 4 of 26 07/17/ :40 AM

5 d'une offre globale visant à virtualiser les moyens informatique de l'entreprise. Microsoft a sorti un hyperviseur basé sur les mêmes principes fondateurs que ses concurrent. L'hyperviseur de Microsoft est intégré dans son «Windows Server 2008» (version 64bits uniquement). Exemples : VMware : propriétaire, hyperviseur sur plateforme x86 (produits ESX et ESXi -Gratuit-) Xen : noyau léger supportant des noyaux Linux, Plan9, NetBSD, etc. Hyper-V : propriétaire, hyperviseur sur plateforme x86. Objectif de cette page L'objectif de cette page est de donner une première approche de la virtualisation sous Xen : manuellement mais aussi via les outils Xen (xen-tools). Les manipulations ont été réalisées sur une Debian Lenny 5.0 et en utilisant LVM. Requis Plusieurs packages sont nécessaires pour pouvoir faire tourner le processus Xen. Pour une machine 32bits : $ sudo aptitude install xen-linux-system xen-686 bridge-utils xen-tools Le premier paquet (xen-linux-system xen-686) va permettre d'avoir un nouveau kernel patché pour xen. Le deuxième paquet est un paquet qui va permettre au machine virtuelle de pouvoir "sortir" sur le réseau et d'avoir accès à Internet par exemple. Le dernier paquet est la suite d'outils pour xen. Une fois ces paquets installés, il faudra rebooter sur le kernel patché xen. Pour vérifier que vous avez bien booté sur le bon kernel vous pouvez utiliser la commande suivante : $ uname -a Linux psrv-qg-dmz xen-686 #1 SMP Sat Jan 10 22:52:47 UTC 2009 i686 GNU/Li A ce stade, Xen (ses outils et le kernel) est installé! on peut donc commencer à créer nos premières machines virtuelles! 5 of 26 07/17/ :40 AM

6 Paramètrage de xend xend est le processus qui permet de gérer les interfaces entre les machines virtuelles (DomU) et la machine physique (Dom0). Il est nécessaire de modifier son fichier (/etc/xen/xend-config.sxp) de configuration pour permettre aux DomU de pouvoir "sortir" sur le réseau. Voici à quoi doit ressembler - au moins - ce fichier de configuration : $ sudo cat /etc/xen/xend-config.sxp grep -v "^#" (network-script network-bridge) (vif-script vif-bridge) (dom0-min-mem 196) (dom0-cpus 0) (vncpasswd '') Les deux premières lignes correspondent aux modifications à apporter pour la configuration réseau. Il est nécessaire de relancer le service afin que les modifications soient prises en compte : $ sudo /etc/init.d/xend restart Nota : en fin de doc, il y a la config à suivre si l'on souhaite mettre du bonding Création d'un DomU avec les xen-tools Comme expliqué plus haut, nous allons voir les deux méthodes possibles pour la création de vos DomU. Cette première méthode se base sur les outils de xen-tools. Elle est plus simple et rapide que celle que nous verrons plus tard. Elle se divise en deux étapes : étape 1 : modification du fichier de configuration des xen-tools, pour que les options correspondent à nos besoins. étape 2 : création de l'image du DomU. étape 1 : configuration des xen-tools La configuration des outils xen passe par le fichier /etc/xen-tools/xen-tools.conf. Ce dernier permet d'initialiser des options qui seront utilisées pour la création des 6 of 26 07/17/ :40 AM

7 DomU. L'unique but de cette configuration est d'assurer un certain confort dans l'utilisation des outils. Voici le fichier que j'ai utilisé avec les explications pour chaque entrée : $ sudo cat /etc/xen-tools/xen-tools.conf grep -v "^#" lvm = vg0 # le nom de mon groupe de volume qui sera utilise pour faire # les futurs disques install-method = debootstrap # la methode d'installation choisie size = 4Gb # la taille de la partition / par defaut memory = 64Mb # la taille de la RAM par defaut swap = 128Mb # la taille de la SWAP par defaut fs = ext3 # le systeme de fichier par defaut dist = lenny # la distribution par defaut a installer image = sparse # sparse vs. full disk images. gateway = netmask = broadcast = passwd = 1 kernel initrd # en placant cette option a 1, un password vous sera demande # lors de l'installation du DomU = /boot/vmlinuz-`uname -r` = /boot/initrd.img-`uname -r` mirror = ext3_options = noatime,nodiratime,errors=remount-ro ext2_options = noatime,nodiratime,errors=remount-ro xfs_options = defaults reiser_options = defaults Attention cette configuration suppose qu'un groupe de volume vg0 a déjà été créé. Pour toute information sur lvm ca se passe ici Toutes les options de configuration pour la création des images sont accessibles en via la commande suivante : $ sudo xen-create-image --manual étape 2 : création de l'image du DomU Maintenant que tout semble bien configuré, nous pouvons utiliser les xen-tools pour générer le fichier de configuration xen de notre DomU mais aussi pour installer le système de notre DomU! Pour cela il suffit de lancer la commande suivante : 7 of 26 07/17/ :40 AM

8 $ sudo xen-create-image --hostname=psrv-qg-dmz ip= (plus d'options de création en consultant le man de xen-create-image). Il faut noter que les options non explicitées seront initialisées grâce au fichier de conf édité plus tôt : /etc/xen-tools/xen-tools.conf. Voici ce que donne l'éxecution de la commande : # xen-create-image --hostname=psrv-qg-dmz ip= General Information Hostname : psrv-qg-dmz-0-1 Distribution : lenny Partitions : swap 128Mb (swap) / 4Gb (ext3) Image type : full Memory size : 64Mb Kernel path : /boot/vmlinuz xen-686 Initrd path : /boot/initrd.img xen-686 Networking Information IP Address 1 : [MAC: 00:16:3E:8C:EB:F0] Netmask : Broadcast : Gateway : Creating swap on /dev/vg0/psrv-qg-dmz-0-1-swap Done Creating ext3 filesystem on /dev/vg0/psrv-qg-dmz-0-1-disk Done Installation method: debootstrap Done Running hooks Done No role scripts were specified. Skipping Creating Xen configuration file Done Setting up root password Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully All done Logfile produced at: /var/log/xen-tools/le-nom-de-votre-host.log N'hésitez pas à suivre l'évolution de l'installation : 8 of 26 07/17/ :40 AM

9 tail -f /var/log/xen-tools/le-nom-de-votre-host.log Si tout se passe bien, les deux disques virtuels /dev/vg0/psrv-qg-dmz-0-1-swap et /dev/vg0/psrv-qg-dmz-0-1-disk auront été créés et formatés (vérification avec la commande lvdisplay) et un fichier aura été généré : /etc/xen/psrv-qg-dmz-0-1.cfg. Cependant cette méthode ne va créer que 2 partitions : pour / et pour le swap. Si vous souhaitez plus de partitions/disques formattés pour des fs différents c'est aussi possible! Pour cela il va falloir créer un fichier dans le répertoire /etc/xen-tools/partition.d/ en s'inspirant de l'exemple suivant : $ sudo cat /etc/xen-tools/partitions.d/test-server [root] size=1g type=ext3 mountpoint=/ options=sync,errors=remount-ro [swap] size=2g type=swap [home] size=1g type=ext3 mountpoint=/home options=nodev,nosuid [usr] size=4g type=ext3 mountpoint=/usr options=nodev [var] size=4g type=ext3 mountpoint=/var options=nodev,nosuid [tmp] size=4g type=ext3 mountpoint=/tmp options=nodev,nosuid La commande pour créer le DomU est donc complétée d'une option pour les partitions : $ sudo xen-create-image --hostname=psrv-qg-dmz ip= partition=te 9 of 26 07/17/ :40 AM

10 Le DomU est donc créé et presque prêt à l'emploi... presque car tel quel, le fichier généré ne permettra pas d'avoir accès à la console de la machine virtuelle. Pour permettre cela, executer simplement la ligne suivante : echo "extra = 'xencons=tty1 clocksource=jiffies'" >> /etc/xen/psrv-qg-dmz-0-1.cfg Cette ligne est une option de boot du kernel pour le DomU qui spécifie que tty1 (soit la première console) est dédiée au mode console xen. Il est aussi possible de modifier certaines valeurs du fichier /etc/xen/psrv-qg-dmz- 0-1.cfg pour tunner certaines valeurs "après coups" comme la RAM, le nombre de CPU... Création d'un DomU "manuellement" - METHODE OBSOLETE! La création des DomU via les outils xen est très intéressante mais ne permet pas une souplesse totale essentiellement pour les partitions. En effet à chaque fois 2 partitions seront créées : une pour / et une pour le swap et visiblement il n'est pas possible de spécifier plus de partitions (du moins j'ai pas trouvé comment :) edit : en fait si cf. paragraphe d'avant ). Cette section décrira donc les étapes à suivre pour permettre de créer un DomU avec les spécifications systèmes que l'on souhaite. Pas forcément très compliqué, la procédure reste tout de même plus longue que la précedente. On souhaite avoir un DomU avec les partitions suivantes : / de 1Go /boot de 64Mo /usr de 5Go /tmp de 2Go /var de 50Go /home de 5Go /usr/local de 5Go un swap de 2Go 10 of 26 07/17/ :40 AM

11 Pour cela nous allons suivre les étapes suivantes : étape 1 : création des partitions avec LVM étape 2 : installation du système étape 3 : création du fichier de configuration du DomU étape 1 : création des partitions avec LVM La création et la manipulation des partitions avec LVM n'est pas l'objectif de cette page mais ce tuto permettra de comprendre les lignes de commandes qui suivent : lvcreate -n p01 -L 64m vg0 lvcreate -n p02s -L 2g vg0 lvcreate -n p03 -L 1g vg0 lvcreate -n p04 -L 5g vg0 lvcreate -n p05 -L 2g vg0 lvcreate -n p06 -L 50g vg0 lvcreate -n p07 -L 5g vg0 mkswap /dev/vg0/p02s mke2fs -j /dev/vg0/p01 mke2fs -j /dev/vg0/p03 mke2fs -j /dev/vg0/p04 mke2fs -j /dev/vg0/p05 mke2fs -j /dev/vg0/p06 mke2fs -j /dev/vg0/p07 A ce stade, vous avez donc toutes vos partitions créées et formatées. étape 2 : installation du système L'installation du système se fera via debootstrap. Mais avant il faut monter toutes les partitions précédémment créées. 11 of 26 07/17/ :40 AM

12 $ sudo mkdir /data/forinstall $ sudo mount /dev/vg0/p03 /data/forinstall $ sudo mkdir /data/forinstall/boot /data/forinstall/usr /data/forinstall/tmp /data/f $ sudo mount /dev/vg0/p01 /data/forinstall/boot/ $ sudo mount /dev/vg0/p04 /data/forinstall/usr/ $ sudo mount /dev/vg0/p05 /data/forinstall/tmp/ $ sudo mount /dev/vg0/p06 /data/forinstall/var/ $ sudo mkdir /data/forinstall/usr/local $ sudo mount /dev/vg0/p07 /data/forinstall/usr/local/ $ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda % / tmpfs % /lib/init/rw udev % /dev tmpfs % /dev/shm /dev/sda % /boot /dev/sda % /data /dev/sda % /home /dev/sda % /tmp /dev/sda % /usr /dev/sda % /usr/local /dev/sda % /var /dev/mapper/vg0-p % /data/forinstall /dev/mapper/vg0-p % /data/forinstall/boot /dev/mapper/vg0-p % /data/forinstall/usr /dev/mapper/vg0-p % /data/forinstall/tmp /dev/mapper/vg0-p % /data/forinstall/var /dev/mapper/vg0-p % /data/forinstall/usr/local Maintenant on peut lancer l'installation du système dans cette arborescence : $ sudo debootstrap --arch i386 lenny /data/forinstall/ Puis pour finaliser l'installation : $ cd /data/forinstall $ cp /etc/apt/sources.list etc/apt/ $ cp -a /lib/modules/ xen-686/ lib/modules/ $ cp /etc/resolv.conf etc/ $ cp /etc/network/interfaces etc/network/ $ vim etc/network/interfaces # a modifier avec les informations reseaux du DomU $ vim etc/hostname # a modifier avec le nom du DomU $ vim etc/hosts # a modifier ainsi : localhost <nom_du_domu> La dernière chose qu'il reste à faire et d'éditer la fstab du futur DomU afin de monter les partitions comme il se doit (et avec les options voulues). 12 of 26 07/17/ :40 AM

13 # cat etc/fstab proc /proc proc defaults 0 0 /dev/sda1 /boot ext3 defaults 0 2 /dev/sda2 none swap sw 0 0 /dev/sda3 / ext3 errors=remount-ro 0 1 /dev/sda4 /usr ext3 defaults 0 2 /dev/sda5 /tmp ext3 defaults 0 2 /dev/sda6 /var ext3 defaults 0 2 /dev/sda7 /usr/local ext3 defaults 0 2 Le DomU est donc créé et configuré. Il ne reste plus qu'a démonter toutes les partitions du DomU. étape 3 : création du fichier de configuration du DomU Il faut maintenant refaire un fichier de configuration du DomU pour le processus xend. Créez le fichier /etc/xen/psrv-qg-dmz-0-3.cfg comme suit : 13 of 26 07/17/ :40 AM

14 # # Kernel + memory size + cpu # kernel = '/boot/vmlinuz xen-686' ramdisk = '/boot/initrd.img xen-686' memory = '1024' vcpus = '2' # # Disk device(s). # root = '/dev/sda3 ro' disk = [ ] 'phy:/dev/vg0/p01,sda1,w', 'phy:/dev/vg0/p02s,sda2,w', 'phy:/dev/vg0/p03,sda3,w', 'phy:/dev/vg0/p04,sda4,w', 'phy:/dev/vg0/p05,sda5,w', 'phy:/dev/vg0/p06,sda6,w', 'phy:/dev/vg0/p07,sda7,w', # # Hostname # name = 'psrv-qg-dmz-0-3' # # Networking # vif = [ 'ip= ' ] # # Behaviour # on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'destroy' extra = 'xencons=tty1' # /!\ sans cette ligne pas d'acces possible via xm console Exploitation des DomU démarrer un DomU D'abord il faut s'assurer que le processus xend tourne bien et le démarrer si nécessaire. Puis pour démarrer une machine virtuelle, il suffit de lancer la commande suivante xm create <file>, par exemple : 14 of 26 07/17/ :40 AM

15 $ sudo xm create /etc/xen/psrv-qg-dmz-0-3.cfg Using config file "/etc/xen/psrv-qg-dmz-0-3.cfg". Started domain psrv-qg-dmz-0-3 $ La vérification des DomU activé, se fait ainsi : # xm list Name ID Mem VCPUs State Time(s) Domain r psrv-qg-dmz b On constate bien que la machine virtuelle psrv-qg-dmz-0-3 est bien démarrée et se trouve dans l'état blocked. finalisation de l'installation La machine virtuelle tourne bien, il ne reste plus qu'à se connecter à la console de cette dernière pour finir la configuration (en particulier configurer SSH pour avoir un accès distant). Pour avoir accès à la console de la machine virtuelle psrv-qg-dmz-0-3, il suffit de taper la commande suivante : # xm console psrv-qg-dmz-0-3 Debian GNU/Linux 5.0 le-nom-de-votre-host hvc0 psrv-qg-dmz-0-3 login: Le seul login possible pour le moment est root, avec un password dans le cas d'une installation avec les outils et sans password dans le cas d'une installation manuelle. Pour la suite de l'installation et de la configuration de cette machine virtuelle, il vous faudra suivre les instructions de la procédure d'installation d'un OS chez Linkeo. Ainsi vous aurez installé et configuré entre autre votre serveur SSH pour avoir l'accès distant... cependant si vous essayez de vous connectez vous risquez de tomber sur l'erreur suivante : PTY allocation request failed on channel 0. Pour pallier à ce problème, il suffit d'installer udev et de rajouter une ligne dans fstab comme suit : $ sudo aptitude install udev... $ sudo echo "none /dev/pts devpts defaults 0 0" >> /etc/fstab $ sudo mount -a 15 of 26 07/17/ :40 AM

16 La dernière chose à régler est l'indépendance de la clock du DomU par rapport au Dom0, pour cela il suffit de faire ceci : $ sudo echo "xen.independent_wallclock=1" >> /etc/sysctl.conf $ sudo sysctl -p $ sudo echo "jiffies"> /sys/devices/system/clocksource/clocksource0/current_clocksou Cette opération ne sera à faire qu'une seule fois! Explications : commandes / admin # lister les machines referencees dans xen xm list # le resultat se presente sous la forme suivante : # name domid memory vcpus state cputime # ou # * name : nom de la machine virtuelle # * domid : id de la machine virtuelle # * memory : taille de la RAM allouee a la machine virtuelle # * vcpus : nombre de processeur virtuel alloues a la machine virtuelle # * state : # - r == running # - b == blocked # - p == paused # - s == shutdown # - c == crashed # * cputime : temps CPU consomme par la machine virtuelle # demarrer la machine virtuelle definie dans fichier.cfg xm create fichier.cfg # arreter la machine virtuelle # on peut utiliser le nom ou l'id xm shutdown nom # changer la quantite de memoire ou le nombre de cpu xm mem-set id taille xm vcpu-set id number # s'il est toujours possible de reduire la taille de la memoire ou le nombre de VCPU # il est impossible de les augmenter au dela des valeurs definies dans le fichier de # conf de la machine virtuelle # a noter la taille est definie en Mo # afficher les messages XEN au boot: xm dmesg # le log de xend : /var/log/xen/xend.log 16 of 26 07/17/ :40 AM

17 Configuration avancées mettre en place le bonding pour les DomU Le bonding des DomU se fait... au niveau du Dom0! En effet pour le DomU, il y aura toujours une seule interface réseau (eth0). Tout se joue au niveau du Dom0 sur lequel on va déclarer eth1 et eth0 éligible au bonding, et c'est l'interface de bonding qui sera utilisée faire "sortir" le flux réseau des DomU On suppose ici que le kernel est bien compilé avec le module de bonding. On peut le vérifier ainsi : $ cat /boot/config-`uname -r` grep BONDING CONFIG_BONDING=m La seule chose à faire est de modifier le fichier /etc/network/interfaces du Dom0 comme suit : $ cat /etc/network/interfaces # The loopback network interface auto lo iface lo inet loopback # definition de l'interface de bonding : bond0 auto bond0 iface bond0 inet manual slaves eth0 eth1 bond_mode active-backup # mode active backup : bond_miimon 100 # check toutes les 100ms bond_updelay 4000 # temps de latence entre la decouve bond_primary eth0 # l'interface primaire est eth0 auto br0 iface br0 inet static address # adresse IP du Dom0 netmask gateway bridge_ports bond0 # liaison du pont avec l'interface d bridge_stp off # desactive le Spanning tree bridge_fd 0 # temps en secondes entre "learning Voici la liste complète des options pour le bonding : updelay : temps de latence entre la découverte de la reconnexion d'une interface et de sa ré-utilisation. downdelay : temps de latence entre la découverte de la déconnexion d'une interface et de sa désactivation de bond0. 17 of 26 07/17/ :40 AM

18 miimon : fréquence de surveillance des interfaces par Mii ou ethtool. La valeur conseillée est 100. use_carrier : utilisation de la surveillance des interfaces par "carrier". arp_interval : système de surveillance par ARP, évitant l'utilisation de miitool et ethtool. Si aucune trame est arrivée pendant l'arp_interval, on envoie par cette interface jusqu'à 16 requêtes ARP à 16 adresses IP. Si aucune réponse n'est obtenue, l'interface est désactivée. arp_ip_target : liste des adresses IP, séparées par une virgule, utilisée par la surveillance ARP. Si aucune n'est renseignée, la surveillance ARP est inactive Mais pour qu'une telle configuration soit active il va falloir modifier la configuration du démon xen (/etc/xen/xend-config.spx) en remplacant la ligne (network-script networkbridge), le fichier devient : $ sudo cat /etc/xen/xend-config.sxp grep -v "^#" (network-script network-dummy) (vif-script vif-bridge) (dom0-min-mem 196) (dom0-cpus 0) (vncpasswd '') De plus il faudra modifier les entrées vif de chaque fichier de configuration de DomU (sinon ils n'auront plus de réseau!) comme suit : $ sudo cat migration-test.cfg grep vif vif = [ 'bridge=br0' ] En fait on spécifie manuellement le bridge que la machine virtuelle va utiliser pour "sortir", cette opération était réalisée avant par le script network-bridge de xen (qui créait des soucis lors du reboot du Dom0) Il est possible d'ajouter l'adresse IP de la machine virtuelle dans le vif mais ce n'est pas obligé. HVM : virtualisation matérielle... à completer... Qu'est ce que le HVM? compléter : performance, intérêt, etc of 26 07/17/ :40 AM

19 HVM (Hardware Virtual Machine) est l'abstraction de Xen concernant la virtualisation matérielle (dispo sur les Intel avec VT et les AMD avec Pacifica). Ceci permet des choses relativement intéressante comme celle d'avoir des machines virtuelles utilisant des noyaux différents de celui du Dom0 (on peut donc installer un Windows par exemple!!). Création d'un DomU La création va se dérouler en deux étapes : étape 1 : préparation du DomU, création du fichier xen, des partitions pour le futur file system étape 2 : procédure d'installation du système sur ce nouveau DomU étape 3 : post installation étape 1 : préparatif Tout d'abord il faut bien activer le module VT (virtual technologie) dans notre cas dans le bios car sinon il sera impossible de lancer des DomU en HVM. Ce module s'active au niveau des settings du CPU il suffit de le passer à "enable". Pour cela, une fois rentré dans le menu du BIOS (F2 lors du boot) : Menu > CPU Information <ENTER> Selectionner l'entree : Virtualization Technology et passer a Enable (<fleche de dro Sortir de ce menu <ESC> Sortir du BIOS <ESC> Choisir Save and exit <ENTER> On continue en créant une partition avec LVM que l'on va utiliser pour représenter le disque "physique" de notre futur DomU. lvcreate -n p11 -L 8g vg0 Ainsi on aura un disque de 8Go pour ce DomU qu'on partionnera lors de l'installation de l'os (démarche différente de ce qui a été vu plus tôt). Il faut maintenant déclarer le fichier de configuration xen pour ce DomU et plusieurs nouvelles entrées vont faire leur apparition et certaines changent radicalement : 19 of 26 07/17/ :40 AM

20 kernel = '/usr/lib/xen-3.2-1/boot/hvmloader' builder='hvm' device_model = '/usr/lib/xen-3.2-1/bin/qemu-dm' # specification du mode hvm memory = 512 # TOTEST : sans shadow_memory, xen doit pouvoir gerer seul et au mieux # Shadow pagetable memory for the domain, in MB. # Should be at least 2KB per MB of domain memory, plus a few MB per vcpu. shadow_memory = 8 vcpus=1 on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'destroy' name = 'vnotes-hvm' # # Networking # # la definition change un peu : il y a la précision du type # pour specifier qu'on est bien en HVM # /!\ TOTEST : sans la precision du bridge a monter /!\ vif = ['type=ioemu, bridge=br0'] # definition de l'ordre du boot # correspondance de boot : floppy (a), hard disk (c) or CD-ROM (d) # default: hard disk, cd-rom, floppy #boot="d" # lors de la pre-installation boot='cd' # lors de la post-installation disk = [ ] 'phy:/dev/vg0/p11,ioemu:hda,w', 'file:/usr/src/debian-31r8-i386-netinst.iso,ioemu:hdb:cdrom,r' # le cdrom #'phy:/dev/hdb,ioemu:hdc:cdrom,r' # pour uti # deux methodes d'acces a distance : SDL et VNC sdl=0 # desactivation de SDL vnc=1 # activation de VNC vnclisten=' ' # VNC n'ecoutera que sur vncunused=0 # il faut les incrementer pour chaque DomU dans ce cas # sinon il y aura conflit! vncdisplay=1 # identifiant VNC vncconsole=1 # identifiant VNC usb=1 usbdevice='tablet' # activation des ports USB # precision qu'un clavier est connecte en USB keymap='fr' # sans ca, c'est un keymapping suspect que vous aurez ;) 20 of 26 07/17/ :40 AM

21 étape 2 : installation Une fois le fichier de configuration, on peut lancer la machine virtuelle comme d'habitude : $ sudo xm create /etc/xen/vnotes-hvm.cfg Using config file "/etc/xen/vnotes-hvm.cfg". Started domain vnotes-hvm $ Théoriquement comme on est en "pré-installation", le boot se fait sur l'iso (soit sur le lecteur cd). Mais comment suivre et poursuivre l'installation? VNC!! Vérifiez d'abord qu'un serveur VNC est bien en écoute sur :5901 : # netstat -an grep 5901 tcp : :* LISTEN Si comme moi vous accéder à votre Dom0 via ssh, il sera nécessaire d'ouvrir un tunnel pour pouvoir se connecter au serveur VNC. Pour cela il vous suffit de lancer un terminal et d'éxecuter la commande suivante : [erwan@erwan-laptop -14:34:37- ~]$ ssh -N -T -L 3128: :5901 erwan@<ip_dom0> puis il vous suffit de lancer un VNC sur :3128. A ce stade vous pouvez installer votre système comme vous le souhaitez. étape 3 : post-installation L'installation une fois finie, il ne reste qu'a installer un serveur SSH, pour une prise à distance plus aisée. Une fois SSH configuré, il va falloir éteindre la machine virtuelle et modifier son fichier de configuration xen pour désactiver le VNC et changer l'odre de boot! Exploitation Modification de la taille d'une partition d'un DomU L'avantage de reposer sur LVM laisse la souplesse de resizer les partitions des DomU à la demande : aussi bien pour agrandir ou rétrécir une partition. 21 of 26 07/17/ :40 AM

22 Agrandir une partition Il n'y a aucun problème à agrandir une partition d'un DomU (soit un LV au niveau du Dom0). Les seuls contraintes sont : le DomU doit être éteint être sûr que le VG possède bien de l'espace libre à donner au LV Ensuite il suffit de lancer les commandes suivantes sur le Dom0 $ cat test-mysql-2.cfg grep sda2 'phy:/dev/vg0/test-mysql-2-disk,sda2,w', # ici nous allons donc resizer le LV /dev/vg0/test-mysql-2-disk correspondant à sda2 # on éteint donc le DomU $ sudo xm shutdown test-mysql-2 # puis on éxecute les commandes suivantes : # on ajoute 7Go à la partition, sans le "+" cela signifierait qu'on souhaite une par $ sudo lvresize -L +7g /dev/vg0/test-mysql-2-disk $ sudo e2fsck -f /dev/vg0/test-mysql-2-disk $ sudo resize2fs /dev/vg0/test-mysql-2-disk C'est tout! il ne reste qu'à relancer le DomU et vérifier avec un df la taille de la partition sda2. Rétrécir une partition La réduction de taille d'une partition est un plus subtile : en effet il faut faire très attention à ne pas réduire la partition plus que nécessaire afin d'éviter de perdre des données! Les contraintes sont : le DomU doit être éteint connaître la quantité d'espace à retirer (soit Taille_A_Retirer), la taille actuelle de la partition (soit Taille_Actuelle) afin de terminer la taille finale de la partition (soit Taille_Actuelle-Taille_A_Retirer=Taille_Finale) Ensuite il suffit de lancer les commandes suivantes sur le Dom0 $ cat test-mysql-2.cfg grep sda2 'phy:/dev/vg0/test-mysql-2-disk,sda2,w', # ici nous allons donc resizer le LV /dev/vg0/test-mysql-2-disk correspondant à sda2 # on éteint donc le DomU $ sudo xm shutdown test-mysql-2 # puis on éxecute les commandes suivantes : # on retire 1Go à la partition qui en fait actuellement 10Go $ resize2fs -p /dev/vg0/test-mysql-2-disk 9g # on precise que le filesystem doit ten $ lvresize -L -1g /dev/vg0/test-mysql-2-disk # on retire 1Go à la partition LVM $ resize2fs /dev/vg0/test-mysql-2-disk 22 of 26 07/17/ :40 AM

23 C'est tout! il ne reste qu'à relancer le DomU et vérifier avec un df la taille de la partition sda2. Bonnes pratiques... à completer... Sur le Dom0 il faut penser à avoir le minimum de service qui tourne (il est avant tout là pour gérer les interface des DomU avec le matériel)... Pour retirer les services inutiles : $ sudo update-rc.d -f service_name remove Tips pour le boot du dom0 : avec l'installation du kernel Xen, il y a une nouvelle entrée dans le fichier /boot/grub/menu.lst qu'on peut légérement modifier comme suit : title root kernel module module Xen i386 / Debian GNU/Linux, kernel xen-686 (hd0,0) /xen i386.gz dom0_mem= /vmlinuz xen-686 root=/dev/sda5 ro console=tty0 /initrd.img xen-686 dom0_mem : permet de spécifier la quantité de mémoire allouée au dom0 et attention c'est en Ko! Ici donc 128Mo seront allouées au dom0 Démarrage automatique des domu au boot de la machine physique et du dom0? Deux choses interviennent : le service xendomains doit être démarré et les fichiers de configuration des domu doivent être présents dans /etc/xen/auto : ln -s /etc/xen/domu-file.cfg /etc/xen/auto/domu-file.cfg Migration de machine virtuelle On considère deux types de migrations : les migrations live et les migrations offline. Les migrations lives ne sont possibles que si les "disques" du DomU à migrer sont 23 of 26 07/17/ :40 AM

24 accessibles via le réseau pour le Dom0 cible. Par exemple si les "disques" du DomU se trouvent sur un lecteur NFS... Plusieurs tutoriaux (comme celui ci celui ci ) expliquent comment réaliser cette manipulation relativement simple si tous les prérequis sont réunis. Ces migrations permettent de ne pas avoir de coupure de service (30 à 600ms de reprise annoncé par Xen), en fait ce qui se passe c'est que le contenu de la RAM du DomU sur le Dom0 d'origine est transféré au DomU du Dom0 de destination, et une fois que ceci est réalise le DomU du Dom0 d'origine est éteint et celui du Dom0 de destination activé... Dans notre cas c'est surtout les migrations offlines qui vont nous intéresser. Pour cela il suffit de suivre les étapes suivantes : créer les partitions du DomU sur le Dom0 destination et les monter en respectant la fstab du DomU : la partition /home du DomU sera montée sur /repertoire-racinede-montage/home du Dom0 (un peu comme on a pu le faire ici ) éteindre le DomU sur le Dom0 source monter les disques du DomU sur le Dom0 source en respectant la fstab du DomU (un peu comme on a pu le faire ici ) ensuite il suffit de faire une synchronisation entre les deux Dom0 dans les arborecenses tout juste montées Pour faciliter la synchro, il est préférable de configurer sur le Dom0 source un serveur rsync comme suit : 24 of 26 07/17/ :40 AM

25 $ cat /etc/rsyncd.conf log file=/var/log/rsyncd # for pid file, dont' use /var/run/rsync.pid unless you're not going to run # rsync out of the init.d script. The /var/run/rsyncd.pid below is OK. pid file=/var/run/rsyncd.pid syslog facility=daemon [<REPERTOIRE_RSYNC>] comment = pour la synchro path = <POINT_DE_MONTAGE_SUR_DOM0_SOURCE> use chroot = yes read only = yes list = yes uid = root gid = root strict modes = yes #makes sure the secrets file has proper permissions hosts allow = <IP_DOM0_DEST> hosts deny = * ignore errors = no ignore nonreadable = yes transfer logging = yes log format = %t: host %h (%a) %o %f (%l bytes). Total %b bytes. timeout = 600 refuse options = checksum, dry-run dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz Depuis le Dom0 destination il ne reste qu'a lancer la commande suivante : rsync -av --numeric-ids rsync://<ip_dom0_source>/<repertoire_rsync> <POINT_DE_MONTAG copier ensuite sur le Dom0 de destination le fichier de configuration Xen correspondant au DomU migré, démonter les partitions montées pour la synchronisation et démarrer le DomU sur le Dom0 destination (ouf)! L'arret de service dépend directement du temps nécessaire pour la synchro. A noter que cette opération n'est pas possible pour une machine virtuelle en HVM. Supervision Pour faciliter la configuration de La supervision dans Centreon, 2 templates d'hosts ont été créés : Servers-Linux_dom0 et Servers-Linux_domU. Dans le template Servers-Linux_domU, les interfaces checkées ne sont pas les mêmes (bond0 n'existant pas) et il n'y a pas de check du matériel Dell (via omreport) ni du bonding. Liens : site officiel du projet 25 of 26 07/17/ :40 AM

26 : presentation de xen : lien expliquant les parades possibles au bug de la console : tuto et généralité sur Xen : faire du bonding sous Xen : faire du bonding sous Xen sans changer la configuration de Xen : migration live sous Xen : tout sur les bases de LVM : la doc complète sur la démystification de LVM Categories: Administration Linux 26 of 26 07/17/ :40 AM