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

[Ian Campbell <ian.campbell@citrix.com>]

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? 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?).

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.

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.

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).

Ian.