[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Driver domains and device handling
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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |