[SOLVED] Resize disk of ubuntu 19.10 vm on proxmox...

[liamlows]

Hey guys,

So I am in the process of trying to increase the disk size of one of my VMs from 750GB -> 1.25 TB. The way I have gone about this (following the wiki) is summarized by the following:

1. First i went to the VM page via the proxmox web browser control panel.
2. Then I selected the "Hardware" tab and selected "Hard Disk" and then clicked the resize disk button on the top bar.
3. I incremented the disk by 500GB (no need to use qemu CLI as I am only increasing the size, not shrinking) and confirmed the changes.
4. I then rebooted the whole node (in my case only one named "pve") using the reboot button (not sure if this counts as a cold boot or not)

After rebooting, i started up the VM again and then logged in but when i logged in the filesystem had not recognized the new partition. So i kept reading and read that the best way to handle it is to boot the VM with gparted. I was a bit confused with this as I have no idea how to get that particular VM to boot to gparted? Is this something that is done from the kernel shell on the node? I tried to do it from within the VM but it warned me that doing so with the disk still mounted could be dangerous.

My question to you guys then is what is the proper way to use gparted to adjust the VM's filesystem such that it recognizes the changes. Do I do it from the kernel shell? Do I do it from within the VM and ignore the warning? I understand the wiki and its directions (once inside gparted) but still am unsure about where gparted is actually run from in order to make the VM recognize the new partition/filesystem.

Any help is appreciated! Thanks guys!

 

[Dark26]

you have to increase the size of the partition in the VM, and extend the filesystem. Depends how ubuntu is installed ( only one partition; separate home; lvm or not , raid, encryption ... ; what filesystem you use ( ext4 ; xfs .. ).

if you have on partition on ext4 or xfs, in 30 seconde it's done .

Otherwise if you have multiple partition ; raid ; lvm. it's more complicated.

i will l say to backup before; but 750 gb; a big one..


maybe a

df -h

and

mount

can help

 

[liamlows]

you have to increase the size of the partition in the VM, and extend the filesystem. Depends how ubuntu is installed ( only one partition; separate home; lvm or not , raid, encryption ... ; what filesystem you use ( ext4 ; xfs .. ).

Ahh ok i gotcha, from within the VM this is what fdisk spits out...
NOTE: /dev/sda2 in this case uses ext4 format (/dev/sda2 is primary partition for the VM)

embyhost@embyhost:~$ sudo fdisk -l
...
GPT PMBR size mismatch (1572863999 != 2621439999) will be corrected by write.
The backup GPT table is not on the end of the device. This problem will be corrected by write.
Disk /dev/sda: 1.23 TiB, 1342177280000 bytes, 2621440000 sectors
Disk model: QEMU HARDDISK  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 121E8CA3-3A2D-4EF3-B81D-8CE9E47B2965

Device     Start        End    Sectors  Size Type
/dev/sda1   2048       4095       2048    1M BIOS boot
/dev/sda2   4096 1572861951 1572857856  750G Linux filesystem

So as seen above, the line:

GPT PMBR size mismatch (1572863999 != 2621439999) will be corrected by write. The backup GPT table is not on the end of the device. This problem will be corrected by write.

Implies I have to extend the partition, so i tried this...

embyhost@embyhost:~$ sudo parted /dev/sda
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                          
Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 1048576000
blocks) or continue with the current setting?
Fix/Ignore? F                                                            
Model: QEMU QEMU HARDDISK (scsi)
Disk /dev/sda: 1342GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
1      1049kB  2097kB  1049kB                     bios_grub
2      2097kB  805GB   805GB   ext4

(parted) resizepart 2 100%                                              
Warning: Partition /dev/sda2 is being used. Are you sure you want to continue?
parted: invalid token: 100%                                              
Yes/No?

That last question about partition /dev/sda2 being used is what concerned me. Should I just type yes and let it continue? Or should I do something else.

Also, I thought it was weird that it threw and error for 100% as that is what the wiki says to do.

(parted) resizepart 3 100% (from wiki, i replaced 3 with 2, see above)

Let me know what you think, Thanks again!

 

[liamlows]

Alright, so I figured it out, and it was pretty simple
For anyone else looking for this solution, in my case, I basically did what I mentioned above and except a little different...

(parted) resizepart 2
Warning: Partition /dev/sda2 is being used. Are you sure you want to continue?
Yes/No? y                                                                 
End?  [805GB]? 100%                                                       
(parted) quit                                                             
Information: You may need to update /etc/fstab.

Then I did the following...

embyhost@embyhost:~$ sudo resize2fs /dev/sda2
resize2fs 1.45.3 (14-Jul-2019)
Filesystem at /dev/sda2 is mounted on /; on-line resizing required
old_desc_blocks = 94, new_desc_blocks = 157
The filesystem on /dev/sda2 is now 327679483 (4k) blocks long.

I logged out and back in and viola, it was updated

Not hard at all but scary when your dealing with a really big filesystem haha

 

[greenie]

Alright, so I figured it out, and it was pretty simple
For anyone else looking for this solution, in my case, I basically did what I mentioned above and except a little different...

(parted) resizepart 2
Warning: Partition /dev/sda2 is being used. Are you sure you want to continue?
Yes/No? y                                                                
End?  [805GB]? 100%                                                      
(parted) quit                                                            
Information: You may need to update /etc/fstab.

Then I did the following...

embyhost@embyhost:~$ sudo resize2fs /dev/sda2
resize2fs 1.45.3 (14-Jul-2019)
Filesystem at /dev/sda2 is mounted on /; on-line resizing required
old_desc_blocks = 94, new_desc_blocks = 157
The filesystem on /dev/sda2 is now 327679483 (4k) blocks long.

I logged out and back in and viola, it was updated

Not hard at all but scary when your dealing with a really big filesystem haha

I appreciate comming back to this with your solution however this is a little hard to follow for someone new to this.

For example, what command is (parted) how do i get here?

Could you elaborate with some clearer instructions?

 

[eugenevdm]

Could you elaborate with some clearer instructions?

I just had to go through this so I tried to make clearer instructions here:

https://kb.vander.host/disk-management/how-to-enlarge-an-ext4-disk-on-an-ubuntu-proxmox-vm/

 

[Jorrak]

I have done what you did here I increased from 8 gig to 16 gig in Proxmox, ran parted, but in the last step I get:

sudo resize2fs /dev/sda3
[sudo] password for john:
resize2fs 1.46.5 (30-Dec-2021)
resize2fs: Device or resource busy while trying to open /dev/sda3
Couldn't find valid filesystem superblock.

Is there any way to solve this?


here is fdisk -l

Disk /dev/sda: 16 GiB, 17179869184 bytes, 33554432 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 06BA62F9-63DD-4E43-828F-97EF588B0F7E

Device Start End Sectors Size Type
/dev/sda1 2048 4095 2048 1M BIOS boot
/dev/sda2 4096 3674111 3670016 1.8G Linux filesystem
/dev/sda3 3674112 33554398 29880287 14.2G Linux filesystem


Disk /dev/mapper/ubuntu--vg-ubuntu--lv: 6.25 GiB, 6706692096 bytes, 13099008 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


df -h

Filesystem Size Used Avail Use% Mounted on
tmpfs 383M 1.1M 382M 1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv 6.1G 5.3G 510M 92% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/sda2 1.7G 247M 1.4G 16% /boot
overlay 6.1G 5.3G 510M 92% /var/lib/docker/overlay2/a7e21bf04326cbecaaa836cd21238e87b06a70949653c5efd054d5e4a6420021/merged
tmpfs 383M 4.0K 383M 1% /run/user/1000

 

[eugenevdm]

@Jorrak my gut feeling is you're working with commands aimed at enlarging a raw EXT4 partition but from your output you don't have a raw EXT4 partition, but rather a logical volume group:

Disk /dev/mapper/ubuntu--vg-ubuntu--lv

To be super complete I wouldn't have minded to see the results of your Parted command, to see for example if you got this warning? (If you get that warning it generally means you're on the right track):

Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 146800640 blocks) or continue with the current setting?

Either way, the way to enlarge a logical volume group is different from enlarging a raw partition. A logical volume group may contain a number of partitions.

To enlarge an LVM group you can try these commands, but first read my disclaimer:

- I don't work for Proxmox.
- The link I provided has nothing to do with Proxmox. I merely try to digest their information and information on public forums and then rewrite it in a format I can use every day
- If something goes horribly wrong, and your disk breaks, I will take no responsibility
- I see you are a subscriber. Have you considered reaching out for professional support?
- You have good backups right?

In a nutshell when working with an LVM group you need to introduce new commands in addition to parted and resize2fs. The two additional commands are pvresize and lvextend. So your recipe looks something like this:

```

• parted /dev/sda
  • print and Fix
  • resizepart and choose correct partition and 100%FREE flag
• pvresize /dev/sda3
• lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
• resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv

```

Finally df -h to see it it worked.

 

[Jorrak]

Wow, it worked. Thanks a lot!
Now I do not have to set up a totally new vm to get more storage.

I had backup by the way.

 

[PROcrastinator]

Sorry to revive this old threat, but this is exactly my problem. I installed omv on my Proxmox machine and handed it a 4Gb disc to store the data. The system itself is running on the ssecond disc where all VMs and containers are. I started with 4GB but had problems with the GUI today. In my search I found that the disc is 100% used and was able to delete some files via apt autoremove to get it working again.

I resized the disk to 8GB in Proxmox. fdisk -l shows the 8GB disc, but it is on /dev/vda as /dev/sda ist the data storage.
As mentioned in the Wiki, I do not get the error message that the size mismatch and cannot fix the error.

How do I get this fixed before the disc is full again? Also, how can I prevent it from running full?
I ran du -sh /* | sort -nr | head -15 but only found aroung 900M in /var and 2,3G in /usr
Is this normal, and shoud I have started with much more disc space?

Thanks in advance if anyoe can help me!

 

[eugenevdm]

> fdisk -l shows the 8GB disc

What does `df -h` show? Have you successfully allocated the new disk space?

> but it is on /dev/vda as /dev/sda

This doesn't matter, but before doing disk operations always check `vda`or `sda` or whatever. Typically commands fail is you're not specifying the right disk.

> As mentioned in the Wiki, I do not get the error message that the size mismatch and cannot fix the error.

Please be specific about which Wiki, or article you are referring to. This article:
https://kb.vander.host/disk-management/how-to-enlarge-an-ext4-disk-on-an-ubuntu-proxmox-vm/

...has nothing to do with Proxmox official or unofficial, it's my personal experience.

And what error can't you fix?

> I ran du -sh /* | sort -nr | head -15

Try use `ncdu` instead and install it if it's not there. It will help quickly pinpoint large files as it has a good default for sorting.

> Is this normal, and should I have started with much more disc space?

I don't have an answer for that, but if your logs are filling up quickly (2.3 is quite a bit), then perhaps you need more aggressive rotation or you have to pinpoint why they are growing. In theory on a well kept disk 4 GB should maybe be okay.

 

[PROcrastinator]

Yes, I did mean the error in your guide.
I solved the problem a different way. I used a gparted live cd to boot and changed the size there. I had to move the swap partition to the end which caused an error when booting up. After editing the UIID in /etc/initramfs-tools/conf.d/resume and running update-initramfs -u, the VM is now booting up, although it takes more time than before. I checked the files in /urs with ncdu, thank for the tip, that is really much better. The files are in /usr/lib/modules/6.X.0-0.deb11.6-amd/kernel (X=1 or 0). I also checked the sic usage in the OMV GUI and saw that the disc filled up extremely fast around 2 weeks ago, but I can not track what files where written then.

So I guess I will live with it as long as it is running again and check the file sizes in case it fills up again.
Thank you for your help!