Re: [Xen-devel] Linux-specific blkif.py change

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

On Thu, Nov 02, 2006 at 01:42:50AM +0000, John Levon wrote:

> 
> Changeset 11831:f5321161c649 has broken non-Linux domUs with this
> change:
> 
>          devid = blkif.blkdev_name_to_number(dev)
> +        if not devid:
> +            raise VmError('Unable to find number for device (%s)' % (dev))
> +
> 
> The immediate problem is that Solaris domU's have "0" for dev for the
> first disk. So it's presumably matched on the hex re in util/blkif.py,
> returning 0 and failing this incorrect check. There are other problems:
> 
> 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?
> 
> For now I think the change needs backing out so non-Linux domU's can
> work again. I'm not sure of a better fix; suggestions welcome.

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
first.  I've no idea why this was done in the first place, as it's clearly
wrong.  Like you say, there's no reason for a guest's device name -> number
mapping to be the same as dom0's.

Unfortunately, this is part of the guaranteed interface to guests now, so we
need to reproduce this behaviour for old guests, but there's nothing stopping
us fixing this for new guests.  If we fixed the tools to write the device name
as well as the (Linux) device number then new guests could use the name rather
than the number and do the lookup themselves.

In this scheme, the check above would go -- the failure to look up the device
would be handled simply by writing the name and not the number, and hoping
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).

Would you like to put together a patch along these lines?

Thanks,

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel