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.
0 votes
J'ai récemment rencontré un problème similaire avec un invité KVM Ubuntu 11.04 (64 bits) sur un hôte KVM CentOS 5.6 (64 bits). C'est le seul invité 11.04 que j'ai et il s'est éteint sporadiquement. En vérifiant sa configuration avec mes autres invités, j'ai remarqué qu'un CDROM virtuel lui était associé. J'ai supprimé ce matériel à l'aide de virt-manager et j'ai redémarré, il est opérationnel depuis lors. C'est quelque chose à essayer si vous êtes désespéré.
0 votes
Dans mon cas, le gel des invités était dû au fait que le stockage sous-jacent sur l'hôte était plein...