On Mon, Aug 29, 2005 at 10:12:01AM +1000, Rusty Russell wrote:
> On Fri, 2005-08-26 at 11:28 +0100, Christian Limpach wrote:
> > On Fri, Aug 26, 2005 at 10:20:44AM +1000, Rusty Russell wrote:
> > > Well, we currently don't spuriously fail transactions, because we use
> > > locking to prevent overlapping transactions. As I've argued repeatedly,
> > > this makes for a nicer programming model.
> >
> > How do you handle transaction timeouts then? After all, a guest can
> > get suspended for an arbitrary amount of time and at some point
> > xenstored will have to timeout the transaction and then what?
>
> This is why suspend takes the xenbus_lock; it just doesn't make sense
> otherwise (even without transactions, you could have issued half a
> command, then get migrated to another machine and another store, and
> you'd be screwed).
I didn't mean checkpointing suspend, but the guest getting descheduled
for an arbitrary amount of time, in the worst case the guest getting
user paused for a very long time. Bad luck if it's during a transaction
and the store times out the transaction, what then?
> For xenbus, we can do it either way. But for the tools, we really need
> xenstored to do it, because we need the data to appear in the socket.
> So I think I'll mod xenstored to do it, even though it's a little extra
> traffic (in theory, xenstored could optimize this away if the node has
> *never* existed, but doesn't seem worth it).
Sounds good, thanks!
> > > Domain introductions are the other persistence issue, but they are also
> > > fairly simple. Indeed, they should be placed in the store...
> >
> > Sounds good. I think we also need xenstored to watch for the domain
> > exception virq and remove domains which are dying...
>
> OK, I wasn't sure if xenstored should do this, or have the tools do it.
> I'll look at the xenstored mods...
Great!
christian
_______________________________________________
Xen-tools mailing list
Xen-tools@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-tools
|
Home