>>> Following these notes, we need:
>>>
>>> - a document describing this in full details.
>> Would a txt file do? Where would it go - under tools/examples where other
>> config options are described (albeit in a config file and not a separate
>> file)?
>
> Yep. A text file under docs will be perfect.
>
>
>
Attached is a first stab at this for your perusal. It is mostly based on the
discussion we had in this thread. Please let me know any/all changes you would
recommend.
I am sending this in advance as anything I have captured wrong here would mean
it is likely that the code changes I am making right now could also be wrong!
So please do respond back if I have incorrectly captured any conclusion we
arrived at in terms of the supported/deprecated attributes for the disk
configuration option. Thanks!
Kamala
----------------------------
xl Disk Configuration Option
----------------------------
This document provides a brief description of xl disk configuration option,
different attributes that can be passed through it and the format in which they
need to be specified.
At a higher level, xl disk configuration option takes the following format:
disk = [ 'format:path,vdev:type,attrib', 'format:path,vdev:type,attrib',
... ]
Not all attributes are required and some are deprecated. Following is a brief
description of each of the attribute along with information on whether or not
they are mandatory.
format:
Description: Specifies the format of image file.
Supported values: raw, qcow, qcow2, vhd
Deprecated values: None
Mandatory: No. When not specified raw format is assumed. For a
physical block device the format must be raw and need not be explicitly
specified. For an image file the format could be one of the supported values
and when not specified assumed to be raw.
Backend used: For qcow/qcow2 qemu backend is used as tapdisk2 does not
work with these formats. For raw format image file, tapdisk2 is used and when
not available qemu backend is used as fallback. For vhd format tapdisk2 is
used and tapdisk2 unavailability will result in failure as qemu fallback option
does not support vhd file format.
path:
Description: Block device or image file path. For a physical block
device a /dev will be prepended when not specified and when the path doesn't
start with a '/'.
Supported values: N/A
Deprecated values: N/A
Mandatory: Yes
vdev:
Description: Virtual device as seen by the guest (also referred to as
guest drive designation in some specifications).
Supported values: hd[x], xvd[x]
Deprecated values: None
Mandatory: Yes
type:
Description: Qualifies virtual device type.
Supported values: cdrom
Deprecated values: None
Mandatory: No
attrib:
Description: Specifies access control information. Whether or not the
block device is provided to the guest in read-only or read-write mode depends
on this attribute.
Supported values: 'r', 'w'
Deprecated values: None
Mandatory: Yes
Following are deprecated attributes. Though these atrributes are supported for
backward compatibility, it's usage is not recommended and support for it is
likely to be dropped in future versions of xl.
block-dev-type:
Description: Specifies the block device type.
Supported values: phy, file, tap
Backend used: blkback for type 'phy'. Will result in failure when dom0
does not support blkback backend. For block device type 'file' with format raw
or when no format specfied, tapdisk2 is used when present otherwise qemu
fallback option is used. For 'file' or 'tap' block device type with format
'vhd', only tapdisk2 is used as qemu does not support vhd format. Absence of
tapdisk2 support in this case will result in failure as specified earlier.
access-type:
Description: Backend implementation option to choose from while
accessing block device. Example: tap:aio:vhd:/path/to/file
Supported values: 'aio', 'tapdisk', 'ioemu'
Example usages:
disk = [ 'vhd:/path/to/dev,hda,w', '/path/to/iso,hdc:cdrom,r' ]
disk = [ 'path/to/phy/dev,hda,w', '/dev/cdrom,hdc:cdrom,r' ]
disk = [ 'qcow:/path/to/file,hda,w' ]
disk = [ 'qcow2:/path/to/file,hda,w', 'raw:/path/to/dev,hdc:cdrom,r' ]
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|