* Anthony Liguori <aliguori@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.