[Xen-devel] [HACKATHON] libxl storage plugin session note

[Wei Liu <wei.liu2@xxxxxxxxxx>]

* Background

Jon: XenServer has had plugin storage architecture / model for some
time.  Try to invent new plugin model to not deeply embedded in
XenServer. It needs to work on standard Xen installation.  Early in
the process, need to define APIs. Look into integrate with libxl.


* Data path plugin API

Data path plugin APIs:

- open / close: for some disks, reset on boot.

- attach / detach: may call multiple times on different hosts. returns
  information on which backend to use, metadata to say how backend
  identify the disk.

- activate / deactivate: exclusive, one host at a time.

Attach and activate calls can make migration faster.

Current state: Prototype python plugin to implement the said APIs. IDL
to generate C code. Support to print out human readable information.


Jon: What if we want to use that in libxl?

Ian: exciting and good thing. currently only block script. need to
retain that for some time. block script interface is not
pretty. Concerns there should be no specific knowledge of the
framework if the new mechanism is used.

Paul: data path and control path are separated.


Control path plugin APIs: outside of libxl area, part of libvirt-like
layer. Xen upstream can but doesn't have to use all plugins provided.

* Further discussion

Ian: both APIs need to have spec and plugin repos, libxl will be
consumer of those.

Paul: would be convenient if some management configuration included in
xen.git

Ian: pick the most convenient option.

Paul and Ian: config syntax need to be stable.

Jon: currently UUID is used to identify device, plan to change to URI.

Ian: to make things work across migration, uri needs to be stable,
abstractly describe the object.

Paul: empheral URI, but not sure if it is data path or control path

Ian: the three pairs sound sufficient.

George: need to figure out how those map to libxl internal.

Ian: proposal more generalised then what is currently in libxl. So
libxl internal can be thought as one storage plugin. Currently open
and attach are conflated.

Jon: there is uri in vdev spec, want to put it back. Ian: be careful
about syntax collision with old syntax. then you will need to consider
fit that into libxl idl.

Ian: concern -- driver domain, data path plugin should be run in
driver domain. xl devd in place to communicate. dom0 doesn't need to
trust storage plugin.

Paul: unikernel backend?

Ian: the protocol shouldn't imply using fork-exec. Jon: that's
considered and doable.

Jon: spawn driver domain on demand -- can't decide backend domid
upfront.

Ian: protocol needs to specify which domain plugin runs in and which
domain provides backend.


Ian: performance implication? Python is slow.
Paul: agreed.
Ian: plugin can run as daemon if wishes, requires pre-startup.
Jon: XS has message switch. Registrar for plugin. Could be considered for libxl.
Ian: ppl might not like the idea.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel