Reduction of HDD space of a VM

[miranpiscanc]

Hello again, everyone. How is it possible that the allocated space for an HDD of a VM cannot be reduced when using an SSD connected via USB to the datacenter?

My VM uses only 250GB as the C: drive, so 350GB would be more than enough. However, when I initially created the VM and assigned the SSD to the machine, I used the entire 1TB available on the SSD. But this is a waste, not to mention that the backup is huge because it doesn’t just include the 250GB.

Additionally, when I try to move or clone the machine, it always fails—probably because transferring 1TB is too much.

There must be an easy solution, right? Thanks!

 

[Kingneutron]

Setup Proxmox Backup Server on separate hardware and take advantage of dedup.

Since you're using thin-provisioned storage, if you limit the partition table in-vm to 350GB, it should never grow beyond that size. The size in the PVE GUI is the *max* it would be allowed to grow to if you removed the in-vm constraint.

If you're detail-oriented and Really Need to limit the GUI-level representation of disk limit, you can backup the vm with e.g. Veeam Free Agent or AOMEI and restore it to another VM (or just replace the existing vdisk) with smaller disk size. This is fairly easy if you have a Samba share.

https://www.veeam.com/products/free/microsoft-windows.html

 

[avladulescu]

If your VM is in a qcow2 format, shut it down and use the following command:

> rsync -uitprvUHPS --no-W --inplace (source_path) (destination_path)

Re-run it a couple of times after it finished. The resulting qcow2 file will have the current size and not the set one.

Mind that latest versions of rsync are able to use sparse and inplace on the same time.

 

[miranpiscanc]

The VM format is in RAW, but I don't understand where this is defined, because I have another VM in qcow2, and its backup is much smaller compared to the VM in RAW. Could this be the issue?

 

[miranpiscanc]

As seen in the image, I have three VMs. The two in qcow2 format, each around 375G, have backups of 7G, while the one in RAW format, which is 322G, has a backup of about 300G.

 

[avladulescu]

RAW allocates the full space on the disk (file image) whereas qcow2 will gradually grow depending on the storage/images changes that took place inside the VM.

The backup size depends on the type of backup and format you are using. I would suggest using PBS in the end if possible.

One other point you could tackle this is to move the disk image from raw to qcow2, but mind that on higher disk sizes the process will be much faster if the VM is stopped rather than online and ofc take into consideration your backend storage IO as well as the limits you set in datacenter.cfg/datacenter options.

My first answer was for quickly transferring a VM image (stored as file - raw/qcow2), from a proxmox backend storage location to another one.

 

[gfngfn256]

while the one in RAW format, which is 322G, has a backup of about 300G.

That is normal - the raw format is not thin-provisioning.

The VM format is in RAW

To make that file smaller, you basically need todo 3 things:

1. Shrink the VM's partition within that raw file (safely!) to the required size.
2. Truncate that raw file to its correct size.
3. Do a qm rescan --vmid <VMID> to inform PVE of its new size.

You must have full & restorable backups when doing anything like this.
I have a similar tutorial on this procedure.

Why that VM's disk is created as a raw file vs a qcow2, is probably linked to the historic creation of that VM/disk. You could eventually use "Move disk" to "convert" it to a qcow2. See here.