[Libvir] Questions about the future of libvirt

[David Anderson]

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