From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Jackson Subject: Re: [PATCH 6/6] xl/libxl: implement QDISK libxl_device_disk_local_attach Date: Fri, 30 Mar 2012 14:47:11 +0100 Message-ID: <20341.47455.258834.382780@mariner.uk.xensource.com> References: <1332856772-30292-6-git-send-email-stefano.stabellini@eu.citrix.com> <20337.63226.633651.340221@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: "xen-devel@lists.xensource.com" , Ian Campbell List-Id: xen-devel@lists.xenproject.org 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): Firstly, the performance scalability will be improved if we don't have to funnel all the IO through a single process. Secondly, it avoids propagating failures of any kind from one domain to another. Thirdly, it will make it easier to do disaggregation later if we feel like it. Ian.