WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: Disk naming (Was Re: [Xen-devel] [PATCH] Guest bootloadersupport [1/

To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: RE: Disk naming (Was Re: [Xen-devel] [PATCH] Guest bootloadersupport [1/2])
From: Jeremy Katz <katzj@xxxxxxxxxx>
Date: Thu, 14 Apr 2005 17:47:14 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 14 Apr 2005 21:47:28 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D1E3B9A@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D1E3B9A@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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

<Prev in Thread] Current Thread [Next in Thread>