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

[lee]

Kai Krakow <hurikhan77@×××××.com> writes:

> 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.

Ok, that makes sense when you have more or less unlimited resources to
pay for all the hardware you need for this.  I wonder how much money
you'd have to put out to even get started with a setup like this ...