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