Probleme Vmware Server et SP SSD 2009

[ChristOff]

Bonjour,

Le rtc est-il reconnu par VMware?
Je pense que par défaut il est compilé pour être présent sur /dev/rtc0, il faut rajouter un lien symbolique /dev/rtc (ou changer la config du kernel je suppose, mais je n'ai jamais essayé cette option là).

ChristOff

[Nicko]

Suis saoulé je le reinstalle.

Le support m'a dit de commander un KVM si je veux toucher au bios pour virer les histoires de "intel turbo boost" du i5. Faut pas abuser quand meme

[zakmckraken]

Envoyé par Nicko

Le support m'a dit de commander un KVM si je veux toucher au bios pour virer les histoires de "intel turbo boost" du i5. Faut pas abuser quand meme

c'est dans un sens normal qu'un tech n'aille pas desactiver dans le bios une option qui est censée être activée (dans le cas d'une option qui n'est pas activée alors qu'elle devrait c'est autre chose)

[Nicko]

Sauf que dans notre cas :
- y'a un probleme quelque part.
- le kernel dispo n'est pas le tout dernier
- c'est un technologie recente (rappel les SP SSD ca fait pas 1 an qu'OVH en loue ...)
- les SP SSD ont montré des faiblesses (smartctl en particulier).

[Nicko]

Bon je l'ai collé en distribution vmware OVH.

Ca marche pas mieux, j'ai d'autre probleme (pas de reseau entre autre) mais le support ne reponds pas plus...

Pis j'ai çà aussi :

Oct 27 12:13:44 ns307149 kernel: [3059]: host clock rate change request 12 -> 14
Oct 27 12:13:55 ns307149 kernel: [3059]: host clock rate change request 14 -> 8
Oct 27 12:13:55 ns307149 kernel: [3059]: host clock rate change request 8 -> 12
Oct 27 12:14:01 ns307149 /USR/SBIN/CRON[5702]: (root) CMD (/etc/webmin/sysstats/sysstats.pl)
Oct 27 12:14:11 ns307149 kernel: [3058]: host clock rate change request 12 -> 14
Oct 27 12:14:23 ns307149 kernel: [3058]: host clock rate change request 14 -> 3
Oct 27 12:14:23 ns307149 kernel: [3058]: host clock rate change request 3 -> 9
Oct 27 12:14:23 ns307149 kernel: [3059]: host clock rate change request 9 -> 12
Oct 27 12:14:54 ns307149 kernel: [3058]: host clock rate change request 12 -> 3
Oct 27 12:14:54 ns307149 kernel: [3058]: host clock rate change request 3 -> 9
Oct 27 12:14:57 ns307149 kernel: [3059]: host clock rate change request 9 -> 12
Oct 27 12:15:01 ns307149 kernel: [3058]: host clock rate change request 12 -> 14
Oct 27 12:15:01 ns307149 /USR/SBIN/CRON[5728]: (root) CMD (/etc/webmin/sysstats/sysstats.pl)
Oct 27 12:15:13 ns307149 kernel: [3059]: host clock rate change request 14 -> 3
Oct 27 12:15:13 ns307149 kernel: [3059]: host clock rate change request 3 -> 6
Oct 27 12:15:14 ns307149 kernel: [3058]: host clock rate change request 6 -> 12
Oct 27 12:16:01 ns307149 /USR/SBIN/CRON[5756]: (root) CMD (/etc/webmin/sysstats/sysstats.pl)


C'est la fete...

Ce SP SSD 2009 est une fausse bonne idée il m'a fait perdre un temps considérable...

[Nicko]

Bonjour,

Juste pour tenir tout le monde au courant

Tout d'abord un truc énorme, parceque j'ai fait un apt-get update && apt-get upgrade puis installer Webmin, WebminStats et lftp le support a refusé d'intervenir... Je ne dois pas modifier la distribution. C'est vrai que lftp sur le serveur, enfin soit...

Du coup la j'ai encore une fois ré-installé le serveur, je n'ai rien fait dessus, j'ai juste ajouter l'ip FO dans le fichier /etc/vmware/routes.conf et un reboot après pas de vmnet1 quand je démarre une VM que je viens de créer !

Derrière mêmes messages dans le syslog que précédemment c'est à dire :
au boot (IP FO dans le routes.conf):
Oct 28 18:53:05 ns307149 VMware[init]: RTNETLINK answers: Network is down
Oct 28 18:53:05 ns307149 VMware[init]: RTNETLINK answers: Network is down

et en permanence :
Oct 28 21:20:53 ns307149 kernel: [3017]: host clock rate change request 8 -> 9
Oct 28 21:21:12 ns307149 kernel: [3017]: host clock rate change request 9 -> 0
Oct 28 21:21:12 ns307149 kernel: [3017]: host clock rate change request 0 -> 8
Oct 28 21:21:27 ns307149 kernel: [3017]: host clock rate change request 8 -> 9


Ce deuxieme type d'erreur me fait dire qu'il y a un probleme d'hologe (comme je l'ai eu avant) mais on va voir ce qu'en pense le support.

Par acquis de conscience j'ai refait le test en normal (pas d'ip fo dans le routes et le route add à la main) : comme prévu pas de message d'erreur vmware mais pas de réseau ... Pourtant les routes sont bonnes sur le host:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
91-121-43-90.ov * 255.255.255.255 UH 0 0 0 vmnet1
94.23.227.0 * 255.255.255.0 U 0 0 0 eth0
192.168.37.0 * 255.255.255.0 U 0 0 0 vmnet1
192.168.227.0 * 255.255.255.0 U 0 0 0 vmnet8
default 94.23.227.254 0.0.0.0 UG 0 0 0 eth0


Enfin, je dois dire que je lâcherai plus l'affaire pour maintenant, j'y ai perdu trop de temps !

[Nicko]

Suis de retour aux affaires !

Alors coté distribution vmware mes messages repetés ont porté leur fruit, à priori le support a bien remonté le probleme sur la distribution vmware sur SSD (probleme de reseau plus message sur le clock) et ils ont mis en place une machine de test de leur coté. On verra ce que ca donne.

De mon coté j'ai repris le SSD en main et je teste en Kernel 2.6.31.4...

Affaire à suivre

[Nicko]

Bon pour l'instant le Kernel 2.6.31.4 est une tres bonne chose.

Ma VM est UP Depuis plusieurs heures et je n'ai pas un seul "trou" de 5 min comme précédemment, mes syslog sont OK, la VM ne semble pas se figer, etc...

J'ai juste un truc "bizarre":

Nov 3 21:06:53 ns307149 kernel: CE: hpet3 increasing min_delta_ns to 15000 nsec

ca parle à quelqu'un ce genre de message ?

[Nicko]

Bonne nouvelle le Kernel 2.6.31.4 était la solution !

On est repassé en prod dessus apres 3j de rodage...

Croisons les doigts pour que çà tienne !

[madameirma12955]

Perso j'ai abandonné VMWare Server pour Proxmox. J'ai convertit les machines virtuelles, et ca marche du tonnerre incroyable sur le SSD avec 3x 2008 R2 en x64.
La distrib est une etch en noyau 2.6.24.8 (comment upgrader en 2.6.31.4 ?), il suffit d'upgrader proxmox de 1.1 en v1.4 via aptitude.
Je ne sais pas si c'est stable je n'ai pas de retour d'expérience par contre, mais ca a l'air puisqu'au bout de 92h c'est toujours up et que les machines virtuelles sont toujours aussi véloces.
Cela dit c'est basé sur QEmu qui lui a une bonne expérience.