[SOLVED] Resize VM root disk (no LVM, not on last partition)

R

rokyo401

Member
Mar 12, 2024
36
5
8
Hello,

I'm trying to resize the root disk of a Linux VM on Proxmox but my case doesn't fit the steps shown in the manual (https://pve.proxmox.com/wiki/Resize_disks).

I extended the size via the GUI form 50 to 80GB already. The VM is not showing this, yet, obviously but running the dmesg command from the manual shows the size increase was detected:

Code: 
root@VM:~# dmesg | grep sda
[    1.888739] sd 2:0:0:0: [sda] 104857600 512-byte logical blocks: (53.7 GB/50.0 GiB)
[    1.888782] sd 2:0:0:0: [sda] Write Protect is off
[    1.888783] sd 2:0:0:0: [sda] Mode Sense: 63 00 00 08
[    1.888853] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    1.891177]  sda: sda1 sda2 < sda5 >
[    1.891362] sd 2:0:0:0: [sda] Attached SCSI disk
[    2.600384] EXT4-fs (sda1): mounted filesystem with ordered data mode. Quota mode: none.
[    2.993397] EXT4-fs (sda1): re-mounted. Quota mode: none.
[    3.216527] Adding 998396k swap on /dev/sda5.  Priority:-2 extents:1 across:998396k FS
[3366745.552412] sd 2:0:0:0: [sda] 167772160 512-byte logical blocks: (85.9 GB/80.0 GiB)
[3366745.552560] sda: detected capacity change from 104857600 to 167772160

The partition layout differs from what is shown in the manual since my root drive is not in the last partition (the extended one, as in the manual) but rather in the first/primary partition while the extended one holds the swap partition:

Code: 
root@VM:~# fdisk -l /dev/sda | grep ^/dev
/dev/sda1  *         2048 102856703 102854656   49G 83 Linux
/dev/sda2       102858750 104855551   1996802  975M  5 Extended
/dev/sda5       102858752 104855551   1996800  975M 82 Linux swap / Solaris

This is probably why the remaining steps in the manual do not work for me. Running parted /dev/sda and then print does not show the message shown in the manual:

Code: 
Warning: Not all of the space available to /dev/vda appears to be used, you can
fix the GPT to use all of the space (an extra 268435456 blocks) or continue
with the current setting?
Fix/Ignore? F

but rather just the partition layout again and the new size of the underlying disk:

Code: 
Model: QEMU QEMU HARDDISK (scsi)
Disk /dev/sda: 85.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type      File system     Flags
 1      1049kB  52.7GB  52.7GB  primary   ext4            boot
 2      52.7GB  53.7GB  1022MB  extended
 5      52.7GB  53.7GB  1022MB  logical   linux-swap(v1)  swap

and running (parted) resizepart 1 100% does not resize it but prints out:

Code: 
(parted) resizepart 1 100%                                               
Warning: Partition /dev/sda1 is being used. Are you sure you want to continue?
Yes/No? n

Which I assume will not work, even if I answered "yes"! because there is the extended partition with the swap behind partition 1.

Is there any way to resize the root partition online? Can I just delete the swap partition and the extended one and then run resizepart 1 100%?

If so: How do I do this? And can I re-enable swap afterwards? As a swapfile?

Any help is highly appreciated!
 
Looking at that, it's not a super bad situation.

If you turn off the swap partition (ie run without swap temporarily), then you'll be fine to remove both it and the "extended" partition that seems to just be a wrapper for it.

That would leave you with a single partition on the disk, and you could then resize that partition to be larger using the standard approaches. And if you leave a bit of space at the end of the drive you could make a new swap partition there (if desired). Or you could use a swap file instead, it's up to you.
 
  • Like
Reactions: rokyo401 and Kingneutron
Hmmm, as these are virtual disks... would it be workable to have the swap partition just be on a separate (new) disk instead? That might keep things nicely separated so it doesn't get in the way of expanding the main partition again later on (if needed).
 
  • Like
Reactions: rokyo401 and Kingneutron
justinclift said:
Looking at that, it's not a super bad situation.

If you turn off the swap partition (ie run without swap temporarily), then you'll be fine to remove both it and the "extended" partition that seems to just be a wrapper for it.

That would leave you with a single partition on the disk, and you could then resize that partition to be larger using the standard approaches. And if you leave a bit of space at the end of the drive you could make a new swap partition there (if desired). Or you could use a swap file instead, it's up to you.
Click to expand...

Ah okay, so basically this guide here would do the trick: https://unix.stackexchange.com/a/450015 ?

"a backup" in this case would be "cloning the VM beforehand", I assume? Or would snapshotting also work?
 
Last edited:
justinclift said:
Hmmm, as these are virtual disks... would it be workable to have the swap partition just be on a separate (new) disk instead? That might keep things nicely separated so it doesn't get in the way of expanding the main partition again later on (if needed).
Click to expand...
That makes sense. Could be that I need to further extend the disk in the future!
 
  • Like
Reactions: Kingneutron
rokyo401 said:
Ah okay, so basically this guide here would do the trick: https://unix.stackexchange.com/a/450015 ?
Click to expand...

Mostly yeah. You'll probably need to delete the "extended" partition as well, as that's wrapping the swap partition and kind of taking up space for no reason.

rokyo401 said:
"a backup" in this case would be "cloning the VM beforehand", I assume? Or would snapshotting also work?
Click to expand...

Literally anything that lets you recover your VM back to a working state if things go wrong somehow. A full clone is probably the safest bet (if you have the space spare), though it'll also take a bunch of time to do the clone. Just make sure whatever you use for a back up is definitely going to work if you do need it after all. :)
 
  • Like
Reactions: rokyo401
justinclift said:
Mostly yeah. You'll probably need to delete the "extended" partition as well, as that's wrapping the swap partition and kind of taking up space for no reason.



Literally anything that lets you recover your VM back to a working state if things go wrong somehow. A full clone is probably the safest bet (if you have the space spare), though it'll also take a bunch of time to do the clone. Just make sure whatever you use for a back up is definitely going to work if you do need it after all. :)
Click to expand...

Okay, I wasn't sure if snapshotting would include the disk layout itself, but a full clone definitely should! I'll do the clone just to be safe! ;-)
 
  • Like
Reactions: justinclift
Oh. Since you can do full clones, you could just do a full clone first. Then practise the partition stuff on that clone to make sure it all works as expected.

But still do a backup of your real VM anyway before changing things, just in case something unexpected happens. :)
 
  • Like
Reactions: rokyo401 and Kingneutron
justinclift said:
Hmmm, as these are virtual disks... would it be workable to have the swap partition just be on a separate (new) disk instead? That might keep things nicely separated so it doesn't get in the way of expanding the main partition again later on (if needed).
Click to expand...

Absolutely. To make this easier on yourself, you could boot a systemrescuecd ISO in the vm and do this all from gparted with a GUI. :)

You also have the option of using a swapfile if you have enough space on rootfs, or zram if you have enough RAM.

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

As a sysadmin, I hate the whole idea of LVM in a VM environment. Separate disks instead of playing around with resizing partitions is easier; just don't use XFS if you ever anticipate having to shrink the FS. Expansion is way more common these days tho
 
  • Like
Reactions: rokyo401 and justinclift
Kingneutron said:
just don't use XFS if you ever anticipate having to shrink the FS
Click to expand...
Yeah, that's a surprising failure point with XFS. They designed a (production oriented!) filesystem that can only be expanded, never shrunk.

I used to be positive on XFS, right up until hitting this specific issue. :(
 
XFS is still a great filesystem and has features. It's slightly faster than ext4 on the same hardware and is better on large disks if you don't want to go full ZFS. And you don't have to worry too much about inode allocation.

https://en.wikipedia.org/wiki/XFS#Features

https://www.usenix.org/system/files/login/articles/140-hellwig.pdf

PROTIP - if for some reason you find a need to shrink an XFS filesystem, you can back it up with fsarchiver and then restore it with same - it can convert XFS to ext4 on the fly(!) and all you should need to do is change fstab before rebooting.
 
Last edited:
  • Like
Reactions: justinclift
Thanks @Kingneutron, I havn't come across fsarchiver before. Looks interesting.

So far I've used Clonezilla (or straight dd) when backing up filesystems, but this looks like an improvement over those approaches.
 
Last edited:
Nice, I did it with the SystemRescueCD and GParted, like @Kingneutron suggested and doing a full clone beforehand, like @justinclift recommended and it seems to have worked perfectly!

After starting up the VM again, it now shows 80GB with df -h and I'll only need to create a new swap or maybe just a swapfile. :)

Now, where can I mark the thread as solved, though? :D
 
Last edited:
  • Like
Reactions: Kingneutron
You must log in or register to reply here.
Top Bottom
Back