On Wed, Oct 26, 2011 at 11:50 PM, Eric Blake
<eblake@redhat.com> wrote:
[re-adding the list]
On 10/26/2011 09:37 AM, 邱敏鈴 wrote:
linux distribution : linux2.6.35-30-server version : ubuntu10.10
virsh # version
Compiled against library: libvir 0.8.3
Using library: libvir 0.8.3
Using API: QEMU 0.8.3
Running hypervisor: QEMU 0.12.5
/var/log/libvirt/qemu/controlnode.log
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 1024 -smp
2,sockets=2,cores=1,threads=1 -name controlnode -uuid
ce48e7d5-de02-8faf-c829-9e000ca49b2b -nodefaults -chardev
socket,id=monitor,path=/var/lib/libvirt/qemu/controlnode.monitor,server,nowait
-mon chardev=monitor,mode=readline -rtc base=utc -boot c -drive
file=/vm/vm1/ubuntu-kvm/tmpkzLes0.qcow2,if=none,id=drive-ide0-0-0,boot=on,format=qcow2
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -device
virtio-net-pci,vlan=0,id=net0,mac=52:54:00:17:a2:d0,bus=pci.0,addr=0x3 -net
tap,fd=37,vlan=0,name=hostnet0 -usb -vnc 127.0.0.1:0 -vga cirrus -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4
bind(unix:/var/lib/libvirt/qemu/controlnode.monitor): Permission denied
chardev: opening backend "socket" failed
This part of the log looks suspicious. Could this be an installation issue, or perhaps AppArmor not configured correctly?
virsh # dumpxml controlnode
<domain type='kvm'>
<name>controlnode</name>
<uuid>ce48e7d5-de02-8faf-c829-9e000ca49b2b</uuid>
<memory>1048576</memory>
<currentMemory>1048576</currentMemory>
<vcpu>2</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='/vm/vm1/ubuntu-kvm/tmpkzLes0.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:17:a2:d0'/>
<source bridge='br0'/>
<target dev='vnet0'/>
<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>
</devices>
</domain>
virsh # managedsave-remove controlnode couldn't help!
Nothing in that XML jumped out as suspicious to me. And from the sound of your managedsave-remote not making a difference, my guess of a corrupt managed save image getting in the way is a red herring. I'm not sure what to suggest trying next. Maybe others can chime in...
Maybe can create a new VM & attached the disk on it and see whether it can start or not.. if it can mean the images is not corrupted..if not then bad luck..
Regards,
Peter