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. -- Regards, Kai Replies to list-only preferred.
