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?

Improve this question

1 Answer 1

Reset to default
-1

First, realize their is a segregation between hardware and software. They do not dynamically match each other because they are radically different things.

I'd love to have the disk image contain the file system directly, without any partitions.

The partition table is how the OS knows what hardware it has official use of in terms of data storage. A typical OS does NOT figure out the size of a disk dynamically. It requires that if you change the underlying disk size to "smaller" you have to change the partition table to match; even if you use the extents of the drive for the partition.

Also, the hypersvisor is inherently unaware of the OS details and its partitions because partitions are inherently software and the hypervisor is simulating hardware ONLY.

This means you need a integrated software/hardware solution where each is aware and in control of the other. I am unaware of anything like that.

This would allow for easy resizing from within as well as outside the VM.

Think of a VM in terms of hardware, essentially what you are asking is to change the size of a real HDD on the fly and have the OS dynamically adjust. This is not how things are setup. Changing a virtual disk size vs a real hardware disk size is no different to the OS. Just because it is virtual does not means they "integrate" in any way.

How should I organize a VM disk image so it is as simple as possible to resize?

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. Then install the "other stuff" on another VD. This leaves you modifying a partition of the non-root drive which is inherently easier than modifying the partition of a root drive. Most of my VMs have at least 2 virtual disks for this purpose.

LVM is also another things that is suppose to help with this, but I am unfamiliar of all the options there.

Improve this answer
6
  • 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. Commented Jan 11, 2018 at 8:41
  • "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. Commented Jan 11, 2018 at 8:42
  • 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. Commented Jan 13, 2018 at 15:54
  • My suggestion was to segregate the host OS files from the software installed. This is very different from separateing GRUB from the host OS. Commented Jan 13, 2018 at 15:54
  • 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. Commented Jan 13, 2018 at 22:13

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.