From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [RFC] support more qdisk types Date: Fri, 29 Jan 2016 09:07:42 -0500 Message-ID: <20160129140742.GA31660@char.us.oracle.com> References: <56A6BCDE.6040900@suse.com> <20160127183220.GC3134@char.us.oracle.com> <56A927CF.2030708@cardoe.com> <20160127210947.GA23254@char.us.oracle.com> <56A98029.8040101@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <56A98029.8040101@suse.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: Jim Fehlig Cc: Wei Liu , Ian Campbell , Ian Jackson , Doug Goldstein , xen-devel , Ken Johnson List-Id: xen-devel@lists.xenproject.org On Wed, Jan 27, 2016 at 07:42:49PM -0700, Jim Fehlig wrote: > On 01/27/2016 02:09 PM, Konrad Rzeszutek Wilk wrote: > > On Wed, Jan 27, 2016 at 02:25:51PM -0600, Doug Goldstein wrote: > >> On 1/27/16 12:32 PM, Konrad Rzeszutek Wilk wrote: > >>> On Mon, Jan 25, 2016 at 05:25:02PM -0700, Jim Fehlig wrote: > >>>> I would like to hear the community's opinion on supporting more qdisk types in > >>>> xl/libxl, e.g. nbd, rbd, iSCSI, etc. I prefer supporting additional qdisk types > >>>> in libxl over apps like xl or libvirt doing all the setup, producing a block > >>>> device, and then passing that to libxl. Each libxl app would have to > >>>> re-implement functionality already provided by qdisk. libxl already supports > >>>> IDE, AHCI, SCSI, and Xen PV qdisks. My suggestion is to extend that to initially > >>>> include nbd, rbd, and iSCSI. Sheepdog, ssh, etc. could be added in the future. > >>> ssh? > >>>> I considered several approaches to supporting additional qdisk types, based > >>>> primarily on changes to the disk cfg and interface. At one extreme is to change > >>>> nothing and use the existing 'target=' to encode all required config for the > >>>> additional qdisk types. libxl would need to be taught how to turn the blob into > >>>> an appropriate qdisk. At the other extreme is extending xl-disk-configuration > >>> Either way - new backends would require changes in both libxl and libvirt right? > >>> The libxl would need to understand the new 'target=' blob to parse it out? > >>> > >> libvirt would probably just do what its doing now. Since it can setup > >> the connection and pass the file descriptor into libxl. Honestly I don't > >> see the advantage here because libvirt does a better job from a security > >> standpoint and unless the goal is to have everything and the kitchen > >> sink in libxl/xl. There's already a number of ways to skin the cat (xl, > >> libvirt, xapi, openstack), why another one? > > I believe what Jim is saying that there needs to be some parsing in libxl > > so that it can pass the right information to QEMU. > > Correct. The info is also needed when libxl creates the device in xenstore. I think that would be awesome - especially with the iSCSI and Sheepdog. The one thing that I am worried about is bitrotting. And I would think if test-cases were added for this support - while it is bigger upfront cost - would benefit us long term. Granted I say that - but I hadn't done my share either (xSplice or some other ones I have on mind) so feel free to ignore the recommendation. > > Regards, > Jim >