7:34 p.m.
Hi,
I had a 'domain' called APP03. I was performing auto snapshots each night using
/usr/bin/virsh snapshot-create APP03 .
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.
I have now realised that the qcow2 images are huge (1.1TB image but 80G inside the virtual
machine), I am assuming this is the snapshots tagged onto the virtual hard disk?
How do I reduce the size of those back to something realistic? I've removed old
snapshots from APP03 using virsh snapshot-delete APP03 '<snapshotidnumber>
Hope this makes sense
9:17 p.m.
On 08/20/2014 06:34 PM, Adam King wrote:
If it were still in the old APP03 domain, then 'virsh snapshot-delete
APP03 $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
Hi,
[Can you convince your mailer to wrap long lines?]
I had a 'domain' called APP03. I was performing auto snapshots each
night
using /usr/bin/virsh snapshot-create APP03 .
This creates an internal snapshot, where the state of the snapshot is
stored in the same qcow2 file as the current state.
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.
I have now realised that the qcow2 images are huge (1.1TB image but
80G 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 better
picture on all the snapshots stored in there.
How do I reduce the size of those back to something realistic? I've
removed old
snapshots from APP03 using virsh snapshot-delete APP03
'<snapshotidnumber>
1:51 a.m.
----- Original Message -----
From: "Eric Blake" <eblake(a)redhat.com>
To: "Adam King" <kinga(a)sghs.org.uk>, libvirt-users(a)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 each
night
using /usr/bin/virsh snapshot-create APP03 .
This creates an internal snapshot, where the state of the snapshot is
stored in the same qcow2 file as the current state.
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.
I have now realised that the qcow2 images are huge (1.1TB image but
80G 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 better
picture on all the snapshots stored in there.
How do I reduce the size of those back to something realistic? I've
removed old
snapshots from APP03 using virsh snapshot-delete APP03
'<snapshotidnumber>
If it were still in the old APP03 domain, then 'virsh
snapshot-delete
APP03 $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
7:52 a.m.
On 08/21/2014 12:51 AM, Adam King wrote:
----- Original Message -----
From: "Eric Blake" <eblake(a)redhat.com>
To: "Adam King" <kinga(a)sghs.org.uk>, libvirt-users(a)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(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.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
8:37 a.m.
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(a)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...
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.
10:15 a.m.
On 08/21/2014 07:37 AM, Adam King wrote:
> 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.
Better. Still have the long lines issue, but at least the quoting worked :)
> 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...
which, frankly, seems like a hack.
that page requires offline modification (and so does virt-sparsify).
But there IS a potential solution that can be done without taking the
guest offline: live storage migration with 'virsh blockcopy':
If APP01 is currently using (bloated) disk1.img, it is possible to do a
sequence of commands that still keeps APP01 running the whole time but
switches APP01 over to using a (brand-new, and therefore unbloated)
disk2.img with no impact to the guest contents. Right now, it's still
necessary to go through a transient domain (which highlights the risk
that qemu doesn't make the command restartable, so you don't want the
guest to go down during the window of the operation):
virsh domblklist APP01 # learn what strings you can use for $disk below
virsh dumpxml APP01 > tmp.xml # save the domain, to re-define it later
virsh undefine APP01 # go transient, to allow blockcopy
virsh blockcopy APP01 $disk /path/to/disk2.img --verbose --wait --pivot
$EDITOR tmp.xml # change disk1.img to disk2.img
virsh define tmp.xml # back to normal
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
3720
days inactive
3720
days old
5 comments
2 participants
participants (2)
-
Adam King -
Eric Blake