[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC] support more qdisk types
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 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 > Well I apologize for my comments because I clearly didn't understand what you were proposing. Sounds good. -- Doug Goldstein Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |