From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: [RFC] support more qdisk types Date: Wed, 27 Jan 2016 19:37:11 -0700 Message-ID: <56A97ED7.2000600@suse.com> References: <56A6BCDE.6040900@suse.com> <20160127183220.GC3134@char.us.oracle.com> <56A927CF.2030708@cardoe.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56A927CF.2030708@cardoe.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: Doug Goldstein , Konrad Rzeszutek Wilk Cc: Ian Jackson , xen-devel , Wei Liu , Ian Campbell , Ken Johnson List-Id: xen-devel@lists.xenproject.org On 01/27/2016 01:25 PM, 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. Hmm, I'm not sure I understand. AFAIK, there is no way to pass libxl a file descriptor opened from an image file or block device. > 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'm simply proposing to extend the types of devices supported by and already supported backend - qdisk. libxl configures qdisk based on the contents of the libxl_device_disk struct. This proposal extends the struct with info necessary to support the additional qdisk types. Regards, Jim