From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: [RFC] support more qdisk types Date: Wed, 03 Feb 2016 19:53:37 -0700 Message-ID: <56B2BD31.3030909@suse.com> References: <56A6BCDE.6040900@suse.com> <20160202145930.GB25660@citrix.com> <56B12849.2010705@suse.com> <1454493390.25207.35.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1454493390.25207.35.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Wei Liu Cc: xen-devel , Ian Jackson , Ken Johnson List-Id: xen-devel@lists.xenproject.org On 02/03/2016 02:56 AM, Ian Campbell wrote: > On Tue, 2016-02-02 at 15:06 -0700, Jim Fehlig wrote: >>> And extending >>> the structure seems to be the right thing to do. >> So what do you think of the approach in the RFC patch? It adds discrete knobs in >> the disk config and extends the disk structure similarly. Before I can make >> progress on this we need to agree on extending the config and libxl_device_disk >> structure. > My main concern is that this approach requires us to update libxl for each > new possible backend type. Yes, understood. > > The intention of the target= in the disk spec is that it consumes the rest > of the line so it can be used to encode pretty much anything. Is it not > possible (modulo bugs) to pass all the necessary information to qdisk in > this form? I thought Dave S had made it possible to use qdisk in this way > back in: > > commit a8a1f236a2964506a22d1779648d8e1c8668cb1a > Author: David Scott < dave.scott@eu.citrix.com > > Date: Tue Apr 23 10:59:26 2013 +0100 > > libxl: Only call stat() when adding a disk if we expect a device to exist. > > We consider calling stat() a helpful error check in the following > circumstances only: > 1. the disk backend type must be PHYsical > 2. the disk backend domain must be the same as the running libxl > code (ie LIBXL_TOOLSTACK_DOMID) > 3. there must not be a hotplug script because this would imply that > the device won't be created until after the hotplug script has > run. > > With this fix, it is possible to use qemu's built-in block drivers > such as ceph/rbd, with a xl config disk spec like this: > > disk=[ 'backendtype=qdisk,format=raw,vdev=hda,access=rw,target=rbd:rbd/ubuntu1204.img' ] I thought I tried disk config along those lines with no success. But I'll certainly take a closer look at using target= to encode the config needed by these qdisk block drivers. Thanks for the pointer. Regards, Jim