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

Re: [Xen-devel] [PATCH 6/6] xl/libxl: implement QDISK libxl_device_disk_local_attach



On Fri, 30 Mar 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [PATCH 6/6] xl/libxl: implement QDISK 
> libxl_device_disk_local_attach"):
> > On Tue, 27 Mar 2012, Ian Jackson wrote:
> > > Stefano Stabellini writes ("[PATCH 6/6] xl/libxl: implement QDISK 
> > > libxl_device_disk_local_attach"):
> > > > - Spawn a QEMU instance at boot time to handle disk local attach
> > > > requests.
> > > 
> > > This is a bit strange.  Why does this need to be a single daemon ?
> > > Can't we have one qemu per disk ?
> > 
> > Why is a bit strange? It has always been the case that QEMU PV would
> > take care of all the PV backends for a single domain. Moreover why would
> > you want more QEMUs when you can handle everything you need with just
> > one and a single thread (except the inevitable xenstore thread)?
> 
> Offhand I can think of at least two reasons to prever separate qemus
> (at least one per domain):

We have one per domain, in this case one for dom0.
Keep in mind that the destination here is domain 0.


> Firstly, the performance scalability will
> be improved if we don't have to funnel all the IO through a single
> process.

Given that the process in question is using AIO, it doesn' matter much.


> Secondly, it avoids propagating failures of any kind from
> one domain to another.

There are no two domains involved here, only one: domain 0.

Also, should we spawn a new Linux kernel for each domain we want a
backend for then?
Even with our disaggregated architecture we never thought of having a
backend/driver domain per guest domain.


> Thirdly, it will make it easier to do
> disaggregation later if we feel like it.
 
Disaggregation is ortogonal to this: we are going to have a qemu disk
backend in each domain we want to be able to do local_attach.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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