Driver domains and device handling

["Roger Pau Monné" <roger.pau@citrix.com>]

Hello,

I'm currently reviewing the driver domains protocol proposal, but I
think that before reviewing the protocol we should make clear what kind
of store backends libxl supports, and what are the plans for future
backends.

One of the benefits of the driver domain protocol is that it should
allow to split device connection in at least two phases, which is
important for live migration. The first phase should contain all the
logic that's slower, and should be performed on the receiver domain
without pausing the migrated domain. I've been trying to figure out
which kind of operation should be done in this phase for the different
types of backends, but with the backend support we currently have in
libxl (blkback, qdisk and blktap) I don't think we are able to perform
any kind of preparatory work before actually connecting the device.

One of the backends which I think libxl should support is iSCSI, that
also allows live migration. I've also been trying to figure out how we
are going to handle this kind of devices, and I'm unsure if it will be
best to handle them using Qemu as the backend, which currently has a
userspace implementation of iSCSI, or using an in-kernel initiator and
blkback. The benefits of using Qemu is that it is all contained in
userspace, and we don't pollute the Dom0 (or the Driver Domain) with
unneeded devices, on the other hand it is probably slower than using a
in-kernel initiator. Doing it one way or another, I'm still not able to
see what we can offload to the "preparatory" phase, in the Qemu case we
just launch Qemu, and if we decide to use an in-kernel initiator we only
have to launch a hotplug script with something like: iscsiadm -m node -T
<iqn> -p <ip:port>.

I'm sure there's people on the list with more experience than me on this
field, and I would like to ask for some use-cases where this
"preparatory" phase would be useful, and what actions will be performed
on it.

Thanks, Roger.