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
|
Home