[SOLVED] Didn't give VM a big enough hard drive - Best way to fix it?

H

headband

New Member
Jun 10, 2025
27
0
1
I have an Ubuntu Server VM that I initially gave 64GB to but it has quickly outgrown it. The local-lvm that it's using for the VM disk has extra space on it so I'd like to expand the VM Disk and then somehow also expand the disk inside of the virtual machine itself. All without losing data, of course. Is this possible? What's the best practice here for backing everything up in case I make a mistake?

Thanks!
 
Backup your VM, resize the vhdd afterwards and use live tools like gparted or similar to expand the partition within the VM to the new size.
 
  • Like
Reactions: headband
cwt said:
Backup your VM, resize the vhdd afterwards and use live tools like gparted or similar to expand the partition within the VM to the new size.
Click to expand...
This sounds like a solid plan to me, what's the best way to resize my vhdd?
 
Great thank you, I'll check that out!

Is a snapshot of my VM a good enough backup before I do this?
 
A snapshot is not a backup but for me personally it would be enough of a safely precaution as long as all actions are done inside the VM such as here. But seriously, have backups.
 
Last edited:
  • Like
Reactions: Kingneutron and headband
Ok I went to resize the disk this morning and was given this prompt which is apparently very confusing:

1757691040498.png

I assumed it was asking me the total size I wanted so I put 128, it increased the size of the drive BY 128GB making it 192GB in size which is larger than the physical disk that the lvm is on. I cannot figure out how to reduce the size back down to the 128GB I intended, does anyone else know how? I'm afraid to reduce the size and lose data. The disk started as 64GB and I just added 128GB. I want it to be 128GB total.

Thanks!
 
Hi headband,

well, you will need to reduce the disk size via cli.

Reducing the disk size from GUI is not possible, as far as I know, because that can be a error prone procedure.
(Depending on the disk type and the filesystem within the VM)

For assistance it would be helpful, if you give some information on the kind of filesystem you use within the VM,
an the kind of format the disk image (raw or qcow2) has.
Is the filesystem within the VM already increased? And is this the os disk?

And before you start further with any action, beside rolling back to your backup/snapshot, you should now do a backup.
Therefore you can add the backup capability to a file storage under (Datacenter configuration -> Storage -> local | other filestorage) and use the build in backup functionality. (VM -> Backup -> "Backup now")

(I started to use btrfs as filesystem within vms for that reason a while a ago)

BR, Lucas
 
  • Like
Reactions: headband
bl1mp said:
Hi headband,

well, you will need to reduce the disk size via cli.

Reducing the disk size from GUI is not possible, as far as I know, because that can be a error prone procedure.
(Depending on the disk type and the filesystem within the VM)

For assistance it would be helpful, if you give some information on the kind of filesystem you use within the VM,
an the kind of format the disk image (raw or qcow2) has.
Is the filesystem within the VM already increased? And is this the os disk?

And before you start further with any action, beside rolling back to your backup/snapshot, you should now do a backup.
Therefore you can add the backup capability to a file storage under (Datacenter configuration -> Storage -> local | other filestorage) and use the build in backup functionality. (VM -> Backup -> "Backup now")

(I started to use btrfs as filesystem within vms for that reason a while a ago)

BR, Lucas
Click to expand...
Thanks for the advice!

Would it be ok if I left the VM's disk size (as set in proxmox) larger than the LVM disk itself but only expand it by what's actually available?

I originally wanted to add 64GB to the existing 64GB so if the above is ok my plan is to use this command to expand the LVM inside of the VM:

Code: 
lvresize --size +64G --resizefs /dev/{volume group name}/root
 
Last edited:
The best thing you can do is to restore a snapshot/backup from before. I often forget to mention doing that before messing around with this stuff. If you have none then you'd have to shrink the file system inside first (which can't be done while mounted) and then the volume. For that I do recommend a live iso.
It's not optimal but you can also just leave it like this as LVM-Thin/local-lvm is thin provisioned. Just make sure discard works properly and you set up warning notifications. In this case I'd probably alter the fstrim timer to run at least every day.
 
Last edited:
  • Like
Reactions: Kingneutron and headband
Impact said:
The best thing you can do is to restore a snapshot/backup. Otherwise you'd have to shrink the file system inside first (which can't be done while mounted) and then the volume. For that I do recommend a live iso.
It's not optimal but you can also just leave it like this as LVM-Thin/local-lvm is thin provisioned. Just make sure discard works properly and you set up warning notifications.
Click to expand...
Sorry I think I may not be explaining clearly.

- The local-lvm itself has a total of 151.64GB available in Proxmox.
- The VM's drive was orginally set to use 64GB of this in Proxmox, and the VM is using all of it.
- I accidentally expanded VM's drive in Proxmox from 64GB to 192GB (64+128, was trying to set it to 128GB)
- I didn't do anything inside of the VM yet

Would it be best for me to:
- Resize the VM's drive in Proxmox down to the 128GB I intended (I don't think this would require shrinking the file system since I haven't done anything in the VM yet and this would still be much larger than the VM's current drive)
or
- Just leave the VM's drive in Proxmox as 192GB (larger than the 151.64 available) but only expand it by the +64GB I originally intended inside of the VM and then never expand it beyond that so I don't go over what the physical drive is capable of.

Thanks!
 
Last edited:
The important part was that the LV size is not shrinked smaller than the PV/"partition table"/file system inside the VM.
In this case you can simply lvresize the LV of the VM to 128G. qm rescan afterwards might update the size in the config file or you can do that yourself.
If you show me lsblk -o+FSTYPE,MODEL, lvs and qm config VMIDHERE I can craft you a command. Do a backup before. We use a backup here because we work outside of the VM and have the power to destroy a snapshot.
 
Last edited:
  • Like
Reactions: headband
Impact said:
yourself. The important part was that the LV size is not smaller than the PV/"partition table"/file system inside the VM.
In this case you can simply lvresize the LV of the VM to 128G. qm rescan afterwards might update the size in the config file or you can do that yourself.
If you show me lsblk -o+FSTYPE,MODEL, lvs and qm config VMIDHERE I can craft you a command. Do a backup before.
Click to expand...
Great, thanks a ton!

I'm pretty green so sorry for the dumb question but what is the best way to do a backup? I've only ever used Snapshot.

Here is the output of those commands. Really appreciate the help!

Code: 
root@proxmox:~# lsblk -o+FSTYPE,MODEL
NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS FSTYPE      MODEL
sda                            8:0    0  12.7T  0 disk                         WDC WUH721414ALE600
├─sda1                         8:1    0  12.7T  0 part             zfs_member 
└─sda9                         8:9    0     8M  0 part                        
sdb                            8:16   0   9.1T  0 disk                         WDC WD101EFBX-68B0AN0
├─sdb1                         8:17   0   9.1T  0 part             zfs_member 
└─sdb9                         8:25   0     8M  0 part                        
sr0                           11:0    1  1024M  0 rom                          hp PLDS DVDRW DU8AESH
nvme0n1                      259:0    0 238.5G  0 disk                         PC601 NVMe SK hynix 256GB
├─nvme0n1p1                  259:1    0  1007K  0 part                        
├─nvme0n1p2                  259:2    0     1G  0 part /boot/efi   vfat       
└─nvme0n1p3                  259:3    0 237.5G  0 part             LVM2_member
  ├─pve-swap                 253:0    0     8G  0 lvm  [SWAP]      swap       
  ├─pve-root                 253:1    0  69.4G  0 lvm  /           ext4       
  ├─pve-data_tmeta           253:2    0   1.4G  0 lvm                         
  │ └─pve-data-tpool         253:4    0 141.2G  0 lvm                         
  │   ├─pve-data             253:5    0 141.2G  1 lvm                         
  │   ├─pve-vm--102--disk--0 253:6    0   192G  0 lvm                         
  │   └─pve-vm--101--disk--0 253:7    0     8G  0 lvm              ext4       
  └─pve-data_tdata           253:3    0 141.2G  0 lvm                         
    └─pve-data-tpool         253:4    0 141.2G  0 lvm                         
      ├─pve-data             253:5    0 141.2G  1 lvm                         
      ├─pve-vm--102--disk--0 253:6    0   192G  0 lvm                         
      └─pve-vm--101--disk--0 253:7    0     8G  0 lvm              ext4

Code: 
root@proxmox:~# lvs
  LV            VG  Attr       LSize    Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data          pve twi-aotz-- <141.23g             48.56  2.67                           
  root          pve -wi-ao----  <69.37g                                                   
  swap          pve -wi-ao----    8.00g                                                   
  vm-101-disk-0 pve Vwi-aotz--    8.00g data        65.77                                 
  vm-102-disk-0 pve Vwi-aotz--  192.00g data        32.98

Code: 
root@proxmox:~# qm config 102
agent: 1
boot: order=scsi0;ide2;net0
cores: 4
cpu: x86-64-v2-AES
ide2: local:iso/ubuntu-22.04.1-live-server-amd64.iso,media=cdrom,size=1440306K
memory: 24576
meta: creation-qemu=8.0.2,ctime=1688589025
name: bubba
net0: virtio=76:47:BF:77:99:61,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: l26
scsi0: local-lvm:vm-102-disk-0,iothread=1,size=192G
scsihw: virtio-scsi-single
smbios1: uuid=9c4c1366-f64d-4bf7-9c76-8b44f8ca19f7
sockets: 1
vmgenid: feaab5cb-af48-4f9e-8d06-ebe9ae13a5ff
 
Last edited:
You can just use the Backup tab in the GUI. Ideally you also set up a backup job in Datacenter > Backup. I also create automated snapshots with this.
Try
Bash: 
# Wait for the VM to be stopped
qm shutdown 102

lvresize -L 128G pve/vm-102-disk-0
qm rescan
Then follow the rest of what I linked earlier. I see no discard here. Make sure to enable that as per my Link. It is needed for LVM-Thin to work properly.
Please don't quote every message. This allows me to edit in more information without getting out of sync with the quote and reduces noise.
 
Last edited:
  • Like
Reactions: headband
Great, thanks! I'll do this first thing tomorrow morning when nobody's using the server.

Sorry I might be blind but all I can find in the backup tab and under Datacenter > Backup is options to make Snapshots, not full backups. Should I look somewhere else?
 
Last edited:
Impact said:
I see no discard here. Make sure to enable that as per my Link. It is needed for LVM-Thin to work properly.
Click to expand...

Is this what I need to enable? My options look a bit different than what I see in your link, I think due to version. Just want to make sure I'm doing it right!

1757788559160.png
 
Last edited:
Datacenter
headband said:
Great, thanks! I'll do this first thing tomorrow morning when nobody's using the server.

Sorry I might be blind but all I can find in the backup tab and under Datacenter > Backup is options to make Snapshots, not full backups. Should I look somewhere else?
Click to expand...
Datacenter > Backup: Used for create a Backup Schedule for selected or all VMs.
Since you just need to backup 1 VM then use Node > VM > Backup instead.

Also VM > Backup > Snapshot = make a FULL BACKUP for File System that support Snapshot feature.
 
  • Like
Reactions: headband and Kingneutron
Always have a backup (not just a snapshot) before making changes. I'm starting to see more "how can I shrink" posts and it is a PITA unless it's LXC. Much easier to just restore from before the bad resize.

Especially if the instance was installed with lvm in-vm, then you're pretty much reduced to doing things blind at the console and using rote instructions that you may not understand. And if it's a Red Hat based install, it likely used XFS by default which cannot be shrunk.

S

Thread 'Decrease a VM Disk Size'

Hey,
I'm still new to proxmox and I wanted to know how I could decrease the size of a VM's Disk.

This is the specs of the VM
Screenshot_20230208_021715.png

Within the Linux Ubuntu Server, it shows the following:
Screenshot_20230208_021959.png
Screenshot_20230208_022007.png
Screenshot_20230208_022017.png


Any help would be greatly appreciated.

Thank you!!

PROTIP: Look into systemrescuecd, super grub disc and fsarchiver, which can restore the filesystem from backup on the fly and change it from e.g. XFS to ext4, then you just update VM's fstab and possibly reinstall grub.

https://github.com/nchevsky/systemrescue-zfs/releases

https://distrowatch.com/table.php?distribution=supergrub

https://distrowatch.com/table.php?distribution=Rescatux

https://www.fsarchiver.org/
[[
FSArchiver can extract an archive to a partition which is smaller that the original one as long as there is enough space to store the data. It can also restore the data on a different file-system, so it can use it when you want to convert your file-system: you can backup an ext3 file-system, and restore it as a reiserfs.
]]

Clonezilla can also reportedly resize / copy to smaller on the fly, but I have limited experience with it; might need to look into it further.

I have a mind to write up a whole HOWTO on taking apart an LVM-based VM and restore it to separate vdisks for easy resizing in the future. If you were stuck with a lift-and-shift, could make your life easier.
 
  • Like
Reactions: headband
Kingneutron said:
Always have a backup (not just a snapshot) before making changes. I'm starting to see more "how can I shrink" posts and it is a PITA unless it's LXC. Much easier to just restore from before the bad resize.

Especially if the instance was installed with lvm in-vm, then you're pretty much reduced to doing things blind at the console and using rote instructions that you may not understand. And if it's a Red Hat based install, it likely used XFS by default which cannot be shrunk.

S

Thread 'Decrease a VM Disk Size'

Hey,
I'm still new to proxmox and I wanted to know how I could decrease the size of a VM's Disk.

This is the specs of the VM
Screenshot_20230208_021715.png

Within the Linux Ubuntu Server, it shows the following:
Screenshot_20230208_021959.png
Screenshot_20230208_022007.png
Screenshot_20230208_022017.png


Any help would be greatly appreciated.

Thank you!!

PROTIP: Look into systemrescuecd, super grub disc and fsarchiver, which can restore the filesystem from backup on the fly and change it from e.g. XFS to ext4, then you just update VM's fstab and possibly reinstall grub.

https://github.com/nchevsky/systemrescue-zfs/releases

https://distrowatch.com/table.php?distribution=supergrub

https://distrowatch.com/table.php?distribution=Rescatux

https://www.fsarchiver.org/
[[
FSArchiver can extract an archive to a partition which is smaller that the original one as long as there is enough space to store the data. It can also restore the data on a different file-system, so it can use it when you want to convert your file-system: you can backup an ext3 file-system, and restore it as a reiserfs.
]]

Clonezilla can also reportedly resize / copy to smaller on the fly, but I have limited experience with it; might need to look into it further.

I have a mind to write up a whole HOWTO on taking apart an LVM-based VM and restore it to separate vdisks for easy resizing in the future. If you were stuck with a lift-and-shift, could make your life easier.
Click to expand...

Thank you for the help! I believe most of this only applies if I've resized the disk inside of the VM (which I haven't), am I understanding that right?
 
You must log in or register to reply here.
Top Bottom