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