[Libvir] Features and roadmap tentative draft

Daniel Veillard veillard at redhat.com
Thu Feb 8 18:39:29 UTC 2007


  We had a meeting this week in the Red Hat team and looked at the
work ahead for libvirt. We identified a set of feature that we would
like to get in, the time frame (mostly based on Fedora releases schedules)
and tried to identify remaining issues:

Features        when        Issues
---------------------------------------------------------------------------
KEmu & KVM      FC7         Wire API , the way the process is controlled 
                mid feb     will probably change, but requires QEmu upstream
                            extensions of the monitor
remote access   FC8         Naming (URIs), Authentication and wire protocol
                            inetd hook, XML format slight change for dhcp
Virtual Network FC7         Sharing QEmu, root priviledge for the daemon
                            isolation
Migration       FC8         API design
Access Control  ???         depends on Xen Security Module, KVM equivalent
Storage         ???         Early concept, will be discussed separately
                            on the mailing-list
Sync virsh shutdown FC7     Easy to add in virsh


I expect to make a new libvirt release with the KEmu and KVM support as
well as a first version of the virtual network support next week. Then
the focus will be on remote support and adding migration to the API.


Other various issues raised:

- URL/drivers, making sure that the last proposal for URI used in remote
  connection are okay
- python bindings: disable automatic generation, handle manually, extend
- one Xen driver: currently implemented on top of 3 drivers, clean it up
- go though errors, cleaning up duplicates
- compile without Xen, once KEmu and KVM support gets added
- documentation cleanup: generation and CVS, checkout on libvirt.org
- export the config parser API at the shared library with __ prefix
  since that's used by the daemons but not 
- semantic of virConnect(NULL) is a bit fuzzy, Xen or default engine ?
- Need to plug libxml2 memory routines for memory debug

Of course the details will be discussed on the list, but at least
it gets a bit clearer where we expect to spend time, but as always
other features and feedback is more than welcome, it's needed, so
if there is any issue or comments on our viewpoint of the roadmap
and feature, please share them :-)

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/




More information about the libvir-list mailing list