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 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list