Xen project Mailing List

the hex solution will work nicely. Maybe xen needs its own set of major/minor numbers which xend can parse without having to look them up? eg /dev/xbd1

I wonder how udev will work running in the xenU domain... do you think it would recognise the xen devices? i'll give it ago when I can afford some more testing time.

thanks

James

> I figured it out, at line 228 self.vdev = None (not an integer!!!), because I don't have a /dev/sda1 in /dev so xen can't figure out the major & minor numbers. I run udev which removes anything not being used. My scsi controller is an (old & slow) compaq smart array and the devices for that live in /dev/ida.
> 
> I believe this is a bug, but how would you solve it? The fact that the error isn't reported nicely is definitely a bug though, imho.

Thanks for tracking this down. Xend certainly needs to handle the
error case more gracefully.

We're actually aware of a general problem with the way we handle
looking up block device names. Currently, xend looks both the
subject and target names up in domain 0, and then communicates
device numbers to the front and backend drivers.

This doesn't make sense if the guest domain is actually a NetBSD
OS with entirely different device names/numbers. It also doesn't
always work if you're using backend drivers in separate domains
from dom0 (to enable restartable device drivers), where you might
not have the subject device node in domain 0.

The correct fix is to look both the subject and target device
names up in the context of the domain that's going to be using
them. This will require a few changes to the device control
message protocol. It's on the todo list...

BTW: You can specify devices using the 16bit hex device
number. e.g. in your example to have a target of sda1:
  phy:vg/foobar,0803,w

Ian

RE: [Xen-devel] can't start domains