[libvirt] A laundry list of "TODO" items for libvirt
A bunch of us at Red Hat had a bit of a brainstorming session to make a list of things we'd like to see added to libvirt going forward, to better support our needs for virtualization in Fedora / oVirt. We've put details of everything up on the libvirt wiki: http://wiki.libvirt.org/page/Todo This list isn't a firm commitment to actually implement these features. We may later decide that some of them don't belong in libvirt (eg, the question of allowing multiu-thread access to virConnectPtr is open to debate). Nor have we got people actually working on these items - unless explicitly noted against a todo item. If anyone is looking to do work on libvirt and isn't sure of what to work on, this list may be of interest. Also, this is a wiki, so feel free to add more ideas - or add expanded details to existing ideas. Or reply to this mail, and one of us will add new ideas to the wiki for you The only request is that you don't actually start implementing things from the list without first discussing proposals on this list, because most of these ideas need more design / analysis before its reasonable to write code Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Daniel P. Berrange wrote:
A bunch of us at Red Hat had a bit of a brainstorming session to make a list of things we'd like to see added to libvirt going forward, to better support our needs for virtualization in Fedora / oVirt. We've put details of everything up on the libvirt wiki:
http://wiki.libvirt.org/page/Todo
This list isn't a firm commitment to actually implement these features. We may later decide that some of them don't belong in libvirt (eg, the question of allowing multiu-thread access to virConnectPtr is open to debate). Nor have we got people actually working on these items - unless explicitly noted against a todo item. If anyone is looking to do work on libvirt and isn't sure of what to work on, this list may be of interest.
Also, this is a wiki, so feel free to add more ideas - or add expanded details to existing ideas. Or reply to this mail, and one of us will add new ideas to the wiki for you
Last month you had brought up the idea of a unified api call to lookup all domains, with a flag option to filter the lookup by domain state: https://www.redhat.com/archives/libvir-list/2008-July/msg00215.html This is something that would be nice to have for virt-manager and any management apps built on libvirt, since this will hopefully cut down on communication bandwidth if we are managing multiple remote connections + vms. I'll add that to the wiki later today. Thanks, Cole
On Thu, Aug 28, 2008 at 10:58:34AM -0400, Cole Robinson wrote:
Last month you had brought up the idea of a unified api call to lookup all domains, with a flag option to filter the lookup by domain state:
https://www.redhat.com/archives/libvir-list/2008-July/msg00215.html
It's worth making clear that the key issue isn't the filtering, but the fact that the virConnectListDomains & virDomainLookupByID calls would be combined. This is a big saving in the remote case too because it turns 1+N round-trips into 1 round-trip. Virt-manager and virt-top both make these 1+N calls frequently (as in, once a second, and once every 3 seconds respectively). Also, if we use the __virDrvSupportsFeature call then we can actually emulate it in src/libvirt.c for drivers / libvirtd instances which don't understand the new call. This means that applications can use the new call immediately, with confidence that it will work for all cases. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
On Thu, Aug 28, 2008 at 04:30:55PM +0100, Richard W.M. Jones wrote:
On Thu, Aug 28, 2008 at 10:58:34AM -0400, Cole Robinson wrote:
Last month you had brought up the idea of a unified api call to lookup all domains, with a flag option to filter the lookup by domain state:
https://www.redhat.com/archives/libvir-list/2008-July/msg00215.html
It's worth making clear that the key issue isn't the filtering, but the fact that the virConnectListDomains & virDomainLookupByID calls would be combined. This is a big saving in the remote case too because it turns 1+N round-trips into 1 round-trip.
Virt-manager and virt-top both make these 1+N calls frequently (as in, once a second, and once every 3 seconds respectively).
Yes, this is a huge performance win when talking to XenD since each XenD RPC call to list domains is ~ 0.5-1 second or worse.
Also, if we use the __virDrvSupportsFeature call then we can actually emulate it in src/libvirt.c for drivers / libvirtd instances which don't understand the new call. This means that applications can use the new call immediately, with confidence that it will work for all cases.
Good idea - that hadn't occurred to me - it'll be useful for talking to old libvirtd instances at the very least - implementing the new style for built-in drivers should be trivial already. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Does "host power support" belong on the TODO? (i.e. virConnect{Poweroff,Suspend,Hibernate,Reboot}) If libvirt is going to be the only external interface used to manage a virtualized host, it must be able to poweroff, suspend, (hibernate?), and reboot the host. (For hosts that support IPMI/iLO or other power control interfaces, this isn't necessary, but there are plenty of hosts that don't support any of this.) Dave On Thu, 2008-08-28 at 15:45 +0100, Daniel P. Berrange wrote:
A bunch of us at Red Hat had a bit of a brainstorming session to make a list of things we'd like to see added to libvirt going forward, to better support our needs for virtualization in Fedora / oVirt. We've put details of everything up on the libvirt wiki:
http://wiki.libvirt.org/page/Todo
This list isn't a firm commitment to actually implement these features. We may later decide that some of them don't belong in libvirt (eg, the question of allowing multiu-thread access to virConnectPtr is open to debate). Nor have we got people actually working on these items - unless explicitly noted against a todo item. If anyone is looking to do work on libvirt and isn't sure of what to work on, this list may be of interest.
Also, this is a wiki, so feel free to add more ideas - or add expanded details to existing ideas. Or reply to this mail, and one of us will add new ideas to the wiki for you
The only request is that you don't actually start implementing things from the list without first discussing proposals on this list, because most of these ideas need more design / analysis before its reasonable to write code
Regards, Daniel
On Thu, Aug 28, 2008 at 05:02:29PM -0400, David Lively wrote:
Does "host power support" belong on the TODO? (i.e. ??????virConnect{Poweroff,Suspend,Hibernate,Reboot})
???If libvirt is going to be the only external interface used to manage a virtualized host, it must be able to poweroff, suspend, (hibernate?), and reboot the host. (For hosts that support IPMI/iLO or other power control interfaces, this isn't necessary, but there are plenty of hosts that don't support any of this.)
This is an interesting question - I honestly can't say whether this should be within our scope or not. With things like poweroff, the application requesting the poweroff may well want some form of confirmation or guarentee. This takes you into the realm of fencing / clustering software which can provide these kind of capabilities. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Thu, 2008-08-28 at 22:08 +0100, Daniel P. Berrange wrote:
On Thu, Aug 28, 2008 at 05:02:29PM -0400, David Lively wrote:
Does "host power support" belong on the TODO? (i.e. ??????virConnect{Poweroff,Suspend,Hibernate,Reboot})
???If libvirt is going to be the only external interface used to manage a virtualized host, it must be able to poweroff, suspend, (hibernate?), and reboot the host. (For hosts that support IPMI/iLO or other power control interfaces, this isn't necessary, but there are plenty of hosts that don't support any of this.)
This is an interesting question - I honestly can't say whether this should be within our scope or not. With things like poweroff, the application requesting the poweroff may well want some form of confirmation or guarentee. This takes you into the realm of fencing / clustering software which can provide these kind of capabilities.
While some mgmt apps may choose to talk to another (fencing / clustering / IPMI / iLO) layer to get this functionality in a stronger form, the basic functionality is crucial enough that I think it must exist in libvirt (or otherwise mgmt apps must talk to yet another interface). We use this functionality (in our xen-based dom0) both for upgrading hosts, and for shutting them down to await Wake-On-LAN (to implement our "LivePower" support). VMWare also includes this capability in their ESX API, I'm told. Dave
Hi, Dan Which layer supports OVF(Open Virtual Appliance Format) handling? Thanks Atsushi SAKAI "Daniel P. Berrange" <berrange@redhat.com> wrote:
A bunch of us at Red Hat had a bit of a brainstorming session to make a list of things we'd like to see added to libvirt going forward, to better support our needs for virtualization in Fedora / oVirt. We've put details of everything up on the libvirt wiki:
On Fri, Aug 29, 2008 at 10:41:20AM +0900, Atsushi SAKAI wrote:
Hi, Dan
Which layer supports OVF(Open Virtual Appliance Format) handling?
OVF would be something for tools built using libvirt. Likely candidates for some level of OVF support would be virt-image/-convert and virt-manager Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (5)
-
Atsushi SAKAI -
Cole Robinson -
Daniel P. Berrange -
David Lively -
Richard W.M. Jones