when migrating to SMB/CIFS the disk expands.

[aristosv]

In my home lab, I have a 2 Proxmox servers. I have added an SMB/CIFS storage on both hosts and defined it as "Disk Image" content.

I also have a VM on one of the hosts, with a 120GB disk. But the actual size of that disk is 20GB, my guess is because it's thin provisioned and it only expands as required.

When I try to migrate that VM on the SMB/CIFS storage, the resulting file is 120GB. So, when migrating to SMB/CIFS the VM disk expands.

How can I avoid this, and keep the size of the disk to 20GB?

 

[gfngfn256]

On what local host storage is that VM disk stored?
Is it a qcow2 or a raw?

 

[aristosv]

The local storage is "LVM-Thin"
The disk format is "raw"

 

[gfngfn256]

So, the LVM-Thin (as its' name suggests) has its' own built-in thin-provisioning in the storage itself, so even with that .raw file format, the underlying storage accomplishes the thin-provisioning.

However your SMB/CIFS storage which is a plain FS type storage (not block device) has no thin-provisioning of its' own.
If the file were to be a .qcow2 type this has its' own implementation of thin-provisioning (using copy-on-write).

You may consider converting the raw file to a qcow2 type to accomplish this. You probably want to trim that disk (within it's VM) before doing that. You would use the qemu-img convert command to accomplish this.

 

[aristosv]

instead of migrating a VM, I created a new one on the shared storage and selected the qcow2 format. Unfortunately, it seems that the size on the disk is again 120GB.

 

[gfngfn256]

To see how much the image is actually using, try qemu-img info vm-100-disk-0.qcow2

 

[Kingneutron]

You have to give it the full path tho

updatedb; for disk in $(locate *.qcow2); do qemu-img info "$disk"; done

for disk in $(locate *.qcow2); do qemu-img info "$disk" |egrep 'image|format| size|compression'; echo '====='; done

 

[aristosv]

ok, so the command shows that the file size is 2.34GiB.



but again, the space it takes up on the storage is 120GiB

 

[aristosv]

hmm...maybe not. I don't know how to interpret this.

 

[gfngfn256]

I knew we would eventually get to this rabbit-hole, and have already made my mind up not to go there.
Search this forum & the WWW on this topic!

Good luck.

Sample post.

 

[Kingneutron]

hmm...maybe not. I don't know how to interpret this.

View attachment 79771

What, you don't believe the evidence right in front of your eyes? You've got TWO DIFFERENT THINGS on Linux and Windows(!) telling you the actual size on disk is a little over 2.3GiB. What you see when you do an ' ls ' is the "allocated" or "reserved" size. This is the paradigm of using thin-provisioned storage.

You should also know going forward, du has an --apparent-size option that comes in handy with ZFS:
.
https://serverfault.com/questions/3...now-real-file-size-on-zfs-with-compression-on

/ztoshtera12/ztoshtera12-proxmox-multi/images/128 # ls -l
total 301448182
drwxr----- 2 root root            3 Dec 25 14:44 .
drwxr-xr-x 3 root root            3 Sep 22 12:08 ..
-rw-r----- 1 root root 376883380224 Dec 25 18:53 vm-128-disk-1.raw

root /ztoshtera12/ztoshtera12-proxmox-multi/images/128 # du -h # ACTUAL space being taken up on disk at the moment - can grow to the "allocated limit"
288G    .

root /ztoshtera12/ztoshtera12-proxmox-multi/images/128 # du --apparent-size -h # What applications see / what they can actually address in a thin-provisioned / growable disk
352G    .