On Fri, Nov 03, 2006 at 12:03:04AM +0000, Ewan Mellor wrote:
> I meant log it to xend.log (the log infrastructure), as opposed to
> xend-debug.log (Xend's stderr) if you were making that distinction.
Well, I suppose that's a bit better.
> Certainly we could indicate the failure later, though it's a little
> complicated. Of course, the error can only be detected by the guest, so
> you'll have to make blkfront or the equivalent in Solaris write an error code
> to the store, and then pick that up again from Xend. This has been done to a
> certain extent already, but the problem is that, by this point, xm has
> returned success, so though the error has been flagged, no-one gets to see it,
> other than diagnostic tools, and it's not long before the device teardown
> occurs and the error message is deleted then anyway.
>
> We would need to grab the error code in Xend, before the device teardown, and
> then because there's no client waiting at this point, the only thing we could
> do is log it anyway. Alternatively, we could extend the "wait-for-devices"
> functionality in the xm create path to wait for an indication of successful
> device set-up (at the moment, we only wait for successful hotplugging in
> dom0). In that case, you would actually have a client to send the error
> message to. Which would be nice.
Presumably, one day, these sorts of errors will be forwardable to
something watching what's going via xen-api. At least, that would be
nice.
BTW, it'd be great if one of you could do a quick write-up on the
current code in xen-unstable? There's a heck of a lot of changes just
gone in, and it'd be nice to know what state things are supposed to be
in: what works, what doesn't, what needs improving.
regards
john
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home