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