Re: [libvirt-users] virsh snapshot

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(a)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.