From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Subject: Re: [RFC] support more qdisk types Date: Wed, 27 Jan 2016 14:25:51 -0600 Message-ID: <56A927CF.2030708@cardoe.com> References: <56A6BCDE.6040900@suse.com> <20160127183220.GC3134@char.us.oracle.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1092955550060599677==" Return-path: In-Reply-To: <20160127183220.GC3134@char.us.oracle.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: Konrad Rzeszutek Wilk , Jim Fehlig 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) --===============1092955550060599677== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tmJo7MKCiMdC129xwtedQVsLVjlCsV1wF" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tmJo7MKCiMdC129xwtedQVsLVjlCsV1wF Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 qd= isk 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 su= pports >> 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. >=20 > 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=3D' 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-config= uration >=20 > Either way - new backends would require changes in both libxl and libvi= rt right? > The libxl would need to understand the new 'target=3D' blob to parse it= out? >=20 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? --=20 Doug Goldstein --tmJo7MKCiMdC129xwtedQVsLVjlCsV1wF 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 iQJ8BAEBCgBmBQJWqSfSXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUCHQP/26E/+v6ExWvFvY3sQ22n4JH I1NOHZIdKxKEXRP+OPPoR8pk+FUKXcRoSvYwIJb8UKXCcfMYsTqeGzbfEjBl8yos R2mGWp1owhjh+YB8xWOtVo3AXl0pt58ulGbvok3j0pyrzyT2b4Fo55ifPsj9tTh6 DpIddR5cU+J+3vHs7BX9jdGZPcXKq14dM4eKMTVxTqtjofpnxA/rudDMhPOWKhpq +uwF8AhIffT0fMkuquMcCSTatOjhhFgtY1LTkplIO+jMZdNTrutPD53RZah/a3VI 2AfDsCxR5uO0cYbZfyQmbFNIWMbF9G7Pg1RGAGRyIUl0n1uj3BV85tUvskMv3r/M yNp2N5YCtUVRCbd6Vocy3kf4RcOO7v5Twj2YCxedxNL2bXXAsEFeUJLGU/wL5mMb UlBAQ5u1xHW/fnv3XtD49vdRrob8ygQXmXBwwOpWUggHiMWlw4GbPkT+RC4ExdjY dZw2iaMbeTLqb+JOv/zdoEBIeFFkwA/OaW1ZQvLT9b2SboKasEXzVv0bJlg/l+7o Ei0avbeipkfDeSKyDudPiu1XxJrFaDjIZQbDe5T+PQfa56hnK5usZ5HKtnvYI5D3 tK2YpAOqnQ27YXG6RLwBSi2Qo+j4GwpkEbU0PiQBezSUNQ0AMVA68H3QVTx1c8X/ TaZyz9sBWk3I/voTHZli =PufI -----END PGP SIGNATURE----- --tmJo7MKCiMdC129xwtedQVsLVjlCsV1wF-- --===============1092955550060599677== 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 --===============1092955550060599677==--