J'ai un serveur exécutant Xen 4.1 avec Oneiric dans le dom0 et chacun des 4 domUs. Les disques système des domUs sont des volumes LVM2 construits au-dessus d'un RAID1 mdadm.
Tous les disques système du domU sont EXT4 et sont créés à partir d'instantanés du même modèle d'origine. Trois d'entre eux fonctionnent parfaitement, mais l'un d'entre eux (appelé s-ub-02) continue à être remonté en lecture seule. Un nouveau e2fsck aboutit à un seul diagnostic "étendue invalide" :
e2fsck 1.41.14 (22-Dec-2010)
/dev/domu/s-ub-02-root contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 525418 has an invalid extent
(logical block 8959, invalid physical block 0, len 0)
Clear<y>? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/domu/s-ub-02-root: 77757/655360 files (0.3% non-contiguous), 360592/2621440 blocksLa console affiche généralement les erreurs suivantes pour le disque système (xvda2) :
[101980.903416] EXT4-fs error (device xvda2): ext4_ext_find_extent:732: inode #525418: comm apt-get: bad header/extent: invalid extent entries - magic f30a, entries 12, max 340(340), depth 0(0)
[101980.903473] EXT4-fs (xvda2): Remounting filesystem read-onlyJ'ai créé de nouvelles versions du disque système. La même chose se produit toujours. Ceci, et le fait que le disque est finalement sur un RAID1, me conduit à exclure une erreur de disque matériel.
Le seul élément distinctif évident de ce domU est la présence de nfs-kernel-server donc je le soupçonne. C'est exports ressemble à ceci :
/exports/users 192.168.0.0/255.255.248.0(rw,sync,no_subtree_check)
/exports/media/music 192.168.0.0/255.255.248.0(rw,sync,no_subtree_check)
/exports/media/pictures 192.168.0.0/255.255.248.0(rw,sync,no_subtree_check)
/exports/opt 192.168.0.0/255.255.248.0(rw,sync,no_subtree_check)/exports/users y /exports/opt sont des volumes LVM2 du même groupe de volumes que le disque système. /exports/media est un volume EXT2. (Il y a un problème où les clients voient /exports/media/pictures comme étant un volume en lecture seule, ce que je mentionne par souci d'exhaustivité).
À l'exception du problème de lecture seule, le serveur NFS semble fonctionner correctement sous une charge légère pendant plusieurs heures avant que le problème "invalid extent" ne survienne.
Il n'y a pas d'entrées utiles dans /var/log . Tout d'un coup, plus aucun fichier n'est écrit. Vous pouvez donc voir quand le disque a été remonté en lecture seule, mais il n'y a aucune indication de ce que pourrait être la cause.
Quelqu'un peut-il m'aider à résoudre ce problème ?
Steve
0 votes
Je ne sais pas exactement quel domaine gère quels appareils. Voulez-vous dire que dom0 exécute mdadm sur les disques réels, ou que les dumUs exécutent mdadm sur les disques virtuels ?
0 votes
Le dom0 exécute mdadm (un simple RAID1 avec 2 disques de 465 Go) sous /dev/md0. LVM2 sur le dom0 utilise /dev/md0 comme un volume physique pour créer un groupe de volumes appelé "domu". Les disques du système sont créés dans domu et transmis aux domUs sous la forme /dev/xvdaN, etc.
0 votes
J'ai examiné de plus près les inodes qui ont été signalés comme ayant des extents invalides. Ils correspondent à /var/cache/apt/pkgcache.bin, /var/lib/dpkg/info/nfs-kernel-server.list, /var/cache/apt/srcpkgcache.bin, et /var/lib/apt/lists/security.ubuntu.com_ubuntu_dists_oneiric-security_universe_source_Sources. Il semble que ce soit un problème lié à apt. Mais apt ne cause aucun problème sur les autres domUs...
0 votes
Vous ne passez pas le même LV à plusieurs domUs, n'est-ce pas ?
0 votes
Non, je ne le suis pas. Bien que j'aie essayé une fois. Ce serait cool si on pouvait faire ça avec des partitions en lecture seule. Mais je m'égare.
0 votes
Il semble de plus en plus que le problème ait quelque chose à voir avec APT, même si je ne comprends pas pourquoi cela s'est produit ici et pas dans les autres UD. Je ne comprends pas non plus pourquoi cela s'est produit dans plusieurs instanciations différentes du même domU. Tout pointe vers NFS, mais le problème vient d'APT ? Se pourrait-il qu'il y ait un problème avec l'emballage de nfs-kernel-server ? J'ai commencé à utiliser apt-cacher-ng, j'ai fait une mise à jour apt-get et j'ai maintenant plus de 38 heures de temps de fonctionnement, ce qui est un record pour ce domU ;-)
0 votes
Je pensais que vous transmettiez des LV aux domU pour les utiliser comme disques virtuels. Où se situe le NFS dans ce contexte ?
0 votes
@psusi Les domUs ont des fonctions spécifiques : 1) serveur de base de données ; 2) serveur de fichiers utilisateur ("cloud") ; 3) serveur web ; 4) outils de développement. Chacun possède un disque système, cloné à partir d'un modèle avec des fonctionnalités communes, et un ou plusieurs autres disques. Le nuage fournit à chaque utilisateur un stockage de fichiers accessible par WebDAV à l'extérieur du pare-feu et par NFS au sein du réseau local. Les clients du réseau local utilisent NFS pour accéder au nuage. Cependant, l'enfant à problème - le nuage - fonctionne sans problème depuis plus de 4 jours. Je pense que le problème est résolu. Je ne sais pas pourquoi mais je pourrais écrire une réponse avec mes suppositions.
0 votes
J'ai finalement résolu ce problème en abandonnant ext4 et en revenant à ext3 après que ext4 ait recommencé à jouer. Il y a quelque chose de bizarre qui se passe dans cette VM particulière, mais je ne peux pas passer plus de temps à essayer de trouver ce que c'est.