Table des matières
- 1. Mon nouveau portable
- 2. Xenification
- 3. En avant la musique
- 4. Quelques commandes Xen
- 5. Nattage des machines virtuelles
- 6. Le support VMX
- 7. Virtualisation de WinXP
- 8. Démarrage automatique des machines virtuelles
- 9. Séparer les données
- 10. Tests de performances
- 11. L'interface graphique
- 12. Résumé
- 13. KVM
- 14. Autres configs
J'ai fais très récement l'aquisition d'un Sony Vaio ( PCG-6S4M ) avec comme il se doit un Win machin vista dans les entrailles. Ni une ni deux, je dégage tout ça. L'idée première étant de xenifier cette machine pour disposer d'un Winbeurk (xp) et d'un Linux (Debian) virtuel. Pourquoi le faire alors que c'est si simple avec un qemu, virtualbox ou vmware ? En un mot pour la performance. Pas d'émulation hardware ni logicielle = performance proche du natif, enfin du moins c'est ce que j'ai pu comprendre en consultant dievrses docs sur le Net. Une autre raison est la gestion des machines virtuelles et des ressources utilisées.
Ce qui suit est le cheminement suivi lors de mes divers essais ...
Je ne m'étenderai pas sur les rouages de Xen, c'est décrit un peut partout sur le Net.
Le Domaine0 sera installé sous Debian Etch. Je boote donc sur une ISO Netinst. Le partitionnement du disque est effectué manuellement avec:
-
/win (primaire) en Fat32: 20Go
-
/Debian (primaire) en ext3 : 60 Go
-
/boot (primaire) en ext3 : 150Mo
-
swap (logique) : 2Go
-
/ (logique) en ext3 : 5Go
-
/vserver (logique) en ext3 : le reste du disque
Je fixe ensuite une adresse IP en dur (192.168.1.11 dans mon cas) et installe le minimum requis (Système standard). Après redémarrage de la machine je supprime ce qui fait référence au dépot du CDROM (dans /etc/apt/sources.list), et un update. Un peu de ménage ne fait pas de mal:
apt-get remove exim4 exim4-base nfs-common portmap pidentd pcmcia-cs
Me voilà paré pour l'installation de Xen. Deux méthodes sont alors possibles, soit à partir des sources ou encore avec les binaires de Debian. Paresseux comme une couleuvre je choisis la seconde méthode ;)
Les versions récentes de Xen ne sont malheureusement pas fournies
dans la distribution Etch. Qu'a cela ne tienne je vais utiliser les
backports, pour cela j'ajoute la ligne suivante au fichier
/etc/apt/sources.list
:
deb http://www.backports.org/debian etch-backports main contrib non-free
J'update et installe les clés du dépot backport:
apt-get update apt-get install debian-backports-keyring
Xen en version 3.2 est maintenant disponible, je l'installe de suite:
apt-get install linux-image-2.6-xen-vserver-686 libc6-xen xen-hypervisor-3.2-1-i386 xen-tools xen-utils-3.2-1 bridge-utils
Et je reboote sur le noyau Linux xenifié et me logue.
Les xen-tools founissent les binaires utiles pour la
création/suppression/mise à jour d'images. Les valeurs par défaut pour la
création des images sont paramétrées dans le fichier
/etc/xen-tools/xen-tools.conf
. Jettons un oeil sur
les paramètres qui vont nous être utile :
#dir = /home/xen ... size = 4Gb # Disk image size. memory = 128Mb # Memory size swap = 128Mb # Swap size # noswap = 1 # Don't use swap at all for the new system. fs = ext3 # use the EXT3 filesystem for the disk image. dist = sarge # Default distribution to install. ... #gateway = 192.168.1.1 #netmask = 255.255.255.0 #arch=i386 ... kernel = /boot/vmlinuz-2.6.16-2-xen-686 initrd = /boot/initrd.img-2.6.16-2-xen-686
Pour tester une nouvelle image je modifie les paramètres suivants :
-
dir = /home/xen devient dir = /xserver
-
' dist = etch ' que je conserve . Le nom des distributions installables via debootstrap disponibles sont visibles dans
-
Décommente passwd=1 pour demander le mot de passe
-
Décommente arch=i386
-
J'adapte le kernel/initrd à celui installé sur lequel je viens de booter soit
/boot/vmlinuz-2.6.18-6-xen-vserver-686
et/boot/initrd.img-2.6.18-6-xen-vserver-686
mais j'aurais pu tout aussi bien utiliser n'importe quel noyau. -
Je décommente gateway et netmask
Et enfin je créé ma première image Debian/Etch avec la commande suivante :
xen-create-image --debootstrap --mirror http://ftp.fr.debian.org/debian/ --hostname test -ip 192.168.1.12 General Infomation -------------------- Hostname : test Distribution : etch Fileystem Type : ext3 Size Information ---------------- Image size : 4Gb Swap size : 128Mb Image type : sparse Memory size : 128Mb Kernel path : /boot/vmlinuz-2.6.18-6-xen-vserver-686 Initrd path : /boot/initrd.img-2.6.18-6-xen-vserver-686 Networking Information ---------------------- IP Address 1 : 192.168.1.12 Netmask : 255.255.255.0 Gateway : 192.168.1.1 Creating swap image: /vserver/domains/test/swap.img Done Creating disk image: /vserver/domains/test/disk.img Done Creating ext3 filesystem on /vserver/domains/test/disk.img Done Installing your system with debootstrap mirror http://ftp.fr.debian.org/debian/ Done Running hooks Done No role script 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/test.log
On peut noter que lors de l'exécution des hooks ces ont en vérité
les scripts présents dans
/usr/lib/xen-tools/etch.d/
qui sont lancés. A l'issue le fichier
/etc/xen/test.cfg
est généré.
Notre premier DomainU est maintenant disponible, on boote sur celui-ci avec la commande:
xen0:~# xm create -c test.cfg Using config file "/etc/xen/test.cfg". Error: Device 0 (vif) could not be connected. Backend device not found.
Arghhh
... Ca bloque lors de l'exécution de
/etc/xen/scripts/network-bridge
:(
En fait c'est tout à fait normal, xend tente de monter un bridge sur
l'interface eth0 par défaut or l'interface réseau du vaio est eth1 (eth0
est utilisée pour le firewire). Pour modifier ce comportement il suffit de
décommenter la ligne suivante du fichier
/etc/xen/xend-config.sxp
:
(network-script 'network-bridge netdev=eth1')
Ensuite redémarrage de xend et là l'interface xenbr1 est bien montée. Maintenant il me reste à adapter la configuration de mon domaineU test en pointant sur cette interface.
Dans le fichier
/etc/xen/test.cfg
je modifie
:
vif = [ 'ip=192.168.1.12' ]
par
vif = [ 'ip=192.168.1.12', 'bridge=xenbr1' ]
Voilà je peux redémarrer le domaineU test :
xm create test.cfg xen0:~# xm list Name ID Mem VCPUs State Time(s) Domain-0 0 1892 2 r----- 17.7 test 3 128 1 -b---- 3.2 xen0:~# ping 192.168.1.12 PING 192.168.1.12 (192.168.1.12) 56(84) bytes of data. 64 bytes from 192.168.1.12: icmp_seq=1 ttl=64 time=0.085 ms 64 bytes from 192.168.1.12: icmp_seq=2 ttl=64 time=0.062 ms
Yes :=)
xm create test.cfg # démarre la machine test xm shutdown test # stoppe la machine test xm list # liste des diverses machines xm console test # logue sur la mchine test xm save domain-id # sauve une machine virtuelle, permet de la redémarrer très rapidement xm restor domain-id # Restauration machine virtuelle xm dmesg # Messages Xen xm top # Surveiller les machines virtuelles xm pause ? # Pause une machine virtuelle xm unpause ? # Retirer la pause d'une machine virtuelle xm help # la suite ...
Pour sortir du mode console : CTRL + ]
Comme nous venons de le voir Xen utilise par défaut le mode bridge, or le portable sera dans des contextes différents, au taf, chez moi ou ailleurs. En mode bridge les adresses des machines virtuelles apparaissent sur le réseau telles qu'elles sont définies, je devrais donc reconfigurées ces dernières à chaque changement de contexte ... hors de question ! Pour y pallier il suffit de mettre en oeuvre le nattage des adresses IP des machines virtuelles.
Dans ce cas l'adresse IP du serveur Xen n'est plus sur la même plages d'adresses que celles des machines virtuelles. J'ai modifié l'adresse IP du serveur Xen (dom0) en 10.33.105.105 et conservé les adresses IP des machine virtuelles en 192.168.0.0/16.
Dans le fichier de configuration de la machine virtuelle je modifie :
vif = [ 'ip=192.168.1.12', 'bridge=xenbr1' ] par vif = [ 'ip=192.168.1.12']
La prise en compte du mode nattage est effectuér dans le fichier
/etc/xen/xend-config.sxp
dont il suffit de
décommenter les lignes :
(network-script network-nat) (vif-script vif-nat)
de commenter dans ce même fichier :
(vif-script vif-bridge)
et enfin modifier la ligne comme suit:
#(network-script 'network-bridge netdev=eth1') (network-script 'network-nat netdev=eth1')
Xen "travaillera" en mode Nat. Ensuite il lui faut quelques règles
'
iptables
' qui seront "montées" lors de
l'initialisation de la carte réseau. Pour mémoire lorsque la carte est
activée les scripts présents dans
/etc/network/if-up.d/
sont exécutées (du moins sur
Debian). Il n'y a donc qu'a y ajouter le script
'
xen.sh
" comme suit:
# #!/bin/sh echo "1" > /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -j MASQUERADE
Nota: Toutes les machines virtuelles devront dans ce cas posséder une adresse en 192.168.0.0/16
Rendre ce script exécutable:
chmod +x /etc/network/if-up.d/xen.sh
Encore un dernier détail, si nous souhaitons prendre la main sur une
service quelconque d'une machione virtuelle, il nous faut mettre en oeuvre
la redirection de port. Si par exemple je souhaite accéder au service ssh
de la machine test (192.168.1.12) je dois alors ajouter au fichier
/etc/network/if-up.d/xen.sh
la règle suivante:
iptables -A PREROUTING -t nat -p tcp -i eth1 --dport 22 -j DNAT --to 192.168.1.12:22
Qui nous indique de redirigé les accès en ssh sur l'interface eth1 (et non eth0 pour ce qui me concerne comme indiqué précédement) au serveur Xen seront redirigés sur le ssh de la machine virtuelle test. Attention si le service ssh est utilisé sur le serveur Xen il nous faudra modifier le --dport (en 2222 par exemple). ensuite un ssh -p 2222 Serveur_Xen nous loguera en ssh sur la machine test :)
Et ça fonctionne nickel bien que pourtant si je fais un ifconfig sur le domaine0 :
xen0:~# ifconfig eth1 Lien encap:Ethernet HWaddr 00:1A:80:58:86:16 inet adr:10.33.105.105 Bcast:10.33.255.255 Masque:255.255.0.0 adr inet6: fe80::21a:80ff:fe58:8616/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6773 errors:0 dropped:0 overruns:0 frame:0 TX packets:1030 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:759628 (741.8 KiB) TX bytes:149012 (145.5 KiB) Interruption:18 lo Lien encap:Boucle locale inet adr:127.0.0.1 Masque:255.0.0.0 adr inet6: ::1/128 Scope:Hôte UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:58 errors:0 dropped:0 overruns:0 frame:0 TX packets:58 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:7696 (7.5 KiB) TX bytes:7696 (7.5 KiB) vif1.0 Lien encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF inet adr:192.168.1.139 Bcast:0.0.0.0 Masque:255.255.255.255 adr inet6: fe80::fcff:ffff:feff:ffff/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:55 errors:0 dropped:0 overruns:0 frame:0 TX packets:64 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:7347 (7.1 KiB) TX bytes:7657 (7.4 KiB)
je n'ai pas de 192.168.1.12, dom0 vois donc le 192.168.1.12 en interne et redirige vers cette IP. C'est le routage qui redirige convenablement cette adresse:
xen0:~# route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.1.12 0.0.0.0 255.255.255.255 UH 0 0 0 vif1.0 10.33.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 0.0.0.0 10.33.1.1 0.0.0.0 UG 0 0 0 eth1
On constate que le 192.168.1.12 est redirigé vers l'interface vif1.0
Il existe une troisième et dernière méthodes d'accès aux machines virtuelles appelée 'Routed Network'. Dans ce cas je dois dire que je n'ai pas réussi à atteindre les machines :(
En conclusion, la méthode la plus simple est celle du bridge mais elle nous oblige à la reconfiguration des interfaces lors de l'utilisation du portable sur divers réseaux. La méthode d'accès au machines virtuelles via le nattage ne m'a pas non plus convainu, dû notamement à la lourdeur d'accès aux services. §La dernière méthode je l'oublie ... pour l'instant.
Je vais donc me rabattre vers une méthode pas très satisfaisante à mon gout mais qui aura le mérite de fonctionner en fonction de l'environnement : la création de fichiers de configuration des machines en mode bridge spécifique à l'endroit où je me trouve (winxp-home, winxp-work, winxp-dhcp, test-home, test-work ... )
Pour plus d'infos sur les configurations réseaux de Xen voir les documents http://wiki.xensource.com/xenwiki/XenNetworking et http://doc.fedora-fr.org/wiki/Xen_et_le_r%C3%A9seau ou encore http://wiki.kartbuilding.net/index.php/Xen_Networking
Les processeurs récents supportent la virtualisation ce qui permet de booter sur un OS sans avoir à le modifier, genre un windows. Ainsi le VAIO en ma possession comporte un processor Intel T7250, cette fonctionnonalité peut être vérifier avec la commande :
egrep '^flags.*(vmx|svm)' /proc/cpuinfo flags : fpu de tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
Le flag ' vmx ' d'Intel le confirme :) (svm pour AMD)
Maintenant voyons voir avec XEN en utilisant la commande :
xm dmesg | grep VMX (XEN) CPU0: VMX disabled by BIOS. (XEN) VMX: failed to initialise.
Non c'est pas pôssible !!! %@$ Sony l'a dévalider dans son bios ( R0122S5 bios )et pas un menu pour l'activer !!!
Cherche et recherche sur le Net et j'atterri sur ça : http://forum.notebookreview.com/showthread.php?t=189228&page=8
I have successfully patch Sony Vaio Bios Version: R0122S5. Instead of trial and error with symcmos ( not productive ), i patched the BIOS directly. now the BIOS comes in default with VT-enabled. I'm using the new BIOS myself for my Sony Vaio SZ7. I have attached the BIOS for your download. http://rapidshare.com/files/10880912..._BIOS.rar.html Double Click WinPhlash.exe and load the R0122S5_VT_PATCHED.WPH BIOS. now, sit back and wait.. after it completes, it will restart & shutdown. Power up, Go to CMOS, Remember to "Restore all settings to default" in the cmos. it will clear the old NVRAM Settings and use the new VT-enabled option.
Chaud, chaud c'est pas le même VAIO mais le même bios ... tant pis je me lance ...
Flashage comme indiqué dans l'archive, reboot, reentre dans le bios pour prise en compte du nouveau bios, reboot a nouveau et ...
xm dmesg | grep VMX (XEN) HVM: VMX enabled
YES :) non mais !
Au cas où le lien disparaitrait j'ai sauvegardé cette archive ici : http://www.catapulse.org/static/files/articles/system/vaio/R0122S5_PATCH_BIOS.rar
Bon maintenant je dois être capable de virtualiser un win$
Le principe est de créer un coquille vide et de booter sur une image iso d'installation de winxp. Oui mais comment disposer de l'interface graphique d'installation si X (xorg) n'est pas installé sur la machine ? : via VNC
Dabord copier l'image du CDROM
dd if=/dev/cdrom of=/vserver/iso/winxp.iso
mkdir -p /vserver/domains/winxp dd if=/dev/zero of=/vserver/domains/winxp/WinXP.img bs=1M count=4096
Ensuite
création d'un fichier de configuration
/etc/xen/winxp.cfg
:
kernel = "/usr/lib/xen-3.2-1/boot/hvmloader" builder='hvm' memory = '256' name = 'Winxp' disk = [ 'file:/vserver/domains/winxp/WinXP.img,ioemu:hda,w','file:/vserver/iso/winxp.iso,ioemu:hdc:cdrom,r' ] vif = [ 'type=ioemu, bridge=xenbr1' ] device_model = '/usr/lib/xen-default/bin/qemu-dm' boot='d' vnc=1 vncviewer=1 sdl=0
Attention j'ai utilisé xenbr1 comme expliqué précédement ! De plus pour la version 3.2 de Xen utiliser 'tap:aio:/...' en remplacement de 'file:/...'
De plus pour que VNC puisse être utilisé à partir d'une machine
distante il est nécessaire d'ajouter au fichier
/etc/xen/xend-config.sxp
la ligne suivante et
redémarrer
xend
.
(vnc-listen '0.0.0.0')
Ensuite on boot sur notre iso avec la commande suiivante:
xm create winxp.cfg Using config file "./winxp.cfg". VNC= 1 Started domain Winxp
Reste plus qu'à installer winxp via
vncviewer. Lorsque l'installation est terminée et pour éviter que
l'installation ne redémarre modifier dans le fichier de configuration de
la machine virtuelle (
/etc/xen/winxp.cfg
) le media
de boot qui devient :
boot='c'
.
Autre détail qui a son importance, lorsque l'on boote sous Winxp le
clavier est toujours Querty. Pour la prise en charge du clavier azerty par
défaut il faut aussi ajouter la ligne suivante au fichier
/etc/xen/xend-config.sxp
:
(keymap 'fr')
Et pour finir il y a aussi le problème de décalage de la souris ( entre son pointeur et son affichage). J'ai bien trouvé une option censé le résoudre mais ce n'est pas du tout concluant pour moi :( Peut être faut-il utiliser cette option lors de l'installation ?
Ajouter usbdevice='tablet' au fichier de configuration de la machine virtuelle. Encore une chose, avec un serveur X installé ne pas hésiter via SDL ( sdl=1 )
Pour éviter d'avoir à démarrer manuellement chacune des machines
virtuelles il suffit de créer le répertoire
/etc/xen/auto
et d'y lier les fichiers de
configuration de nos machines :
mkdir /etc/xen/auto ln -s /etc/xen/test.cfg /etc/xen/auto ln -s /etc/xen/winxp.cfg /etc/xen/auto
Lors des précédents paragraphes les machines virtuelles ne sont que
des images de système de fichiers copiées dans
/vserver/domains/
ce qui est ni performant, ni
sécurisé. En effet si le domaine0 devient inacessible pour une raison
quelconque, toutes les machines virtuelles sont perdues. De plus le fait
d'utiliser une image plutot qu'un système de fichier ralenti forcément les
écritures (nombre de couches à traverser pour accéder aux données
).
Dans ce paragraphe nous verrons donc comment stocker les machines virtuelles sur un système de fichiers séparé. Rien de plus simple il nous suffit juste de modifier le champ ' disk ' du fichier de configuration de la machine virtuelle.
ainsi pour l'installation d'un OS sur
/dev/sda
avec un boot sur le vrai CDROM nous aurons:
disk = [ 'phy:/dev/sda,hda,w', 'phy:/dev/cdrom,hdc:cdrom,r' ]
/dev/sda sera connu en hda dans la machine virtuelle, le cdrom sera quant à lui connu en tant que hdc.
Si nous reprenons l'exemple de l'installation de winxp non plus dans
une image mais sur
/dev/sda
, le choix de la partition
se faisant au moment de l'installation, nous aurons notre fichier
/etc/xen/winxp.cfg
égal à :
kernel = "/usr/lib/xen-3.2-1/boot/hvmloader" builder = 'hvm' memory = 512 shadow_memory = 8 name = "winxp" vcpus = 1 vif = [ 'type=ioemu, bridge=xenbr1' ] disk = [ 'phy:/dev/sda,hda,w', 'phy:/dev/cdrom,hdc:cdrom,r' ] device_model = '/usr/lib/xen-3.2-1/bin/qemu-dm' boot='d' sdl=0 vnc=1 vncconsole=1 vncpasswd='' stdvga=0 serial='pty' usbdevice='tablet'
Après l'installation modification de boot='d' en boot='c' . => reboot
Le boot se fait sur le MBR de la machine VAIO, c'est à dire que j'arrive sur le menu Grub :( je dois donc choisir 'windows XP' pour y accéder sinon au bout du délais fixé dans grub je vais booter sur le choix par défaut qui n'est autre que le noyau XEN. En gros je vais déamarrer XEN à nouveau mais dans une machine virtuelle :( Pas bon du tout ça :( => quelqu'un a-t-il une idée pour booter sur la partition de windows sans passer par le MBR ?
Sinon voilà notre winxp sur partititon est accessible via VNC :)
Il existe de nombreuses autres méthode de stockage des données : fichiers (déjà vu), disques, partitions physiques, SAN, volumes (LVM) ou encore images QCow (Qemu Copy-on-Write : en gros une même image est partagée par plusieurs machines virtuelles)
Vraiment décu par les performances de winxp virtualisé je teste tout dabord les accès disques. Téléchargement de HD_Speed je mesure pourtant un débit disque de 45MB/s mais dès que je travaille sur la machine physique ( un find / bien brutal ) je tombe à moins de 2Mo :( Ce qui semble un peu logique vu que je travaille sur le même disque.
Je fais ici seulement une lecture du débit disque et mesure les temps de démarrage/arrêt sous windows
...
Je viens d'upgrader Xen en 3.2, winxp est depuis nettement plus réactif :)
Quelques mesures:
Tableau 1. Performances
Temps démarrage/arrêt | HD (lecture) | |
---|---|---|
Dom0 Xen 3.2 Ubuntu 8.04 | hdparm -tT /dev/sda : 43.5 MB/sec | |
DomU Winxp sur /dev/sda1 - 512Mo | 65s / 10s | HD_speed : 42 MB |
DomU Winxp sur image - 512 Mo | 40s / 10s | HD_speed : 45 MB |
Winxp en natif sur /dev/sda1 - 2Go | 40s / 10s | HD_speed : 45 MB |
Les tests effectués sous Debian Testing et Xen3.3 ont retournés des "performances" équivalentes. Elles sont donc très proches de celle de Windows en natif.
Pour ce qui est de la reconnaissance du matériel ça fera l'objet d'un autre chapitre ...
Tout ça c'est bien beau pour un serveur mais pour un portable il nécessaire de disposer d'une interface graphique. L'idée de départ étant de disposer d'un simple serveur X sur lequel j'aurai exporté l'interface graphique des machines virtuelles. Je vais débuter par une simple installation de Gnome sur le serveur Xen sur lequel j'exporterai les applications X (export DISPLAY ou SSH Forwarding) et Windows (VNC). Le problème avec ce type d'installation est de ne plus pouvoir profiter du système d'équilibrage de charge de Xen ( aujourdhui j'en suis beaucoup moins sûr). Par contre cela permet de ne pas avoir à démarrer un second Linux virtuel et donc l'un dans l'autre ...
Sur la machine physique Xen :
apt-get install xserver-xorg-video-vesa xfonts-100dpi xfonts-75dpi xfonts-base build-essential linux-source-2.6.18
Je peux démarrer un serveur X mais celui-ci n'est pas à l'écoute du
port 6000, du moins sur Debian car il ets lancé avec l'option --nolisten.
Pour modifier cela il suffit de supprimer cette option dans le fichier
/etc/X11/xinit/xserverrc
. J'y ajoute aussi l'option
-ac pour m'éviter les restrictions d'accès à X :
exec /usr/bin/X11/X -dpi 100 -ac
Bon voilà nous avons un serveur X à l'écoute (certes très mal configuré en terme de sécurité). Au tour de la machine test :
xm console test apt-get install xterm export DISPLAY=IP_machine_Xen:0 xterm
Et Ô merveille l'xterm de la machine virtuelle s'affiche sur le serveur X de la machine Xen.
Allons un peu plus loin en installant un environ gniome complet sur la machine virtuelle de test :
tasksel => environnement graphique
Plutôt que d'exécuter xterm je lance cette fois ci ' gnome-session ' ... Cool l'environement graphique s'exécute sur la machine physique Xen :)
Reste plus qu'a régler le petit problème de sécurité du serveur X ( -ac) et le tour est joué.
Une autre solution serait d'exécuter l'export non pas via le DISPLAY mais via ssh et son mode X11 Forwarding.
Si maintenant j'installe vncviewer, qu'il s'exécute lors du démarrage du serveur X et que je démarre le serveur virtuel windows, j'ai un environnement Linux et windows parallèlisé dont je peux équilibrer la charge au travers des outils fournis avec Xen :)
Après ces quelques expérimentations j'ai décidé de tout reprendre de zéro, le choix c'est porté sur sur une installation d'un système Ubuntu sur le Dom0 et de la virtualisation d'un windows sur partition physique. Le système de fichier vserver est réservé pour tester divers OS. Le partitionnement de la machine est le suivant:
-
/win (primaire) en Fat32: 20Go
-
/ (primaire) en ext3 : 60 Go
-
/boot (primaire) en ext3 : 150Mo
-
swap (logique) : 2Go
-
Inutilisé (logique) en ext3 : 5Go
-
/vserver (logique) en ext3 : le reste du disque
- L' installation du système de base a été réalisé avec un CDROM Ubuntu Hardy qui comprend tout ce qu'il faut pour construire et expérimenter Xen (Version 3.3 impérative)
- Créaton des packages de Xen 3.3:
apt-get install prevu DISTRO=hardy prevu-init wget https://launchpad.net/ubuntu/hardy/+source/xen-3.3/3.3.0-1ubuntu7~hardy1/+files/xen-3.3_3.3.0-1ubuntu7~hardy1.diff.gz wget https://launchpad.net/ubuntu/hardy/+source/xen-3.3/3.3.0-1ubuntu7~hardy1/+files/xen-3.3_3.3.0.orig.tar.gz wget https://launchpad.net/ubuntu/hardy/+source/xen-3.3/3.3.0-1ubuntu7~hardy1/+files/xen-3.3_3.3.0-1ubuntu7~hardy1.dsc /usr/bin/prevu xen-3.3_3.3.0-1ubuntu7~hardy1.dsc cd /var/cache/prevu/hardy-debs dpkg -i *.deb
- Reboot sur le noyau Xen
if ifconfig doit impérativement retournée eth0, lo ,peth0, xenbr0.
- Configuration de Xen:
Le fichier de configuration principal de xen
/etc/xen/xend-config.sxp
:
# -*- sh -*- # # Xend configuration file. # (network-script network-bridge) (vif-script vif-bridge) (dom0-min-mem 196) (dom0-cpus 0) (enable-dump no) (vnc-listen '0.0.0.0') (keymap 'fr')
Nota: J'ai supprimé le netdev=xenbr1 car ubuntu assigne eth0 à l'interface principale Ethernet
Le fichier de configuration pour la création automatique des image
Linux
/etc/xen-tools/xen-tools.conf
:
# # /etc/xen-tools/xen-tools.conf # dir = /home/xen size = 4Gb # Disk image size. memory = 128Mb # Memory size swap = 128Mb # Swap size fs = ext3 # use the EXT3 filesystem for the disk image. dist = etch # Default distribution to install. image = sparse # Specify sparse vs. full disk images. # gateway = 192.168.1.1 # netmask = 255.255.255.0 dhcp = 1 # passwd = 1 kernel = /boot/vmlinuz-2.6.18-6-xen-vserver-686 initrd = /boot/initrd.img-2.6.18-6-xen-vserver-686 arch=i386 mirror = http://ftp.fr.debian.org/debian/
Après reboot , un ifconfig me retourne les interfaces eth1, lo, peth1, vif0.1, xenbr1.
Le système windows est déjà installé sur
/dev/sda1
, il sera conservé et virtualisé. Son
fichier de configuration
/etc/xen/winxp.cfg
:
kernel = "/usr/lib/xen/boot/hvmloader" builder='hvm' memory = '512' name = 'winxp' #disk = [ 'tap:aio:/vserver/domains/winxp/WinXP.img,ioemu:hda,w','tap:aio:/tmp/winxp.iso,ioemu:hdc:cdrom,r' ] disk = [ 'phy:/dev/sda,hda,w', 'phy:/dev/cdrom,hdc:cdrom,r' ] vif = [ 'type=ioemu, bridge=xenbr0' ] device_model = '/usr/lib/xen/bin/qemu-dm' boot='c' sdl=1 vnc=0 #vncviewer=0 #vncpasswd='' stdvga=0 serial='pty' usbdevice='tablet'
Attention lorsque la machine virtuelle winxp boote, elle le fait sur /dev/sda et donc il est nécessaire que grub démarre par défaut sur le windows !
C'est tout de même du lourd, tout ça pour disposer d'une machine virtuelle qui tourne sous windows ... et puis je me suis tourné vers KVM qui est sans comparaison de mise en oeuvre, de plus il approche les mesures effectuées avec Xen.
KVM est constitué de deux composants: Un driver noyau gérant le matériel virtualisé et un emulateur de PC. Très ressemblant à qemu tout ça, kvm en est une copie modifiée. ICI sont fait des tests comparatifs qemu vs kvm.
apt-get install kvm qemu modprobe kvm-intel # ou kvm-amd
Soit on créé un disque image vide:
qemu-img create disk.img 4G
On utilise le format qemu compatible avec kvm.
Et on démarre sur l'image :
kvm -hda disk.img -m 512
ou sur un disque (attention sur le mbr )
kvm -hda /dev/sda -m 512 -net nic -net tap,ifname=tap11 -usb -usbdevice tablet -localtime # ou plus complet avec un pont et l'émulation tablet (pour windows) kvm -hda /dev/sda -m 512 -net nic -net tap,ifname=tap11 -usb -usbdevice tablet -localtime
Bon je vais maintenant en rester là, le portable sous Debian Lenny accompagné d'un kvm pour la virtualisation du windows sur partition ... et puis peut être une autre petite partition sous Ubuntu pour l'inspiration :)
Quelques trucs ou configurations spécifiques au vaio ... ( pauvre pour l'instant )
Le premier problème apparait bien vite : les ventilateurs ou du moins celui du CPU ne s'arrète pour ainsi dire pas :(
Je cherche du coté de lm-sensors, pas moyen d'en venir à bout :( Et puis je tombe sur un petit soft qui semble spécialement développé dans ce but. Attention cependant à ne pas fixer de température MAX trop élévé. Dans le script ci-dessous je l'ai paramétré à 65° ( Pour vérifier la température du système exécuter : sensors )
wget http://www.taimila.com/files/fansilencer-v0.1.tar.gz tar xzf wget fansilencer-v0.1.tar.gz cd fansilencer && make ./fansilencer Sony Vaio - Fan silencer v0.1 ----------------------------- Usage: ./fansilencer [MAX TEMPERATURE] [ACTIVE TEMPERATURE] Fan activates when temperature reaches given MAX TEMPERATURE and runs until temperature is dropped down to ACTIVE TEMPERATURE. WARNING! DO NOT USE TOO HIGH MAX TEMPERATURE. THIS MIGHT DAMAGE YOUR SYSTEM OR BRAKE IT COMPLETELY! USE AT YOUR OWN RISK ./fansilencer 55 45
Le silence est d'or :)
Plus qu'à copier le binaire dans
/usr/sbin
et
de faire un petit daemon qui l'exécutera au démarrage (
/etc/init.d/fansilencer
):
#! /bin/sh # /etc/init.d/fansilencer: start the fansilencer daemon. MAX_TEMP=
Commentaires: