[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-API] [Xen-devel] [PATCH 0 of 9 RFC v2] blktap3: Introduce a small subset of blktap3 files
> In fact I'm wondering why the tapback daemon does all the ring setup, > xenbus negotiation anyway. It could just watch "backend/<device-type>" > and when it sees a new backend/<device-type>/<domid>/<devid> fork a new > "tapdisk --domain <domid> --devid <devid>" and have tapdisk take care > of the protocol entirely. Saves a bunch of messaging back and forth I > think. > > I don't have a problem with the existing model, it just strikes me as a > bit odd (but then I don't really know the architecture) > > Ian. I'm not aware of any particular reason for this design option. However, this may turn out to be more interesting/complicated -- I'm including xen-api. In the existing blktap3 prototype, when libxl starts a domain it also spawns the tapdisk. When tapback (formerly known as xenio) detects in XenStore that a front-end wants to connect to the VBD, it needs to locate which tapdisk is designated to serve the corresponding back-end file in order to instruct the tapdisk to connect to the ring. It seems that there is a number of ways for tapback to figure out which tapdisk it must use. I'm not sure whether all these alternatives are possible (please correct me if not), or whether all the necessary information is already written to XenStore. * When libxl spawns the tapdisk, it instructs it to attach to the back-end file. Then, it associates the process ID of the tapdisk with the domain and device Ids (I assume by writing all this to XenStore). When tapback needs to figure out which tapdisk to use, it knows the domain and devices ids so all it has to do is to check XenStore for the corresponding tapdisk. * When libxl spawns the tapdisk, it supplies to it the device and domain ID. It can also tell it which back-end file to use, or write this to XenStore. Tapback can then query all running tapdisk processes and select the one having the specified domain/device ID. It seems that having tapback spawning the tapdisk is simpler, though tapback needs to tell tapdisk which back-end file to use, so it seems that libxl needs to associate the back-end file with the domain and device ids -- I guess this can only be achieved by having libxl writing all this to XenStore. Tapdisk will then take care of running the rest of the XenBus protocol. Which solution is best, given that: * multiple front-ends attached to the same VBD may be desirable * VHD snapshot/coalesce operations need to figure out which tapdisks to pause/refresh * various race conditions should be avoided (?) * other? _______________________________________________ Xen-api mailing list Xen-api@xxxxxxxxxxxxx http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |