On Thu, Jul 17, 2008 at 01:29:45AM +0200, Stefan de Konink wrote:
> Now personally I think it is smart to check if a domain is already
> defined, or in use. If this is not the case libvirtd and the client get
> this message:
>
> libvir: Xen Daemon error : GET operation failed:
>
>
> That doesn't seem to fit the scenario at all :) Why does lookupbyname
> behave so bad?
>
>
> Secondly; I am a bit distracted by the domids concept. These ids are not
> available before a domain is launched. I think it would be interesting
> to allow signed values. In this way the 'defined' not active domains
> would get a negative value and a running domain a positive value. (Dom0
> gets 0) This would have far less implications than using an uuid
> through the codebase consistently (not speaking the about the extra
> overhead).
The dichotomy is very simple, it comes from the following when running
with Xen:
- if the domain is running, we can do an hypercall to check informations
about it using just the id, and in a few microseconds
- if the domain is not running, we must do an HTTP request (hence the GET
error) to xend to get any informations about it, that is also way more
costly (at least in the Xen case)
See the discussion with Dan yesterday. The presence of an ID usually means
the domain is running and the hypervisor knows about it, if not running you
have to query a database or some storage to learn about it and the ID has no
meaning, that's a very different situation in practice, and you need to use
an external identifier name or UUID about it. The dichotomy between internal
identifiers and permanent external identifiers is present everywhere in
computing, really that's nothing new, think DNS for example.
Now for a negative ID, that just doesn't help, it won't be any faster than the
name or UUID lookup, since the hypervisor doesn't know about it, and it would
be libvirt having to maintain that ID, independantly to the hypervisor. Say
if we assign -3 to a domain, we would have to build some storage mechanism to
preserve that identifier mapping, and we would not be able to avoid the
hypervisor from using +3 for another running domain at some point. You really
gain nothing, except complexity and confusion. That just doesn't work IMHO.
The GET operation failed used to be in the way in the past, that was fixed
in one of the previous versions, but not knowing what you're using (version
or API entry point) there is no diagnostic to be done. Get a debugger, put a
breakpoint at __virRaiseError and see where it is coming from based on the
backtrace.
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/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list