[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.