Depuis que j’utilise un P5B-VM d’assus, j’ai nombre d’ennui, mais celui-ci qui est la cause de pas mal de crash de mon serveur de production est de loin le plus ennuyeux : les données sont corrompues sur les disques… de façon aléatoire.
J’ai mis un moment pour cerner la cause … le temps de vérifier les deux disques utilisés en SATA, de checker la mémoire, puis de s’assurer que ce ne soit pas lié à l’usage de XEN ou du RAID… Maintenant, c’est clair, le problème apparaît sur une Linux de base fraîchement installé … pourquoi, c’est encore un grand mystere, mais donc attention à cette carte mère !!!

Ma config : ASUS P5B-VM (bios 901) avec core 2 duo underclocker (ca merde aussi à frequence normale) @ 1.6G / 4Go de Ram / 2 HD Sata 80Go. Kernel 2.6.18 (Opensuse 10.2)

Mise en evidence du problème :
xen-prod:/ # head –bytes=300m /dev/urandom > test
xen-prod:/ # for i in `seq 0 9` ; do cp test test$i ; done
xen-prod:/ # md5sum test*
014666c728c9e3b8299579fae499864a test
014666c728c9e3b8299579fae499864a test0
333fd93d093ac612cd8d5f65628f734e test1
1ab6ee68c6a7d9ff5a05f9d63f0f6df6 test2
96e96483e3175a59c9c05b6720514e1e test3
014666c728c9e3b8299579fae499864a test4
b24dbccc9f4831f8825ab4a55a3be4aa test5
8493efc9c14e4b5c162ac23696fbc16a test6
6a5f4301f66d0379049d79d0e14e2a87 test7
2c81cfa1c3a03aba134574922ee5d75c test8
2ea15c8392bfd0123472a80125bb3abe test9

Soit après copie, 70% des fichiers diffèrent de l’orignal !!

J’ai un peu tout essayé : desactivé le Memory remapping et me priver de 1.2G, passer le sata en mode “compatible” ; ext3 / reisefs … rien n’y fait !!!

Je suis a deux doigts d’aller m’acheter un autre carte mère, donc mon conseil, éviter celle-ci… et si vous avez une solution … contactez moi !
Après quelques recherches supplémentaires, en enlevant 2G le problème disparaît. la mémoire n’est pas en cause puisqu’en inversant les barrettes le problème n’apparaît plus non plus. C’est bien la carte mère (ou sa gestion sous linux) qui pose problème. J’avais lu des problèmes liés au chip ethernet, mais pas au contrôleur SATA … il y en a donc … Bref, au choix .. un serveur à 2Gb ou une nouvelle carte mère.. je crois que je vais tenter l’option n°2

Toujours quelques soucis de plus … sans quoi je m’ennuierai sans doute … Bref, depuis que je suis passé de l’opensuse 10.1 à 10.2 j’ai perdu pas mal de dB sur ma carte son.

Je ne suis pas totalement sure de la cause, mais si ça vous arrive, je peux vous proposer la solution suivante :
Choisir comme système de son OSS (dans le control-panel de KDE > Son et multimédia > Système de son > Matériel). Une fois le système de son relancé (il faudra peut être un petit kill des familles pour tuer l’ancien…) il est possible via Kmix de modifier le niveau des VIA-DXS, ils étaient grosso-modo à 0 … quand on les passe à quelque chose comme 75% … comme par hasard ça fonctionne 😉
Une fois ce paramétrage fait, il est aussi possible de positionner les valeurs des DXS par les commandes suivantes:

amixer set ‘VIA DXS’,0 85% unmute
amixer set ‘VIA DXS’,1 85% unmute
amixer set ‘VIA DXS’,2 85% unmute
amixer set ‘VIA DXS’,3 85% unmute

J’ai rencontré quelques soucis pour mettre à jour ma Suse 10.1 ; plus particulièrement pour configurer le serveur de mise à jour. En effet dans mon cas la procédure d’inscription par Yast n’a jamais voulu fonctionner. Bref … Voila comment configurer manuellement le serveur de mise à jour ..

Vous procédé comme pour l’installation d’un fournisseur de RPM quelconque mais choisissez les modes et options suivantes:

• HTTP
• nom du serveur : ftp.tu-chemnitz.de
• répertoire : /pub/linux/suse/ftp.suse.com/suse/update/10.1

Chez moi … ca fonctionne!

Suite à un crash encore inexpliqué, la base RPM d’un de mes serveur s’est retrouvée totalement corompue !!! Que faire dans un tel cas ?

Il existe bien quelques option magiques telles que rpm –rebuilddb mais bien sure ce fu sans succès pour moi. Impact de ce problème : impossible de reinstaller des packages partis en morceau lors d’une mise à jour …. ennuyeux quand il s’agit de la JVM sur un serveur web j2ee … Bref… quand plus rien ne marche, il faut sortir l’artillerie lourde.
Attention, ce qui suit s’approche d’une opération de type arakiri … chacun assumera donc ses responabilités si ca venait à sateliser votre serveur …. Pour ma part ca m’a sauvé la vie.
Bon bref… c’est à vos risques et périls.

Donc, pour s’en sortir, il faut degager la base corompue et en installer un neuve. La base se trouvant dans /var/lib/rpm il faut commencer par une petite copie de sauvegarde :
cd /var/lib
cp -R rpm rpm.old

Ensuite créer un nouvel espace pour la base neuve :
mkdir rpm ; mkdir rpm/alternatives
Maintenant on cré la nouvelle base :
rpm –initdb –dbpath /var/lib/rpm

Il ne reste plus qu’a reinstaller les package en vrac dans la base d’origine… Mais bien sur, les dépendence n’etant plus dans la nouvelle base il faudra force un peu les choses avec les options suivantes :
rpm -i –nodeps –force nom_du_package.rpm
Cela ne fonctionne que si les packages etaient deja installé, je veux dire si les dépendences sont bien présentes sinon il faudra les reconstruire en installant tout à la main …

A la fin, il est plutot mieux de revenir à l’ancienne version de bdd en recopiant dans l’autre sens….

Petit soucis semble-t-il avec la configuration du pare-feu de la Suse 10.2 en utilisation Serveur NFS. Lorsque le firewall est lancé sur le serveur le client n’arrivent plus à se connecter, y compris si une règle spécifique a été ajouté via yast…

La solution consiste à ajouter manuellement les ports utilisés par NFS : dans yast2 / pare-feu, allez dans la partie intitulée “Service autorisés” puis clicker sur “Avancé”. Il faut alors remplir dans Ports TCP 111 et dans port UDP 111 2049

Maintenant NFS fonctionne…

Lorsque l’on créé un serveur avec de multiples VM, toutes n’ont pas la même importance. Dans mon cas, le serveur de production de ce site est sur une VM elle même tournant sur un serveur de taille raisonnable que je partage avec d’autres VM dont la disponibilité et le temps de réponse sont moins critique comme des serveurs de test ou de développement par exemple.

La configuration du scheduleur de Xen permet d’associer des priorités différentes aux VM. L’ancien systeme utilisé par Xen etait basé sur la commande xm sched-sedf n’etant plus en vogue, c’est le scheduleur par crédit que j’utilise et dont je vous livre quelques éléments de configuration au travers des deux parametres de configuration :

• Tout d’abord le poids (weight), c’est une valeur 16 bits (0 à 65535) qui indique qu’une VM de poids 2 fois suppérieur à une autre aura 2 fois plus souvent le CPU. La valeur par defaut est 256. Pour changer le poids il faut utiliser les options : xm sched-credit -d [Domain] -w [valeur]
• Le second parametre (cap) indique l’utilisation maximum qu’un domaine va faire du CPU. Ainsi si le cap d’un domaine est fixé à 50, celui-ci ne pourra utiliser que 50% d’un CPU même si le CPU est disponible. La valeur 0 permet d’utiliser ce qui est disponible sans limite. La valeur est modifiée par la commande : xm sched-credit -d [Domain] -c [valeur]

Je ne sais pas trop d’où vient le probleme mais ma Suse 10.2 utilisée comme serveur de VM tournant sur la même version me pose quelques problemes d’horloge !!!
Mes VM ont à chaque fois 2h de décalage par rapport a l’hôte et il m’est impossible de modifier l’heure de la VM 🙁 pas glop ! J’ai finalement réussi à corriger cela, pas vraiment comme je l’aurai souhaité… mais apres tout cela fonctionne : j’utilise NTP pour resynchroniser l’horloge … voici le procédé en quelques étapes :

Il faut en premier faire en sorte que la VM puisse avoir une horloge différente du Domain-0. Pour cela il faut modifier d’une part le fichier /etc/sysctl.conf en ajoutant la ligne suivante : xen.independent_wallclock = 1. Cette commande permettra de positionner un flag à 1 au lancement du systeme. Pour que la prise en compte soit immédiate il faudra aussi positionner manuellement ce flag à 1 par la commande suivante : echo 1 > /proc/sys/xen/independent_wallclock.

Ensuite, il suffit de lancer Yast2 et de choisir l’activation du NTP dans les services réseaux.

Le tour est joué .. ma VM est à l’heure !!

Depuis que je suis passé sous open-suse 10.2 mon PC rame en passant son temps à grater le disque dur. Les process update-status et parse-metadata prenant 90% de CPU et balayant sans arret le HD…
Le probleme vient de ZEN-UPDATER, je pensais que Zen voulait dire que c’etait plus cool avec ben non ! moi la souris qui ratatine ca a le don de m’enerver… bref la solution est simple : virer tout ça !
Comment faire : jeter un oeil ici
A savoir:
La première chose à faire est de quitter Zen Updater (l?application qui vérifie la disponibilité des mises à jours et dont l?icône se trouve dans la boîte à miniatures du tableau de bord, à côté de l?horloge) en faisant un clic droit dessus ⇒ Quitter.

Ensuite, se rendre dans YaST ⇒ Logiciels ⇒ Installer et supprimer des logiciels et désinstaller ces packages :
* zmd
* libzypp-zmd-backend
* sqlite-zmd
* rug
* zen-updater

Activer openSUSE Updater (installer le package opensuse-updater, le cas échéant), via le Menu K ⇒ Système ⇒ Applet bureau ⇒ openSUSE Updater.

Il faut à présent se réenregistrer pour avoir les mises à jour en ligne : YaST ⇒ Logiciels ⇒ Configuration de la mise à jour en ligne.

A noter que la manip en version 10.1 est décrite ici
Il faudra donc faire ceci :
1) stop zen service (not required but more elegant):
Yast -> System -> System Services (runlevel) -> disable NOVELL zen

2) Enlever les paquets suivants :
libzypp-zmd-backend
zen-updater
ruby-zypp
rug
zmd
mono-core
mono-core-32bit
mono-data
mono-web
log4net
dbus-mono
glib-sharp2
gtk-sharp2