On Thu, Nov 02, 2006 at 11:38:04PM +0000, John Levon wrote:
> On Thu, Nov 02, 2006 at 11:21:17PM +0000, Ewan Mellor wrote:
>
> > > 1) util/blkif.py logs to xend-debug.log if the stat() fails. This is
> > > needlessly chatty, and indicates there's some kind of error, when there
> > > is not.
> > >
> > > 2) util/blkif.py has a load of Linux gook for getting the device
> > > numbers. Luckily Solaris has a completely different naming scheme, but
> > > wouldn't this go horribly wrong if a domU just happened to use the same
> > > name, different device number?
> > >
> > > It's not clear to us why Linux even needs to do this?
> >
> > I think that the correct fix would be for the tools to pass the untranslated
> > device name into the guest, rather than translating it to a device number
>
> Sounds sensible to me.
>
> > that it's not an old Linux guest. The change was intended to improve the
> > error message that you receive in this case, so at the least, the failure
> > ought to be logged (unless you can come up with some way to detect old Linux
> > guests, and only complain in that case).
>
> Is there some other way to indicate the failure later? We'd like
> xend-debug.log to be essentially silent during normal operation for a
> non-debug xend...
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.
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.
> > Would you like to put together a patch along these lines?
>
> I can do a patch for xend, but I'm not familiar enough to update the
> Linux side of things.
That's fine -- if you can make it work for Solaris without breaking the
existing functionality, we can move Linux over to the new scheme at a later
date.
Cheers,
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home