Como faço para investigar um convidado KVM sem resposta?

Question

Que passos posso dar para investigar um convidado do KVM que congela uma vez a cada duas semanas? Por "congela", quero dizer que não há resposta quando tento conectar com "ssh" ou "console virsh". O host é o Ubuntu (natty, 11.04), usando o libvirt para gerenciar seus convidados, e o convidado é o Ubuntu (natty, 11.04), ambas as edições do servidor sem gerenciador de janelas instalado.

Se eu forçar o convidado a reiniciar, funciona bem por mais uma semana. Não há mensagem recente ou relevante no syslog do convidado (para indicar um pânico no kernel, etc). Pelo que sei, pode ser que a rede virtual e o tty estejam quebrando e me impedindo de falar com o convidado. O host administra três outros hóspedes quase idênticos que permaneceram estáveis durante todo o ano. Se o próprio convidado está falhando, não deveria haver alguma indicação no syslog?

O disco é um volume lvm lógico configurado com o 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>

    

Answer 1

Investigar esses tipos de problemas é realmente difícil porque você precisa isolar diferentes recursos da configuração e testá-los - o que é muito difícil em uma configuração commplex e como a repro é um processo de duas semanas.

A primeira coisa a fazer é configurar o syslog para enviar os logs pela rede para um serviço syslog remoto (possivelmente aquele executado no host - você precisaria ativar o acesso à iluminação remota no servidor syslog) para permitir que você detecte erros que não entraram no log de convidados devido a espaço livre de armazenamento ou problemas de sincronização.

Se isso não fornecer informações úteis, você pode tentar conectar-se ao console serial convidado ( insira a descrição do link aqui veja aqui para detalhes) e registre qualquer coisa que aconteça a um arquivo de log no host.