0
Disk images of virtual machines usually contain a parition table that contains one or more file systems. Resizing that is a bit painful, as you need to carefully rewrite the partition table before you can resize the. Inside a Linux VM, the changed partition table can't be read-in on the fly, so you need one more reboot of the VM.
I'd love to have the disk image contain the file system directly, without any partitions. This would allow for easy resizing from within as well as outside the VM. However, in such an installation the Grub bootloader so no longer reliable, because it needs to point to its stage2 via hard-coded block position, which makes the VM unbootable every few months when the file system moves stuff around. (With a DOS partition table, it uses the unallocatable space between MBR and first partition to put its stage2 into. With other partition tables, you create a separate bootloader partition for that.)
Is there any way around this?
How should I organize a VM disk image so it is as simple as possible to resize?
First ideas are:
Using two disk images per VM, one disk of fixed size just for the bootloader (MBR+stage2) and a second disk containing directly the filesystem.
Using a different bootloader. But don't have LILO and Syslinux the same problem? The first 512 bytes of a disk are simply too small to contain a file system driver.
Is there any other, perhaps simpler, way to achieve this?
vog
Posted 2018-01-10T22:35:24.520
Reputation: 187
Thanks for taking the time to write such a long answer, but it doesn't make any sense to me. For example, "The partition table is how the OS knows what hardware it has official use of in terms of data storage." ... This is plain wrong. I can attach a virtual disk that doesn't have any patition table whatsoever (e.g. zeroed out the MBR), and the OS within the virtual disk still knows its exact size. – vog – 2018-01-11T08:41:11.407
"You might segregate your OS from all other files.; that is have a separate VD (virtual disk) for your OS with enough headroom for changes and updates" ... this is almost the same as the first item in my "First Ideas" list. I was asking for options that are different from this working, somewhat cumbersome, solution. – vog – 2018-01-11T08:42:22.160
Yes, you can attach a disk and disk can report back its size but until the disk is allocated (partitioned), the OS cannot "use" it in the typical sense. Also, the OS cannot change the disk size for the same reason the hypervisor cannot change the partition size. And a partition is required on a drive for an OS to use it for its own files. This answer was mostly suppose to bring to light how the hypervisor and OS server two VERY DISTINCT functions that you will not be able to meld. – Damon – 2018-01-13T15:54:50.290
My suggestion was to segregate the host OS files from the software installed. This is very different from separateing GRUB from the host OS. – Damon – 2018-01-13T15:54:57.053
So many half knowledge, as well as plain wrong statements, in so few sentences. I honestly don't know how to deal with that properly, other than downvoting the answer. Just to pick a single example: "And a partition is required on a drive for an OS to use it for its own files" ... No, you don't need partitions at all. It is advisible, for sure, but not required. I set up many VM in the past where the file system was directly on the disk image, without any partition table. It did have downsides, but it worked. – vog – 2018-01-13T22:13:42.720
@vog No worries on the downvote! There was a premise of "typical" setup that will keep files and data safe which usually aligns with having partitions. Even without a partition, the OS still can't safely "deal" with a dynamically sized block device. Im sure you'll figure something out. You've got the knowledge obviously. – Damon – 2018-01-14T06:13:51.383