[libvirt] some unsorted questions
Hi, Currently I'm working on my webserver thingie. And I notice some annoying error messages. Generally I use a predefined host to do the basic setup of defining a domain. So a client can shoot its XML directly into a post request, or we set it up by parsing some parameters from the URI. 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). If this gets implemented I would suggest a call that fetches all domains from a running system and not only the defined or only the active ones. Stefan
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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Thu, Jul 17, 2008 at 01:29:45AM +0200, Stefan de Konink wrote:
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).
There are 3 identifiers for domains - ID - unique amongst all running domains on a hypervisor - Name - unique amongst all domains on a hypervisor - UUID - unique amongst all domains in a datacenter So if you want to track inactive domains, you have a choice of name or UUID. The recommendation is always that applications use UUID to track domains internally. Name should mostly be used when interacting with a user, not for internal application tracking. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Thu, Jul 17, 2008 at 01:29:45AM +0200, Stefan de Konink wrote:
If this gets implemented I would suggest a call that fetches all domains from a running system and not only the defined or only the active ones.
This is a good idea regardless. The current APIs require an application todo num = list number of domains for 1 to num lookup domain by id In the case of the Xen drivers, this requires O(n) calls to XenD which are rather expensive. XenD does actually have ability to return data about all domains in a single request. So if we had an API for fetching all domains at once it'd only require O(1) expensive XenD calls. I'd imagine something like this int virConnectListAllDomains(virConnectPtr conn, virDomainPtr **domains, int stateflags); The 'stateflags' parameter would be a bit-field where each bit corresponded to one of the virDomainState enumeration values. The 'domains' list would be allocated by libvirt, and filled in with all the domain objects, and the total number of domains as the return value. So as an example, listing all paused domains virDomainPtr *domains; int ndomains; ndomains = virConnectListAllDomains(conn, &domains, (1 << VIR_DOMAIN_PAUSED)); We probably want to define constants for the latter set of flags #define VIR_DOMAIN_LIST_NOSTATE (1 << VIR_DOMAIN_NOSTATE) #define VIR_DOMAIN_LIST_RUNNING (1 << VIR_DOMAIN_RUNNING) #define VIR_DOMAIN_LIST_BLOCKED (1 << VIR_DOMAIN_BLOCKED) #define VIR_DOMAIN_LIST_PAUSED (1 << VIR_DOMAIN_PAUSED) #define VIR_DOMAIN_LIST_SHUTDOWN (1 << VIR_DOMAIN_SHUTDOWN) #define VIR_DOMAIN_LIST_SHUTOFF (1 << VIR_DOMAIN_SHUTOFF) #define VIR_DOMAIN_LIST_CRASHED (1 << VIR_DOMAIN_CRASHED) And some convenience combos: #define VIR_DOMAIN_LIST_ACTIVE (VIR_DOMAIN_LIST_NOSTATE | VIR_DOMAIN_LIST_RUNNING | VIR_DOMAIN_LIST_BLOCKED | VIR_DOMAIN_LIST_PAUSED | VIR_DOMAIN_LIST_SHUTDOWN | VIR_DOMAIN_LIST_CRASHED) #define VIR_DOMAIN_LIST_INACTIVE (VIR_DOMAIN_LIST_SHUTOFF) #define VIR_DOMAIN_LIST_ALL (~0) The same style API can be added for listing of virNetwork and virStoragePool objects. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Daniel P. Berrange schreef:
In the case of the Xen drivers, this requires O(n) calls to XenD which are rather expensive. XenD does actually have ability to return data about all domains in a single request. So if we had an API for fetching all domains at once it'd only require O(1) expensive XenD calls. I'd imagine something like this
int virConnectListAllDomains(virConnectPtr conn, virDomainPtr **domains, int stateflags);
The 'stateflags' parameter would be a bit-field where each bit corresponded to one of the virDomainState enumeration values. The 'domains' list would be allocated by libvirt, and filled in with all the domain objects, and the total number of domains as the return value.
Yes; initially I was looking for something like this. I think this is a great idea. Now I wonder, if it could be faster (with the lookup mechanism) to check if the domain exists, before connecting to it. Stefan
Daniel P. Berrange wrote:
On Thu, Jul 17, 2008 at 01:29:45AM +0200, Stefan de Konink wrote:
If this gets implemented I would suggest a call that fetches all domains from a running system and not only the defined or only the active ones.
This is a good idea regardless. The current APIs require an application todo
num = list number of domains for 1 to num lookup domain by id
In the case of the Xen drivers, this requires O(n) calls to XenD which are rather expensive. XenD does actually have ability to return data about all domains in a single request. So if we had an API for fetching all domains at once it'd only require O(1) expensive XenD calls. I'd imagine something like this
int virConnectListAllDomains(virConnectPtr conn, virDomainPtr **domains, int stateflags);
I've thought about something similar as well. It would also be useful to have a command like ListUUIDs with similar state flags, giving apps a more light weight manner of polling for domain state changes (ex. virt-manager) - Cole
On Thu, Jul 17, 2008 at 10:22:05AM -0400, Cole Robinson wrote:
Daniel P. Berrange wrote:
On Thu, Jul 17, 2008 at 01:29:45AM +0200, Stefan de Konink wrote:
If this gets implemented I would suggest a call that fetches all domains from a running system and not only the defined or only the active ones.
This is a good idea regardless. The current APIs require an application todo
num = list number of domains for 1 to num lookup domain by id
In the case of the Xen drivers, this requires O(n) calls to XenD which are rather expensive. XenD does actually have ability to return data about all domains in a single request. So if we had an API for fetching all domains at once it'd only require O(1) expensive XenD calls. I'd imagine something like this
int virConnectListAllDomains(virConnectPtr conn, virDomainPtr **domains, int stateflags);
I've thought about something similar as well. It would also be useful to have a command like ListUUIDs with similar state flags, giving apps a more light weight manner of polling for domain state changes (ex. virt-manager)
A plain ListUUIDs wouldn't be any more efficient - we'd still have to hit either Xenstore or XenD to get the listing, and once you're doing that you may as well return the name & ID too in a virDomainPtr object Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (4)
-
Cole Robinson -
Daniel P. Berrange -
Daniel Veillard -
Stefan de Konink