<font color='black' size='2' face='arial'>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:
<div><br>
</div>

<div>
<div>file format: qcow2</div>

<div>virtual size: 100G (107374182400 bytes)</div>

<div>disk size: 70G</div>

<div>cluster_size: 65536</div>

<div>Format specific information:</div>

<div>    compat: 0.10</div>

<div><br>
</div>

<div>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.  <span style="font-size: 13.3333px;">Afterward I tried a web reference technique and</span><span style="font-size: 13.3333px;"> </span><span style="font-size: 10pt;"> 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":</span></div>

<div><br>
</div>

<div> file format: qcow2</div>

<div>virtual size: 100G (107374182400 bytes)</div>

<div>disk size: 29G</div>

<div>cluster_size: 65536</div>

<div>Format specific information:</div>

<div>    compat: 1.1</div>

<div>    lazy refcounts: false</div>

<div><br>
</div>
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.</div>

<div><br>
</div>

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

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