[Libvir] Questions about the future of libvirt

[David Anderson]

* Anthony Liguori <aliguori at us.ibm.com> [2006-03-02 14:14:38]:
> Just the hostname and port actually.  The /xend part is always implied 
> by the Xend protocol.

Right.  Is there a preferred formatting for the name parameter?
'http://dom0.whatever:8000' is a little annoying to parse, and doesn't
specify that the connection is to a Xen daemon, which could be a
problem for future support of other virtualization engines.  How about
'xen:tcp:dom0.whatever.net:8000' ?

Other than that, I'm factoring out the connection step into a single
function that handles both readonly and write connections, and I'm
wondering about the handling. In virConnectOpenReadOnly, all three
methods (hypervisor, xenstore, xend) are tried in turn, and the only
criterion for success is that one succeed.  However, in
virConnectOpen, all three must succeed.  Would it be desirable to
unite these three, and if not could you explain why there is a
difference in handling of failure between the two?

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?

Actually, looking through the code, it seems to me that the xend
interface can accomplish almost all of the current API by itself (and
the few functions it doesn't provide could probably be implemented).
Is the direct hypervisor/xenstore access kept in only for performance
reasons?

> 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.

> Do you need to be able to pin VCPUs to particular domains?

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.

> Nope, this is just what it's for :-)

Ah, good.  Then patches will be coming soon :)

- Dave, still a little puzzled.