[Libvir] Next features and target for development

[Daniel P. Berrange]

On Tue, Jul 10, 2007 at 11:49:18AM -0400, 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.

Yep, that's something interesting to look at.

>   - 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

I took at look at this a few weeks back, but before I got anywhere near
doing the libvirt coding, I blocked on the fact that USB in QEMU is
horribly unreliable. The revised XML format I suggested

http://www.redhat.com/archives/libvir-list/2007-March/msg00205.html

is more or less OK. But we will need to add some more attributes to mak it
possible to do hot-plug add/remove. I got stuck trying to figure this out
and not had time to re-visit yet. 

>   - Support for Xen-API new entry points at least for localhost access
>     since we have remote support now

Yeah, talking Xen-API over the UNIX domain socket should be something
worth looking at. In theory it could be faster than the SEXPR based
protocol since we'd only be asking for data we actuarlly need. In practice
I'm not at all certain whether it will be faster - since I fear we may 
need far more round-trip requests. So this all needs a proof of concept
done - implementing the listDomainIDs, getDomainInfo and a DumpXML 
method would be the 3 APIs I'd start with. With those we'd get a good
idea of the complexity / performance.

>   - 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 ?

VirtualBox, VMWare, too....

> Now is a good time to suggest new potential directions, and I certainly forgot
> some obvious points, so what did I missed ?

 - Mandatory access control for APIs - use SELinux engine to enforce the
   acls, in similar way to DBus. NB,  using SELinux in an application is
   totally independnant on whether you have SELinux enabled for the kernel
   or not. 

 - Storage APIs - previously discussed for allocating/enumerating
   volumes on a host.

 - Device listing - enumeration of devices on a host - virt-manager wants
   to know about host ethernet devices (and whether they're bridged) so
   it can display options when creating guests, and host USB devices (so
   we can hot-plug a host USB device straight into the guest OS), and host
   disks / partitions so we can hand them off to a guest  (unclear whether
   this should be part of a storage API or not - TBD)

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  -=|