6:29 p.m.
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
2:35 a.m.
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
3:24 a.m.
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 :|
4:46 a.m.
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 :|
8:52 a.m.
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
9:22 a.m.
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
9:35 a.m.
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 :|
6006
days inactive
6007
days old
6 comments
4 participants
participants (4)
-
Cole Robinson -
Daniel P. Berrange -
Daniel Veillard -
Stefan de Konink