Re: [RFC] support more qdisk types

[Jim Fehlig <jfehlig@suse.com>]

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?

Regards,
Jim