[libvirt-users] Is there still no easier way to shrink a VM image?

[Dominik Psenner]

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 at 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 at redhat.com>
> To: Leroy Tennison <leroy.tennison at verizon.net>
> Cc: libvirt-users <libvirt-users at 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 at redhat.com
> >https://www.redhat.com/mailman/listinfo/libvirt-users
>
> _______________________________________________
> libvirt-users mailing list
> libvirt-users at redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20170711/1631f5b7/attachment.htm>