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

[Kingneutron]

If it helps future readers, I did a full writeup:

https://github.com/kneutron/largefiles/blob/main/howto-resize-lvm-vm-disks-down.docx

Example: Rocky 9 EFI-boot VM with 256GB LVM single disk, after maint you end up with 128GB total (thin provisioned) spread out over several vdisks and no LVM to worry about in the future. Rootfs gets resized up, we add a new /var/log partition and shrink /home down.

Can resize XFS rootfs down by backing up / restoring to smaller disk with fsarchiver. Long term, you're much better off separating things out over several dedicated virtual disks. You don't need LVM bc it's already in a virtual environment.

I don't believe you need to resize the disk down in-vm, you can create a new smaller disk and migrate the filesystem over.

 

[Impact]

Why would you not write this in markdown so people can actually read it online?

 

[Kingneutron]

Why would you not write this in markdown so people can actually read it online?

SRSLY? It took me several hours of experimentation to write it up AT ALL and make sure it worked. Feel free to apply your time and effort.

 

[headband]

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?

Was hoping I could get a quick check-in on this before I get started so I don't mess anything up. Thanks!

 

[Impact]

You do not need to do anything other than what I shared in this case.

 

[headband]

Ok cool thanks, I'll let yall know how it went soon!

 

[headband]

Alright, progress has been made but I've hit a sticking point. Following Impact's directions I was able to resize the lv back down to 128GB using the command lvresize -L 128G pve/vm-102-disk-0 and then qm resize after I enabled discard for the disk.

The problem occurs when I try to resize the LV inside of the VM itself using the command sudo lvresize --extents +100%FREE --resizefs /dev/ubuntu-vg/ubuntu-lv (via the instructions here at the bottom). That command gives this output:

~$ sudo lvresize --extents +100%FREE --resizefs /dev/ubuntu-vg/ubuntu-lv
[sudo] password for headband:
  Size of logical volume ubuntu-vg/ubuntu-lv unchanged from <62.00 GiB (15871 extents).
  Logical volume ubuntu-vg/ubuntu-lv successfully resized.
resize2fs 1.46.5 (30-Dec-2021)
The filesystem is already 16251904 (4k) blocks long.  Nothing to do!

It's like the VM can't see that it has more drive available in the LV. In the Proxmox console under bubba > Hardware the hard disc is listed correctly as 128GB now. Any ideas out there as to how I should proceed?

 

[Impact]

Do exactly what I described at the bottom here.

 

[headband]

Run cfdisk /dev/sda and resize the sda3 partition. Confirm and write. Then run pvresize /dev/sda3 and lvresize -r -l +100%FREE ubuntu-vg/ubuntu-lv.

Awesome, thanks! When I try the first command I get this error and I'm not sure how to run it without the disk being used:

Device is currently in use, repartitioning is probably a bad idea.
                                     Quit program without writing changes

 

[Impact]

I already answered in the other thread. You can ignore that warning in this case and continue.

 

[headband]

Awesome, it worked - THANK YOU!!!!!!

 

[headband]

Edit: Nevermind, I thought I had a problem but my local-lvm disc was full due to backups from this project. I deleted those and I'm good to go again!

 

[Impact]

You shouldn't be able to store backups on local-lvm. I assume you mean snapshots?

 

[headband]

My backup tab only has snapshots as an option and I could never figure out how to do a full backup so I just cloned the VM instead and the clone resided on local-lvm.

 

[Impact]

The snapshot mode of a backup does not change that you do a backup. It's about data consistency and need to stop/suspend the VM to achieve it. It's good to have both backups and snapshots. But still, local-lvm cannot directly store backups or files.