Re: [Libvir] Proposal for virtual devices
On Wed, Sep 06, 2006 at 03:48:43PM +0200, michel.ponceau(a)bull.net wrote:
I previously made a proposal for block devices. It was rejected
because it
was VBD-specific and Xen-specific. Here is a proposal for transparent
interface with Xen or other. The virtual device attributes (VDA) are
transferred from/to application without considering their meaning, except
backend domain, previously requested to be the name for user, while it is
the ID for Xen.
This is just exchanging a direct Xen-specific API, for an indirectly
Xen-specific API. The end result is the same - applications using this
API will be forced to know about & use Xen-isms when configuring new
block devices. The XML used to initially create a domain manages to
allow definition of block devices without using Xen-isms, so there is
no reason why the same shouldn't be possible here.
I also question why we need virDomainGetVdevs at all, when this information
is already available from the XML provided by virDomainGetXMLDesc. Adding
a new API which duplicates this info doesn't seem like a benefit to me.
int virDomainGetVdevs(virDomainPtr domain, char *type, virVDA *attr,
int
maxattr);
* @type: pointer to device type, "disk", "network" ...
* @attr: pointer to an array of virVDA structures
* @maxattr: number of structures in attr array
* Return: (number of VDAs per device)<<16 + (number of devices), if
success;
I question why we need virDomainGetVdevs at all, when this information
is already available from the XML provided by virDomainGetXMLDesc. Adding
a new API which duplicates this info doesn't seem like a benefit to me.
We do need an explicit API for fetching disk I/O statstics, but that's not
what's being addressed here.
int virDomainCreateVdev(virDomainPtr domain, char *type, virVDA
*attr, int
nbattr);
* @type: pointer to device type, "disk", "network" ...
* @attr: pointer to an array of virVDA structures
* @nbattr: number of structures in attr array
For "disk" type, Xen requires the following VDA names:
"uname" (backend device, value either "phy:<>" or
"file:<>"
"dev" (virtual device number)
"mode" (value "ro" for read-only, or "rw" for
read/write)
"backend" (backend domain ID)
This function translates "backend" user value (name) into ID.
Nak. This is still full of Xen-isms, and doesn't follow the API style
of existing APIs. If we need to pass arbitrarily extendable metadata
then XML should be used. If not then we should use strongly typed
parameters, or a struct containing strongly typed parameters.
int virDomainDestroyVdev(virDomainPtr domain, char *type, char
*ref);
* @type: pointer to device type, "disk", "network" ...
* @ref: pointer to virtual device reference (number for Xen...)
Close, but 'ref' isn't acceptable - there is already a unique parameter
for refering to devices - their device name as detailed in the 'dev'
attribute of the <target> element. Using a Xen specific integer ID is
wrong.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|