Catapulse

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:

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 :

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:

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:

- 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 )

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

#! /bin/sh
# /etc/init.d/fansilencer: start the fansilencer daemon.

MAX_TEMP=

   


Commentaires:

 

tomlechat

  15/9/2009 - 16h49

 


J'ai rien compris, mais j'aimerai bien avoir le niveau pour comprendre tout ca !
 
Salutations


  
 
 

admin

  16/9/2009 - 13h39

 


Au final il y a bien plus simple : ne pas installer Xen sur Vaio (cause bridage BIOS, la bidouille que j'ai dû effectuer pour le flasher m'a donner quelques sueurs). Aujourdhui j'utilise VirualBox, bien plus conviviale.


  
 
 

PPROM

  29/3/2010 - 9h0

 


Bonjour, 
 
J ai pas mal de retard pour le post mais ce tuto est d actualité pour moi.
 
Je suis sous Debian Lenny et Kernel 2.6.26-2-xen-686 et il n y a rien à faire impossible de créer une vm ( debootstrap, copy..) meme avec l aide de Virt-manager il ne me trouve pas les fichiers installables ( FTP, HTTP, NFS, Locaux..).
 
Je commence serieusement à douter de la fiablité du produit...
 
++
 
PPROM


  
 
 

admin

  31/3/2010 - 17h17

 


De quel produit ? Xen ou Vaio ?
 
De Xen, étrange il y a quand même pas mal de monde qui l'utilise non ? Mais si c'est du Vaio alors je confirme, on ne m'aura plus avec cette mer^H^Hmarque : tout est bridé, il n'y a qu'à regarger le bios, on te laisse tout juste le droit de modifier l'heure :(


  
 







Add_a_comment

Author_name



Author_email



Author_site




Comment