Hi
Before posting this I ve read all 10 posts about shrinking disks but none of them seemed to be the <<<correct>>> officially approved way, so I thought to give it one more try.
Backend info: PVE is installed in a mirror zfs and the VM is a win 10 test machine installed on the local-zfs which is thin-provisioned . Attached are 2 .raw disks from local-zfs as well 32gb each, disk-0 for the OS and disk-1 for data.
VM installation options Default (i440fx) and Default (SeaBIOS)
My use case scenario is to shrink the disk-1 from 32gb to 20gb and see what needs to be done in order for those changes to be visible to VM and PVE as well,
Failed attempts: First I tried to check the naming scheme of the disk 1 from the hardware options menu of the VM which brought me to local-zfs:vm-110-disk-1
Commands
qm resize 110 /dev/zvol/rpool/data/vm-110-disk-1 -- -10G failed to recognize the command
qm resize 110 /dev/zvol/rpool/data/vm-110-disk-1 --shrink -10G failed to recognize the command
qemu-img resize -f raw /dev/zvol/rpool/data/vm-110-disk-1 --shrink -10G failed to recognize the command
which makes me wondering if the above commands are for qcow2 disk images only?
What I consider to be successful was:
Inside the Win VM -> disk partition and after defragmentation (not a good idea for ssd drives maybe for spinners sas - sata a better thought) I shrunk the 32gb to 20gb which left me with 12gb (numbers here are integers, there are always differentiations with the actual and shown disk space for many reasons I won t mention here) unpartitioned
disk space which was what I was expecting. But the point is ... the unpartitioned space to be non existent there.
Afterwards shutted down the VM went to cli and with
zfs list found the path for the disk I wanted to shrink rpool/data/vm-110-disk-1
So with command
zfs set volsize=20G rpool/data/vm-110-disk-1 made the disk image 20Gb. (Tried at that point to start the VM back on again but the unpartitioned space was still there)
Afterwards (since on gui the image still shows 32gb) issued the command
nano /etc/pve/qemu-server/110.conf and changed the line
scsi1: local-zfs:vm-110-disk-1,cache=writeback,discard=on,size=32G to scsi1: local-zfs:vm-110-disk-1,cache=writeback,discard=on,size=20G
After saving changes restarted the node and the next time I turned win VM on again the unpartitioned space had been reduced from 12Gb to 0.8Gb which was fine. It needs a lot of fining in order to be able to disappear at all the unpartitioned space (at least I think this way)
What I didn t do and don t know if it would help is set the refreservation parameter to 0 from none and another thing that I could have done but don t know if and where it would help (maybe not restarting the node?) was to issue the command qm rescan -vmid 110 (maybe this way I wouldn t have to edit the /etc/pve/qemu-server/110.conf file??)
Anyway is my approach a valid one?
Were all the steps I did necessary?
Anything I could omit or add to make my procedure more valid?
Is there any relevance between the storage to be thin-provisioned and the ability to be shrunk?
PS By the way maybe it plays an important role if the VM is installed in bios or uefi mode because of the sector that the partition is written. Bios writes it's info at the initial place of the disk (which is good for a shrink procedure), while in uefi mode the info is written at the last part of the partition and I don t know if I would be able to shrink the partition and still the VM to be bootable afterwards.
Thank you in advance!!
Before posting this I ve read all 10 posts about shrinking disks but none of them seemed to be the <<<correct>>> officially approved way, so I thought to give it one more try.
Backend info: PVE is installed in a mirror zfs and the VM is a win 10 test machine installed on the local-zfs which is thin-provisioned . Attached are 2 .raw disks from local-zfs as well 32gb each, disk-0 for the OS and disk-1 for data.
VM installation options Default (i440fx) and Default (SeaBIOS)
My use case scenario is to shrink the disk-1 from 32gb to 20gb and see what needs to be done in order for those changes to be visible to VM and PVE as well,
Failed attempts: First I tried to check the naming scheme of the disk 1 from the hardware options menu of the VM which brought me to local-zfs:vm-110-disk-1
Commands
qm resize 110 /dev/zvol/rpool/data/vm-110-disk-1 -- -10G failed to recognize the command
qm resize 110 /dev/zvol/rpool/data/vm-110-disk-1 --shrink -10G failed to recognize the command
qemu-img resize -f raw /dev/zvol/rpool/data/vm-110-disk-1 --shrink -10G failed to recognize the command
which makes me wondering if the above commands are for qcow2 disk images only?
What I consider to be successful was:
Inside the Win VM -> disk partition and after defragmentation (not a good idea for ssd drives maybe for spinners sas - sata a better thought) I shrunk the 32gb to 20gb which left me with 12gb (numbers here are integers, there are always differentiations with the actual and shown disk space for many reasons I won t mention here) unpartitioned
disk space which was what I was expecting. But the point is ... the unpartitioned space to be non existent there.
Afterwards shutted down the VM went to cli and with
zfs list found the path for the disk I wanted to shrink rpool/data/vm-110-disk-1
So with command
zfs set volsize=20G rpool/data/vm-110-disk-1 made the disk image 20Gb. (Tried at that point to start the VM back on again but the unpartitioned space was still there)
Afterwards (since on gui the image still shows 32gb) issued the command
nano /etc/pve/qemu-server/110.conf and changed the line
scsi1: local-zfs:vm-110-disk-1,cache=writeback,discard=on,size=32G to scsi1: local-zfs:vm-110-disk-1,cache=writeback,discard=on,size=20G
After saving changes restarted the node and the next time I turned win VM on again the unpartitioned space had been reduced from 12Gb to 0.8Gb which was fine. It needs a lot of fining in order to be able to disappear at all the unpartitioned space (at least I think this way)
What I didn t do and don t know if it would help is set the refreservation parameter to 0 from none and another thing that I could have done but don t know if and where it would help (maybe not restarting the node?) was to issue the command qm rescan -vmid 110 (maybe this way I wouldn t have to edit the /etc/pve/qemu-server/110.conf file??)
Anyway is my approach a valid one?
Were all the steps I did necessary?
Anything I could omit or add to make my procedure more valid?
Is there any relevance between the storage to be thin-provisioned and the ability to be shrunk?
PS By the way maybe it plays an important role if the VM is installed in bios or uefi mode because of the sector that the partition is written. Bios writes it's info at the initial place of the disk (which is good for a shrink procedure), while in uefi mode the info is written at the last part of the partition and I don t know if I would be able to shrink the partition and still the VM to be bootable afterwards.
Thank you in advance!!
Last edited: