Just seen this with libvirt-0.7.1-12.fc12: $> virsh save rawhide-20090904 /var/lib/libvirt/images/rawhide-20090904.sav Domain rawhide-20090904 saved to /var/lib/libvirt/images/rawhide-20090904.sav $> virsh restore /var/lib/libvirt/images/rawhide-20090904.sav error: Failed to restore domain from /var/lib/libvirt/images/rawhide-20090904.sav error: internal error Timed out while reading monitor startup output from the qemu log file: sh: /var/lib/libvirt/images/rawhide-20090904.sav: Permission denied LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -S -M pc-0.11 -m 1024 -smp 1 -name rawhide-20090904 -uuid 137b3e14-9c53-c788-5763-9a16e6fa14c0 -monitor unix:/var/lib/libvirt/qemu/rawhide-20090904.monitor,server,nowait -boot c -drive file=/var/lib/libvirt/images/rawhide-20090904.img,if=virtio,index=0,boot=on,format=raw -net nic,macaddr=52:54:00:51:74:32,vlan=0,model=virtio,name=virtio.0 -net tap,fd=18,vlan=0,name=tap.0 -serial pty -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0 -k en-gb -vga std -incoming exec:cat char device redirected to /dev/pts/7 load of migration failed selinux: $> ausearch -m AVC -ts recent ---- time->Fri Oct 16 12:46:46 2009 type=SYSCALL msg=audit(1255693606.288:89): arch=c000003e syscall=59 success=yes exit=0 a0=7f56dc09f410 a1=7f56dc007350 a2=7f56dc006fb0 a3=7f56e88ded50 items=0 ppid=1 pid=15632 auid=0 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=6 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c58,c912 key=(null) type=AVC msg=audit(1255693606.288:89): avc: denied { read } for pid=15632 comm="qemu-kvm" path="/var/lib/libvirt/images/rawhide-20090904.sav" dev=dm-0 ino=3466530 scontext=system_u:system_r:svirt_t:s0:c58,c912 tcontext=unconfined_u:object_r:virt_image_t:s0 tclass=file Are we not re-labelling the save file before attempting to restore from it?
moving to F12VirtTarget - as bad is this is, it wouldn't stop us shipping and we haven't made any progress on fixing it
Actually the problem here is that we're not relabelling the save file when initially saving the guest. So the save file never gets the VM state written,and thus any later restore is doomed to fail.
*** This bug has been marked as a duplicate of bug 532654 ***