[Xen-devel] Xen vbd numbering

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

In May 2008 I wrote:
>  Old format:
> 
>   202 << 8 | disk << 4 | partition    xvd, disks and partitions up to 15
>     8 << 8 | disk << 4 | partition      sd, disks and partitions up to 15
>     3 << 8 | disk << 6 | partition      hd, disks 0..3, partitions 1..63
> 
>  New format:
> 
>   1 << 28 | disk << 8 | partition     xvd, disks or partitions 16 onwards
> 
>  Reserved for future use:
> 
>   2 << 28 onwards

But now that I get down and dirty with some code I discover that
actually what we have is not quite this.  Much Linux-specific stuff
has crept in and the result is a mess.

After consultation, what we intend to implement in libxl is as
follows:

 * The abstract interface specifies, for each VBD:

     * Nominal disk type: Xen virtual disk (aka xvd, the default);
       SCSI (sd); IDE (hd).  This is for use as a hint by the guest's
       device naming scheme.

     * Disk number, which is a nonnegative integer,
       conventionally starting at 0 for the first disk.

     * Partition number, which is a nonnegative integer
       where by convention partition 0 indicates the "whole disk".

       Normally for any disk _either_ partition 0 should be supplied
       in which case the guest is expected to treat it as they would a
       native whole disk (for example by putting or expecting a
       partition table or disk label on it);

       _Or_ only non-0 partitions should be supplied in which case the
       guest should expect storage management to be done by the host
       and treat each vbd as it would a partition or slice or LVM
       volume (for example by putting or expecting a filesystem on
       it).

  * The syntaxes are, for example:
       d0 d0p0  xvda     Xen virtual disk 0 partition 0 (whole disk)
       d1p2     xvda2    Xen virtual disk 1 partition 2
       d536p37  xvdtq37  Xen virtual disk 536 partition 37
       sdb3              SCSI disk 1 partition 3
       hdc2              IDE disk 2 partition 2
    The d*p* syntax is not supported by xm/xend.

 * This is encoded in the concrete interface as an integer (in a
   canonical decimal format in xenstore), whose value encodes the
   information above as follows:

    1 << 28 | disk << 8 | partition      xvd, disks or partitions 16 onwards
   202 << 8 | disk << 4 | partition      xvd, disks and partitions up to 15
     8 << 8 | disk << 4 | partition      sd, disks and partitions up to 15
     3 << 8 | disk << 6 | partition      hd, disks 0..1, partitions 0..63
    22 << 8 | (disk-2) << 6 | partition  hd, disks 2..3, partitions 0..63
    2 << 28 onwards                      reserved for future use
   other values less than 1 << 28        deprecated / reserved

   The 1<<28 format handles disks up to (1<<20)-1 and partitions up to
   255.  It will be used only where the 202<<8 format does not have
   enough bits.

   Guests MAY support any subset of the formats above except that if
   they support 1<<28 they MUST also support 202<<8.

   Some software has provided essentially Linux-specific encodings for
   SCSI disks beyond disk 15 partition 15, and IDE disks beyond disk 3
   partition 63.  These vbds, and the corresponding encoded integers,
   are deprecated.

 * Guests SHOULD ignore numbers that they do not understand or
   recognise.  They SHOULD check supplied numbers for validity.

 * We know that not all guests conform to this interface.  For
   example, old Linux systems interpret the integer as
       major << 8 | minor
   where major and minor are the Linux-specific device numbers,
   and some old configurations may depend on deprecated high-numbered
   SCSI and IDE disks.

   We will therefore preserve the existing facility to specify
   the xenstore numerical value directly by putting a single
   number (hex, decimal or octal) in the domain config file instead
   of the disk identifier.

Ian.

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