From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Goirand Subject: Re: Xen Memory De-duplication Date: Tue, 12 Oct 2010 18:20:08 +0800 Message-ID: <4CB43658.6030302@goirand.fr> References: <96a60488-b3aa-4141-92a4-587257b48d86@default> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Aditya Gadre wrote: > This kind of implementation will require the disk blocks from > different DomUs to be mapped to same physical disk block. > For example, > 1) Shared read only filesystem > 2) Union based filesystem > 3) Virtual machine images deployed on a host filesystem which has > deduplication enabled > > What kind of arrangement of filesystem is used in production > environments for DomUs which host large number of VMs as in cloud > enviorment? > I don't know for others, but for us (eg: at GPLHost), none of what you described above is doable. Each VM has its own LVM partition, and we wont have shared filesystem among many VMs. Never ever. We don't use virtual machine *images* either. What would be nicer, would be a more general approach, and maybe have the possibility to use a filesystem that is already mounted on the dom0. Why? Because most of the time, what is wasted, is the free space in each LVM, in what I described above. Thomas