1

I have a hard disk which is the sole physical volume in an LVM2 volume group. The volume group contains a single logical volume, call it lv-host.

I've then created a VMDK virtual disk using lv-host as a physical device. This virtual disk is then the only storage attached to a virtual machine. I've installed Ubuntu (18.04 server) on this VM, treating the VMDK disk as a physical volume of a volume group containing logical volumes for swap and the root partition (call these lv-guest-root and lv-guest-swap). lv-guest-root is LUKS-encrypted.

I now want to shrink lv-host to make room for another volume. To do this, I need to:

  • Shrink the ext4 filesystem on lv-guest-root.
  • Shrink lv-guest-root.
  • Shrink the nested volume group and physical volume.
  • Shrink lv-host.

The first step is eluding me. I've tried following this procedure to resize the partition from within the virtual machine but I can't find the last thing keeping the mount point busy when I try to unmount it. As far as I can tell, nothing has a file open on the partition and there are no anonymous inodes or nested mount points left.

The obvious alternative is to do it on the host. But the kernel doesn't seem to recognise that the LV contains another VG that it should create device files for - ie there is no /dev/mapper/lv-guest-root etc.

Is there a way to tell the kernel that it should be looking for a volume group within this logical volume?

Or can someone suggest another way through this?

2
  • The linked procedure is something you do when nothing else works. You have many other options available here, so no need to jump through hoops. Why not just boot a livecd/rescue system in the VM? Also if it's ext4 on LUKS on LVM, make sure you take the LUKS header size/data offset into consideration. – frostschutz Jan 1 '20 at 20:52
  • TBH in the end I chickened out on this. Backed up the data I wanted and blew the whole thing away and started from scratch. I think the lesson here is to keep LVM configuration on the host side and let guests treat volumes as though they were bare, un-volumised, unencrypted physical devices. I'm sure this approach will cause me other difficulties later on (how will VirtualBox and the guest react when the size of a "physical" device changes?) but for now it seems okay. – Tom Jan 2 '20 at 12:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.