[gentoo-user] Re: {OT} Allow work from home?

[Kai Krakow]

Am Wed, 20 Jan 2016 01:46:29 +0100
schrieb lee <lee@××××××××.de>:

> >> Overcommitting disk space sounds like a very bad idea.
> >> Overcommitting memory is not possible with xen.
> >
> > Overcommitting diskspace isn't such a bad idea, considering most
> > installs never utilize all the available diskspace.
>
> When they do not use it anyway, there is no reason to give it to them
> in the first place.  And when they do use it, how do the VMs handle
> the problem that they have plenty disk space available, from their
> point of view, while the host which they don't know about doesn't
> allow them to use it?
>
> Besides, overcommitting disk space means to intentionally create a
> setup which involves that the host can run out of disk space easily.
> That is not something I would want to create for a host which is
> required to function reliably.
>
> And how much do you need to worry about the security of the VMs when
> you build in a way for the users to bring the whole machine, or at
> least random VMs, down by using the disk space which has been
> assigned to them?  The users are somewhat likely to do that even
> unintentionally, the more the more you overcommit.

Overcommitting storage is for setups where it's easy to add storage
pools when needed, like virtual SAN. You just monitor available space
and when it falls below a threshold, just add more to the storage pool
whose filesystem will grow.

You just overcommit to whatever storage requirments you may ever need
combined over all VMs but you initially only buy what you need to start
with including short term expected growth.

Then start with clones/snapshots from the same VM image (SANs provide
that so you actually do not have to care about snapshot dependencies
within your virtualization software).

SANs usually also provide deduplication and compression, so at any
point you can coalesce the images back into smaller storage
requirements.

A sane virtualization solution also provides RAM deduplication and
compaction so that you can overcommit RAM the same way as storage. Of
course it will at some point borrow RAM from swap space. Usually you
will then just migrate one VM to some other hardware - even while it is
running. If connected to a SAN this means: You don't have to move the
VM images itself. The migration is almost instant: The old VM host acts
as some sort of virtualized swap file holding the complete RAM, the new
host just "swaps in" needed RAM blocks over network and migrates the
rest during idle time in the background. This can even be automated by
monitoring the resources and let the VM manager decide and act.

The Linux kernel lately gained support for all this so you could
probably even home-brew it.

-- 
Regards,
Kai

Replies to list-only preferred.