Bug 524268 - KVM guest fails to start up after virt-snapshot in Fedora12
KVM guest fails to start up after virt-snapshot in Fedora12
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: virt-v2v (Show other bugs)
12
x86_64 All
low Severity high
: ---
: ---
Assigned To: Matthew Booth
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-18 11:40 EDT by IBM Bug Proxy
Modified: 2010-04-06 11:49 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-04-06 11:49:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 56293 None None None Never

  None (edit)
Description IBM Bug Proxy 2009-09-18 11:40:39 EDT
=Comment: #0=================================================
SANTWANA SAMANTRAY <santwana.samantray@in.ibm.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
Comment 1 Mark McLoughlin 2009-09-21 10:31:29 EDT
Sounds like we need to chmod o+x /var/lib/virt-snapshot/images ?
Comment 2 Richard W.M. Jones 2009-09-21 10:38:38 EDT
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?
Comment 3 Matthew Booth 2009-09-21 18:30:48 EDT
Re Comment #2: I don't recall that conversation.
Comment 4 Matthew Booth 2009-09-21 18:37:36 EDT
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 5 IBM Bug Proxy 2009-09-22 04:20:45 EDT
------- Comment From anoop.vijayan@in.ibm.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@in.ibm.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!
Comment 6 Richard W.M. Jones 2009-09-22 05:06:58 EDT
(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).
Comment 7 Matthew Booth 2009-09-30 09:47:17 EDT
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.
Comment 8 Matthew Booth 2009-09-30 09:48:30 EDT
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.
Comment 9 Mark McLoughlin 2009-10-02 11:49:03 EDT
Taking this off F12VirtBlocker, sounds like we're not encouraging people to use this v2v-snapshot tool
Comment 10 Matthew Booth 2009-10-02 13:36:31 EDT
We are encouraging its use. Only for v2v, though.
Comment 11 Matthew Booth 2009-10-05 09:01:54 EDT
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.
Comment 12 Bug Zapper 2009-11-16 07:37:15 EST
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
Comment 13 Vedran Miletić 2009-12-04 13:26:53 EST
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 14 IBM Bug Proxy 2010-01-07 04:00:45 EST
------- Comment From santwana.samantray@in.ibm.com 2010-01-07 03:58 EDT-------
Hi,

This issue is still existing in the Fedora12-GA release.

Thanks,
Santwana
Comment 15 Matthew Booth 2010-01-07 04:43:47 EST
Yes. I haven't pushed a new release in a while. I'll re-open this bug to track.
Comment 16 Matthew Booth 2010-04-06 11:49:22 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.