Situation horrible - systèmes de fichiers montés simultanément par plusieurs instances de système d'exploitation indépendantes

Comment sortir de cette situation en toute sécurité?

Les détails sont les suivants:

Un serveur xen a des périphériques de bloc alloués aux machines virtuelles. Mais ces appareils ont également été montés à l'intérieur de Xen.

En fait, 44 de ces dispositifs à blocs ont été montés comme ceci. Pour aggraver les choses, chaque périphérique physique est vu sur 4 chemins et chacun d'entre eux est monté sur un point de montage séparé. En d'autres termes, les appareils sont en fait montés 5 fois chacun.

Le système d'exploitation invité VM voit le chemin via un pseudo périphérique PowerPath (alloué en tant que périphérique phy: block au domU)

Certains appareils sont formatés en ext2 et reiserfs.

Pas besoin de m'expliquer les risques de corruption du système de fichiers impliqués ici.

Je crains que même le simple démontage des systèmes de fichiers puisse entraîner une corruption et je pense qu'à ce stade, couper l'alimentation de l'hôte est l'option la plus sûre .

Notez que les applications, les bases de données Oracle pour la plupart, dans toutes les machines virtuelles sont toujours en cours d'exécution et en cours d'utilisation.

J'ai découvert cela en étudiant une utilisation élevée du processeur sur le dom0. Il existe un processus de "recherche" impossible à éliminer, avec cwd -> / media / disk-12 qui est monté à partir de / dev / sdf1, qui appartient à / dev / emcpowerr

Avant que quiconque ne le demande, la seule fois où j'ai vu des processus ne peut pas être tué et continuer à utiliser le CPU et la RAM (contrairement à un processus défunt / zombie), c'est quand il y a des E / S validées en attente, par exemple une synchronisation retournée mais pas encore physiquement sur le disque . Le plus souvent, cela se produit sur les E / S de bande.

Suggestions!?

PS Je me serais attendu à ce que les appareils soient "réservés" une fois montés, pour éviter ce genre de chose? Ou n'est-ce pas possible sous Linux?

EDIT: Tout d'abord, je suis convaincu que KDE au sein de l'hyperviseur) est le coupable. Il semble que KDE monte les périphériques qu'il peut lors de la journalisation pour créer des icônes de bureau. La même chose ne se produit cependant pas sur les autres serveurs Xen, mais tous les autres serveurs exécutent une version beaucoup plus ancienne de SLES et KDE ... V4 semble être la version incriminée, la 3.4 se comportant mieux).

De plus, deux machines virtuelles non critiques ont été bloquées. Après les avoir arrêtés, ils ne redémarreraient pas en raison d'une corruption du système de fichiers. La machine virtuelle principale / de production est toujours en cours d'exécution et la base de données sur elle fonctionne toujours, mais il s'agit clairement d'une bombe à retardement. Le client tente de reconstruire l'environnement sur une autre machine virtuelle sur un autre serveur mais est bloqué par des problèmes de configuration de certains composants, nous attendons donc ...

En tout cas, j'estime qu'aucune des réponses n'a jusqu'à présent été plus que "les meilleures pratiques sont toujours fermées gracieusement" et j'espère obtenir quelque chose de plus concret ... En tout cas, j'estime que cette situation mérite une attention en pensant. L'arrêt entraînera-t-il la synchronisation des E / S en cours, en particulier les mises à jour des métadonnées du système de fichiers de l'hyperviseur, et entraînera-t-il une corruption potentiellement majeure du système de fichiers?

Si les disques sont en cours d'écriture à partir d'un seul point de montage, aucun dommage n'est fait. Faites un arrêt propre, (sauvegardez-le de l'état suspendu si vous voulez) réparez les supports. N'exécutez rien d'autre que les applications nues nécessaires sur le Dom0. Si, OTOH, les partitions sont écrites à partir de plusieurs chemins, c'est MAUVAIS et empire par la seconde. Débrancher.

Je n'ai aucune raison concrète mais mon intuition me dit que ce qui suit peut être la meilleure approche:

1. Fermez les applications.
2. Copiez toutes les données de la machine virtuelle via le réseau vers un emplacement de sauvegarde.
3. Démontez les systèmes de fichiers depuis la machine virtuelle.
4. Arrêtez la machine virtuelle. (Il n'y a qu'une seule machine virtuelle en cours d'exécution sur cet hôte maintenant).
5. Assurez-vous qu'aucun domU n'est configuré pour démarrer automatiquement.
6. Coupez l'alimentation de l'hôte pour empêcher l'hyperviseur d'effectuer des actions de «fermeture», de synchronisation des E / S en attente, etc.
7. Démarrez la machine virtuelle, en espérant que l'hyperviseur lui-même ait survécu au coup sec.
8. En cas d'échec, reconstruisez l'environnement. (Les disques de démarrage des VM sont basés sur des fichiers, mais les points de montage des données résident sur un disque externe alloué en tant que périphériques de bloc)
9. Vérifiez si l'hyperviseur monte des systèmes de fichiers appartenant aux domU. Démontez-les avant de démarrer les domU)
10. Désactivez le montage automatique de KDE.
11. Démarrez la machine virtuelle et forcez une vérification FS complète.

Alternative à 11: démarrez la machine virtuelle et montez les systèmes de fichiers sans fsck complet.

Le raisonnement est que je ne veux pas que l'hyperviseur Xen ait plus de chance qu'absolument nécessaire pour provoquer la corruption sur les systèmes de fichiers domU.

Je ne suis pas un expert Xen et je n'avais encore aucune expérience avec cela. Mais mon approche si j'étais à votre place serait: d'abord je sais que je pourrais perdre des données (peut-être même toutes); Deuxièmement, j'essayais de créer des instantanés, puis de suspendre les machines virtuelles, en les restaurant dans un environnement différent et sûr.
Je ne veux pas vous donner de faux espoirs, mais je pense que vous aurez de la chance si vous pouvez récupérer quoi que ce soit.

Attention : suivre ces conseils pourrait vous faire perdre toutes les données. C'est à vous de voir si cela vaut le risque ou non.

Avec beaucoup de chance, vos applications fonctionnent toujours car les données qu'elles utilisent sont toutes en mémoire volatile. Vous devriez essayer de tirer parti de cette situation (essayez d'évaluer si cela pourrait être le cas par application) et d'exporter les données en direct vers un partage réseau si les applications offrent une telle fonctionnalité. Si des données se trouvent sur le disque, cette fonction d'exportation peut être "verrouillée" un peu comme votre findinstruction ou planter (et planter l'application ou le système d'exploitation) en raison des données de disque modifiées / corrompues.

Ensuite, vous pouvez essayer de créer un instantané en direct, selon les instructions de l'article suivant: Création d'instantanés dans Xen . J'irais pour l'instantané octet par octet, bien qu'il puisse se coincer un peu comme votre findcommande ... Cependant, je ne donnerais pas autant d'espoir.

Avant d'exécuter la commande précédente, vous devez lire ce document de Citrix qui vous aide à comprendre les instantanés dans Xen (PDF) .

Je te souhaite bonne chance.