Назад | Перейти на главную страницу

Как проверить, не отвечает ли гость KVM?

Какие шаги я могу предпринять, чтобы исследовать гостя KVM, который зависает примерно раз в две недели? Под «зависанием» я подразумеваю, что нет ответа, когда я пытаюсь подключиться с помощью «ssh» или «virsh console». Хост - это Ubuntu (natty, 11.04), использующий libvirt для управления своими гостями, а гостевой - Ubuntu (natty, 11.04), обе серверные версии без установленного оконного менеджера.

Если я заставлю гостя сбросить настройки, он будет работать нормально еще неделю. В гостевом системном журнале нет недавних или соответствующих сообщений (для обозначения паники ядра и т. Д.). Насколько я знаю, может случиться так, что виртуальная сеть и tty ломаются и мешают мне разговаривать с гостем. Хозяин управляет тремя другими, почти идентичными гостями, которые стабильны в течение всего года. Если сам гость дает сбой, не должно ли быть какой-то индикации в системном журнале?

Диск представляет собой логический том lvm, настроенный с помощью 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>

Исследовать такие проблемы действительно сложно, потому что вам нужно будет изолировать различные функции установки и протестировать их, что очень сложно при такой сложной установке, и поскольку воспроизведение занимает две недели.

Первое, что нужно сделать, это настроить системный журнал для отправки журналов по сети в удаленную службу системного журнала (возможно, тот, который работает на хосте - вам нужно будет включить удаленный доступ к пересылке на сервере системного журнала), чтобы вы могли для обнаружения ошибок, которые не попали в гостевой журнал из-за свободного места в хранилище или проблем с синхронизацией.

Если это не дает никакой полезной информации, вы можете попробовать подключиться к гостевой последовательной консоли (подробности здесь) и записывать все, что там происходит, в файл журнала на хосте.