Re: [Libvir] Questions about the future of libvirt

Hi, I've spent the last few hours going over the code of libvirt, trying to work out how I could use it. As far as I can tell, there are a few things missing from it that I would need. I'm willing to submit the patches for these features,

but I'd like a little guidance from the expert(s), to make sure I'm not missing something vital about the organization of libvirt. * Support for pure remote connections At the moment, virConnectOpen only supports connecting to a local hypervisor, and does so in three different ways (xenHypervisorOpen to get a local handle to the hypervisor, xs_daemon_open to get access to the XenStore, and xend_setup to connect to the running xend instance). For security reasons, the application I'm writing should run outside of dom0, which pretty much reduces the possible access paths to Xend via TCP. How much work would it be to alter the libvirt API to allow for pure remote connections? As far as I can tell, most if not all of the functions currently implemented can be called entirely through Xend, so it'd just be a matter of changing virConnectOpen to take a name argument and not opening the store/hypervisor connections when given a name like "http://dom0.whatever.net:8000/xend/".

Once that is done, all functions need to be checked to verify that they all check the existence of the hypervisor/xenstore handle before trying to use them, and that they all have a gracious xend fallback if not. Am I missing something absolutely vital here?

Hopefully I'm not, which leads me to... * Accessing and modifying the memory/vcpu settings for domains Currently, from the API you can change the maxmem parameter of a domain, but not the memory parameter. Also, access to the vcpu configuration is not at all implemented afaict. The memory parameter is a simple matter of adding the right public API to drive the xend_backend functions; for vcpu support, the xend_internal API would have to be extended, at least to feature the equivalent of xen.xend.XendClient.Xend.xen_domain_set_vcpus() in the legacy python API, so that clients can alter the number of vcpus allocated to a domain.

Again, am I missing anything completely, hopelessly vital? :-) If I have not completely missed the point of libvirt, my intuition tells me I'll be submitting a lot more patches after these two, if things work out. Let me know if I'm on the right tracks, so that I can start hacking away :)

Regards, - Dave. -- Libvir-list mailing list Libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list