Re: Proposal for virtual devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 06, 2006 at 03:48:43PM +0200, michel.ponceau@xxxxxxxx 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  -=| 


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]