[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC] support more qdisk types
On Fri, Jan 29, 2016 at 10:18:01AM -0700, Jim Fehlig wrote: > Konrad Rzeszutek Wilk wrote: > > 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. > > Agreed. At a minimum I planned to add testing of any new disk config settings > to > tools/libxl/check-xl-disk-parse. Were you thinking of something more > end-to-end > like a new OSSTEST case? Oh, hadn't know that existed. I was thinking OSSTest - but if check-xl-disk-parse fits the bit, pick that. > > Regards, > Jim > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |