Re: [Xen-devel] [RFC] support more qdisk types

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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