Emile “iMil” Heitor ‘s home

Après moult heures passées à backporter des bouts de Xen 3.0.4 vers Xen 3.0.3 pour essayer de garder un peu de cohérence dans mon packaging, j’ai fini par choisir la solution de facilité et récupérer Xen 3.0.4 chez XenSource. Eh-bin-ça-marche. Enfin cette saloperie de broadcom 4400 daigne faire transiter des lutins magiques depuis un dom0.
Bon leur quenelle est en 2.6.16, le boot est un peu chaotique, mais j’ai du link convivial.

update

Rappel des faits.

Y’a quelques semaines, on m’a confié ce monstre pour en faire un calculateur meteo de poche. Muni d’un Xen -c’est ce que j’ai proposé-, le laptop, modulo le support des instructions VT et assez de RAM, devra pouvoir faire tourner une version minimale de nos solutions.
Premier echec, le modèle initial était muni d’un chip Intel T5500, et comme on peut le lire sur cette page de wikipedia, ce CPU ne supporte pas les instructions VT.
Patience est mère de toutes les vertus, après quelques jours d’attente, je reçois donc le même modèle muni d’un T5600. Un rapide grep vmx /proc/cpuinfo finit de me rassurer.
Confiant, j’installe gentiement une debian des familles, apt-get install xen-blabla, reboot, nickel, ssh pwet: no route to host. “Qu’est-ce que…”, ifconfig -a: pas d’eth0. Et là, c’est le début de l’enfer, un tour rapide sur google me renseigne sur la detresse qui va être la mienne: le module b44, supportant la Broadcom 4400 qui munit ce laptop, ne fonctionne pas sous Xen 3.0.3 (une histoire sordide de DMA_BITS hardcodé à 31). Je hacke, je tweake, je backporte, avec panic‘s pour seuls résultats.
En désespoir de cause, je récupère, comme dit plus haut, la version binaire de Xen 3.0.4 et là… dhclient eth0, boum, ça marche.

Epilogue

Il a tout de même subsisté un petit stress, alors que je m’appretais à xm create mon premier domU hvm, je me vois rembarré par une erreur du style: “unable to start hvm, is your CPU VT/AMD-V compatible or is it enabled in your BIOS ?”. Eh bin non justement, c’est absolument pas enabled dans le BIOS pour la simple raison que ces petites truites de chez HP ne permettent pas, par defaut, d’agir sur l’activation des instructions VT du nx7400. Avouez que c’est quand même particulièrement crétin de vendre du matos de ouf sans fournir la possibilité de s’en servir. Fort heureusement, en fouillant un peu sur le site d’HP, je finis par découvrir un upgrade pour le bios en question, dont la mention “ready for Vista” ne laisse absolument pas présumer qu’il ajoute une entrée dans le BIOS: “Enable Virtualization Technology”.
Bref, flashage, reboot, activation du VT, reboot, et ?… crash de Xen.
C’est fatiguant un peu.
Reboot sur un kernel classique, las, je re-apt-get xen-blabla, re-install.sh du Xen 3.0.4 binaire, je traffique un peu mon menu.lst, et là, probablement parce ce laptop en avait plus qu’assez que je le maltraite, reboot et…ça-marche.
Pour finir, re-packaging d’un noyau Xenifié à l’aide de make-kpkg en utilisant le tarball source de XenSource, dpkg -i, et me voici enfin en possession d’une debian Xenifiée fonctionnelle sur un portable muni d’un CPU VT-capable.

J’f'rais pas ça tous les jours.

Alors que j’étais plein d’entrain et que je m’apprétais à utiliser les snapshots LVM avec mon Xen, je lance, confiant, un

lvcreate -s -L2048M -n lvconvivial /dev/vgconvivial/base

et je me mange un

LV vgconvivial/lvconvivial in use: not deactivating
Couldn't deactivate new snapshot.

Je cherche donc un peu, et je tombe sur ça http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343671#msg20
Je m’empresse donc d’éditer le-dit udev-rules, comme mentionné dans le ticket, pis ça marche.

Tu notes ça dans un coin ?

Je pouvais evidemment pas résister à transformer tatooine, ma ws ubuntu, en convi-Xen0. Muni d’une carte graphique à base de chipset nvidia, j’avais lu de-ci de-la qu’il existait des patches pour faire fonctionner les drivers du malin sur un domaine 0.Voici donc les quelques liens sur lesquels je me suis basé ainsi que quelques confs

. Procédure de chez OpenSUSE pour patcher les-dits drivers

Perso, j’ai pas litteralement suivi la procédure, après patchage, j’ai simplement executé nvidia-installer, présent à la racine de l’archive NVIDIA-Linux-x86-1.0-9631-pkg1.

. Une doc fort bien concue sur la xenification d’une debian, l’adaptation à ubuntu est triviale

Mon /etc/network/interfaces :

auto xenbr0
iface xenbr0 inet static
  pre-up brctl addbr xenbr0
  post-up brctl addif xenbr0 eth0
  post-up ifconfig xenbr0 up
  post-up ifconfig eth0 up
  post-down brctl delbr xenbr0
  address 192.168.0.2
  netmask 255.255.255.0
  gateway 192.168.0.1
  bridge-ports eth0
  bridge_maxwait 0

Mon NetBSD-domU, basique :

kernel = "/home/xen/netbsd/netbsd-INSTALL_XEN3_DOMU.gz"
memory = 256
name = "netbsd"
disk = [ 'file:/home/xen/netbsd/netbsd.qcow,ioemu:hda1,w',
	'file:/home/xen/netbsd/i386cd-3.1.iso,ioemu:hdc:cdrom,r' ]
vif = [ 'bridge=xenbr0' ]

Et le resultat :)

Addon

J’ai noté d’horribles ralentissements lors de l’utilisation intensive du disque virtuel, et après quelques recherches, je suis tombé sur ceci dans la FAQ de Xen :

2.3. Error about root device still mounted when it’s not mounted, zombie domU that can’t be killed, domU hangs under heavy I/O (e.g disk) access

You may try to pass nousb to dom0 kernel command line, or pass ignorebiostables, or try to disable software IRQ affinity for 1850/2850 systems.

Et effectivement, après avoir ajouté l’option ignorebiostables dans mon menu.lst, tout semble réagir au poil :

title           XEN/2.6.17
root            (hd0,0)
kernel          /boot/xen-3.0-i386.gz ignorebiostables
module          /boot/xen0-linux-2.6.17-6-generic-xen0 root=UUID=387cb651-f182-4
b1f-a5b9-a2e5ef119d5a ro
module          /boot/xen0-linux-2.6.17-6-generic-xen0.initrd.img

Si ton Xen t’insulte tout plein avec des phrases du genre :

Error: Device (vbd) could not be connected. Backend device not found.

Pas de panique ami lutin, le pauvre Xen n’a juste tout plus de devices loopback à disposition. Rend leur heureux, et agrémente ton /etc/modprobe.conf de cette petite ligne magique :

options loop max_loop=64

Et tu pourras xm create tout plein de domaines supplémentaires.

Au boulot, j’ai reçu de nouveaux jouets. La particularité de ces bestiaux, c’est d’être équipés de CPUs “Dual-Core Intel Xeon 5140 Processor (2.33 GHz, 1333 FSB)”, et la particularité de ces CPUs, c’est qu’en petit, en bas de l’encadré les concernant, on peut lire “NOTE: Intel Xeon Processor 5100/5000 sequence are 64-bit, Dual-Core, 4MB L2 Cache, and support Intel VT technology.”. Et ça, c’est luvz.

J’attendais le passage du père Noël depuis un moment pour réaliser un fantasme longuement reflechi, basculer une plateforme complète de lab de vmware à Xen.
J’vous la fait courte: non seulement ça marche, mais comme prévu, ça démonte.

Voici en résumé ce que vous avez besoin de savoir pour migrer une image vmware vmdk vers une image Xen :

À l’aide de qemu-img, outil integré dans qemu que vous installerez evidemment au préalable, on convertit le .vmdk en image brute exploitable par Xen :

$ qemu-img convert test.vmdk test.img

Voici une conf fonctionnelle prenant en compte le fonctionnement en mode HVM, aka full virtualisation, sans modification du guest. C’est cette feature qui nécessite un CPU supportant la techno VT :

kernel = '/usr/lib/xen/boot/hvmloader'
builder = 'hvm'

memory  = '256'
name = 'test'

device_model = '/usr/lib/xen/bin/qemu-dm'

# On déclare deux cartes réseau de type pcnet, celles qu'émulent vmware
nic=2
vif = [ 'type=ioemu, mac=00:50:56:01:09:01, bridge=xenbr0, model=pcnet', \
 'type=ioemu, mac=00:56:3e:00:00:02, bridge=xenbr0, model=pcnet' ]

sdl=0
# L'output sera visible sur un serveur vnc sur son display 1
vnc=1
vnclisten='192.168.10.20'
vncunused=0
vncdisplay=1
vncpasswd=''

disk = [ 'file:/home/xen/test/test.img,hda,w' ]

après avoir classiquement créé son domaine

# xm create test

reste à se connecter sur la console vnc depuis un client vncviewer :

$ vncviewer 192.168.10.20:5901

Vous pouvez maintenant aller faire le cake devant vos commerciaux.