libvirt users - Jul 2017 - Re: Is there still no easier way to shrink a VM image?

Thanks for letting me know I'm not making myself clear, let me try again
with a few more specifics,  These are Windows VMs with three disk images for C:,
D: and L:.  To simplify I'll focus on the image for C: which had grown to
77G physical size on the hypervisor's ssd (I just double-checked that with
'ls -al' because qemu-img below says 70G, this image had two snapshots
at one time which may be the reason for the discrepancy).  qemu-img info
reports:



file format: qcow2
virtual size: 100G (107374182400 bytes)
disk size: 70G
cluster_size: 65536
Format specific information:
    compat: 0.10


I used Windows Server 2012r2 "Optimize" (defrag) and then reduced the
C: partition to about 67G in Disk Administrator leaving the remaining 33G as
unallocated.  Afterward I tried a web reference technique and  used Sysinternals
SDelete to zero the free space then used 'qemu-img convert -O qcow2
<original.qcow2> <new.qcow2>' to produce a physical image size
of 29G.  qemu-img info reports on "new.qcow2":


 file format: qcow2
virtual size: 100G (107374182400 bytes)
disk size: 29G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false


The issue is that the virtual size is still 100G.  I don't have the physical
disk space to allow approximately 12 images (all configured for a virtual size
of 100G) to grow to that size (6 VMs with C: and D: on a 1TB ssd, L: is on an
hdd which isn't an issue).  I need to change that virtual size number for
this image to 67 or 68G.  On the D: images I can drop to approximately 40G for
an aggregate total of about 650G for all six VMs - well within the 875G physical
size limitation that the ssd provides after overhead.


That's a long background to why I need to change the virtual disk size. 
Again, any alternatives would be much appreciated.


-----Original Message-----
From: Martin Kletzander <mkletzan@redhat.com>
To: Leroy Tennison <leroy.tennison@verizon.net>
Cc: libvirt-users <libvirt-users@redhat.com>
Sent: Tue, Jul 11, 2017 2:51 am
Subject: Re: [libvirt-users] Is there still no easier way to shrink a VM image?

On Tue, Jul 11, 2017 at 12:34:31AM -0500, Leroy Tennison
wrote:
>I have numerous qcow2 images which need to be reduced in size and have
>their maximum size (virtual size) reduced.  Physical disk space became
>so low that VMs "auto-paused" themselves, I moved enough images to
solve
>the immediate problem but need to rectify the underlying issue.  It
>seems that qcow[2] files are grown in size such that the data inside of
>them takes about 50-60% of the space (does anyone know the actual
>algorithm or how to control it?).  Given the total physical disk space
>on the hypervisors, I need something more restrictive.
>
I don't get it.  You have virtual size greater than the free space on
the physical storage and instead of the VM finding out you want the
guest OS to see it has no space at all?
>Our hypervisors are a mix of Ubuntu 14 or 16 LTS (qemu-img 2.2 or 2.5).
>After doing all the preparation (defragment, reduce OS partition size)
>"qemu-img resize" reports that shrinking isn't supported yet. 
My web
>research indicates that, to accomplish this,  I have to:
>
>    convert to raw
>
>    shrink the image
>
>    convert back to qcow[2]
>
>    increase the image size to provide for some growth
>
>I'm hoping I've missed something in my research and that someone
knows
>an easier way.  I don't feel constrained to qemu-img but this is a
>production environment precluding consideration of experimental
>software.  Virt-resize, guestfish or any other reasonable option is fine
>with me.  Solutions or ideas?  Thanks.
>
>_______________________________________________
>libvirt-users mailing list
>libvirt-users@redhat.com
>https://www.redhat.com/mailman/listinfo/libvirt-users

Alternative one: Disks are cheap! Buy one with 3tb and you have plenty of
headroom.

On 11 Jul 2017 5:40 p.m., "Leroy Tennison"
<leroy.tennison@verizon.net>
wrote:
> Thanks for letting me know I'm not making myself clear, let me try
again
> with a few more specifics,  These are Windows VMs with three disk images
> for C:, D: and L:.  To simplify I'll focus on the image for C: which
had
> grown to 77G physical size on the hypervisor's ssd (I just
double-checked
> that with 'ls -al' because qemu-img below says 70G, this image had
two
> snapshots at one time which may be the reason for the discrepancy).
>  qemu-img info reports:
>
> file format: qcow2
> virtual size: 100G (107374182400 bytes)
> disk size: 70G
> cluster_size: 65536
> Format specific information:
>     compat: 0.10
>
> I used Windows Server 2012r2 "Optimize" (defrag) and then reduced
the C:
> partition to about 67G in Disk Administrator leaving the remaining 33G as
> unallocated.  Afterward I tried a web reference technique and  used
> Sysinternals SDelete to zero the free space then used 'qemu-img convert
-O
> qcow2 <original.qcow2> <new.qcow2>' to produce a physical
image size of
> 29G.  qemu-img info reports on "new.qcow2":
>
>  file format: qcow2
> virtual size: 100G (107374182400 bytes)
> disk size: 29G
> cluster_size: 65536
> Format specific information:
>     compat: 1.1
>     lazy refcounts: false
>
> The issue is that the virtual size is still 100G.  I don't have the
> physical disk space to allow approximately 12 images (all configured for a
> virtual size of 100G) to grow to that size (6 VMs with C: and D: on a 1TB
> ssd, L: is on an hdd which isn't an issue).  I need to change that
virtual
> size number for this image to 67 or 68G.  On the D: images I can drop to
> approximately 40G for an aggregate total of about 650G for all six VMs -
> well within the 875G physical size limitation that the ssd provides after
> overhead.
>
> That's a long background to why I need to change the virtual disk size.
> Again, any alternatives would be much appreciated.
>
> -----Original Message-----
> From: Martin Kletzander <mkletzan@redhat.com>
> To: Leroy Tennison <leroy.tennison@verizon.net>
> Cc: libvirt-users <libvirt-users@redhat.com>
> Sent: Tue, Jul 11, 2017 2:51 am
> Subject: Re: [libvirt-users] Is there still no easier way to shrink a VM
> image?
>
> On Tue, Jul 11, 2017 at 12:34:31AM -0500, Leroy Tennison wrote:
> >I have numerous qcow2 images which need to be reduced in size and have
> >their maximum size (virtual size) reduced. Physical disk space became
> >so low that VMs "auto-paused" themselves, I moved enough
images to solve
> >the immediate problem but need to rectify the underlying issue. It
> >seems that qcow[2] files are grown in size such that the data inside of
> >them takes about 50-60% of the space (does anyone know the actual
> >algorithm or how to control it?). Given the total physical disk space
> >on the hypervisors, I need something more restrictive.
> >
>
> I don't get it. You have virtual size greater than the free space on
> the physical storage and instead of the VM finding out you want the
> guest OS to see it has no space at all?
>
> >Our hypervisors are a mix of Ubuntu 14 or 16 LTS (qemu-img 2.2 or 2.5).
> >After doing all the preparation (defragment, reduce OS partition size)
> >"qemu-img resize" reports that shrinking isn't supported
yet. My web
> >research indicates that, to accomplish this, I have to:
> >
> > convert to raw
> >
> > shrink the image
> >
> > convert back to qcow[2]
> >
> > increase the image size to provide for some growth
> >
> >I'm hoping I've missed something in my research and that
someone knows
> >an easier way. I don't feel constrained to qemu-img but this is a
> >production environment precluding consideration of experimental
> >software. Virt-resize, guestfish or any other reasonable option is fine
> >with me. Solutions or ideas? Thanks.
> >
>
> >_______________________________________________
> >libvirt-users mailing list
> >libvirt-users@redhat.com
> >https://www.redhat.com/mailman/listinfo/libvirt-users
>
> _______________________________________________
> libvirt-users mailing list
> libvirt-users@redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-users
>

OK, so you basically want to change the virtual size, ok.

When the domain is running you can use 'virsh blockresize', if it is
not, then 'virsh vol-resize' will do the trick.  You should, however,
make sure the filesystem size is changed first so that there is no
access outside the volume.