Questions about the future of libvirt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]