Re: [RFC] support more qdisk types

[Jim Fehlig <jfehlig@suse.com>]

Wei Liu 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.
>>
> 
> This is a good idea in general.
> 
>> 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. 
> 
> I think you mean "libxlu would need to be taught how to turn that blob
> into an appropriate libxl_device_disk" -- libxl doesn't parse user
> configuration, it deals with the libxl_device_disk directly to construct
> arguments for QEMU.

Right. But if the configuration is all encoded in 'target=', libxlu already
parses that and puts it in libxl_device_disk.pdev_path.

> Either it is done by extending target= or adding discrete options, the
> heavy lifting is going to be in libxlu.  I don't think we want to parse
> a string inside libxl.

Ok. So in your opinion, even if any new disk config is encoded in 'target=',
libxlu should split that up into (new) members of libxl_device_disk, not just
plop it into libxl_device_disk.pdev_path?

>> At the other extreme is extending xl-disk-configuration
>> with discrete knobs for each possible config item and making the
>> libxl_device_disk structure more hierarchical. E.g.
>>
> 
> I don't think the second half (hierarchical structure) is closely tied
> to whether target= is extended or discrete knobs are used.

Nod.

> And extending
> the structure seems to be the right thing to do.

So what do you think of the approach in the RFC patch? It adds discrete knobs in
the disk config and extends the disk structure similarly. Before I can make
progress on this we need to agree on extending the config and libxl_device_disk
structure.

Regards,
Jim