[libvirt-users] virsh snapshot

[Eric Blake]

On 08/21/2014 12:51 AM, Adam King wrote:
> 
> ----- Original Message -----
> From: "Eric Blake" <eblake at redhat.com>
> To: "Adam King" <kinga at sghs.org.uk>, libvirt-users at redhat.com
> Sent: Thursday, August 21, 2014 3:17:09 AM
> Subject: Re: [libvirt-users] virsh snapshot

Including this blurb in the reply was overkill.

> 
>> > I then wanted the domain to be called APP01 for clarity's sake, so I
> did virsh dumpxml APP03 > APP03.xml, edited the name to APP01 and
> changed the ID. I then did virsh define APP03.xml to get APP01.
> 
>> >Yes, this achieves the goal of defining a new domain name that inherits
> from the old state.

Your quoting is horrible.  You used the same prefix for your original
content as for my reply (">> >" in both cases).  I'm not sure what
mailer you are using, but it is making conversation difficult.

> 
> -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization
> library http://libvirt.org Thanks for the response. I'll look at the
> text wrap. Before you responded I ran virsh snapshot-list APP01 to find
> no snapshots. I then ran virsh snapshot-list APP03 to find one per day

Worse, you put your new content AFTER a line containing just "-- ".  Any
compliant email would have stripped the "-- " and all subsequent lines
as the signature before letting you edit to add your reply.  But because
your mailer didn't do that, your entire content appeared as if it were a
signature, which meant when I hit "reply-all", your content was omitted
from my edit window.  I had to hit "ctrl-a" to select the entire
message, then "reply-all" to reply to the selected text, but that in
turn triggers a Thunderbird bug that anything selected with a trailing
space gets line-wrapped in the reply; and because the signature line "--
" has a trailing space, you can see how botched the reply looks.  So I'm
having to do a lot of manual work just to get a sane repesentation of
your reply before I can even answer it.

> 
> Thanks for the response. 
> I'll look at the text wrap. 
> Before you responded I ran virsh snapshot-list APP01 to find no snapshots.

That's as I thought.  By creating a new domain, you've discarded all of
libvirt's tracked information about the image.  The snapshots themselves
aren't gone, just libvirt's tracking of the snapshots.

> I then ran virsh snapshot-list APP03 to find one per day for 3 months...
> APP03 was shutdown so I used awk to pull out the snapshot ID's. 
> I from a file I then ran 
> while read line
> do
> virsh snapshot-delete APP03 $line
> done </file
> 
> Leaving just 1 snapshot
> 
> I have run qemu-img info on the file as you said, here's the output
> 
> qemu-img info /virtual/APP03-c.qcow2 
> image: /virtual/APP03-c.qcow2
> file format: qcow2
> virtual size: 80G (85899345920 bytes)
> disk size: 987G
> cluster_size: 65536
> Snapshot list:
> ID        TAG                 VM SIZE                DATE       VM CLOCK
> �K�‘�Q�w���q���
U�
�eInh�ik�{K
?�M�w

Ouch.  That's a qemu bug.  Qemu should never report uninitialized data
like that.  I don't know if you kept the original file around, but this
sort of garbage should be reported to qemu-devel at nongnu.org.

Also, be aware that snapshot deletion does NOT shrink the listed disk
size of a file, although with newer qemu, it DOES punch holes so that
the amount of disk space actually occupied by the file is smaller. Or
put another way, qemu-img (which is all the more libvirt snapshot-delete
is using) does not know how to compact an image after deleting snapshots
(no one has yet written a qcow2 defragmenter, although such a thing
should be technically doable).  In your situation, I'd highly recommend
looking into virt-sparsify from libguestfs - that's a program that is
designed to copy (or even attempt in-place) disk images so that the copy
doesn't need as large of a file size.

> 
> APP03 is down but APP01 needs to be up. 
> What exactly is the qemu-img command I need?

Wait.  So you have APP01 still up and running, AND using the same disk
image as what the APP03 definition points to, AND you modified the
image?  That's a recipe for disaster.  You _cannot_ safely modify a
qcow2 image by two simultaneous processes, and the fact that APP01 is a
running qemu process means that the only _safe_ way to delete snapshots
from that image is via qemu commands triggered through the libvirt
process managing that qemu process.  Maybe that explains the corrupted
display from qemu-img.  I hope you didn't corrupt your data too badly.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 539 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20140821/efe803ac/attachment.sig>