Our storage layers are the following in a standard setup:

  • Outside of the OS:
    • LUN on SAN
    • VMware VMFS volume on LUN
    • virtual disks (VMDKs) on the VMFS
  • Inside the OS (Linux):
    • the VMDK corresponds to an LVM PV (physical volume) directly on the device (no partitions)
    • 1 PV = 1 VG = 1 LV, which finally contains:
    • the filesystem (ext3)

Note that we are not talking about the root disk here.

Now to the question.

Sometimes there are users who need more space on a volume temporarily. Meaning: They want to give the space back after they are done. / I want to take it back after they are done.

Some considerations:

  • It's not as easy as creating a symlink to a second volume that we can create temporarily, in order to be removed again later. That is because sometimes it is not known in advance exactly where the space is required. Also, in that case it may not be 100% transparent because data may have to be moved around for this. So I won't consider this an acceptable answer.
  • I won't expand the physical volume (because that would require making the VMDK bigger and you can't easily make it smaller again).
  • The same applies to the filesystem.
  • The only solution thus seems to use the LVM layer for which it is no problem to expand and reduce at will.
  • But: the filesystem on top of it can only be easily expanded, not shrinked.

So what would be a possibility to do this on-the-fly and without any sort of downtime, thus completely transparently?

  • Can't you just add new vmdk's as new non-LVM disks (/dev/sdc etc/) and partition/format/mount them for the users then get rid of the whole disk when it's done? anything else seems a lot more complex. – Chopper3 Dec 28 '14 at 15:39
  • That would be the option where I symlink or mount a second volume somewhere into the first filesystem, which I excluded being an option, because it's not sure exactly where the space is required. Also I don't want to have to shut down anything. Feel free to give me an idea of what more complex options you are thinking about :) – Marki Dec 28 '14 at 16:40
  • Can you give more details? The OS involved, the filesystems involved, the amount of data in use, how much things need to be expanded by, the performance requirements, etc. – ewwhite Dec 28 '14 at 17:45
  • It's simply a question of volume. Say the filesystem has 40G, and they want to test stuff and temporarily need 80G. I don't want to say those additional 40G permanently goodbye since they don't need it permanently. OS is Linux as I said, more specifically SLES. Filesystems are usually ext3. – Marki Dec 28 '14 at 19:26
  • I'm curious about this statement: But: the filesystem on top of it can only be easily expanded, not shrinked. Why can't it be shrunk? linux.die.net/man/8/resize2fs – 0xSheepdog Aug 31 '15 at 16:26

This is totally a case of needing to plan better... And maybe improving deployment and provisioning process.

LVM on top of VMware is a bit redundant, especially since you can add/remove Thin-provisioned VMDK disks on-the-fly. You've excluded this, but it IS a valid approach.

If the storage needs are truly dynamic, the additional risk of making LVM device changes and expanding/shrinking file systems isn't worth it. This could have perhaps been solved by better partitioning.

| improve this answer | |
  • 1
    Whether they are thin- or thick-provisioned you can always add/remove them on the fly from the OS, that is for sure. The advantage of an additional LVM layer is that you can add another VMDK on-the-fly by expanding the filesystem using a VMDK even if it comes from a different LUN (ok, you can also kind-of concatenate VMDKs). But all these insights still don't solve the main question which is how you can completely transparently expand and again later shrink a virtualized filesystem. The problem is the filesystem itself in the end. Maybe then simply the fact of using ext is the problem. – Marki Dec 28 '14 at 19:24

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.