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.

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.

libvirt/virt-manager guys are welcome to overrule that suggestion, as the previous suggestions are already great :)

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.

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(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list