[Libvir] feature sujestions
Hello, I'm a grad student from Brazil. I was looking for some interesting project to do as my final work and it I think that contributing to your project would be a great achievement to me. Do you have some kind list with feature suggestions? I am particularly interested in remote administration. I helped a colleague to write a graphical tool to administrate a remote Xen site last year. Thank you. MB -- Computers are useless; they can only give you answers! -- Picasso
Márcio Parise Boufleur wrote:
Hello, I'm a grad student from Brazil. I was looking for some interesting project to do as my final work and it I think that contributing to your project would be a great achievement to me. Do you have some kind list with feature suggestions? I am particularly interested in remote administration. I helped a colleague to write a graphical tool to administrate a remote Xen site last year.
Hello Marcio, We have remote administration working for the command line tools (like virsh), but virt-manager still has a few problems, so any help you can give there would be welcome. Some other features off the top of my head: - Fleshing out all the QEMU & KVM features, so that QEMU & KVM support is as good as Xen support. See all the 'x' squares on this page: http://libvirt.org/hvsupport.html - Help with really getting virt-manager to work remotely. Allow drag-and-drop in virt-manager to migrate domains between hypervisors. - Help porting and packaging for other systems (Debian, Gentoo, *BSD, Solaris, Windows, ... -- some of these have porting projects already, so your time is best spent joining and working with existing projects) - More static analysis of code paths, particularly memory allocation/deallocation and error handling, where in both cases there are lots of little-used paths with problems (http://et.redhat.com/~rjones/cil-analysis-of-libvirt/) - Help Shuveb Hussain with OpenVZ work - VMWare - I don't know how good the Portuguese translation of the libvirt / virt-manager strings is -- maybe it could do with checking. 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
Richard W.M. Jones wrote:
Márcio Parise Boufleur wrote:
Hello, I'm a grad student from Brazil. I was looking for some interesting project to do as my final work and it I think that contributing to your project would be a great achievement to me. Do you have some kind list with feature suggestions? I am particularly interested in remote administration. I helped a colleague to write a graphical tool to administrate a remote Xen site last year.
Hello Marcio,
We have remote administration working for the command line tools (like virsh), but virt-manager still has a few problems, so any help you can give there would be welcome.
Some other features off the top of my head:
- Fleshing out all the QEMU & KVM features, so that QEMU & KVM support is as good as Xen support. See all the 'x' squares on this page: http://libvirt.org/hvsupport.html
- Help with really getting virt-manager to work remotely. Allow drag-and-drop in virt-manager to migrate domains between hypervisors.
- Help porting and packaging for other systems (Debian, Gentoo, *BSD, Solaris, Windows, ... -- some of these have porting projects already, so your time is best spent joining and working with existing projects)
- More static analysis of code paths, particularly memory allocation/deallocation and error handling, where in both cases there are lots of little-used paths with problems (http://et.redhat.com/~rjones/cil-analysis-of-libvirt/)
- Help Shuveb Hussain with OpenVZ work
- VMWare
- I don't know how good the Portuguese translation of the libvirt / virt-manager strings is -- maybe it could do with checking.
Rich.
------------------------------------------------------------------------
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Throwing one more thing out there, that's tangentially related, since you said you were interested in UI things: Some distributed stuff to complement the remote features above: Cobbler (http://cobbler.et.redhat.com) integration with virt-manager for being able to graphically pick what profile the user wants to install from a list of remote boot servers. (There's an XMLRPC API for this), and also ways to configure the boot server from a simple GTK app (not part of virt-manager). This could be of use where people want to roll out configurations that someone else has set up for them, but they are not comfortable with the command line tools. Perhaps it would be possible to export a set of virt-manager settings to Cobbler for reuse by virt-manager users on other machines. libvirt/virt-manager guys are welcome to overrule that suggestion, as the previous suggestions are already great :) --Michael
On Thu, Aug 23, 2007 at 12:41:22PM -0400, Michael DeHaan wrote:
Richard W.M. Jones wrote: Some distributed stuff to complement the remote features above: Cobbler (http://cobbler.et.redhat.com) integration with virt-manager for being able to graphically pick what profile the user wants to install from a list of remote boot servers. (There's an XMLRPC API for this), and also ways to configure the boot server from a simple GTK app (not part of virt-manager). This could be of use where people want to roll out configurations that someone else has set up for them, but they are not comfortable with the command line tools. Perhaps it would be possible to export a set of virt-manager settings to Cobbler for reuse by virt-manager users on other machines.
I agree we need something along those lines, and IMHO if they are more comfortable using point and click, I guess they would also prefer have automatic discovery of where cobbler was installed. Do we have (or could add) avahi support for discovery of the service. If most install options could be centralized (think like an automatic setup template based for example on the user LDAP info), provisioning for a new user could come as simple an UI as: "A centralized setting si available, pick one of the OSes" "Fedora 7" "Fedora 6" "Centos 5" ... maybe even the processor count and memory size could be defaulted from the centalized profiles. Yes you can do this already from the CLI, but being able to make it trivial and integrated in the virtmanager GUI, would probably make a big difference in usability.
libvirt/virt-manager guys are welcome to overrule that suggestion, as the previous suggestions are already great :)
Nah, but one thing is sure, there is plenty of things interesting to work on :-) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
On Thu, Aug 23, 2007 at 12:41:22PM -0400, Michael DeHaan wrote:
Richard W.M. Jones wrote: Some distributed stuff to complement the remote features above: Cobbler (http://cobbler.et.redhat.com) integration with virt-manager for being able to graphically pick what profile the user wants to install from a list of remote boot servers. (There's an XMLRPC API for this), and also ways to configure the boot server from a simple GTK app (not part of virt-manager). This could be of use where people want to roll out configurations that someone else has set up for them, but they are not comfortable with the command line tools. Perhaps it would be possible to export a set of virt-manager settings to Cobbler for reuse by virt-manager users on other machines.
I agree we need something along those lines, and IMHO if they are more comfortable using point and click, I guess they would also prefer have automatic discovery of where cobbler was installed. Do we have (or could add) avahi support for discovery of the service.
Added a few days ago upstream, yes (0.6.1 candidate). You have to install avahi-tools, it's not a hard RPM requires, but if it's there, cobbler will publish as "cobblerd".
If most install options could be centralized (think like an automatic setup template based for example on the user LDAP info), provisioning for a new user could come as simple an UI as: "A centralized setting si available, pick one of the OSes" "Fedora 7" "Fedora 6" "Centos 5" ...
Right now Cobbler is all hierarchial (distros -> profiles -> systems) and there's a XMLRPC API. So you could have a drop down "pick your distro" and then be able to pick your profile under the distro. You could optionally be able to pick a system definition (which includes a MAC address) to deploy but it would fine to leave that out if it didn't make sense.
maybe even the processor count and memory size could be defaulted from the centalized profiles. Yes you can do this already from the CLI, but being able to make it trivial and integrated in the virtmanager GUI, would probably make a big difference in usability.
Yep, I like this. A good way to fine defaults for each distro would be to see if there is a default profile named after the distro, which is what "cobbler import" creates today if you feed it a DVD or rsync mirror. Or they could optionally pick another profile, and have the option of refining choices either way.
libvirt/virt-manager guys are welcome to overrule that suggestion, as the previous suggestions are already great :)
Nah, but one thing is sure, there is plenty of things interesting to work on :-)
Daniel
On Fri, Aug 24, 2007 at 02:41:57PM -0400, Michael DeHaan wrote:
Daniel Veillard wrote:
On Thu, Aug 23, 2007 at 12:41:22PM -0400, Michael DeHaan wrote:
Richard W.M. Jones wrote: Some distributed stuff to complement the remote features above: Cobbler (http://cobbler.et.redhat.com) integration with virt-manager for being able to graphically pick what profile the user wants to install from a list of remote boot servers. (There's an XMLRPC API for this), and also ways to configure the boot server from a simple GTK app (not part of virt-manager). This could be of use where people want to roll out configurations that someone else has set up for them, but they are not comfortable with the command line tools. Perhaps it would be possible to export a set of virt-manager settings to Cobbler for reuse by virt-manager users on other machines.
I agree we need something along those lines, and IMHO if they are more comfortable using point and click, I guess they would also prefer have automatic discovery of where cobbler was installed. Do we have (or could add) avahi support for discovery of the service.
Added a few days ago upstream, yes (0.6.1 candidate). You have to install avahi-tools, it's not a hard RPM requires, but if it's there, cobbler will publish as "cobblerd".
Excellent, the discovery problem is the usual bootstrap one which really confuses the users !
If most install options could be centralized (think like an automatic setup template based for example on the user LDAP info), provisioning for a new user could come as simple an UI as: "A centralized setting si available, pick one of the OSes" "Fedora 7" "Fedora 6" "Centos 5" ...
Right now Cobbler is all hierarchial (distros -> profiles -> systems) and there's a XMLRPC API. So you could have a drop down "pick your distro" and then be able to pick your profile under the distro. You could optionally be able to pick a system definition (which includes a MAC address) to deploy but it would fine to leave that out if it didn't make sense.
okay
maybe even the processor count and memory size could be defaulted from the centalized profiles. Yes you can do this already from the CLI, but being able to make it trivial and integrated in the virtmanager GUI, would probably make a big difference in usability.
Yep, I like this.
A good way to fine defaults for each distro would be to see if there is a default profile named after the distro, which is what "cobbler import" creates today if you feed it a DVD or rsync mirror. Or they could optionally pick another profile, and have the option of refining choices either way.
Sounds good, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Thu, 2007-08-23 at 13:17 -0400, Daniel Veillard wrote:
I agree we need something along those lines, and IMHO if they are more comfortable using point and click, I guess they would also prefer have automatic discovery of where cobbler was installed. Do we have (or could add) avahi support for discovery of the service. If most install options could be centralized (think like an automatic setup template based for example on the user LDAP info), provisioning for a new user could come as simple an UI as: "A centralized setting si available, pick one of the OSes" "Fedora 7" "Fedora 6" "Centos 5" ... maybe even the processor count and memory size could be defaulted from the centalized profiles.
Along the same lines: enhance virt-manager to support deploying virtual machine images based on virt-image and its XML image format. There are lots of possible ways in which this could go, for example: * Focus on UI, build VM's based on images stored locally/in a fixed directory * Build above out to download images from a central server (or any webserver, which would aid in distribution of images) * Freeze an existing/running VM into an image * p2v migration that takes a physical installation and produces a VM image (even something simple that just scrapes bits off disk and packages them w/o worrying too much about device complications would be really valuable) * Tracking of image/machine association (think template images for a development group that they can 'check out' and use) David
Thank you for your sujestions. In the coming months, I will be working in integrating Cobbler with virt-manager. I will be posting my progress here as soon as I can. Thanks again for your support. MB On 8/24/07, David Lutterkort <dlutter@redhat.com> wrote:
On Thu, 2007-08-23 at 13:17 -0400, Daniel Veillard wrote:
I agree we need something along those lines, and IMHO if they are more comfortable using point and click, I guess they would also prefer have automatic discovery of where cobbler was installed. Do we have (or could add) avahi support for discovery of the service. If most install options could be centralized (think like an automatic setup template based for example on the user LDAP info), provisioning for a new user could come as simple an UI as: "A centralized setting si available, pick one of the OSes" "Fedora 7" "Fedora 6" "Centos 5" ... maybe even the processor count and memory size could be defaulted from the centalized profiles.
Along the same lines: enhance virt-manager to support deploying virtual machine images based on virt-image and its XML image format. There are lots of possible ways in which this could go, for example:
* Focus on UI, build VM's based on images stored locally/in a fixed directory * Build above out to download images from a central server (or any webserver, which would aid in distribution of images) * Freeze an existing/running VM into an image * p2v migration that takes a physical installation and produces a VM image (even something simple that just scrapes bits off disk and packages them w/o worrying too much about device complications would be really valuable) * Tracking of image/machine association (think template images for a development group that they can 'check out' and use)
David
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- Computers are useless; they can only give you answers! -- Picasso
participants (5)
-
Daniel Veillard -
David Lutterkort -
Michael DeHaan -
Márcio Parise Boufleur -
Richard W.M. Jones