=Comment: #0================================================= SANTWANA SAMANTRAY <santwana.samantray.com> - KVM guest fails to start up after virt-snapshot in Fedora12 rawhide(k.v- 2.6.31-14.fc12.x86_64) Machine: x3650, x3550 While the guest is shutdown, then do: virt-snapshot <guest> After that start the guest, it fails with an error: Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/engine.py", line 567, in run_domain vm.startup() File "/usr/share/virt-manager/virtManager/domain.py", line 652, in startup self.vm.create() File "/usr/lib64/python2.6/site-packages/libvirt.py", line 293, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: internal error unable to start guest: qemu: could not open disk image /var/lib/virt-snapshot/images/f12_guest-vda-1253257370.qcow2 Versions Installed: qemu-0.10.92-1.fc12.x86_64 qemu-system-x86-0.10.92-1.fc12.x86_64 libvirt-0.7.1-1.fc12.x86_64 libvirt-devel-0.7.1-1.fc12.x86_64 virt-manager-0.8.0-3.fc12.noarch
Sounds like we need to chmod o+x /var/lib/virt-snapshot/images ?
Didn't we agree _not_ to call this program virt-snapshot just yet, because of the potential for confusion with a general purpose libvirt-based snapshotting program?
Re Comment #2: I don't recall that conversation.
The permissions on /var/lib/virt-snapshot/images *should* be 0755, which should be sufficient if the commands were run as root. It's possible to run virt-snapshot as a regular user, but you need to fiddle with directory permissions. Were all commands run as root? Alternatively, it's possible that there was no problem accessing the snapshot, but instead there was a problem accessing the backing store (iirc these result in the same error message). Right now, libvirt doesn't correctly set the SELinux context correctly on a backing store the same way as it does for the volume itself. Does it work if you try again with SELinux in permissive mode? If so, could you please post the AVC message?
------- Comment From anoop.vijayan.com 2009-09-22 04:17 EDT------- [root@mx3650b ~]# getenforce Disabled [root@mx3650b ~]# ls -l /var/lib/libvirt/images/f12_guest.img -rw------- 1 root root 12884901887 2009-09-22 13:29 /var/lib/libvirt/images/f12_guest.img [root@mx3650b ~]# virsh list --all Id Name State ---------------------------------- - f12_guest shut off [root@mx3650b ~]# virsh start f12_guest Domain f12_guest started [root@mx3650b ~]# ls -l /var/lib/virt-snapshot/images/ total 0 [root@mx3650b ~]# virt-snapshot f12_guest [root@mx3650b ~]# ls -l /var/lib/virt-snapshot/images/ total 136 -rw------- 1 root root 262144 2009-09-22 13:37 f12_guest-vda-1253606872.qcow2 [root@mx3650b ~]# virt-snapshot --rollback f12_guest [root@mx3650b ~]# ls -l /var/lib/libvirt/images/f12_guest.img ls: cannot access /var/lib/libvirt/images/f12_guest.img: No such file or directory [root@mx3650b ~]# virsh list --all Id Name State ---------------------------------- - f12_guest shut off [root@mx3650b ~]# virsh start f12_guest error: Failed to start domain f12_guest error: cannot set ownership on /var/lib/libvirt/images/f12_guest.img: No such file or directory ------- Comment From anoop.vijayan.com 2009-09-22 04:20 EDT------- Redhat, Could you please give a little more detail on the usage of virt-snapshot? Is it supposed to be used when the vm is shutdown? Adding a few examples to the man pages would really help. Thank you!
(In reply to comment #5) > Redhat, > Could you please give a little more detail on the usage of virt-snapshot? Is it > supposed to be used when the vm is shutdown? Adding a few examples to the man > pages would really help. Yes. Specifically, the current virt-snapshot that we're talking about here cannot take snapshots of live domains yet. That would require libvirt to cooperate with the underlying hypervisor so that one could snapshot memory and disk at the same time. This is the reason I think we should rename this virt-snapshot with some other name, until we get the real virt-snapshot (which would be part of libvirt).
I have renamed virt-snapshot to v2v-snapshot. I will also improve the documentation with better worked examples, and make it much more obvious that this tool only works on shutdown guests. I will also consider making the tool check that a live domain is shutdown before creating a snapshot for it.
For me, the most disturbing part of #5 is that rollback deleted both the snapshot and the backing store. I have replicated this and am working on it.
Taking this off F12VirtBlocker, sounds like we're not encouraging people to use this v2v-snapshot tool
We are encouraging its use. Only for v2v, though.
I've now pushed 4 changes relating to this bug: 1. Rename virt-snapshot to v2v-snapshot 2. Improve documentation with worked examples, and stress that guest must be shut down. 3. When doing a rollback, check that a volume is a snapshot volume before deleting it. 4. Refuse to run v2v-snapshot or virt-v2v against a guest which isn't shut down. I think this addresses everything. These changes will all be in the next release.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The VERIFIED, FAILS_QA and RELEASE_PENDING bug states are not used by Fedora (they are used in the RHEL process). I'm closing this bug ahead of time. It is possibly fixed, but Reporter, if you can reproduce it using a current version of Fedora (version 12), please reopen it. --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
------- Comment From santwana.samantray.com 2010-01-07 03:58 EDT------- Hi, This issue is still existing in the Fedora12-GA release. Thanks, Santwana
Yes. I haven't pushed a new release in a while. I'll re-open this bug to track.
After fixing this bug, this functionality has now been entirely removed from virt-v2v. Instead, virt-v2v will always copy disk images prior to conversion.