7 votes

Comment puis-je enquêter sur un invité KVM qui ne répond pas ?

Quelles mesures puis-je prendre pour examiner un invité KVM qui se fige environ une fois toutes les deux semaines ? Par "gel", je veux dire qu'il n'y a aucune réponse lorsque j'essaie de me connecter avec "ssh" ou "virsh console". L'hôte est Ubuntu (natty, 11.04), utilisant libvirt pour gérer ses invités, et l'invité est Ubuntu (natty, 11.04), deux éditions serveur sans gestionnaire de fenêtres installé.

Si je force l'invité à se réinitialiser, il fonctionne bien pendant une autre semaine. Il n'y a aucun message récent ou pertinent dans le syslog de l'invité (pour indiquer une panique du noyau, etc.). Pour ce que j'en sais, il se peut que le réseau virtuel et le tty soient en panne et m'empêchent de parler à l'invité. L'hôte exécute trois autres invités, presque identiques, qui ont été stables toute l'année. Si l'invité lui-même tombe en panne, ne devrait-il pas y avoir une indication dans le syslog ?

Le disque est un volume logique lvm configuré avec virtio

% cat /etc/libvirt/qemu/vm-et.xml

    <domain type='kvm'>
      <name>vm-et</name>
      <uuid>8df572f1-e1dc-275a-4b9f-b7c322e2f5d3</uuid>
      <memory>2048576</memory>
      <currentMemory>2048576</currentMemory>
      <vcpu>1</vcpu>
      <os>
        <type arch='x86_64' machine='pc-0.12'>hvm</type>
        <boot dev='hd'/>
      </os>
      <features>
        <acpi/>
      </features>
      <clock offset='utc'/>
      <on_poweroff>destroy</on_poweroff>
      <on_reboot>restart</on_reboot>
      <on_crash>destroy</on_crash>
      <devices>
        <emulator>/usr/bin/kvm</emulator>
        <!--<disk type='file' device='disk'>
          <driver name='qemu' type='qcow2'/>
          <source file='/usr/scratch/appliances/vm-et/ubuntu-kvm/tmpzwV0x3.qcow2'/>
          <target dev='hda' bus='ide'/>
          <address type='drive' controller='0' bus='0' unit='0'/>
        </disk>-->
        <controller type='ide' index='0'>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
        </controller>
        <interface type='bridge'>
          <mac address='52:54:00:5a:1f:b4'/>
          <source bridge='br0'/>
          <model type='virtio'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
        </interface>
        <input type='mouse' bus='ps2'/>
        <graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1'/>
        <video>
          <model type='cirrus' vram='9216' heads='1'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
        </video>
        <memballoon model='virtio'>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
       </memballoon>
        <disk type='file' device='disk'>
          <source file='/dev/vg1/lv-et'/>
          <target dev='vda' bus='virtio'/>
        </disk>

        <serial type="pty">
          <source path="/dev/pts/3"/>
          <target port="1"/>
        </serial>

      </devices>
    </domain>

0 votes

Voici la configuration de qemu

0 votes

Avez-vous essayé de vous connecter avec vnc ? D'après mon expérience, même sur les noyaux en panne, vous pouvez lire les derniers messages du système (qui ne sont pas entrés dans le syslog).

0 votes

Essayez-vous de vous connecter via une adresse IP directe, ou par un nom d'hôte qui dépend du DNS ? J'ai souvent rencontré des problèmes de connectivité dans des environnements où le DNS n'était pas tout à fait à la hauteur, et où une recherche de nom d'hôte échouée m'envoyait sur une fausse piste. La KVM est-elle pingable lorsqu'elle ne répond plus ? Comment l'adresse IP de la KVM a-t-elle été attribuée ? A-t-elle été correctement attribuée par DHCP, ou était-elle codée en dur ? Il se peut qu'il y ait un conflit d'adresse IP sur le réseau et qu'un autre ordinateur ou appareil réponde à l'adresse IP que le KVM pense posséder.

1voto

Martin Woodward Points 9972

Il est très difficile d'enquêter sur ce type de problèmes car il faut isoler les différentes caractéristiques de la configuration et les tester, ce qui est très difficile sur une configuration aussi complexe et la reproduction prend deux semaines.

La première chose à faire est de configurer le syslog pour qu'il envoie les journaux par le réseau à un service syslog distant (peut-être celui qui fonctionne sur l'hôte - vous devrez activer l'accès au transfert à distance sur le serveur syslog) pour vous permettre d'attraper les erreurs qui n'ont pas été enregistrées dans le journal de l'invité en raison d'un espace de stockage libre ou de problèmes de synchronisation.

Si cela ne donne aucune information utile, vous pouvez essayer de vous connecter à la console série de l'invité ( voir ici pour les détails ) et enregistre tout ce qui s'y passe dans un fichier journal sur l'hôte.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X