1

Our end-goal is to make it easy to increase disk space on partitions at any point in the future. Whether it's the system drive that needs more space, or something like /var

In researching what is best to use for disk partitioning, I came across this article: https://docs.microsoft.com/en-us/azure/virtual-machines/linux/configure-lvm

which says, "While it is feasible to configure LVM on any disk attached to the virtual machine, by default most cloud images will not have LVM configured on the OS disk. This is to prevent problems with duplicate volume groups if the OS disk is ever attached to another VM of the same distribution and type, i.e. during a recovery scenario. Therefore it is recommended only to use LVM on the data disks."

But even on a system (non-data disk), if you're not using LVM, how would you expand this disk partition if needed, since we don't have access to the VM console?

For example, recently in our internal environment (not in Azure), we had a VM that wasn't using LVM at all, and needed a middle partition expanded. The only solution we found was to boot the VM off a boot disk and use GPARTED. This isn't an option in Azure.

How is this handled or recommended to be handled in Azure VMs if the same situation arose? (if a partition in the middle needing additional space, on a non-LVM disk) Mostly trying to plan out how we should be building our Linux VM's to avoid future issues like this.

Improve this question

2 Answers 2

Reset to default
2

How is this handled or recommended to be handled in Azure VMs if the same situation arose? (if a partition in the middle needing additional space, on a non-LVM disk)

Looking at search results, I would say Azure recommend you not do that.

Provided cloud images appear put the root partition at the end of the disk. I assume the idea is to put data partition(s) on separate disk(s).

E.g. this link shows a CentOS image from the Azure marketplace in this format, and also suggests that the same proceedure was tested with an Ubuntu image. It also explains that you are able to use fdisk on a running system to delete the OS partition and re-create it to reflect the new available space. I.e. this does not require booting into a GPARTED disk. You must then reboot, before you can resize the filesystem inside the partition. There may be other ways of doing this as well.

https://blogs.msdn.microsoft.com/cloud_solution_architect/2016/05/24/step-by-step-how-to-resize-a-linux-vm-os-disk-in-azure-arm/

Improve this answer
1
  • I also do agree the best strategy is to put data partitions in different disks. I usually use / + /usr + swap in one disk as my template VM, and then disks for data partitions. +1 Commented May 23, 2018 at 15:17
0

LVM only also brings a negligible penalty for use, and it might be worth using in certain scenarios, specially large DB partitions.

Nonetheless, in OS partitions, I fully agree you might not need it.

Also of note that if you are using a file system that allows online growing, you might get away and do not need to use LVM again, in other kind of scenarios.

For instance, xfs file systems, and also as @sourcejedi correctly points out, ext4 and btrfs.

As for Azure, if you do need to boot on the side, it only requires a bit of planning. Set up an extra small Recover/boot partition between 200-500MB with a rescue image in a VM at install time.

Improve this answer
3
  • 2
    ext4 and btrfs also allow online growing, surely it is unlikely that you use a filesystem that does not support online growing :-). Commented May 23, 2018 at 14:11
  • @sourcejedi true indeed, it was an example. Thanks for remembering it. Commented May 23, 2018 at 15:16
  • yes but when there are several partitions and you need to expand the middle partition. This is the challenge. Commented May 24, 2018 at 12:31

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.