[libvirt-users] virsh snapshot

[Adam King]

> 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.


OK, let's see if this is better. Turned out my email app wasn't doing text wrap and quoting prefix default was bizarre....my apologies.

> 
> > 
> > -- 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.

I'll pass this on as a bug, certainly not best practice leading up to this though.

> 
> 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.
> 

That certainly does sound useful. I have found http://serverfault.com/questions/329287/free-up-not-used-space-on-a-qcow2-image-file-on-kvm-qemu
which, frankly, seems like a hack. 

> > 
> > 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.
> 

Looking back, that does seem rather a silly thing to do, corruption wise the majority of it is ok (fingers crossed), with the rest being restorable.  

Thanks again.