[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen Memory De-duplication


  • To: Xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: Thomas Goirand <thomas@xxxxxxxxxx>
  • Date: Tue, 12 Oct 2010 18:20:08 +0800
  • Cc:
  • Delivery-date: Tue, 12 Oct 2010 03:21:49 -0700
  • Domainkey-signature: a=rsa-sha1; c=simple; d=goirand.fr; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=postfix; b=aMc ZX4JML66JM7K0J9VqrzvhU6rzS8HH1N4FiRi5/3kOloF6pSusFQGhYFLyyP0A2S4 xHGbcA4kmNZgBfg4ZvZa+sb+B6ql/sLJT6h88NN0CjusDtKOBOxxW7h815FBENYp /ZJzpecGegGccaSVvPS/1Qr6NqpjYy9oPmqrLKEI=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.