[libvirt-users] virsh start VM failed

[vmnode guy]

On Wed, Oct 26, 2011 at 11:50 PM, Eric Blake <eblake at 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...
>
>
> --
> Eric Blake   eblake at redhat.com    +1-801-349-2682
> Libvirt virtualization library http://libvirt.org
>


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20111026/1dffb3bc/attachment.htm>