Kai Krakow <hurikha...@gmail.com> writes: > Am Wed, 20 Jan 2016 01:46:29 +0100 > schrieb lee <l...@yagibdah.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 ...
