[Libvir] [Libvirt] Proposal to add 3 functions for VBDs (Virtual Block Devices)

[Daniel Veillard]

On Thu, Aug 24, 2006 at 05:58:02PM +0100, Daniel P. Berrange wrote:
> On Thu, Aug 24, 2006 at 12:51:58PM -0400, Daniel Veillard wrote:
> > On Thu, Aug 24, 2006 at 05:54:21PM +0200, Philippe Berthault wrote:
> > > I think that, instead of designate the backend domain by its id, it 
> > > would be better to designate it by its name.
> > > This is because the id isn't fix, excepted for the domain-0.
> > 
> >   Right, providing a flexible and generic enough naming scheme is probably
> > the best, using strings is definitely better IMHO. Usually devices will
> > be associated to existing devices or files, which will be referenced by
> > names. If those resources doesn't exist as such or can't be named, it's 
> > better to still build a naming scheme around the mechanism, for example:
> > 
> >     'xen:vbd:0:1234' or 'xen:vif:2:0123' 
> > 
> > and using those names separates the API from the specifics, while allowing
> > some flexibility.
> 
> This is just exposing xen specific attributes via the backdoor, rather 
> than via an explicit API. The result is same - applications will become
> more dependant on particular hypervisor impementation details.

  well I wanted just to illustrate the case where we can't name the resources
in a preexisting way. I was thinking of the specifc case were you ask domain
n to map a device exported from domain m. 

> If we're going to expose block info & allow attach / detach, we should
> follow the data format already exposed for block devices in the XML:
> 
>   - device name   - eg  hda, xvda1, xvda1, etc
>   - backing store - path to a file 
>   - type - phys / file
>   - readonly - boolean
>   - type - floppy, cdrom, disk

  In the general case, yes we need to reuse those existing names, just that
we may need to invent more names.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/