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

Re: [Libvir] Questions about the future of libvirt



David Anderson wrote:
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,
Excellent!
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/";.
Just the hostname and port actually. The /xend part is always implied by the Xend protocol.
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?
Not that I know of.
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.
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.

Do you need to be able to pin VCPUs to particular domains?
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 :)
Nope, this is just what it's for :-)
Regards,
- Dave.

--
Libvir-list mailing list
Libvir-list redhat com
https://www.redhat.com/mailman/listinfo/libvir-list


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