The output above shows that Ubuntu doesn't know anything about thin provisioning. Appears that during the installation, sda3 only had about 50G, which it used for the PV. I've never seen that before, but we don't use thin provisioning for VMs, just containers.
If you understand LVM, it looks like resizing the different logical parts should be easy and not need downtime. If it was me, I'd try this:
- Use pvresize to increase the PV size.
- Use vgextend to increase the VG size. (may not be needed; pvresize may automatically vgextend too)
- Use lvresize to shrink the current LV to 25G or less - the size depends on how much you want to waste with the OS and file-based swap.
- Use lvcreate to make another LV to be used for /home and all data, sized to use the amount needed for the next 3 months.
Whenever using lvresize or lvcreate, I use the -r option so the file system gets handled automatically. Forget to do that and you'll need another step.
I'd leave at least 20% of the VG free for future needs and to be used for swap.
Never allocate the entire disk to LVs. We need to leave some space to extend storage where it is needed later, some for snapshots so our backups can be clean, and perhaps some for swap, which it seems the system doesn't have. Normally, there should be a swap LV on a system like this.
I'm not a fan of using file-based swap. LVs are much cleaner and avoid certain issues.
To give you an idea about different LVM:
Code:
regulus:~$ sudo lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root vgubuntu-mate -wi-ao---- 17.00g
home vgubuntu-mate -wi-ao---- 12.00g
swap_1 vgubuntu-mate -wi-ao---- 4.10g
regulus:~$ sudo vgs
VG #PV #LV #SN Attr VSize VFree
vgubuntu-mate 2 3 0 wz--n- 39.49g 6.39g
regulus:~$ sudo pvs
PV VG Fmt Attr PSize PFree
/dev/vda5 vgubuntu-mate lvm2 a-- <29.50g 0
/dev/vdb1 vgubuntu-mate lvm2 a-- <10.00g 6.39g
That's on my main desktop. I screwed up during the install and only gave the VM 30G because the prior desktop VM was using only 25G total. 20.04 is bloated. Anyway, I added a new 10G physical disk (as far as the VM was installed knew), vdb. then I made that new disk part of the VG and gave some of the storage to the root LV.
Code:
regulus:~$ lsblk -e 7 -o name,size,type,fstype,mountpoint
NAME SIZE TYPE FSTYPE MOUNTPOINT
sr0 1024M rom
vda 30G disk
├─vda1 512M part vfat /boot/efi
├─vda2 1K part
└─vda5 29.5G part LVM2_member
├─vgubuntu--mate-root 17G lvm ext4 /
├─vgubuntu--mate-swap_1 4.1G lvm swap [SWAP]
└─vgubuntu--mate-home 12G lvm ext4 /home
vdb 10G disk
└─vdb1 10G part LVM2_member
└─vgubuntu--mate-root 17G lvm ext4 /
All this work was done while the VM kept running. No downtime needed. These were the commands:
https://ubuntuforums.org/showthread....6#post13963156
Notice how I left 6G free? This gets used for nightly backups as snapshot storage. At some point in the future, I may clean this up by extending the vda allocation to the VM - really doesn't matter. On the VM host, vda and vdb are just LVs presented to the VM, regulus, as block devices. See:
Code:
$ sudo lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
lv-regulus hadar-vg -wi-ao---- 30.00g
lv-regulus-2 hadar-vg -wi-ao---- 10.00g
A little "Inception" loop here. Like that movie.
Adv Reply
Originally Posted by TheFu
Bookmarks