Difference between revisions of "Shrink Qcow2 Disk Files"

From Proxmox VE
Jump to: navigation, search
 
(27 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
[[Category:HOWTO]]
 
[[Category:HOWTO]]
Over time the *.qcow2 disk files can grow larger than the actual data stored within them. This can also happen faster if you defragment the drives within the XP VM itself. In order to shrink the *.qcow2 files, you'll need to zero out all free space of the drives within the XP VM first. Below are (very rough) notes on how to do this:
+
Over time a guest's *.qcow2 disk files can grow larger than the actual data stored within them, this happens because the Guest OS normally only marks a deleted File as zero, it doesn't gets actually deleted (performance reasons), so the underlying qcow2 file cannot differentiate between allocated and used and allocated but not used storage.
==Windows Guest Preparaton==
+
 
* Defragment your VM's Windows drives either by using the built in defragment program or a 3rd party one such as [http://www.piriform.com/defraggler Defraggler].
+
In order to shrink the *.qcow2 files you've two options, enable TRIM support or zero out all free space of the partitions contained within the guest and then reconvert the image with qemu-img.
* Download and install the latest [http://eraser.heidi.ie/ Eraser] inside the XP VM.
+
 
* Load Eraser.
+
'''IMPORTANT WARNING:''' Always have offsite backups ready, you never know!
** Edit main settings. Change default file erasure and unused space erasure methods to '''British HMG IS5 (Baseline) (1 pass)'''. This will zero out space instead of using random data.
+
 
** Create a new job under Erase Schedule and add the free space from the C:\ drive (and any other drive you want to shrink).
+
= Recommended Solution =
** Run the job.
+
The recommended version is to pass TRIM commands (known from SSDs) from the VM to the backing storage. This has the advantage that it works automatically, does not need to write the whole free parts of all disks to zero and must only be setup once.
** '''Note:''' I've had Eraser crash during this process. If this happens, it will leave a directory under the root of your drive with all sorts of random data in it. You'll want to delete this folder and start the process again. Keep running the process until it goes through without crashing. Hopefully the folks at Eraser are working on the stability of this new version.
+
==PVE Configuration==
 +
Requirements:
 +
* Thin-provisioned backing storage (qcow2 disk, thin-lvm, zfs, ...)
 +
* ''Virtio-SCSI'' controller configured on guest.
 +
* Guest scsi* disks with the ''discard'' option enabled
 +
* See [https://pve.proxmox.com/wiki/Qemu_trim/discard_and_virtio_scsi Qemu trim/discard and virtio scsi] for configuration details.
 +
[[File:SCSI Controller Type UI.png|750px|SCSI Controller Type]]
 +
 
 +
[[File:VM Disk Edit To SCSI.png|500px|VM Disk With SCSI And Discard]]
 +
==Linux Guest Configuration==
 +
Modern Linux guest systems can use the well known ''fstrim'' command to trim a device and free all unused storage on the underlying device:
 +
fstrim -av
 +
 
 +
Many modern Linux distributions have already setup a timer or cron job which executes a TRIM about once a week.
 +
==Windows Guest Configuration==
 +
For those Windows versions which support TRIM (Win7/2008R2 and up should be supported, see [https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-behavior this]) you should not have to setup anything, Windows should periodically trigger a TRIM to the disks.
 +
 
 +
You can see if TRIM is enabled with:
 +
fsutil behavior query DisableDeleteNotify
 +
 
 +
This should output ''0'' (zero) else set it with:
 +
fsutil behavior set DisableDeleteNotify 0
 +
 
 +
= Manual Solution =
 +
This solution is no longer necessary and is only needed on Windows XP and earlier and older Linux distributions that don't support fstrim.
 +
==Windows Guest Preparation==
 +
These steps are all performed within the Windows guest.
 +
* Defragment your Windows guest's drives either by using the built in defragment program or a 3rd party one such as [http://www.piriform.com/defraggler Defraggler] or [http://ultradefrag.sourceforge.net/en/index.html UltraDefrag].
 +
* Zero out the free space either using [http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx SDelete] ('''recommended''') or [http://eraser.heidi.ie/ Eraser] (using '''British HMG IS5 (Baseline) (1 pass)''').  
 +
===Zero Using SDelete===
 +
* Download [http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx SDelete] and save it somewhere on your system (eg. <code>C:\windows\system32\</code>).
 +
* Run SDelete and zero free space:
 +
<pre>
 +
sdelete -z
 +
</pre>
 +
* If there is more than one partition, then for eg., drive E:\, use:
 +
<pre>
 +
sdelete -z e:
 +
</pre>
 +
 
 +
==Linux Guest Preparation==
 +
Use the following command to zero out your disk:
 +
<pre>
 +
dd if=/dev/zero of=/mytempfile
 +
# that could take a some time
 +
rm -f /mytempfile
 +
</pre>
 +
 
 
==Shrink the Disk File==
 
==Shrink the Disk File==
 
* Shut down the VM.
 
* Shut down the VM.
* Log into the Proxmox shell and go to the VM's disk storage directory.
+
* Log into the Proxmox node and go to the VM's disk storage directory.
* '''Note:''' These next two steps assume that '''source''' is your original disk and '''shrunk''' us the new shrunken disk. Change the file names to meet your needs.
+
* '''IMPORTANT:''' Create a backup of your existing VM disk file:
 +
<pre>
 +
cp image.qcow2 image.qcow2_backup
 +
</pre>
 +
* '''Option #1:''' Shrink your disk without compression (better performance, larger disk size):
 
<pre>
 
<pre>
qemu-img convert -c -O qcow2 source.qcow2 shrunk.qcow2
+
qemu-img convert -O qcow2 image.qcow2_backup image.qcow2
 
</pre>
 
</pre>
* Backup the original disk file and move the shrunken disk into its place:
+
* '''Option #2:''' Shrink your disk with compression (smaller disk size, takes longer to shrink, performance impact on slower systems):
 
<pre>
 
<pre>
mv source.qcow2 source-bak.qcow2
+
qemu-img convert -O qcow2 -c image.qcow2_backup image.qcow2
mv shrunk.qcow2 source.qcow2
 
 
</pre>
 
</pre>
 +
* ''Example: A 50GB disk file I shrank without compression to 46GB, but with compression to 25GB. Time to compress was almost twice as long as an uncompressed shrink.
 
* Boot your VM and verify all is working.
 
* Boot your VM and verify all is working.
 
* When you verify all is well, it should be safe to either delete the backup of the original disk, or move it to an offline backup storage.
 
* When you verify all is well, it should be safe to either delete the backup of the original disk, or move it to an offline backup storage.

Latest revision as of 11:42, 20 March 2019

Over time a guest's *.qcow2 disk files can grow larger than the actual data stored within them, this happens because the Guest OS normally only marks a deleted File as zero, it doesn't gets actually deleted (performance reasons), so the underlying qcow2 file cannot differentiate between allocated and used and allocated but not used storage.

In order to shrink the *.qcow2 files you've two options, enable TRIM support or zero out all free space of the partitions contained within the guest and then reconvert the image with qemu-img.

IMPORTANT WARNING: Always have offsite backups ready, you never know!

Recommended Solution

The recommended version is to pass TRIM commands (known from SSDs) from the VM to the backing storage. This has the advantage that it works automatically, does not need to write the whole free parts of all disks to zero and must only be setup once.

PVE Configuration

Requirements:

  • Thin-provisioned backing storage (qcow2 disk, thin-lvm, zfs, ...)
  • Virtio-SCSI controller configured on guest.
  • Guest scsi* disks with the discard option enabled
  • See Qemu trim/discard and virtio scsi for configuration details.

SCSI Controller Type

VM Disk With SCSI And Discard

Linux Guest Configuration

Modern Linux guest systems can use the well known fstrim command to trim a device and free all unused storage on the underlying device:

fstrim -av

Many modern Linux distributions have already setup a timer or cron job which executes a TRIM about once a week.

Windows Guest Configuration

For those Windows versions which support TRIM (Win7/2008R2 and up should be supported, see this) you should not have to setup anything, Windows should periodically trigger a TRIM to the disks.

You can see if TRIM is enabled with:

fsutil behavior query DisableDeleteNotify

This should output 0 (zero) else set it with:

fsutil behavior set DisableDeleteNotify 0

Manual Solution

This solution is no longer necessary and is only needed on Windows XP and earlier and older Linux distributions that don't support fstrim.

Windows Guest Preparation

These steps are all performed within the Windows guest.

  • Defragment your Windows guest's drives either by using the built in defragment program or a 3rd party one such as Defraggler or UltraDefrag.
  • Zero out the free space either using SDelete (recommended) or Eraser (using British HMG IS5 (Baseline) (1 pass)).

Zero Using SDelete

  • Download SDelete and save it somewhere on your system (eg. C:\windows\system32\).
  • Run SDelete and zero free space:
sdelete -z
  • If there is more than one partition, then for eg., drive E:\, use:
sdelete -z e:

Linux Guest Preparation

Use the following command to zero out your disk:

dd if=/dev/zero of=/mytempfile
# that could take a some time
rm -f /mytempfile

Shrink the Disk File

  • Shut down the VM.
  • Log into the Proxmox node and go to the VM's disk storage directory.
  • IMPORTANT: Create a backup of your existing VM disk file:
cp image.qcow2 image.qcow2_backup
  • Option #1: Shrink your disk without compression (better performance, larger disk size):
qemu-img convert -O qcow2 image.qcow2_backup image.qcow2
  • Option #2: Shrink your disk with compression (smaller disk size, takes longer to shrink, performance impact on slower systems):
qemu-img convert -O qcow2 -c image.qcow2_backup image.qcow2
  • Example: A 50GB disk file I shrank without compression to 46GB, but with compression to 25GB. Time to compress was almost twice as long as an uncompressed shrink.
  • Boot your VM and verify all is working.
  • When you verify all is well, it should be safe to either delete the backup of the original disk, or move it to an offline backup storage.