0

My goal is a default configuration for LVM thin-provisioning that is flexible enough to reserve a safety margin for one admin VM LV (VolA) versus user LVs (VolU1, VolU2, VolU3 ...) even if various administrators (on separate installations) use very different amounts of disk space in their respective admin virtual machines.

For example, one administrator may use 4GB in System1's VolA, but another admin may use 50GB in System2's VolA. This means that a fixed-size volume of 50GB would be unacceptable to the first administrator (and vice-versa), so putting VolA in the thin pool with the other "user" VM volumes is required for flexibility. It is not possible to hand-tailor installations for these systems.

More requisites:

  • Admin VM is the storage host, and runs from the thinpool
  • User VMs occupy the same pool
  • Over-provision; all LV virtual sizes = physical disk size.

The problem occurs when user inexperience, bugs or DoS attempt in user VMs cause allocation of all remaining free space for their user volumes (VolU1, VolU2, etc...) and leave VolA with no free space and the admin VM unable to boot or function normally.

The solution / failsafe should be as automatic and as passive as possible. An ideal solution might be an LVM property set for all user LVs, allowing them to allocate space only when poolFree < N, while VolA has no such restriction. But I've been unable to find such a feature in Linux LVM and need suggestions.

After some research it seems a solution could involve using a setting for dmeventd to execute commands (such as 'pause all VMs') when a threshold is reached. A newer man page for dmeventd I found online says this is possible with dmeventd/thin_command setting in lvm.conf; it seems this feature was added in May 2017 so I would have to find a backport.

Another option could be adding a rule like the following to rsyslog.conf:

:msg, contains, "some dmeventd message"  ^my_pause_vm_script
tasket
  • 51
  • 3
  • 1
    *Why* would you put the admin volume in a thin pool? If you are the admin, surely you can decide if and when you need to increase the size of a regular admin logical volume, instead of relying on it pretending to be very large from the start and auto allocate from the thin pool as needed? – psusi Apr 06 '18 at 17:54
  • If you want snapshots or especially chains of snapshots, you want a thin volume (for performance reasons). Quite a few SDS products work better with thin volumes. Regardless of OPs intent, that's a pretty good reason. – Spooler Apr 07 '18 at 02:26
  • On second thought, the use case for these systems is not a good fit for "server", so it may be better to move this to a different site like Unix&Linux. – tasket Apr 19 '18 at 20:25

1 Answers1

0

If you want to prevent users from over-allocating the same thin pool as your admin host, then you might want to take a different approach with this allocation.

You could separate the administrative workloads into a separate thin pool. And if you're over-allocating it's generally a good approach to provide more elastically assignable backing storage to your pools in order to deal with temporary over-allocating. A good easy way to do that would be to reserve some large slower LUNs as a cheap "emergency" PV for your pools.

I know that LVM can do this emergency expansion using it's own configuration, but I'm writing this on a ham sandwich that can barely get out of its own way so I'll have to find that documentation later.

Spooler
  • 7,016
  • 16
  • 29