Re: [Libvir] Questions about the future of libvirt
* Anthony Liguori <aliguori(a)us.ibm.com> [2006-03-02 18:05:58]:
I would think changing virConnectOpen(const char *) to
virConnectOpen(const char *host, int port) and have port default to
something sane if say 0 is specified would be nice.
Okay. And when we start supporting other virtualization methods, we
can rev that API to add a 'type' param.
I think virConnectOpenReadOnly should continue to fail if host !=
NULL.
There is no read-only TCP equivalent current (although I've been
thinking of adding this to Xend in the future).
Okay. Then, when xend has a way of locking a connection to read-only,
we can change that.
>My question here is all to do with figuring out how to handle
remote
>xend connections. If the connection is remote, then the hypervisor and
>xenstore connections will inevitably fail. And if that is acceptable
>in the case of remote connections, then surely the two opening
>functions could be factored into a single one that always tolerates
>partial failure?
I'd have to think about this a bit more. Having a different open makes
it clear to the user that certain ops may fail.
We can keep them different opens. I just wanted to unite the code in
a single internal function, and make the public functions use that, to
avoid code duplication:
static virConnectPtr
connect_open(const char *host, int port, int read_only)
{
/* Common init code */
}
virConnectPtr
virConnectOpen(const char *host, int port)
{
return(connect_open(host, port, 0));
}
virConnectPtr
virConnectOpenReadOnly(const char *host, int port)
{
return(connect_open(host, port, 1));
}
Also, currently OpenReadOnly still tries to open the xen hypervisor
and xend connections. Shouldn't it just open a xenstore connection,
to enforce read-onlyness ?
The hypervisor calls are kept for performance (although I'm not
convinced this is necessary :-)) and the xenstore access is kept for
"read-only" access. Xenstore offers (on localhost) a lesser privileged
read only port which lets you get some domain information (which is
useful for things like a Xen gnome applet).
Ok, that's clearer now. Thanks.
>>This my fault. The backend doesn't expose the VCPU
pinning set because
>>I was too lazy to parse it in the backend code. You can certainly set
>>the number of VCPUs and do hotplugging with the existing code.
>>
>
>Erm, you can? Through the official API, and while the guest is
>running? I grepped for 'cpu' in the source code, and that returned
>only querying functions.
>
I'm talking about the backend code. The number of VCPUs (which is fixed
at build time) is set as part of the domain configuration information.
I didn't realize that xend_set_vcpus was the hotplugging interface!
I'll have to ask Ryan about what they exposed it this way. It seems
like a bad protocol decision.
Oh, right. I'll send a patch for vcpu setting support then.
>Not yet (though it'd be a nice feature to have, for
completedness :)
>), but being able to set the general number of vcpus for a domain,
>without pinning them to any specific one would be cool.
>
Yeah, okay, that's totally reasonable and should be in libvirt right
now. If you want, you can write up a quick patch to add it.
Right.
- Dave.