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