On Mon, 2005-09-19 at 09:54 +0100, Keir Fraser wrote:
> I wholeheartedly agree that restore should be equivalent to xenstored
> restart from the p.o.v. of the xenbus driver. That's how the block qnde
> net drivers already work. But it's orthogonal to whether we mux
> connections onto a single transport page.
OK, that's a little confusing. There are three ways to talk to
xenstored (dom0, domU kernel, domU userspace), and two comms problems
(xenstored restart, and migration).
1) For domU kernels, we have a shared page, so xenstored restarts are
completely transparent to the domains: the new xenstored just maps the
page and away we go. We also hold the xenstore_lock across entire
transactions, which is grabbed on save/restore, so we trivially avoid
any sync issues on migration.
2) When dom0 tools connect to xenstored, they use a socket, which
there's no easy way for the new xenstored to pick up (eg. you write to
the socket just as the daemon shuts down...). The idea, then, is to
handle reconnecting in libxenstore itself. The recent protocol tweaks
are designed to make this trivial. There's no migration of dom0 tools
to worry about.
3) The new problem is domU tools. By providing a kernel device node we
make it look exactly like talking through a socket, so libxenstore is
basically unchanged. By each open using a separate page to talk to
xenstored, we don't have to hold the kernel lock, nor worry about tool
errors/crashes screwing the kernel's store page. xenstored restarts are
transparent. On migration, we can simply force close (unmap page,
return EBADF), which libxestore can treat exactly like the xenstored
restart case with sockets, reconnect and re-xmit.
The only issue is that, in the case of migration, the new xenstored
won't know about any transaction currently in progress. We can either
migration transactions (easy for clients), or return EAGAIN for the next
operation (easy for xenstored, sucks for clients).
Cheers,
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home