Re: [Libvir] Next features and target for development
On Tue, Jul 10, 2007 at 05:12:38PM +0100, Richard W.M. Jones wrote:
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.?
I think we assume server <-> server & that the admin has the servers
in a particular cluster setup to be able to talk with each other.
(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?
The app can validate to some degree by looking at the capabilities
XML to see what's supported on both ends & what the guest is using.
So I'd let the app do high level validation with that, and just then
propagate errors from the underlying system - keeping poliucy out of
the libvirt API.
(3) Should the data be encrypted when it travels?
Implementation defined, so not something for libvirt to worry about. Its
a separate task to make XenD use SSL/TLS for communcating with other XenDs
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?
Upstream would like to kill the SEXPR api. So far we've prevented them
doing this. SEXPR is limited in so much as its all, or nothing & this
has horrific performance issues, because pulling out all the device info
hits xenstored alot - hence a single SEXPR request can take as much as
1 second to complete :-(
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|