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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/