Reprise du message précédent :
Passe à xenserver. C'est du centos également en dom0 et tu n'auras pas ces problemes.

oui mais bof, ca veut dire reinstallation complete du systeme, etc... d'autres VMs installées sur ce serveur sont en production..

T'as bien fait gaffe de mettre des adresses mac différentes ?
C'est bien celles que tu as spécifié qui sont utilisées coté Windows (je connais pas les drivers PV pour Windows, donc si ca se trouve ca peut poser pb).
Ton bridge xenbr0 c'est le même que pour des VMs qui n'ont pas ce problème ?

je comfirme que le pbm venait des adresses MAC. J'ai supprimé l'adresse MAC spécifiée en dur dans la définition du vif pour la laisser attribuée par Xen et ca fonctionne beaucoup mieux. Il y avait effectivement eu un doublon d'adresse... (patapé ! )

Dites, j'utilise VBox sans souci depuis un certain temps, et j'ai commencé à m'intéresser à l'usage de périfs USB.
Apres un premier échec, j'ai suivi les docs qui disent de vérifier son appartenance au groupe vboxusers…
 
Mais là, grosse surprise, bien que Vbox fonctionne parfaitement avec mon user courant, il n'y a pas de groupe ainsi nommé sur ma machine.
 
Il est normalement créé a l'intall de VBox mais ça semble ne pas avoir été fait…
 
Avez vous déja eu ce pb ?  
 
J'utilise VirtualBox OSE 3.0.8 sous Ubuntu 9.10

Virtualbox OSE ne supporte pas l'USB.
Il faut télécharger la version complète sur le site de Virtualbox.

Oh les petits coquins… comme le menu existe aussi sous OSE, j'y ai cru
Sinon, c'est normal l'absence du groupe vboxusers  en dehors du pb d'USB ?

Bon, avec xen 3.4, la migration de domU en 32 bits marche de nouveau super bien sur des dom0 en 64 bits \o/

Oui, je suis bien content de ce 3.4, ça roule bien

Cela dit j'ai réussi à planter ma VM (je sais pas si c'est dû au multiples migrations où à l'activité que je génère dedans, je penche plutot pour le second) :

 
La bonne nouvelle c'est qu'il a planté pendant que je compilais le 2.6.32 qui me permettra de voir si ce bug en cas de forte charge est résolu (mais donc il est clairement lié au domU, et pas au dom0 ou à l'hyperviseur).
Mais vu mes récentes lectures sur xen-users et xen-devel, j'ai peur qu'il soit toujours présent

Bon, avec le 2.6.32 c'est encore plus catastrophique, plantage à la moindre migration, charge ou pas dans le domU

auto promo pour ceux que ça intéresse : http://www.rottenbytes.info/?p=291

Interessant, mais moi j'aime pas trop savoir qu'un soft prends la décision de migrer une VM tout seul, vue la stabilité du bouzin lors de migration

j'ai pas de problème de stabilité
 
pour les tests j'ai bien du faire 50 migrations hier, pas de soucis

Lance des compils de kernouille dans tes VMs

Ah pis le problème se pose qu'avec des VMs avec au moins 2 vcpus

 
tu testes s'il y a assez de ressources (ram et cpu) restantes sur les cibles ?

Puisqu'on est dans les tips

Un truc que j'ai découvert hier lors de mes investigations (et qui a été confirmé ce matin dans un mail de xen-users, drole de coincidence ) : par défaut, Debian + Noyau Xen gère très mal la balance des interruptions sur les différents CPU (chez moi, toutes les interruptions liées à ma carte FC allait uniquement sur le CPU0 dans le dom0) : il faut installer irqbalance dans le dom0, et le configurer en mode "ONESHOT", et la ça marche nickel.

Tip n°2 : si vous faites une affectation de VCPU/CPU précise dans le dom0, réexecuter irqbalance

Bon je sais pas si ça va résoudre mes soucis (j'ai regardé aussi du coté de la gestion des horloges dans le domU découplée de celle du dom0), mais en terme de perfs à priori c'est mieux (enfin si vous avez plusieurs CPU/coeurs/hyperthreading sur le dom0)

 
CPU oui, pas de bascule si le load a déjà atteint un certain seuil. et RAM non pas encore, faudra que modifie mon agent pour ça. Comme dit dans le post, c'est un PoC

C'était juste une question comme ça

edit : tu te base sur quel load ?

 
celui du dom0, le faire indépendamment par VM c'était pas super simple pour un premier essai

mais le load est pas visible coté dom0 ?

Bon à priori, avec le changement pour les horloges dans les domU, la migration se passe bien maintenant (avec noyau 2.6.26-2-xen-amd64 de chez Debian)

 
je parle du load du dom0 lui même  

Ben oui, il est pas influencé par le load des VMs, d'où mon étonnement

Bon, 10 aller/retour de ma VM en pleine charge entre mes deux hyperviseurs, aucun souci.
 
Plam> tu connaitrais une bonne ressource qui explique les différents clocksource possible (xen ou jiffies) ? parce que google me renvoit sur un million de listes de diffusion, mais ca contient peu d'explication technique...

 
euh, d'après mes expériences, la load du Dom0 != la somme des load des DomU. D'ailleurs c'est hot de trouver un indicateur fiable pour avoir la charge moyenne des Xends. Il faut prendre en compte la load de chaque domU et calculer en fonction de leurs poids respectifs/nombre de cœurs etc. Pas simple
 

 
En trèèèès gros j'avais retenu que jiffies c'est le ticks CPU et Xen c'est l'hyperviseur qui donne ses propres ticks. Lequel est le mieux, plus approprié, faut que je fouille mon gmail dans le label "ML Xen user" ou "ML Xen dev" (ce qui est faisable)
 

Ben le xen est plus simple, t'installes un ntp dans ton dom0 et t'es censé être tranquille.
 
Sauf que ca me fait des problème à la migration, et je soupçonne que ce soit aussi à cause de cela que j'ai souvent des messages de type CPU softlock dans mes VMs hyper chargées (après est-ce la source de mes plantages aléatoires de VM... ?)

qu'as-tu changé?

T'as tout là (mais sans les explications techniques que je recherche )
http://wiki.debian.org/Xen#A.27clo [...] ckwards.27

ah oui, le fameux time went backwards.
Et cela résoud tes problèmes pour un VCPU >= 2 ou il s'agit d'un autre problème?

je répète : c'est un proof of concept, pas une solution pour de la prod. perso je me baserais plus sur les I/O et les infos à la "xm top" pour voir les bottlenecks.

Pour les horloges j'ai jiffies comme source

edit : voila c'est le workaround 1 que j'utilise

Ben le problème ne se présente que sur des VMs avec plusieurs vCPU (en même, j'ai quasiment que ça)
et pour ce qui est de la résolution du problème, seul le temps me le dira, les plantages constatés sont
super aléatoires, ça peut tourner sans problème pendant des mois, et pis je peux avoir deux plantages
à une semaine d'intervalle... c'est bien là le coté difficile à résoudre, parce que difficilement reproductible

 
J'utilise jiffies et ntp dans chaque domU (installé avec la bonne conf automatiquement grâce aux xen-tools, et j'ai pas de soucis
 

 
T'inquiète je sais que c'est une PoC, mais c'est juste que je me suis aussi penché sur le problème de la load, et que j'avais fait des tests. Si tu as un DomU qui taffe à fond, ça n'aura aucune influence sur la load du Dom0 !

Oui mais est-ce que tu connais les détails techniques ?
Parce que bon, j'ai du mal à comprendre pourquoi c'est pas le clocksource par défaut du coup

Et le xen.independant_wallclock, certains le mettent à 0 + jiffies, d'autres à 1 + jiffies
EDIT: et d'autres qui utilisent le independant_wallclock à 1, et laissent xen comme clocksource

Bref, sans explications, pour moi c'est du vaudou, et j'aime pas ça moi, le vaudou

J'avoue qu'au sus de mes problèmes précédents (en iSCSI par exemple), j'ai pas eu le temps de creuser de ce côté

Plam> toi qui connait un peu l'API Xen, je voudrais récupérer les valeurs VBD_RD, VBD_WR, CPUTIME, NETTX et NETRX telles que dans "xm top", mais les metrics (VM_metrics, VBD_metrics, etc...) de l'API ne me permettent d'avoir que des instantanées de ces infos.
J'ai du passé à coté mais je vois pas où je peux récupérer cela, une idée

 
Plop. De tête là comme ça, il me semble que c'est Xend qui utilise une base rrd pour stocker les instantanés pour les afficher dans xm top.  
 
T'es sur quel API ? La nouvelle en OCaml ou l'ancienne en python ?  
 
 
 
Sinon j'ai fait des tests de charge CPU sur mes DomU's, cpu à fond, d'autre I/O à fond : pas eu de oops ni de panic.

 
 
Des RRDs ? t'es sur ?

 
En fait, comme je traîne souvent sur les ML de Xen, j'avais bien lu ça quelque part :
 

 
C'est Dave Scott qui répond