Reprise du message précédent :

 
j'ai que l'adresse mac dans le vif hvm.

 
L'adresse mac de ton interface "réelle" je suppose.
 
Je testerai ça demain

l'adresse mac du vif

 
Donc tu choisis une adresse MAC pour ton "futur" vif ? (donc tu prends un choix au hasard si tu laisses Xen gérer ?)

c mon fichier de conf pour un domu hvm
name="xxx"
memory=1024
vcpus=1
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
on_xend_start = "start"
on_xend_stop = "shutdown"
localtime=1
#si multiple cpu
#timer_mode=2
 
builder="hvm"
device_model="/usr/lib/xen-default/bin/qemu-dm"
kernel="/usr/lib/xen-default/boot/hvmloader"
boot="dc"
disk = [ 'phydev/xen-lvm/windows3-data,hda,w','fileiso/XP.ISO,hdc:cdrom,r' ]
#Changer la mac pour une autre install 00 :16 :3E est le domaine xen
vif = [ 'mac=00:16:3e:05:70:03,bridge=br0' ]
# vif=[ 'mac=00:16:3e:0b:e9:5a,model=rtl8139,type=ioemu,bridge=eth0', ]
keymap="fr"
stdvga=0
vnc=1
vncunused=0
vncdisplay=30
apic=1
acpi=1
pae=1
 
usb=1
#usbdevice='tablet'
usbdevice="host:13fe:1a00"
serial="pty"

Bon ça avance : le domU et le dom0 arrivent à se pinger dans les deux sens.
Mais le domU n'arrive pas à voir une autre IP que la passerelle (no ping sur le dns qui est dans le même range par exemple)

Selon ce tuto : http://wiki.kartbuilding.net/index.php/Xen_Networking
 
je suis censé voir un xenbr0 sur mon Dom0, or j'ai "que" :
eth0
peth0
vif3.0
tap0
lo
 
Un network-bridge status me donne :
============================================================
12: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN  
    link/ether 00:22:19:14:32:63 brd ff:ff:ff:ff:ff:ff
    inet 10.145.208.34/24 brd 10.145.208.255 scope global eth0
    inet6 fe80::222:19ff:fe14:3263/64 scope link  
       valid_lft forever preferred_lft forever
12: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN  
    link/ether 00:22:19:14:32:63 brd ff:ff:ff:ff:ff:ff
    inet 10.145.208.34/24 brd 10.145.208.255 scope global eth0
    inet6 fe80::222:19ff:fe14:3263/64 scope link  
       valid_lft forever preferred_lft forever
 
bridge name bridge id  STP enabled interfaces
eth0  8000.002219143263 no  peth0
       tap0
       vif3.0
 
10.145.208.0/24 dev eth0  proto kernel  scope link  src 10.145.208.34  
default via 10.145.208.1 dev eth0  
 
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
10.145.208.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         10.145.208.1    0.0.0.0         UG    0      0        0 eth0
============================================================

Je crois que je vais tenter le bridge manuel.

Humm, c'est normal que j'ai pas de xenbr0 du coup, sur ma version de Xen c'est eth0 (peth0 étant en fait l'ancien eth0)

Suis ce howto et ca marchera :
http://www.howtoforge.com/virtuali [...] enny-amd64

Bon, en HVM ça marche sous Debian (pour tester le HVM, même si je sais que le PV est mieux pour une Debian).
 
Toujours pas sous Windows, je sais point pourquoi (impossible de pinger la passerelle mais le Dom0 oui).
 
Mais bon c'est Windows hein

Bon maintenant, avec les Xen-tools, c'est bien dommage de pas pouvoir deboostraper à cause d'un proxy
C'est curieux quand même, que cet outil n'a pas de conf à renseigner en cas de proxy.

MAJ de la situation :
- j'arrive à utiliser les Xen-tools (j'ai du export la variable http_proxy) : deboostrap OK, PV Debian roule parfaitement, aucune conf à faire, le bridge est niquel

- mes DomU debian PV se ping entre eux, ping le Dom0, et la machine windows. Ils vont sur le net sans soucis.

- mon DomU HVM Debian no soucis aussi.

- la machine Windows (2003 server), firewall désactivé, ping tous les DomU's et le Dom0, mais ça va pas plus loin : ni la passerelle, ni le DNS qui est dans le même range ! je pige pas, je dois rater un truc.

Je continue à creuser.

edit : pareil que ce gars là :
http://lists.xensource.com/archive [...] 01135.html

edit2 : TROUVE §§§§§§§

device_model="/usr/lib/xen-default/bin/qemu-dm"

qui était commenté, et fallait pas

edit3 : en tout cas, ça m'a bien permis de me familiariser avec le bridge (pour avoir fait que du nat avant).
Et puis j'ai mieux intégré les principes de PV/HVM etc.

Bon désolé, c'est pas du flood, mais trop d'édit tue l'édit :

Je m'apprête à tester avec les Xen PV Drivers 0.9.12-pre13.exe
Bref, le dernier avant le dontuse

edit : pour le réseau, ça a l'air pas trop mal. Par contre, soucis de driver avec le contrôleur de disque..

edit2 : environ 6000ko/s en soutenu, pas trop mal

HDtach :
 

 
Avec les drivers PV.  
Sans, j'ai le droit à une scie, là je trouve que c'est plutôt correct ^^

Ben avec les solutions Xen open source, en cas de crash il se passera rien du tout
Après tu peux utiliser hertbeat2 pour redémarer une machine en cas de crash, mais ce sera un reboot.
Mais pour ma part, je n'ai jamais constaté de crash avec mes machines virtuelles, et pourtant ce sont des services très utilisés (messagerie, stockage...)

Le principe du warm standby c'est sympa quand même, peut être qu'un jour ce sera intégré

Nan mais "une copie de contexte en permanence" ca me parrait peu jouable, ca reviendrait à transformer le réseau en bus mémoire, et niveau perfs c'est pas encore ça

 
VMware ESX le fait, donc c'est possible

Ben tu as dis que la MV était rebootée en cas de crash :|

 
Oui mais j'ai oublié de préciser que le warm standby est possible dans la nouvelle version jesaispluscombien
 
Sinon heartbeat ira bien

Donc c'est synchros à intervalle régulier, pas en permanence

http://www.osrg.net/kemari/ (http://www.osrg.net/kemari/download/kemari_linux.mov)
 
alors

 
ça, ça m'intéresse beaucoup.

Y'en a qui ont upgradé des dom0 etch vers lenny ?

 
Oui. J'ai survécu (mais ensuite j'ai préféré repartir sur du "neuf", lenny direct)

 
tu avais des domU PV ou HVM ? tu es passé en xen 3.2 ?

 
Que du Debian PV. La version des paquets sur Lenny oui

Je suis passé de etch à lenny et en xen 3.2 avec des domU debian et un windows 2003 server en hvm.
Pas de soucis particulier
http://forum.hardware.fr/forum2.ph [...] 0#t1114194

tain j'arrive pas à passer un domU 32 bits PV sur un dom0 64 bits
 

 
des pistes ?

J'ai jamais fait de 32->64, je saurai pas te dire

C'est un noyau 32 bits ? les modules sont biens dispos dans le domU ?

je vois pas ce qu'il peut manquer

http://bugs.debian.org/cgi-bin/bug [...] bug=518431 + http://groups.google.com/group/lin [...] 9a5c?pli=1
 
combo
 
et en plus : http://saalwaechter-notes.blogspot [...] probe.html
 
j'ai vérifié, mes binaires sont bien des 32 bits.... ça me saoule ces conneries

Oui mais le noyau c'est sur le dom0 (à moins que tu n'utilises pygrub ?)

 
c'est installé sur les 2 j'ai dpkg -i *.deb

Oui mais le initrd, il a été construit sur le dom0 ou t'as récupéré celui du domU ?

humm
 
il est fourni avec le kernel xen i386 de debian... Tu m'embrouilles là

Nan il est créé à l'install du paquet il me semble, dpkg/apt affiche d'ailleurs un update-initramfs généralement

il est créé dans le chroot, donc en archi 64 bits. c'est surement ça le soucis...

C pas mal xenSERVER de citrix (vi je decouvre ). Bon le truc c'est que lenny n'est pas encore dispo et que les templates debian existantes sont en 32 bits. Mais franchement c'est stable et bien foutu !
 
ps: j'avais écris le nom trop vite