Reprise du message précédent :
Si tu peux mettre à jour ton Dom0 en stable, ça me paraît déjà une bonne solution..
Ensuite si tu peux pas, la doc est assez claire, dans la conf de ton DomU, les x ça ne remplace pas et le reste est expliqué (en gros). Mais oui, faut prendre le temps de comprendre exactement ce que tu fais.  
 
Donc niveau timing, si ta un autre Dom0, tu migres tes VM de prod dessus, et tu upgrade à coté ton Dom0 actuel, et vice versa.

Mettre à jour le dom0? Cela ne garantit pas que le problème sera résolu étant donné que c'est fixé dans unstable. Et puis c'est dommage de mettre à jour le système de virtualisation, alors qu'il est censé s'affranchir du matériel (au moins pour les domU). Non, je pense qu'il faut utiliser les fonctionnalités disponibles dans les fichiers de config.
C'est expliqué dans la doc, mais vraiment à l'arrache. Il y a quelques exemples mais je ne m'en sors pas. J'ai essayé plusieurs combinaisons sans succès    
Niveau timing, oui temporairement, j'ai mis le domU sur une autre machine. Il faudra que je résolve le pb, car la plupart de nos machines seront équipées de ces CPU.

Rien à voir.
Bien sûr que ça se met un jour, aussi bien un hyperviseur qu'une VM  
Pis le noyau Xen de Lenny était tout pourri

enfin c'est quand même le principe

oui je suis au courant. Là il me faudrait passer du 3.4 au 4.x. Je vais avoir plus d'ennuis à vérifier que mes domU fonctionnent bien après upgrade du dom0, que résoudre un pb sur ce domU    

je te l'accorde
 

esxi les gars, esxi

Ca change rien au problème, il faudrait bien qu'il le mette à jour de temps en temps

ouais mais les MAJ marche sans prise de tete, contrairement à mes mauvais souvenirs de xen

Bah comme l'a dit Plam, bascule sur un autre HV, mise à jour de premier, re-bascule, tests, validation, mise à jour du second HV.
C'est pareil avec ESXi ou HyperV ou n'importe quel système de virtualisation

en tout cas pour avoir testé les 2, xen et vsphere, ce dernier est à des années lumières du premier niveau interface, monitoring, stabilité et perfs des vm windows

T'as une licence "un coeur" offerte à chaque fois que t'en dis du bien sur le net ?

même pas c'est gratos jusqu'à 32 Go de Ram par machine

moi c'est le peu de windows qui me fait rester sur du libre.. Si j'avais beaucoup d'OS microsoft à gérer, d'abord je démissionnerai, mais admettons que j'ai pas le choix, je metterai un vmware

Maintenant virtualiser du linusque, quasi full debian, Xen c'est top !

edit : d'ailleurs j 'ai eu oui-dire que le backend de Xen Orchestra serait en réecriture afin de permettre une install facile, une intégration ldap et plein d'autres choses

 
Tu exagères....!  C'est malheureusement avec cette vision des choses que le SI de certaines (rares) universités sont dans les choux. C'est fini la guéguerre microsoft/monde libre dans le monde de l'entreprise/universitaire  

Toutefois, Windows montre ses limites dans les salles serveurs depuis quelques années.  
 
Les gestionnaires (pour rester poli) se rendent compte des couts induits par les logiciels de Redmond (licences, bonhommes, pannes, sécurité ...). Je travaille dans le secteur des services chez un des gros mammouth du secteur. Sauf si couteau sous la gorge, tout nouveau projet se doit de tourner sous RedHat64 virtualisé ou au pire dans un LPAR AIX. Il faut des vrais raisons métier et technique pour introduire une plate-forme windows neuve dans les salles machine maintenant.  
 
La tendance actuelle est de laisser crever les applis sous windows pour les remplacer par des applis web avec des serveurs applicatifs du type apache/weblogic qui tournent sous RedHat ou AIX.

Pour la partie applicative, je suis bien d'accord, et je ne défends pas IIS par exemple Par contre, pour la partie gestion du poste de travail, force est de constater qu'il n'y a pas vraiment d'alternative au monde windows.
 
Dans mon équipe et sur mon parc, on essaie maintenant de prendre le meilleur des 2 mondes, en s'appuyant sur une infra. esx (après avoir abandonné successivement xen et xenserver)

 
Non, je n'exagère pas, puisque c'est précisément un choix de vie Pour moi ce n'est pas Microsoft en lui même, mais le proprio. À titre personnel, je considère ce modèle (proprio) de développement comme obsolète. J'ai de la chance d'avoir un profil qui me permet de trouver facilement un boulot tout en respectant mes « convictions », donc je vais pas me priver
 

 
C'est pas très étonnant, tant mieux
 

 
Le poste de travail, heureusement que c'est pas mon domaine Et que le web « riche » permet de pallier le « soucis » du client pour un bon nombre d'applications
 
 

 
 
Bon finalement, je suis revenu à la charge. J'aime pas partir sur une défaite  
 
Du coup, j'ai trifouiller, refléchis, re trifouiller, re refléchis, re re trifouiller, re re refléchis et BINGO ca marche.    
 
Je sais pas comment c'etait dans la version 3 de Xen mais dans la 4, eth0 est en faite un bridge renommé et l'interface physique réelle est peth0.  
 
Du coup en refaisant la config à la main, dans cette partie,
 

 
il faut remplacer eth0 par peth0 pour avoir ca au final
 

 
Et donc avec bridge=xenbr100 pour l'interace dans le fichier de conf de la vm, j'arrive à avoir du réseau.  
 
Maintenant me reste plus qu'a adapter les scripts dispo ici, et roulez jeunesse  

Du coup si on fait pas de gestion de parc, Xen est très bien

et si tu bosses seul ouais

Le peth0 c'est seulement si tu utilises le script network-bridge  de Xen    
 
Si t'avais utilisé les scripts vlan que tu cites à la place (network-bridge-vlan ou network-multi-vlan selon que t'as un ou plusieurs bridge), comme je te l'avais dit, il y aurait jamais eu de renommage de eth0 en peth0, donc ça aurait marché y a deux mois

Non

 
on a quand même + de 400 postes sous Windows ici et pas un AD ni rien

vous avez même pas un ldap rien?

Sans doute samba/openldap, qu'on va arrêter chez nous (5000 postes)... pour passer en AD.

Voilà, samba/openldap. Maintenant que ça ait tenu sur 5000 postes, ça prouve que ça tient la charge

ah mais j'ai pas dit le contraire Par contraire niveau fonctionnalité, gestion du poste et co-administration, c'est zero. Mes techs perdent trop de temps avec ce système, et comme on ne va pas vers une augmentation des ressources humaines...

 
Je m'en suis servi pourtant. Maintenant est ce que c'est dû au faite que je m'en suis pas servi dés le début pour la toute premiere vm que y'a eu le renommage, je sais pas. En meme temps, c'etait là une premiere pour moi dans le monde de la virtu, je découvre, j'apprends, je comprends
 

Le script qui créé les bridge est lancé par le script d'init xend, au lancement de la machine.
Donc effectivement, si il était actif, et que t'as pas, après modif de la conf de xend pour lui dire d'utiliser le nouveau, soit rebooté la machine, soit arrêté manuellement le script de bridge pour relancer le nouveau, ben effectivement, eth0 était devenu peth0.

 
Ca m'interessait de savoir comment s'est optimisé tout ca, pour pouvoir monter en charge sur ce que j'ai.  
 

 
C'est sur que niveau fonctionnalités, ca vaut pas un ad. Mais couplé a un fog et du wpkg, y'a de quoi s'en sortir mine de rien je pense.

 
De mémoire, je me rappel avoir mis les scripts dans la conf de xen (tu parle bien de xend-config.xsp ?) et redémarrer le dom0 et plus d'une fois. Du coup ca me met un doute, je sais pas ou j'ai merdé a ce moment là et je sens que ca va me travailler  

Yep, y'a moyen de s'en sortir (j'utilise clonezilla), mais ce n'est pas optimisé. Et comme il y aura de moins en moins de postes informatiques (dans notre ministère en tout cas), et de plus en plus de travail... il faut aller vers le plus efficace. Sinon... externalisation (CNRS a déjà commencé). C'est clair, il faut en être conscient.

Je comprend bien le choix

On utilise AutoIT pour déployer « rapidement », mais ce n'est pas intégré comme avec un AD, c'est certain !

Dans un monde idéal (l'entreprise que je monte moi-même) pas un seul poste windows ! Ça doit être « marrant » à admin d'ailleurs Je sais pas si ya beaucoup d'exemple sur le net d'ailleurs (de mass pc clients sous Linux par exemple)

A part sur quelques postes purement scientifiques (et encore) ou en accès libre (firefox et basta), je n'en connais pas. Avec puppet, ca doit etre gérable par contre.

Oui sauf que Puppet c'est pas accessible au technicien lambda qui attends la retraite

Clair ! Mais pour gérer un parc nux, à part çà et certaines solutions Mandriva, je vois pas.

Ca tombe bien parce qu'avec des copains on avait commencé à prendre le truc en main et on trouvait ça chouette.
On se demandait ce que foutait le branleur de codeur à la con qui veut pas se sortir les doigts pour faire des updates

 
dit ça donc au branleur de codeur à la con qui veut pas se sortir les doigts (c'est pas moi qui bidouille le backend - j'ai fait le proto mais il a refait le code -, car je laisse ça à un as du code, qui a juste le défaut d'être perfectionniste maladif)
 
Et ça va forcément avancer puisqu'au plus tard à la moitié de l'année, ya 50% de chance que je monte la SARL

 
Une question que je me pose en passant.  
Si je met en place les scripts en question, au prochain redémarrage du dom0 est ce que l'interface eth0 sera renommée en peth0 et le bridge en eth0 ou pas ? Et est ce que vu que le renommage à deja eu lieu, il est permanent ?

Non, ces scripts ne font pas de renommage de eth0, et pour cause, ils n'utilisent pas eth0 mais des interfaces eth0.vlan (ou ethX.vlan, voire bondX.vlan dans le cas de bonding, tu peux utiliser le paramètre "netdev=X" pour spécifier l'interface à utiliser, par défaut il utilise eth0). Et pour ceux là il ne les renomme pas en peth0.vlan.
Les bridges sont créés avec pour nom vlanbr${numero_vlan} (donc attention à tes fichiers de conf de VM )
 
J'ai pas compris ta question de redémarrage qui a déjà eu lieu et si c'est permanent... mais si tu entends pour la gestion des bridges, tu peux les détruire et les recréer en appelant le script configuré dans xend-config (network-bridge ou network-multi-vlan ou celui que tu as configuré) et en précisant stop (pour tout "détruire" ) ou start (pour les créer) :
network-bridge stop
network-multi-vlan start
Ou, si tu utilises unr autre interface que eth0 :
network-multi-vlan netdev=bond0 start
 
Je sais pas si je suis clair

Ok donc pas de renommage de eth0 au boot du dom0 avec ces scripts la. Pour les vlans, je crois comprendre comment gérer la chose mais du coup me vient une question supplémentaire, que devient le bridge par défaut créer par xen, est ce qu'il y'a un équivalent qui sera dispo avec les scripts pour les vlans ? Parce que j'ai aussi des vms qui tournent sur le vlan natif arrivant sur le dom0.
 
Scuzi, c'est pas redémarrage que je voulais dire mais c'est renommage J'etais pas réveillé ce matin et je le suis toujours pas d'ailleurs

Ben ce que tu appelles le bridge par défaut, c'est créé par le script network-bridge, donc il sera créé ou pas selon ce que tu mets dans le script avec gestion des vlans.

Mais je ne comprends pas ton "vlan natif". Tu veux dire que sur eth0 tu as du traffic taggué et du non taggué (ton "vlan natif" ) qui arrive ? c'est possible ça ?
Dans tous les cas, soit tu tag ce "vlan natif" comme les autres, et ton dom0 utiliseras eth0.vlan_natif comme interface, + un bridge par dessus,
soit tu le taggues pas (si c'est possible... et si ça l'est, ça ne me parrait pas forcément pertinent comme approche, mais bon...) et alors tu peux utiliser un script network-bizarroid-bridges genre :
network-bridge "$@"
network-bridge-vlan vlan=X "$@"
network-bridge-vlan vlan=Y "@"
...

L'important, et il est essentiel de le comprendre, c'est que xen se contente d'exécuter un script en lui passant un argument start, ou stop. Derrière, tu lui fais faire CE QUE TU VEUX