| :!: Xen 4 et Squeeze sont juste survolé ici... | ====== Xen ====== Liens: *http://wiki.debian.org/Xen *[[http://en.wikipedia.org/wiki/Xen]] *http://www.catapulse.org/articles/view/84 A suivre: *http://howto.landure.fr/gnu-linux/debian-4-0-etch/installer-et-configurer-xen-sur-debian-4-0-etch ===== 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 [[http://www.intel.com/cd/products/services/emea/fra/319662.htm|Liste des processeurs Intel supportant le VT]]. [[http://www.tayo.fr/benchmark-processeur--tous-aide.php|Processeurs selon leurs performances]] [[http://www.howtoforge.com/make-your-xen-pae-kernel-work-with-more-than-4gb-ram-debian-etch-grub|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 [[http://lwn.net/Articles/166330/|tester]] ? C'est [[http://unit.aist.go.jp/itri/knoppix/xen/index-en.html|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: ... ... (network-script network-bridge) ... ... # (network-script network-dummy) ... ... 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 netmask 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: *http://wiki.libvirt.org/page/Networking *http://xen.1045712.n5.nabble.com/Networking-issue-with-quot-conntracking-quot-after-upgrade-Xen-3-2-gt-4-0-td3309595.html *http://lists.xensource.com/archives/html/xen-users/2009-08/msg00614.html 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 netmask network broadcast 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 = c'est à dire 0 1 ou 2 etc... vncunused = 0 Le port VNC sera alors: 5900+ === Usage === Sur le "''Dom0''" : # xm create /etc/xen/win2k.cfg Sur le poste client: $ ssh -L 5000:localhost:5900 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: *[[http://www.option-c.com/xwiki/Create_a_Debian_VM_with_debootstrap]] *[[http://mlc.homelinux.com:88/blog/?cat=9&paged=3]] *[[http://www.scribd.com/doc/352721/Une-goutte-de-blog-Connaissezvous-debootstrap-]] *[[http://perso.ens-lyon.fr/sebastien.mei/wiki/doku.php?id=documentations:xen-tools]] 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 ” 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 Logical volume "debtest-root" created lvm> lvcreate -L 512M -n debtest-swap Logical volume "debtest-swap" created lvm> exit On pourrait aussi utiliser "''dd''" ou une "vraie" partition. === Formater === # mkfs.ext3 /dev//debtest-root # mkswap /dev//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//debtest-root /mnt/domU # debootstrap etch /mnt/domU ... ... I: Base system installed successfully. # Autre exemple avec **''debootstrap''** : # debootstrap --arch i386 etch /mnt/ 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 # /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. # # /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 .thierry-jaouen.local == 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 = "" 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: *[[http://wiki.gcu.info/doku.php?id=unix:xen_hvm]] 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 :-) \\ {{hvmxen-windowz2k.jpg|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 --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 5632 -f Attacher une nouvelle image: # xm block-attach file: 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 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/.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 -auth /var/lib/xdm/authdir/authfiles/A:0-XXXXXX Prendre votre meilleur "''vncviewer''" et voila "''xdm''" :\\ {{xen-xdm-debian.jpg|}}\\ S'identifier, et on est dans X !\\ {{xen-fce4.jpg|}}\\ 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 au pire: # xm destroy === console === # xm console Et on arrive dans une sorte de "tty" .\\ Pour quitter. [Ctrl]+[Alt]+ ] (comme "telnet") === config === La configuration vu par xen: # xm list --long 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 - la VM est mis en pause - l'etat de la RAM et du CPU est sauve dans "le fichier" - "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 ==== Lien: http://wiki.xensource.com/xenwiki/XenNetworking === 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: ... ... ## Xen Linux kernel options to use with the default Xen boot option # xenkopt=console=tty0 xencons=off dom0_mem=1024 ... ... module /vmlinuz-2.6.18-6-xen-686 root=/dev/mapper/vgraid1-xencave ro console=tty0 xencons=off dom0_mem=1024 ... ... Et puis, dans "/etc/xen/xend-config.sxp" : ... ... # TJ ----------- #(dom0-min-mem 196) (dom0-min-mem 1024) # ------------- ... ... Pourquoi ? mystere... ===== USB pour DomU ===== Lien: *http://www.virtuatopia.com/index.php/Adding_USB_Devices_to_a_Xen_HVM_domainU_Guest *http://xgu.ru/wiki/USB_%D0%B2_Xen *http://wiki.xensource.com/xenwiki/Assign_hardware_to_DomU_with_PCIBack_as_module Pas de **''lsusb''** dans le DomU ? # aptitude install usbutils ====== Xen Lenny ====== ===== Introduction ===== Lien: *http://www.howtoforge.com/virtualization-with-xen-on-debian-lenny-amd64 *http://wiki.isonoe.net/xen/installation_de_xen_sous_debian_lenny 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/ /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="" 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 [[brouillon_xen_32_64|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 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 ===== Créer un DomU avec une carte reseau "dummy" ! Liens: * http://blogs.simc.be/simc/index.php/post/2010/12/08/Xen-%3A-dummy-un-r%C3%A9seau-interne-haut-d%C3%A9bit-pour-vos-VM * http://www.debian-administration.org/articles/360 ===== nvidia ===== C'est possible ? Lien: http://blogs.simc.be/simc/index.php/post/2009/02/08/Nvidia-est-xen-encore-plus-simple