----- Original Message ----- From: "Eric Blake" <eblake@redhat.com> To: "Adam King" <kinga@sghs.org.uk>, libvirt-users@redhat.com Sent: Thursday, August 21, 2014 3:17:09 AM Subject: Re: [libvirt-users] virsh snapshot On 08/20/2014 06:34 PM, Adam King wrote:> Hi, >[Can you convince your mailer to wrap long lines?]> > I had a 'domain' called APP03. I was performing auto snapshots eachnight using /usr/bin/virsh snapshot-create APP03 .>This creates an internal snapshot, where the state of the snapshot isstored in the same qcow2 file as the current state.> I then wanted the domain to be called APP01 for clarity's sake, so Idid 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 inheritsfrom the old state.> > I have now realised that the qcow2 images are huge (1.1TB image but80G inside the virtual machine), I am assuming this is the snapshots tagged onto the virtual hard disk?>Most likely, yes. 'qemu-img info /path/to/file' will give you a betterpicture on all the snapshots stored in there.> > How do I reduce the size of those back to something realistic? I'veremoved old snapshots from APP03 using virsh snapshot-delete APP03 '<snapshotidnumber>>>If it were still in the old APP03 domain, then 'virsh snapshot-deleteAPP03 $name', where 'virsh snapshot-list APP03' will show you the list of names. But given that you renamed to APP01, libvirt probably is unaware of the snapshots; so you'll have to do more legwork. You can use qemu-img snapshot -d to delete the snapshots yourself, or you can use 'virsh snapshot-create[-as] --redefine ...' to temporarily create a snapshot with the right name so that you can then do 'virsh snapshot-delete' (probably more effort than it's worth, so I'd stick with raw qemu-img commands). Don't do this while the guest is running - using qemu-img is only safe for an offline image. -- 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 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 {����}���{�l6�z�Sa�ׂP��2ZZ �e�j��~_��� ^.���=I��=n�ӱ��5��^F���*��v�6��Oc�JfH-[,~9�/̫��%O�cn�2��V䴘t n��]m�UC2d� 2.4G 2096-06-18 11:54:302089366:21:24.846 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 0 1970-01-01 01:00:00 00:00:00.000 APP03 is down but APP01 needs to be up. What exactly is the qemu-img command I need? Thanks
On 08/21/2014 12:51 AM, Adam King wrote:> > ----- Original Message ----- > From: "Eric Blake" <eblake@redhat.com> > To: "Adam King" <kinga@sghs.org.uk>, libvirt-users@redhat.com > Sent: Thursday, August 21, 2014 3:17:09 AM > Subject: Re: [libvirt-users] virsh snapshotIncluding 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 dayWorse, 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�wOuch. 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. 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
> 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-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.