Red Hat Bugzilla – Bug 498750
RFE: Add a 'managed' save/restore/snapshot libvirt API
Last modified: 2010-04-14 10:59:54 EDT
virsh restore doesn't seem to work.
I do a save to a file, that completes, shuts down the kvm guest and saves the file.
Doing a restore gives:
[root@theleb libvirt]# virsh restore /var/lib/libvirt/test-snap-20090502
error: Failed to restore domain from /var/lib/libvirt/test-snap-20090502
error: operation failed: failed to start VM
Happy to test or provide more info.
Also, as a side note, the virt-manager doesn't seem to have a restore option, only save.
Kevin - could you attach /var/log/libvirt/qemu/test-snap-20090502.log ? Also, any AVCs ? Please also attach the guests XML config
Well, there is no /var/log/libvirt/qemu/test-snap-20090502.log file. ;(
The name of the guest was "lucius", but the lucius.log file there is empty. ;(
Ah, I do see avcs however. Will attach them.
I tried another restore after 'setenforce 0' and got the same error.
This time there is something in the lucius.log file however:
qemu_popen: returning result of qemu_fopen_ops
migrate "exec:dd of='/tmp/testsave' oflag=append conv=notrunc 2>/dev/null"
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin /usr/bin/qemu-kvm -S -M pc -m 512 -smp 2 -name lucius -uuid e25534db-201a-f519-7445-e7e187ab02e1 -monitor pty -pidfile /var/run/libvirt/qemu//lucius.pid -boot c -drive file=,if=ide,media=cdrom,index=2 -drive file=/var/lib/libvirt/images/lucius-2.img,if=virtio,index=0,boot=on -drive file=/var/lib/libvirt/images/extra-f10.img,if=virtio,index=1 -net nic,macaddr=54:52:00:3c:97:9e,vlan=0,model=virtio -net tap,fd=22,script=,vlan=0,ifname=vnet2 -serial pty -parallel none -usb -vnc 127.0.0.1:2 -k en-us
char device redirected to /dev/pts/4
char device redirected to /dev/pts/5
* CPU #0: pc=0x00000000000ffff0 thread_id=15442
CPU #1: pc=0x00000000000ffff0 thread_id=15444
Created attachment 342326 [details]
Created attachment 342327 [details]
I believe this is a bug, and users should not be allowed to specify where the snapshot is going to be stored.
For example kevin specified to have libvirt write data to /tmp and then have qemu_t append to it? Not even shore if qemu_t is actually trying to append or is this a leaked file descriptor?
While libvirt allows arbitrary file paths, this can't be expected to work with SELinux enforcing.
In the future we have plans for a 'managed' save/restore/snapshot API, where libvirtd decides where the files are stored, and not the user. In the meantime, users running SELinux should expect to use a path known to SELinux policy, like /var/lib/libvirt/qemu
Moving to upstream libvirt tracker, then
*** Bug 479857 has been marked as a duplicate of this bug. ***
cf, this idea upstream
I've started work on this, though I still have a ways to go.
DV ended up doing this as a separate interface, and it went in upstream. Moving to POST.
This was released as part of 0.8.0, so I'll close this out as CURRENTRELEASE.