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