Re: Missing libvirt+libxl functionality (Was: Re: [Xen-users] Programmatic administration of Xen machines)

[Jim Fehlig <jfehlig@suse.com>]

On 01/08/2016 05:46 AM, Ian Campbell wrote:
> On Thu, 2016-01-07 at 22:54 -0700, Jim Fehlig wrote:
>>>> I had even more trouble, e.g. I wasn't able to use non-standard block
>>>> scripts (neither via /etc/xen/scripts/block-XXX nor via a script
>>>> parameter) which are mandatory for me.
>>> Looking at the code it seems like this is still missing.
>>>
>>> Copying the devel list and maintainer in case I've either missed something
>>> or there is a reason for this (other than "still on the TODO list", which I
>>> expect is most likely).
>> It is on a TODO list, but I'm not sure how to solve it :-/. Unlike the
>> libxl_device_disk struct, the corresponding libvirt struct does not support a
>> 'script' field, and I doubt it ever will. Repeated attempts to add a 
>> element to the  config have been rejected. The libvirt community prefers
>> all config needed to setup disks be provided in the XML, not left to a magic
>> script doing unknown things behind libvirtd's back.
> That's an understandable position for them to take, I think.
>
> If someone does use the libvirt's XML based mechanisms to configure things
> then does the libxl backend correctly plumb them through?

No, not at this time. At least not the interesting ones like nbd, iscsi, rbd
(and to some extent npiv).

>  I suppose
> something in libvirt either produces a blk device (which can be trivially
> converted to a suitable libxl disk phy thing) or a reference to some image
> file (perhaps less trivially convertable but doable, most of the time?).

That would be one approach. The other would be to pass the info to libxl. In
some use cases, it is desired/needed in libxl anyhow. I was recently
experimenting with qemu's integrated librados support, which provides native
access to block devices on ceph clusters. I hacked xl/libxl to support an 'rbd'
qdisk, adding server, port, etc. to xl.cfg and libxl_device_disk. The info was
needed when invoking qemu. nbd and iscsi qdisks could be similarly supported.
IMO, it would be unfortunate to reimplement qdisk features in the libvirt libxl
driver. Note that for many of these disk types, the libvirt qemu driver passes
the config along to qemu.

>
> If the libvirt XML stuff works then I don't see any pressing need to plumb
> Xen scripts through to libvirt if the libvirt maintainers do not want to
> support that abstract concept. If folks want functionality which would only
> be available via scripts then they should be encouraged to implement that
> functionality generically in libvirt in a way which is acceptable to the
> maintainers.

Right. That's exactly what has happened over the years as libvirt has gained
support for nbd, rbd, iscsi, and npiv disk devices.

>
> I appreciate that this might mean that some xl style cfg files cannot be
> laundered through domxml-from-native to create a working xml config, but I
> think that's a natural consequence of having two separate projects with
> somewhat non-overlapping featuresets and design goals.

Agreed, but we can strive to minimize that.

>
> I see domxml-from-native as more of a convenience for configurations which
> fall into the union of xl and libvirt's featuresets. I suppose if someone
> was feeling adventurous then they could try and have domxml-from-native
> spot some uses of well known block scripts and convert to the equivalent
> libvirt XML e.g. spot block-iscsi and convert that into equivalent libvirt
> XML objects (assuming libvirt supports iscsi, I didn't look).

Yes, that would be possible.  E.g. something like the following xl -> domxml
conversion

  disk = [ 'iscsi:iqn.2013-07.com.example:iscsi-nopool/2,xvda,w' ]

  <disk type='network' device='disk'>
    <driver name='qemu' type='raw'/>
    <source protocol='iscsi' name='iqn.2013-07.com.example:iscsi-nopool/2'>
      <host name='example.com'/>
    </source>
    <target dev='xvda'/>
  </disk>

But as mentioned above, I think there is some benefit in supporting some of
these disk types in libxl, and hence xl.cfg. I owe the list an RFC mail about
this topic and hope to post something in the next week or two - unless the idea
is immediately discouraged :-).

Regards,
Jim