On Thu, 2005-04-14 at 22:13 +0100, Ian Pratt wrote:
> > Things start getting odd if you start mixing anything that
> > natively shows up as scsi with a vbd scsi, though, don't
> > they?
>
> Yep, it's a bit skank. I've had this before when I had a guest that was
> moutning an iscsi target directly, and also a partition on the local
> scsi disk via a vbd. I had to import the local scsi disk partition as
> /dev/hda1 as the iscsi needed the sda.
Yeah, that's what I was sort of thinking might be needed.
> I think we still register the xda major/minor for such eventualities.
This isn't that hard to do through lanana
> Users really like to be able to boot the same file system both native
> and on Xen without modifications, so I think this requirement wins out
> for the moment.
>
> Perhaps in preparation, vendors could make their installers 'xda' aware?
Keeping it working in the short-term while people want to do this might
be reasonable, but if they're doing the Right (tm) thing and mounting by
label or uuid, it doesn't matter what the device is. And I think that
medium term, there are going to be plenty of other changes needed for
going from a native system to an unprivileged guests. I can go ahead
and start getting the patches for the xd devs, though, once they have a
major/minor.
> [Hmm, we should probably officially register the major also. Anyone know
> how to go about this? Or better, do it for us?]
http://www.lanana.org/docs/device-list/instructions.txt has the
instructions. I can volunteer to send the information upstream. It
looks like using xd is already going to be a namespace conflict with the
ooollldddd IDE devices, though. What if we go with vbd for the device
names? Then the questions are
a) How many minors per disk device? This dictates number of partitions.
It's probably reasonable to just do 15 like SCSI (especially as more can
then be handled dynamically for 2.6)
b) How many vbds do we want to have static majors for? 16 is probably
reasonable and this then means that we only take up a single block
minor.
This would then give for the devices.txt entry --
XXX block Xen Virtual Block Device
0 = /dev/vbda First Xen VBD whole disk
16 = /dev/vbdb Second Xen VBD whole disk
32 = /dev/vbdc Third Xen VBD whole disk
...
240 = /dev/vbdp Sixteenth Xen VBD whole disk
Partitions are handled in the same way as for IDE
disks (see major number 3) except that the limit on
partitions is 15.
> > And upstream has been fairly resistant to other !scsi
> > or !ide devices sitting on those devices. I've had this
> > argument with Jeff Garzik before about a few of the esoteric
> > SATA drivers that don't even pretend to be scsi. And things
> > like partitioning tools and hardware probing will start
> > showing more problems with ioctls not working as that starts
> > to show up.
>
> Yep, we might hit resistance. Let's hope no-one reads our drivers too
> closely :-)
Heh :-)
Jeremy
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home