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

[Stefano Stabellini <stefano.stabellini@eu.citrix.com>]

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.