[Libvir] Questions about the future of libvirt

Anthony Liguori aliguori at us.ibm.com
Thu Mar 2 20:14:38 UTC 2006


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 at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>   




More information about the libvir-list mailing list