Outils pour utilisateurs

Outils du site


serveur_xen
:!: Xen 4 et Squeeze sont juste survolé ici…

Xen

Introduction

On va mettre en place un noyau pouvant creer des systemes virtuels:
On parle de “Dom0” pour le systeme qui héberge.
On parle de “DomU” pour les systemes hébergés, et aussi de: Virtual Machine (VM)

Le système s'appuie sur Xen et Debian.
Les systémes virtualisés sont aisement installable s'ils sont prévu (patché) pour fonctionner avec Xen.

A contrario, pour “virtualiser” des systèmes non patchés , genre Windowz 2k ou XP, il faudra utiliser Xen sur un processeur supportant le “VT” (Virtual Technologie), anciennement nommé “Vanderpool”.

Ce n'est pas le cas d'un AMD Athlon 3400+ … :-\
Mais c'est le cas d'un Intel DualCore 6320 :-D

Liste des processeurs Intel supportant le VT.

Processeurs selon leurs performances

Xen 32 bits qui reconnait plus de de 3.3 GB et même plus de 4 GB !

Live-CD

Un live CD existe pour tester ?

C'est Xenoppix !?

:!: Marche Pas … grrrrr

Creer le Dom0 sous Debian

On a fraichement installer une Debian Etch, avec une partition “/boot” de 256 M, quelques centaines de Giga sur en volume “LVM” , et une dernière partion non alloué de 15 Go…

Au boot, ce système ne connait rien de Xen.

Prérequis

  • Il faut booter avec “grub” (et pas lilo)
  • Debian Etch (stable) pour les packages

Ici, on ne va pas compiler Xen.

Packages

On installe les paquets (il y a plusieurs versions: on choisirat les meilleures!) :

# aptitude install linux-modules-2.6.18-6-xen-686 linux-image-2.6.18-6-xen-686 xen-linux-system-2.6.18-6-xen-686 

En fait, ca installe bien d'autres choses… Voyez ce qu'il y a au final:

$ dpkg -l | grep xen
ii  libc6-xen                              2.3.6.ds1-13etch4                    GNU C Library: Shared libraries [Xen version
ii  linux-image-2.6.18-6-xen-686           2.6.18.dfsg.1-17etch1                Linux 2.6.18 image on i686
ii  linux-image-2.6.18-6-xen-vserver-686   2.6.18.dfsg.1-17etch1                Linux 2.6.18 image on i686
ii  linux-modules-2.6.18-6-xen-686         2.6.18.dfsg.1-17etch1                Linux 2.6.18 modules on i686
ii  linux-modules-2.6.18-6-xen-vserver-686 2.6.18.dfsg.1-17etch1                Linux 2.6.18 modules on i686
ii  xen-hypervisor-3.0.3-1-i386-pae        3.0.3-0-4                            The Xen Hypervisor on i386 with pae
ii  xen-linux-system-2.6.18-6-xen-686      2.6.18.dfsg.1-17etch1                XEN system with Linux 2.6.18 image on i686
ii  xen-utils-3.0.3-1                      3.0.3-0-4                            XEN administrative tools
ii  xen-utils-common                       3.0.3-0-2                            XEN administrative tools - common files

(Compléter votre installation de package si nécessaire…)
Surtout bien vérifier qu'on a “libc6-xen”.

:!: PAE signifie que Xen pourra (en theorie) utiliser plus de 4GB de RAM… En pratique, je ne sais pas ce que ça vaut.

Ne pas oublier les packages réseaux:

# apt-get install bridge-utils iproute

Dont on aura vivement besoin ultérieurement…

Pour executer des systèmes non-Xen (genre Windowz) il faut aussi installer “xen-ioemu” :

# apt-get install xen-ioemu-3.0.3-1

Et enfin:

# mv /lib/tls /lib/tls.disabled

Je ne sais pas trop pourquoi, mais c'est mieux de faire ça.

On pourra ajouter des scriptes pour simplifier la configuration:

# aptitude install xen-tools

Reboot

On verifie que l'OS est prêt a booter sous Xen … “/boot/grub/menu.lst” .

On “reboot” sur le système XEN !

1er Boot

Nous voila sous le “Dom0” :

$ uname -a
Linux xendeb 2.6.18-6-xen-686 #1 SMP Wed Jan 23 07:51:35 UTC 2008 i686 GNU/Linux

Vous avez au moins 2 nouveaux scripts dans “/etc/init.d/” :

$ ls /etc/init.d/ | grep xen
xend
xendomains

Vous avez un nouveau répertoire “/etc/xen” :

$ ls -la /etc/xen/
drwxr-xr-x   2 root root 4096 2008-02-06 18:18 auto
drwxr-xr-x   2 root root 4096 2008-02-06 18:11 scripts
-rw-r--r--   1 root root 4645 2008-02-06 18:25 xend-config.sxp
-rw-r--r--   1 root root 1256 2006-11-13 15:13 xend-pci-permissive.sxp
-rw-r--r--   1 root root 4129 2006-11-13 15:13 xend-pci-quirks.sxp

Et de nouveaux jeux de commandes, par exemple:

# xm list
Name                                      ID Mem(MiB) VCPUs State   Time(s)
Domain-0                                   0     2000     4 r-----    109.0

Ce qui confirme le “Dom0” …

Bridge

Il faut configurer le réseau afin que le Machine Virtuel puisse avoir un accés au réseau, sans restriction de la part du “Dom0”.

Methode Xen

ATTENTION ⇒ Cette méthode m'a pété mon réseau ⇐

Il s'agit d'abord de modifier le fichier de config “/etc/xen/xend-config.sxp” pour avoir:

... <snip> ...
(network-script network-bridge)
... <snip> ...
# (network-script network-dummy)
... <snip> ...

C'est à dire: virer un commentaire quelque part, et en mettre un autre un peu plus loin.

Et puis:

# /etc/init.d/xend restart

:!: Si vous ne perdez pas le contrôle de votre machine, c'est que ça a fonctionné.
Ce ne fut pas le cas pour moi !

Si ca fonctionne, un bridge fonctionnel nommé “xenbr0” est créé.

On pourra aussi essayer en ajoutant un commentaire là:

#(vif-script vif-bridge)

Et en precisant les interfaces:

(network-script 'network-bridge bridge=br-xen netdev=eth0')

Quand ça marche, ca ressemble à ça:

# brctl show
bridge name     bridge id               STP enabled     interfaces
br-xen          8000.feffffffffff       no              vif0.0
                                                        peth0

Et quand il y a un DomU (avec l'id '4'):

# brctl show
bridge name     bridge id               STP enabled     interfaces
br-xen          8000.feffffffffff       no              vif0.0
                                                        peth0
                                                        vif4.0

Methode Debian

:!: Il s'avère qu'il y a toujours un problème… grrrr

Lien: http://julien.danjou.info/xen.html

Cette méthode “Debian” a fonctionné pour moi, et elle me parait bien plus lipide. (je n'ai pas une tonne d'interfaces bizarres créées…)

Editer “/etc/network/interfaces” et bridgé votre interface réseau comme cela:

auto eth0
iface eth0 inet manual

auto br-xen
iface br-xen inet static
      address <IP_ADDRESS>
      netmask <NETMASK>
      gateway <GATEWAY>
      bridge_ports eth0
      # optional
      bridge_stp off
      bridge_maxwait 0

ou aussi, sans IP par defaut:

auto br-xen
iface br-xen inet manual
      bridge_ports eth0
      bridge_stp off
      bridge_maxwait 0

Adapté selon vos besoin…

Un petit:

# /etc/init.d/networking restart

Et aprés une quinzaine de secondes de lag …
Voila, l'interface eth0 parait toujours la même, et pourtant: elle bridge !

Le bridge s'appelle “br-xen” …

Dans le fichier /etc/xen/xend-config.sxp, faire en sorte d'avoir (pour la partie réseau):

...
(network-script network-dummy)
...
(vif-script vif-bridge)
...

Bien mettre en commentaire la ligne “(network-script network-bridge)” ou equivalent.

Tips

tracking

Liens:

Désactiver le “tracking” sur le bridge…

Sinon /proc/net/ip_conntrack se peuple de suivit de tout les DomU !!!!!

Dans par exemple: /etc/sysctl.d/local.conf

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

Ajouter aussi dans /etc/modules

# TJ ----------
bridge
# -------------

Sinon, au moment de l'execution de “procps” qui applique les regles dans “/etc/sysctl.d/*” , ces valeurs ci-dessus ne pourraient être appliqués.

Methode en production

$ cat /etc/xen/xend-config.sxp | grep -v "^#" | grep -v "^$"
(network-script 'network-bridge netdev=eth0 bridge=xenbr0')
(network-script network-dummy)
(vif-script vif-bridge)
(dom0-min-mem 1024)
(dom0-cpus 0)
$ cat /etc/network/interfaces | grep -v "^#" | grep -v "^$"
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
      address <IP>
      netmask <NETMASK>
      network <NETWORK>
      broadcast <BROADCAST>
      gateway <GATEWAY>

ARP et MAC

Dans /etc/sysctl.conf , faire en sorte que les interfaces ne repondent qu'au requetes ARP concernant leur propre interface.

# TJ -------
net.ipv4.conf.default.arp_ignore=1

(Sinon, sur un même reseau, plusieurs interfaces peuvent revendiquer l'IP recherché)

Configuration

Des exemples dans les packages:

# cp /usr/share/doc/xen-utils-common/examples/xmexample1.gz .
# gunzip xmexample1.gz

Et regarder:

# vi xmexample1

Exemples

Debian

#
#  Configuration file for the Xen instance hostlvm, created on
# Sun Feb  3 03:11:23 2008.
#

#
#  Kernel + memory size
#
kernel  = '/boot/vmlinuz-2.6.18-6-xen-686'
ramdisk = '/boot/initrd.img-2.6.18-6-xen-686'

memory  = '128'

#
#  Disk device(s).
#
root    = '/dev/sda1 ro'

disk    = [ 'phy:mainvol/hostlvm-disk,sda1,w', 'phy:mainvol/hostlvm-swap,sda2,w' ]

#
#  Hostname
#
name    = 'hostlvm'
#
#  Networking
#
dhcp = 'dhcp'
vif  = [ '' ]

#
#  Behaviour
#
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

Windowz

Il faut intercaler la couche “ioemu” …

kernel = "/usr/lib/xen-default/boot/hvmloader"
builder='hvm'
memory = '512'
name = 'Win2000'
#vcpus = 2
#disk = [ 'file:/mnt/media/data/xen/domains/win2k/win2k.img,ioemu:hda,w','file:/home/thierry/iso/Windows_2000_EN.iso,ioemu:hdc:cdrom,r' ]
#disk = [ 'phy:/dev/lvm0/win2k,ioemu:hda,w','file:/home/thierry/iso/Windows_2000_EN.iso,ioemu:hdc:cdrom,r' ]
disk = [ 'phy:/dev/sda3,ioemu:hda,w','file:/home/thierry/iso/Windows_2000_EN.iso,ioemu:hdc:cdrom,r' ]
#dhcp = 'dhcp'
#vif  = [ '' ]
#vif = [ 'type=ioemu, bridge=xenbr0' ]
vif = [ 'type=ioemu, mac=aa:00:00:00:00:d2, bridge=br-xen' ]
device_model = '/usr/lib/xen-default/bin/qemu-dm'
memmap = '/usr/lib/xen/boot/mem-map.sxp'
#boot="d"
boot = 'c'
#sdl=1
#vnc=0
sdl = 0
vnc = 1
vncdisplay=1
vncunused=0
usb = 0
audio = 0
localtime = 1
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

Windowz detaillé

Dans ”/etc/xen/win2k.cfg”, on peut avoir:

kernel = "/usr/lib/xen-default/boot/hvmloader"
builder='hvm'
memory = '512'
name = 'Win2000'
vcpus = 2

^ 2 cpus: ne fonctionne pas, je ne sais pas pourquoi.
Continuons:

disk = [ 'phy:/dev/sda3,ioemu:hda,w','file:/home/thierry/iso/Windows_2000_EN.iso,ioemu:hdc:cdrom,r' ]

^topologie des disks…. au choix…

dhcp = 'dhcp'
#vif  = [ '' ]
vif = [ 'type=ioemu, bridge=xenbr0' ]
device_model = '/usr/lib/xen-default/bin/qemu-dm'
memmap = '/usr/lib/xen/boot/mem-map.sxp'

^mystère…

boot='d'
#boot='c'

^booter sur 'c' ou 'd'

#sdl=1
#vnc=0
sdl=0
vnc=1

^utiliser vnc pour voir l'ecran au lieu de SDL sous X

vncviewer=1
vncdisplay=1
vncunused=0
vncpasswd='toto'

^marche pas…

keymap='fr'

^marche pas encore…

usb=0
audio=0

^desactive audio et usb?

localtime=1

^cale la date sur celle de la machine (et non pas utc)

on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

^ne sait pas encore ce que c'est…

# Fin du fichier

Interface Homme/Machine

Pour le dialogue “Homme/Machine Virtuel”, on alternera joyeusement entre “X et SDL” et “VNC” …

En résumé: utilisé “X” pour installer un OS jusqu'a installation d'un serveur VNC dans la machine virtuelle.
Le VNC “natif” est prometteur mais trop buggé.

X et SDL

On pourra voir la machine dans une fenêtre sous X et c'est beau. Mais il y a 1 gros problèmes:
Il faut X … et pour optimiser les ressources, ce n'est pas l'idéal.

configuration

Dans la configuration de la virtual machine il faudra mettre:

sdl=1
vnc=0

Usage

Exemple d'utilisation, dans “kconsole” :

# xm create /etc/xen/win2k.cfg

Et voila.

VNC

C'est léger et rapide (et pas besoin de X), mais la souris se décale et le clavier est d'un mode “Qwerty-Russian” inutilisable.

Pour le problème de souris, il suffit de désactiver son “accélaration” dans les propriétés Windowz.
Pour le clavier, je n'ai pas de solution: y parait que c'est un bug qui traine…

Pour finir, il y aurait d'autres points a éclaicir sur la configuration… (pas trouvé de doc)

configuration

Dans la configuration de la virtual machine il faudra mettre:

sdl = 0
vnc = 1
vncdisplay = <NUMERO_DISPLAY>   c'est à dire 0 1 ou 2 etc...
vncunused = 0

Le port VNC sera alors: 5900+<NUMERO_DISPLAY>

Usage

Sur le “Dom0” :

# xm create /etc/xen/win2k.cfg

Sur le poste client:

$ ssh -L 5000:localhost:5900 <IP_DU_DOM0>
password: xxxx
$ 

Nous voila connecté, et on a ouvert un “tunnel”.

Toujours sur le client, on fait passer “vncviewer” par le tunnel ouvert:

$ vncviewer 0::5000

Et hop.

Solution ?

Alterner entre les 2 modes de fonctionnements:

  • Pour l'installation: préférer X
  • Pour la supervision: utiliser un serveur VNC dans la machine virtuelle

Debian en machine Virtuel

De nombreux tutoriaux explique trés bien comment faire.

En gros, il faut utiliser “debootstrap” et c'est super.

Liens:

Exemple (compliqué):

# xen-create-image --hostname=hosttest --dist etch --debootstrap --mirror ftp://ftp.fr.debian.org/debian --size 2Gb --swap 1Gb --dhcp --dir /root/xen --kernel /boot/vmlinuz-2.6.18-6-xen-686 --initrd /boot/initrd.img-2.6.18-6-xen-686

On peut remplacer ”–dir …” par ”–lvm <nom_dun_groupe_lvm>”

Demarrer:

# xm create /etc/xen/hosttest.cfg

Créer volumes

LVM

On utilise “lvm” qui semble le compagnon idéal de Xen:

# lvm
lvm> lvcreate -L 8G -n debtest-root <GROUP_NAME>
  Logical volume "debtest-root" created
lvm> lvcreate -L 512M -n debtest-swap <GROUP_NAME>
  Logical volume "debtest-swap" created
lvm> exit

On pourrait aussi utiliser “dd” ou une “vraie” partition.

Formater

# mkfs.ext3 /dev/<GROUP_NAME>/debtest-root
# mkswap /dev/<GROUP_NAME>/debtest-swap

Installer Debian

Est-ce que cela peut aider ?

$ cat /root/dbootstrap_settings
# Inserted by languagechooser.
LANG_INST="fr_FR@euro"
LANGUAGE_INST="fr_FR:fr:en_GB:en"
# Inserted by kbd-chooser.
KEYBD="i386/azerty/fr-latin9"
# inserted by prebaseconfig
SUITE="stable"

(trouver sur un disk sur le point d'être écrasé…)

debootstrap

# mkdir /mnt/domU
# mount -o loop /dev/<GROUP_NAME>/debtest-root /mnt/domU
# debootstrap etch /mnt/domU
... <snip> ...
I: Base system installed successfully.
#

Autre exemple avec debootstrap :

# debootstrap --arch i386 etch /mnt/<SOMEWHERE> ftp://ftp.fr.debian.org/debian

Et pour lenny, en incluant des packages supplémentaires:

# debootstrap --arch i386 --include=locales,udev,exim4,openssh-server lenny /mnt/domu ftp://ftp.fr.debian.org/debian

Ok!

configurer

modules

Un tuto dit de faire:
cp -dpR /lib/modules/KERNEL_VERSION-xenU /mnt/my_debian_domU/lib/modules
Mais franchement, je n'ai pas compris quoi faire !

Finalement j'ai fait:

# cp -dpR /lib/modules/2.6.18-6-xen-686 /mnt/domU/lib/modules

ou, pour Lenny 64 bit par exemple:

# cp -dpR /lib/modules/2.6.26-2-xen-amd64 /mnt/domU/lib/modules

passons…

tls

:!: pas sous Xen Lenny

Faut toujours desactiver ce truc:

# mv /mnt/domU/lib/tls /mnt/domU/lib/tls.disabled

(Il parait qu'il faut parfois le refaire, lorsqu'on a installé certains packages…)

chroot

On est pas obligé, mais pour que ce soit moins dangereux…

Entrer dans le système de fichier du nouveau système:

# chroot /mnt/domU /bin/bash

(Assurez-vous d'être bien chrooté! “# ls /home” )

reseau

hostname
# echo "debtest" > /etc/hostname
resolv.conf
# cat /etc/resolv.conf
search thierry-jaouen.local
nameserver 192.168.0.2
nameserver 212.27.40.240
nameserver 212.27.40.241
interfaces

Completer “/etc/network/interfaces” :

# cat interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
      address 192.168.1.24
      netmask 255.255.255.0
      gateway 192.168.1.1
      broadcast 192.168.1.255
sources.list
# cat sources.list
#
# deb cdrom:[Debian GNU/Linux 4.0 r3 _Etch_ - Official i386 CD Binary-1 20080217-11:50]/ etch contrib main

deb http://ftp.fr.debian.org/debian/ etch main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ etch main contrib non-free

deb http://security.debian.org/ etch/updates main contrib non-free
deb-src http://security.debian.org/ etch/updates main contrib non-free
fstab

Configurer les “mount” (fstab):

# Begin /etc/fstab
# <file system> <mount-point>   <type>   <options>                      <dump> <pass>
/dev/sda1          /             ext3      defaults,errors=remount-ro    0     0
/dev/sda2          swap          swap      sw                            0     0
proc               /proc         proc      defaults                      0     0
# End /etc/fstab

Ou bien (old-fashion, but what diff?):

# cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount-point>   <type>   <options>                      <dump> <pass>
/dev/hda1          /             ext3      defaults,errors=remount-ro    0     1
/dev/hda2          none          swap      sw                            0     0
proc               /proc         proc      defaults                      0     0
# End /etc/fstab
hosts

Completer le fichier:

# cat /etc/hosts
127.0.0.1       localhost
<IP_DU_MACHIN>  <NOM>.thierry-jaouen.local <NOM>
inittab

Commenter quelques lignes dans /etc/inittab , pour avoir:

1:2345:respawn:/sbin/getty 38400 tty1
#2:23:respawn:/sbin/getty 38400 tty2
#3:23:respawn:/sbin/getty 38400 tty3
#4:23:respawn:/sbin/getty 38400 tty4
#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6

Ca evite quelques warnings au boot.

Fin ?

D'abord, quitter le “chroot” :

# exit 

(ou Ctrl+D)

# umount /mnt/domU
# rmdir /mnt/domU

booter

creer VM

# cat /etc/xen/debtest.cfg
#########################################"

kernel  = '/boot/vmlinuz-2.6.18-6-xen-686'
ramdisk = '/boot/initrd.img-2.6.18-6-xen-686'
name = "debtest"

memory  = '128'

root    = '/dev/hda1 ro'
disk    = [ 'phy:/dev/boko/debtest-root,hda1,w', 'phy:/dev/boko/debtest-swap,hda2,w' ]

#dhcp = 'dhcp'
#vif = [ 'mac=a1:1d:09:69:32:1d, bridge=br-xen' ]
vif = [ 'bridge=br-xen' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

# EOF

Ou bien, plus recent:

#########################################"

kernel  = '/boot/vmlinuz-2.6.18-6-xen-686'
ramdisk = '/boot/initrd.img-2.6.18-6-xen-686'
name = "<NOM_DE_LA_VM>"

memory  = '128'

root    = '/dev/sda1 ro'
disk    = [ 'phy:/dev/vgraid1/debtest,sda1,w', 'phy:/dev/vgraid1/debtest_swap,sda2,w' ]

#dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:01:23:45, bridge=xenbr0' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

# EOF

demarrer VM

# xm create debtest.cfg -c le “-c” permet d'avoir immediatement une console associé au demarrage (comme si on avait branché une console!).

Achever l'installation

libc6-xen

Lien: http://www.fsugar.be/pmwiki.php?n=Admin.DebianXen

Il parait qu'il faut faire:

# apt-get update
# apt-get install libc6-xen
mot de passe pour root
# passwd
udev

Essentiel pour Lenny

# aptitude update
# aptitude install udev
1er user
# adduser thierry
# adduser thierry adm
tz

Sous Etch:

# tzconfig

Sous Lenny:

# dpkg-reconfigure tzdata
locales
# aptitude install locales
# dpkg-reconfigure locales
ssh
# aptitude install openssh-server
a la fin

rebooter le domu… c'est mieux… non ?

X

Lien: http://www.amule.org/wiki/index.php/How_to_launch_VNC_with_aMule_at_Linux_boot

Activer X11 sans devoir utiliser une “virtual machine”, ce qui est beaucoup trop lourd.

Pour cela, on va utiliser l'aptitude de “vnc” a emuler un “display” ! Ainsi, nous n'aurons pas besoin d'avoir une vraie carte video.

''/dev/mem: mmap: Bad address''

Oups:

Setting up xfonts-base (1.0.0-4) ...
/dev/mem: mmap: Bad address
warning:
 /usr/lib/X11/fonts/misc does not exist or is not a directory
  
Setting up xvnc4viewer (4.1.1+X4.3.0-21) ...

Le répertoire des “fonts” est plutot:

/etc/X11/fonts

Non ?

Déjà, on vire le message étrange: /dev/mem: mmap: Bad address .
C'est “laptop-detect” qui pose un “problème” mineur.

# aptitude purge laptop-detect

Ce qui supprime:

Suppression de tasksel ...
Suppression de tasksel-data ...

Mais on s'en fout.

installation vnc

# aptitude install vnc4server xvnc4viewer
:!: Aprés avoir choisit son gestionnaire de fenetre
$ vnc4server :0

ou

$ vnc4server

Aprés la configuration, un “X” demarre, mais c'est moche.

Il faut editer le fichier .vnc/xstartup pour avoir :

#!/bin/sh

# Uncomment the following two lines for normal desktop:
# unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
x-window-manager &

xfce4

Installation de xfce:

# aptitude install xfce4

Dans le fichier xstartup mettre:

# x-window-manager &
startxfce4 &

On met en commentaire “x-window-manager &” et on rajoute simplement “startxfce4 &” .
Et voila.

kde

Installation de kde “light”:

# aptitude install kdebase

Dans le fichier xstartup mettre:

# x-window-manager &
startkde &

Et voila.

tips

Desactiver les tentations de “kdm” de demarrer “kde”:

# echo "/bin/false" > /etc/X11/default-display-manager

Et ainsi:

# /etc/init.d/kdm start
Not starting K Display Manager (kdm); it is not the default display manager.

Windowz en machine Virtuel

Liens:

Le but est d'installer un Windowz 2k PRO:

  • on utilisera un disk “physique” en “/dev/sda3
  • on utilisera une “iso” du CD d'install.

Voir un exemple de configuration plus haut.
La première fois, on boot sur 'd', c'est a dire le CDROM. Et continuera en bootant sur 'c'.

# xm list
Name                                      ID Mem(MiB) VCPUs State   Time(s)
Domain-0                                   0     1488     4 r-----    157.9
Win2000                                    2      512     1 -b----     51.6

Erreur

# xm create win2k.cfg
Using config file "/etc/xen/win2k.cfg".
Error: HVM guest support is unavailable: is VT/AMD-V supported by your CPU and enabled in your BIOS?

Le processeur ne supporte pas le VT ? vérifions :

# xm info | grep xen_caps
xen_caps               : xen-3.0-x86_32p

Il faut plutôt avoir:

# xm info | grep xen_caps
xen_caps               : xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p

Fait iech!

Quand ca marche

C'est beau :-)
Windowz 2000, sous Xen, avec VNC

Ejecter iso du cdrom

Lien: http://www.firstserved.net/blog/2007/06/15/how-to-mount-and-eject-a-cd-rom-on-a-windows-xen-guest/

Où est le CD-ROM ?

# xm block-list <domu> --long
(768
  ((backend-id 0)
      (virtual-device 768)
      (device-type disk)
      (state 1)
      (backend /local/domain/0/backend/vbd/7/768)
  )
)
(5632
  ((backend-id 0)
      (virtual-device 5632)
      (device-type cdrom)
      (state 1)
      (backend /local/domain/0/backend/vbd/7/5632)
  )
)

Ici, “5632” est le cdrom…

“Ejecter” en detachant…

# xm block-detach <domu> 5632 -f

Attacher une nouvelle image:

# xm block-attach <domu> file:<path_to_iso> hdc:cdrom r

PV drivers

Suite a des performances assez médiocre en disk et (surtout) réseau sous Windows, me voila en quête de “PV Drivers” …

Qu'est-ce donc ? ⇒ http://wiki.xensource.com/xenwiki/XenWindowsGplPv

Pour ce que j'ai compris, des pilotes optimisés pour se débarrassé de QEMU.

La suite, une autre fois.

Tips

Interfaces Homme/Machine

SDL via SSH

On va se connecter via SSH et demarrer une machine virtuelle, mais la fenetre “SDL” apparaître sur son poste en LOCAL.
ATTENTION: il faut un bon débit entrant !

$ ssh -X <IP_SERVEUR_XEN>

Sur le serveur, devenir root:

$ su

Copier la “clé” “.Xauthority” du user courant:
(A supposé qu'on est a la racine du home user courant)

# cp .Xauthority /root/.

Tester que ca fonctionne (facultatif…):

# konsole

ou

# xterm

Demarrer la machine virtuelle:
(On suppose bien sur que “sdl=1” dans la conf)

# xm create /etc/xen/<machine_virtuelle>.cfg

Et voila !

[Ctrl]+[Alt]” pour sortir la souris de la fenêtre SDL…

:!: L'inconvenient, c'est lorsqu'on ferme la fenetre, on kill la machine virtuelle !

X

Pour certains OS, on installera un gestionnaire de fenêtre:

# aptitude install xorg xfce4 xdm xscreensaver x11vnc

Si necessaire:

# xdm start

Et rechercher la clé d'authentification X.

# ps aux | grep auth

Recupérer une information comme ça:

/usr/bin/X vt7 -dpi 100 -nolisten tcp -auth /var/lib/xdm/authdir/authfiles/A:0-XXXXXX

Et avec “x11vnc” :

# x11vnc -display :0 -password <MOT_DE_PASSE> -auth /var/lib/xdm/authdir/authfiles/A:0-XXXXXX

Prendre votre meilleur “vncviewer” et voila “xdm” :

S'identifier, et on est dans X !

Configurer le xscreensaver afin qu'il bloque simplement la session, en cas d'oubli. (mais il faudra sans doute plutot fermer la session ! voir “xdm” aussi)

Commandes

Arret

# xm list

Et en fonction de l'ID

# xm shutdown <ID>

au pire:

# xm destroy <ID>

console

# xm console <nom_de_la_machine_ou ID>

Et on arrive dans une sorte de “tty” .
Pour quitter.

[Ctrl]+[Alt]+ ]

(comme “telnet”)

config

La configuration vu par xen:

# xm list --long <domU name or ID>

Utile pour voir les commandes acceptés ou pas…

Commandes halucinantes

save

Arreter une machine virtuelle en plein vol, en sauvergardant son état (RAM & Co.):

# xm save wwwcave wwwcave.save
  1. la VM est mis en pause
  2. l'etat de la RAM et du CPU est sauve dans “le fichier”
  3. “le fichier” fait un peu plus que la taille de la RAM… hallucinant.

(Cela se produit automatiquement lorsqu'on arrete un Dom0.)

restore

Aprés un “save”, remettre une machine virtuelle en service.

# xm restore wwwcave.save

Et ca revit immédiatement.

Reseaux

Plusieurs cartes reseaux

1 carte réseau réelle, mais besoin d'en créer 2 pour une machine virtuelle.

Suffit d'ajouter dans la config, comme par exemple pour un Windows:

vif = [ 'type=ioemu, mac=00:36:6E:17:43:01, bridge=br-xen', 'type=ioemu, mac=00:36:6E:17:43:99, bridge=br-xen' ]

Verifions:

# brctl show
bridge name     bridge id               STP enabled     interfaces
br-xen          8000.001d0969312d       no              eth0
                                                        tap0
                                                        tap1
                                                        vif14.0
                                                        vif14.1

ttyS0

methode 1

Par défaut, Xen se réserve l'usage du port ttyS0 (COM1, pour les vieux).

Il faut d'abord lui interdire en ajoutant xencons=off , dans /boot/grub/menu.lst :

## Xen Linux kernel options to use with the default Xen boot option
# xenkopt=console=tty0 xencons=off

Sans oublier:

# update-grub

On voit alors que les paramètres du noyau ont été changé:

title           Xen 3.0.3-1-i386-pae / Debian GNU/Linux, kernel 2.6.18-6-xen-686
root            (hd0,0)
kernel          /xen-3.0.3-1-i386-pae.gz
module          /vmlinuz-2.6.18-6-xen-686 root=/dev/mapper/vgraid1-xencave ro console=tty0 xencons=off
module          /initrd.img-2.6.18-6-xen-686
savedefault

Il existe d'autres methodes, mais ca m'a semblé la plus “propre”.

methode 2

xencons=off n'est plus forcement d'actualité, avec Lenny notamment, ou sur des serveurs plus “pro”.

Exemple de conf de menu.lst :

...
## Xen Linux kernel options to use with the default Xen boot option
# xenkopt=console=tty0 console=hvc0
...

4gb seg fixup

solution

Lien: http://www.completefusion.com/wordpress/4gb-seg-fixup-errors-on-debian-lenny-xen-domu/

Bien verifier que le package “libc6xen” est installé, et que /lib/tls n'existe pas.

Au final, il m'a suffit d'editer le fichier /etc/ld.so.conf.d/libc6-xen.conf , et d'y ajouter (ou modifier) la ligne:

hwcap 0 nosegneg

Et puis:

# ldconfig
# reboot

Et voila.

L'upgrade du DomU de Etch à Lenny à fonctionné ! :-)

old issue

En voulant installé un “DomU” sous Lenny (mauvaise idée avec un Xen sous Etch), j'ai des tonnes de messages comme cela (dans le DomU) :

Oct 29 23:33:01 gallery kernel: 4gb seg fixup, process rsyslogd (pid 1117), cs:ip 73:b7e81522
Oct 29 23:33:15 gallery kernel: printk: 588 messages suppressed.

Aucune méthode ne permet de corriger le problème.

Ni echo “hwcap 0 nosegneg” > /etc/ld.so.conf.d/libc6-xen.conf
Ni echo “hwcap 0 nosegneg” > /etc/ld.so.conf.d/nosegneg.conf
Ni mv /lib/tls /lib/tls.disabled
Ni rien.

:!: installer libc6xen dans le DomU ?

Memory squeeze

Si on a des messages comme ca dans les logs:

kernel: xen_net: Memory squeeze in netback driver.

Alors il faut suivre les conseils ici: http://www.crucialp.com/blog/2008/08/17/xen-bug-xen_net-memory-squeeze-in-netback-driver-32bit-pae/

En gros, il faut jouer avec “dom0_mem” dans la config de grub, et dans la config xen. Dans grub, faire en sorte d'avoir:

... <snip> ...
## Xen Linux kernel options to use with the default Xen boot option
# xenkopt=console=tty0 xencons=off dom0_mem=1024
... <snip> ...
module          /vmlinuz-2.6.18-6-xen-686 root=/dev/mapper/vgraid1-xencave ro console=tty0 xencons=off dom0_mem=1024
... <snip> ...

Et puis, dans “/etc/xen/xend-config.sxp” :

... <snip> ...
# TJ -----------
#(dom0-min-mem 196)
(dom0-min-mem 1024)
# -------------
... <snip> ...

Pourquoi ? mystere…

USB pour DomU

Xen Lenny

Introduction

Lien:

Tiens, c'est encore plus simple ?

$ dmesg | grep paravirtualized
Booting paravirtualized kernel on bare hardware
:!: Lenny est stable… et alors?

upgrade Etch Lenny

On va essayé de montrer comment faire un upgrade de “Xen Etch” en “Xen Lenny” .

C'est purement expérimental, car je vais de surprise en surprise, pour ne pas dire, bug en bug.

sous Etch

reseau

:!: Mettre en place la méthode de Bridge “Debian” pour Xen.

Sinon, vous allez perdre le reseau.

MAJ

Sur le Dom0 Etch, faire les dernières mises à jour qui vont bien:

# LANG=C aptitude update
# LANG=C aptitude upgrade

Si nécessaire, rebooter.

non Xen

Rebooter sur un noyau non Xen !

Et oui: il semblerait que l'upgrade soit dangeureuse dans le Dom0.

Un fois sur ce noyau, faire une mise à jour classique, Etch vers Lenny.
En gros: Modifier /etc/apt/sources.list

:!: Laisser les repository Etch ! Car on pourra utiliser le noyau Xen Etch

… et puis:

# LANG=C aptitude update
# LANG=C aptitude install apt dpkg aptitude
# LANG=C aptitude full-upgrade

Reboot, toujours sur le noyau non Xen !

Xen 3.2

install

:!: On va procéder sans desinstaller la version de Xen Etch… Faire attention
# LANG=C aptitude update
# aptitude install xen-hypervisor-i386 xen-utils
# aptitude install linux-image-2.6-xen-686 
:!: Verifier (dans /boot/grub/menu.lst ) qu'on va booter par defaut sur ce noyau

Ceci fait, on va rebooter sous ce nouveau Dom0.

:!: Attention: vérifier bien que le reseau est configuré en mode bridge selon la méthode “Debian” expliqué plus haut !

Virer Xen Etch

Dans le cas ou vous ne gardez pas les repository Etch, et le Xen Etch:

# aptitude purge xen-hypervisor-3.0.3-1-i386-pae xen-utils-3.0.3-1 xen-linux-system-2.6.18-6-xen-686 xen-ioemu-3.0.3-1

sous Lenny et Xen 3.2

On reboot sous Lenny, et le Dom0 Xen.

Ca marche ?

Parfait.

2.6.18-6-xen-686 à 2.6.26-1-xen-686

Les “DomU” doivent toujours fonctionné, si vous avez conservé les noyau Xen-Etch.

Sinon, il faut corriger les configurations comme cela:

Arrêter le DomU, et puis, copier les modules du nouveau noyau:

# mount /dev/vg0/<LVNAME> /mnt/domu
# cp -dpR /lib/modules/2.6.26-1-xen-686 /mnt/domu/lib/modules
# umount /mnt/domu

Puis modifier la configuration du DomU pour avoir:

#kernel  = '/boot/vmlinuz-2.6.18-6-xen-686'
#ramdisk = '/boot/initrd.img-2.6.18-6-xen-686'
kernel  = '/boot/vmlinuz-2.6.26-1-xen-686'
ramdisk = '/boot/initrd.img-2.6.26-1-xen-686'

Et puis redemarrer… avec les bugs…

Les Bugs

console

Lien: http://www.mail-archive.com/debian-kernel@lists.debian.org/msg40309.html

L'accès aux DomU, via la commande “xm console domU” ou “xm create domU.cfg -c” ne fonctionne plus !!!!

Solution 1

Dans la config du DomU, ajouter ça:

extra='xencons=tty'

Mais assurez-vous d'avoir cette ligne dans /etc/inittab :

1:2345:respawn:/sbin/getty 38400 tty1

Solution 2

Dans /etc/inittab des DomU , faire en sorte d'avoir:

1:2345:respawn:/sbin/getty 38400 hvc0

( hvc0 remplace tty1 )

Extrait de /etc/inittab :

1:2345:respawn:/sbin/getty 38400 hvc0
#1:2345:respawn:/sbin/getty 38400 tty1
#2:23:respawn:/sbin/getty 38400 tty2
#3:23:respawn:/sbin/getty 38400 tty3
#4:23:respawn:/sbin/getty 38400 tty4
#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6

Mais aussi, editer /etc/securetty et ajouter:

# TJ ------
# xen console
hvc0

Sinon, 'root' ne pourra pas se connecter via la console xen !

fd

Lien: http://www.ducea.com/2009/02/18/linux-tips-bash-completion-devfd62-no-such-file-or-directory/

Etrange erreur dans un DomU Lenny:

$ ls -bash: /dev/fd/62: Aucun fichier ou répertoire de ce type
-bash: /dev/fd/60: Aucun fichier ou répertoire de ce type

D'aprés un lien, /dev/fd n'est pas créé… http://www.mail-archive.com/debian-boot@lists.debian.org/msg106513.html

Solution:

# aptitude install udev

Hu!

clocksource/0: Time went backwards

methode 1 (Obsolete?)

Lien: http://tuttodebian.blogspot.com/2008/05/xen-clocksource0-time-went-backwards.html

Et le temps s'arrete sur un DomU …

Rapidement, uniquement s'il y a ce bug, ajouter dans la config du DomU :

extra = 'clocksource=jiffies'

methode 2 (mieux?)

:!: Ca ne fonctionne pas !

Lien: http://wiki.debian.org/Xen#A.27clocksource.2BAC8-0.3ATimewentbackwards.27

Ne rien touché à la conf des DomU, mais plutot au niveau du Dom0, en apportant la modification suivante:

# echo "jiffies" > /sys/devices/system/clocksource/clocksource0/current_clocksource

Pour que ce soit en place à chaque boot, voici un petit script:

#! /bin/sh
### BEGIN INIT INFO
# Provides:          skeleton
# Required-Start:    $remote_fs
# Required-Stop:     $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Example initscript
# Description:       This file should be used to construct scripts to be
#                    placed in /etc/init.d.
### END INIT INFO

# Author: Thierry JAOUEN
#

# Do NOT "set -e"

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="My Xen Stuff"
NAME=myxen-stuff
SCRIPTNAME=/etc/init.d/$NAME

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

#
# Function that starts the daemon/service
#
do_start()
{
      # http://wiki.debian.org/Xen#A.27clocksource.2BAC8-0.3ATimewentbackwards.27

      echo "jiffies" > /sys/devices/system/clocksource/clocksource0/current_clocksource
}

#
# Function that stops the daemon/service
#
do_stop()
{
      echo "xen" > /sys/devices/system/clocksource/clocksource0/current_clocksource
}

#
# Function that sends a SIGHUP to the daemon/service
#
do_reload() {
      return 0
}

case "$1" in
  start)
      [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
      do_start
      case "$?" in
              0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
              2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
      esac
      ;;
  stop)
      [ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
      do_stop
      case "$?" in
              0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
              2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
      esac
      ;;
  #reload|force-reload)
      #
      # If do_reload() is not implemented then leave this commented out
      # and leave 'force-reload' as an alias for 'restart'.
      #
      #log_daemon_msg "Reloading $DESC" "$NAME"
      #do_reload
      #log_end_msg $?
      #;;
  restart|force-reload)
      #
      # If the "reload" option is implemented then remove the
      # 'force-reload' alias
      #
      log_daemon_msg "Restarting $DESC" "$NAME"
      do_stop
      case "$?" in
        0|1)
              do_start
              case "$?" in
                      0) log_end_msg 0 ;;
                      1) log_end_msg 1 ;; # Old process is still running
                      *) log_end_msg 1 ;; # Failed to start
              esac
              ;;
        *)
              # Failed to stop
              log_end_msg 1
              ;;
      esac
      ;;
  *)
      #echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
      echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
      exit 3
      ;;
esac

Il faut que ce script demarre *avant* les services Xen (qui va demarrer les DomU), donc:

# update-rc.d myxen-stuff defaults 19

Et puis tester.

PTY allocation request failed on channel 0

Lien: http://www.rottenbytes.info/?p=49

Surprise avec ssh. Message d'erreur !

# aptitude install udev

Je n'ai pas eu besoin d'en faire plus.

Windows

Et autres hvm ?

En fait, c'est plus simple qu'avant… les pilotes nécessaires (ioemu) sont déjà prêt à l'emploi.

Win2k

:!: Windows 2000 32 bit, fonctionne avec Xen 64 bit !

Toujours des bugs avec VNC, mais ça fonctionne.

Voici la conf:

$ cat win2k.cfg | egrep -v "^(#|$)"

kernel = "/usr/lib/xen-default/boot/hvmloader"
builder = "hvm"
memory  = "256"
disk = [ 'phy:/dev/vgraid1/win2k_test,ioemu:hda,w', 'file:/home/thierry/tmp/iso/w2k-en-sp0.iso,hdc:cdrom,r' ]
device_model = '/usr/lib/xen-default/bin/qemu-dm'
name    = 'win2k'
vif  = [ 'type=ioemu, mac=00:16:3E:FF:00:12,  bridge=xenbr0' ]

vnc=1

vnclisten="0.0.0.0"
vncpasswd="<MOT_DE_PASSE_SECRET>"
vncunused=0
vncdisplay=1

keymap= "fr"
localtime = 1

boot = "cda"

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

Ca va beaucoup mieux aprés l'installation , embedded , de VNC 4.

Win2k et 2 CPU

Suffit de rajouter dans la conf:

memory  = "384"
vcpus = 2

Lorsque Windows a demarrer, modifier le pilote ACPI:
“Device Manager” ⇒ “Computer” ⇒ “ACPI Uniprocessor” et changer (le driver) en “ACPI Multiprocessor”

Redemarrer, et puis:

# xm vcpu-list
Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
...
win2k                               22     0     0   ---      28.5 any cpu
win2k                               22     1     1   r--      23.8 any cpu
...

Bugs

VM start failed

Impossible de demarrer un DomU avec Windows 2000 … (qui marche sur un autre serveur !)

On a notamment ça dans les logs /var/log/xen/xend.log :

[2009-08-02 23:25:37 3248] DEBUG (XendDomainInfo:1618) XendDomainInfo.constructDomain
[2009-08-02 23:25:37 3248] DEBUG (balloon:132) Balloon: 2796 KiB free; need 2048; done.
[2009-08-02 23:25:37 3248] ERROR (XendDomainInfo:440) VM start failed

Aprés de multiples recherches, aucune solution.
Mais beaucoup de reference au paramètre dom0-min-mem

Et puis, un coup de chance, et si je rebootait en ajoutant dom0_mem=1024 !

Donc, dans /boot/grub/menu.lst , ma ligne “kernel” ressemble à ça:

module          /vmlinuz-2.6.26-2-xen-amd64 root=/dev/mapper/vg0-sys ro console=tty0 xencons=off dom0_mem=1024

Pour faire propre, on apporte plutot la modif à “xenkopt”, comme ça:

# xenkopt=console=tty0 xencons=off dom0_mem=1024

(Rappel: le '#' n'est pas un commentaire pour grub !)

Et puis:

# update-grub

Xen Lenny 64 bit

Voir la suite ICI

de 32 a 64 bit

La seule méthode trouvé: re-installé tout !

Toutefois, grâce à “lvm”, on va faire ça dans un nouveau volume…

64 bit

Mettre la (ou les) interfaces en mode bridge, comme vu plus haut.

Et puis:

# aptitude install xen-hypervisor xen-utils linux-image-xen-amd64

Xen Divers

Dupliquer DomU

Un domu existe et fonctionne… comment le dupliquer sans l'arreter.

A chaud

etat

Analyser le disk du DomU a dupliquer:

# lvs
...
  wwwgallery      vg0  -wi-ao   8,00G
# xm list
...
wwwgallery                                   3   256     1     -b----  23859.1

snapshot

sync DomU

Avant la “photo” du disk, on peut forcer le DomU a faire un “sync” comme cela:

# xm sysrq <domain> s

Le 's' va ordonner au kernel du DomU de faire un “sync”. On voit dans les logs:

kernel: [542823.748854] SysRq : Emergency Sync
kernel: [542823.748914] Emergency Sync complete
photo
:!: forcer aussi le DomU a faire un “sync”. Voir ci-dessus

Faire un snapshot (une photo) de l'etat du disk:

# sync && lvcreate -L 1G -s -n gall_snap /dev/vg0/wwwgallery

“sync” pour forcer un ecriture immediate des buffers sur disk.

La commande “lvcreate” :
On créé un snapshot (photo instantannée) du disk.

Un coup d'oeil:

  LV              VG   Attr   LSize   Origin     Snap%  Move Log Copy%  Convert
  gall_snap       vg0  swi-a-   1,00G wwwgallery   0,08
...
correction

On a un instantanné du disk, et vraissemblablement dans un état intermédiare sale. (ecriture en cours par exemple).

Donc on corrige le disk:

# e2fsck -f -p /dev/vg0/gall_snap
/dev/vg0/gall_snap : récupération du journal
/dev/vg0/gall_snap: Lors de l'effacement de l'i-noeud orphelin 196616 ........
...
/dev/vg0/gall_snap : 63938/1048576 fichiers (2.8% non contigus), 1441396/2097152 blocs

Et voila. Le disk est “sain”.

:!: On aurait pu faire ça aprés avoir créé le nouveau volume…

nouveaux volumes

Voir le volume d'origine:

# lvs --units k
...
  wwwgallery      vg0  -wi-ao  8388608,00K

Et créer le même:

# lvcreate -L 8388608K -n gall2 vg0
  Logical volume "gall2" created

Maintenant, on peut dupliquer le “snapshot” dans le nouveau volume:

# dd if=/dev/vg0/gall_snap of=/dev/vg0/gall2 bs=1M
8192+0 enregistrements lus
8192+0 enregistrements écrits
8589934592 bytes (8,6 GB) copied, 223,805 s, 38,4 MB/s

Voila.

Si pas déjà fait, “réparer” le disk avec e2fsck (voir plus haut)

fin du snapshot

On peut detruire le snapshot, on n'en aura plus besoin.

# lvremove /dev/vg0/gall_snap
Do you really want to remove active logical volume "gall_snap"? [y/n]: y
  Logical volume "gall_snap" successfully removed

personnalisation

le volume

Monter le nouveau volume et le personnaliser…

# mount /dev/vg0/gall2 /mnt/domu

hostname, interfaces , etc…

editer aussi la conf dans “udev” afin que ce dernier accepte la nouvelle interface “eth0” (par exemple)

swap

Creer un swap (si on reprend la même conf)

# lvcreate -L 524288K -n gall2_swap vg0
  Logical volume "gall2_swap" created
# mkswap /dev/vg0/gall2_swap
....
domu xen cfg

Adapter la conf du domu

Demarrer nouveau domu

# xm create gall2.cfg -c

network

Ca rame, alors j'essaye:

# ip link set dev vif15.0 txqlen 1000

Avec iperf ⇒ 820 Mbits/s

# ip link set dev vif15.0 txqlen 32

iperf ⇒ 690 Mbits/s

100 Mbits/s en moins… ce n'est pas rien.

Tips

Dummy

nvidia

serveur_xen.txt · Dernière modification : 2011/09/22 14:35 de thierry