Daniel Veillard wrote:
Hi all,
now that 0.3.0 is out, it's probably time to build the next set of
features we aims at developping in the next months, the list I have
currently is short, but still significant:
- migration API: now that we have remote support it should be
possible to build an API for migration of domains between
2 connections. Could be as simple as
int virDomainMigrate(virDomainPtr domain, virConnectPtr to, int flags);
sounds like a fun and very useful part.
Some issues around migration which are up for discussion:
(1) Where does the data travel (ie. server -> server, server -> client
-> server)? If it goes server -> server, what about routing, firewalls,
etc.?
(2) Are the hosts compatible? (eg. microarchitecture, hypervisor, ...
other sources of incompatibility?) Should we care at the API level or
just report errors from the hypervisors?
(3) Should the data be encrypted when it travels?
Xen uses a particular port & protocol for migration. Is this protocol
one-way or two-way?
- USB support: we discussed that already, but the initial patch
did
not match the XML format suggestions we should try to resurrect this
http://libvirt.org/search.php?query=USB&scope=LISTS
http://www.redhat.com/archives/libvir-list/2007-March/thread.html#00118
- Support for Xen-API new entry points at least for localhost access
since we have remote support now
Is there stuff we can do with Xen-API which we can't do with the sexpr
API? Are upstream going to continue offering both APIs?
- platform support: resolve the PPC64 issues
- more engine support: OpenVZ is on the work, is there interest in
lguest, UML or for example Solaris zones ?
Or VirtualBox-OSE, which I've been playing around with today.
Other things to think about:
- Storage API.
Rich.
--
Emerging Technologies, Red Hat -
http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903