On Oct 23, 2006, at 2:56 AM, Tony Breeds wrote:
I'm slowly working my way through a default run on xm-test on my
JS20 trying to determine if the tests that fail represent real
with xen on PPC, or if they're showing problems with the tests
By correcting some of the create/* tests (patches posted to xen-devel)
XenPPC now passes that whole group.
In looking at the block-* tests, I see that the failures are due to
domU kernel including scsi support, which then causes a conflict on
number 8, resulting in a lot of failures in xm-test.
If I try to do this manually, I get:
Registering block device major 8
register_blkdev: cannot get major 8 for sd
xen_blk: can't get major 8 with name sd
vbd vbd-2065: 19 xlvbd_add at /local/domain/0/backend/vbd/1/2065
The problem is described in:
Where we are told:
"all you need to do is disable the entire scsi subsystem"
GTFOOH! (said in my best soprano)
There has to be a better way!
I'd like to know how everyone feels about creating a "make
target which turns of the driver that aren't needed?
I think it is unacceptable.
Seriously, it is really important to XenPPC that the same kernel
image work everywhere
Or alternatively suggestions on how to keep a unified kernel image
One alternative is to use the ide devices
$ xm block-attach 3 file:/root/disk2 hdb2 w
Works just fine, for disks.
There is also the "xvd" (Xen Virtual Block Device) which can be
attached using xen major 20
$ xm block-attach 6 file:/root/disk2 xvda w
Which translates into (202,0), which is lanana blessed:
I had to:
mknod /dev/xvda b 202 0
to be able to mount it.
I do not know what the official/current Xen support for "xvd", but it
is a good question, I'll ask.
Xen-ppc-devel mailing list