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...


--
Eric Blake   eblake@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