From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Subject: Re: [RFC] support more qdisk types Date: Fri, 29 Jan 2016 08:21:30 -0600 Message-ID: <56AB756A.5070608@cardoe.com> References: <56A6BCDE.6040900@suse.com> <20160127183220.GC3134@char.us.oracle.com> <56A927CF.2030708@cardoe.com> <56A97ED7.2000600@suse.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5180366238458222579==" Return-path: In-Reply-To: <56A97ED7.2000600@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 , Konrad Rzeszutek Wilk Cc: Ian Jackson , xen-devel , Wei Liu , Ian Campbell , Ken Johnson List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============5180366238458222579== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hrwe87DtvxTqW5e4Us61B0O52F6oKQ2fN" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hrwe87DtvxTqW5e4Us61B0O52F6oKQ2fN Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/27/16 8:37 PM, Jim Fehlig wrote: > 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 qdis= k 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 t= he future. >>> ssh? >>>> I considered several approaches to supporting additional qdisk types= , based >>>> primarily on changes to the disk cfg and interface. At one extreme i= s to change >>>> nothing and use the existing 'target=3D' to encode all required conf= ig for the >>>> additional qdisk types. libxl would need to be taught how to turn th= e blob into >>>> an appropriate qdisk. At the other extreme is extending xl-disk-conf= iguration >>> Either way - new backends would require changes in both libxl and lib= virt right? >>> The libxl would need to understand the new 'target=3D' 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. >=20 > 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. >=20 >> Honestly I don't >> see the advantage here because libvirt does a better job from a securi= ty >> 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? >=20 > I'm simply proposing to extend the types of devices supported by and al= ready > supported backend - qdisk. libxl configures qdisk based on the contents= of the > libxl_device_disk struct. This proposal extends the struct with info ne= cessary > to support the additional qdisk types. >=20 > Regards, > Jim >=20 Well I apologize for my comments because I clearly didn't understand what you were proposing. Sounds good. --=20 Doug Goldstein --hrwe87DtvxTqW5e4Us61B0O52F6oKQ2fN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWq3VtXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUF24P/26GHqgDzUKWusXQ+nl0BgQN a9MJXUkcSBi091q6D1O3AVLqdHode3pu8aFgNEoBqKZ0Tusar27KlNARCaVidX50 mWvuEWFb9UJvk0mGi37lcgi2Ksob/q5YX6Lv+gm+Fu40dT6KmN56CS+8asia1WGy 1lubLH9zXNr3VWkL2WPDBABhQlOfSeHt3Log0+p2VmZmuPoh3NHEVHmgmggBVJJx j8WvPIItPoeTOb7Hvjnvwfqzwv/YwgKnD2F2m7ipFg2MEn0PY4G2tlxC1EvnLQ3k 9oANC1rBMtqN6W+VvE+erRSCGDI6dPp07FGJPicjMkDvZiQ/Sq9rQdJfjI+J2iNp ZqLENtG/LyP14+UqZwIJYT/tSXxYg+3enlSnfpUc+Vt+pzyhnXbaIvkjssVGZ1/R QekK6u/0bDytUJFf5plqWUO8XvVdScId1+WX8oWwFnPUdKPJl1iHu+NZTSA4vzcV ZoEBlng1dKsEqTISAKY1H+NA7sBALj4LMm81InZKHE527QeKOophbMKk9gqLYHOx d/8WorU/cf4UXfcW9oNB9lOIto6frUM4ntye+nHIqifdzEpri/pAjQV/DSM0DpVR 9wizfmBIcDOrzaQe1/sYSDSuJjjGfqhA72kIMubKCcoEWuNimmIdHqfe4zbHGQ6D mF9cNjJyFcLhPNeVEmuY =wjnG -----END PGP SIGNATURE----- --hrwe87DtvxTqW5e4Us61B0O52F6oKQ2fN-- --===============5180366238458222579== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5180366238458222579==--