Am Freitag, 25. Juni 2010 schrieb Daniel P. Berrange:
On Fri, Jun 25, 2010 at 06:08:07PM +0200, Guido Winkelmann wrote:
This is the guest's XML config: ===================== <domain type='kvm'> <name>testserver-a</name> <uuid>ce57ebe0-ea37-0353-bbe0-e23dbbd17708</uuid> <description>libvirt C-API Test</description> <memory>262144</memory> <currentMemory>262144</currentMemory> <vcpu>1</vcpu> <os> <type arch='x86_64' machine='pc-0.13'>hvm</type> <boot dev='hd'/>
[snip]
=====================
(as found in /usr/local/etc/libvirt/qemu/)
and here are the last few lines from the logfile (/usr/local/var/log/libvirt/qemu/testserver-a.log):
Have you set any LIBVIRT_LOG environment variables or set any of the logging settings in /etc/libvirt/libvirtd.conf ? If so, which ones ? Your log file contains alot of stuff I wouldn't normally expect to be there & I wonder if there is a verbose logging level enabled that is causing a buffer overflow somewhre ?
I have log_level = 1 in /usr/local/etc/libvirt/libvirtd.conf. [...]
affinity 17:21:14.803: debug : qemuSecurityDACSetProcessLabel:546 : Dropping privileges of VM to 0:0 Supported machines are: pc Standard PC (alias of pc-0.12) pc-0.12 Standard PC (default) pc-0.11 Standard PC, qemu 0.11 pc-0.10 Standard PC, qemu 0.10 isapc ISA-only PC
This is the ultimate problem - your guest XML lists 'pc-0.13', so I assume you must have deployed this guest with a newer QEMU and now trying to start it with an older one.
Could be... I've been switching from qemu-kvm release 0.12.4 to git and back a couple of times, mostly because libvirt used to silently require support of the "-nodefconfig" option in qemu until a couple of commits ago...
Changing the XML to list one of these valid machine types should let you start the guest
Undefining and redefining the guest domains (without an explicit machine type) made it possible to start them again. IMHO, though, the segfault is a separate issue, and still should not have happened. Guido