Contents |
[edit]
Development Roadmap
The following features are pieces that are currently on the radar for virt-manager development but aren't being targetted for a specific release (yet).
[edit]
Short Term
Short term features are pieces that will not require significant development work to implement and require little to no work outside of the virt userland tools
- Create guest from existing disk -- Import an existing disk image, just creating the neccessary config around it without starting the installer. May want to wait until storage management lands.
- XML output -- We would like to be able to write the libvirt guest config XML to a file, for export to other tools, backup, and so on.
- Crash-dump button -- Would like to have UI for crashing a guest and storing the crash dump somewhere. Support for this is already available in libvirt.
- Customize logging -- We would like to be able to set a log size for virt-manager logs and roll or truncate the logs. We would also like to be able to customize the logging level from the UI.
- Allow the user to tune dom0 configuration from virt-manager -- It would be useful to be able to change dom0's CPU and memory usage from virt-manager; we can already do this with virsh.
- Allow the user to assign vCPU/pCPU pin information -- Not at create time, but in the details section.
- Documentation Overhaul -- Help docs are quite out of date. Would also be nice to add tooltips in helpful locations.
[edit]
Medium Term
Medium term features are some combination of modest development work, user impact, and dependence on work in other projects (libvirt, xen, qemu, etc.)
- Handle storage management -- Storage management is available in libvirt since version 0.4.1 (March 08). virt-manager needs to take advantage of this, allowing the user to create different storage objects and use them for hardware addition or guest creation.
- Remote vm creation -- Requires remote storage management.
- Migration Support -- Migration is already supported in libvirt. Having drag and drop migration would be pretty slick.
- International keyboard support -- The console locale at the moment is us-english only. We will have slightly better locale support for virt-manager 0.4 based on upstream frame buffer work. There are fundamental problems with locales and the vnc protocol, however. Ultimately we need a way to make locale support transparent for all supported locales.
- Tool to clone a VM -- We would like to be able to export a VM config, change the UUID and the mac address(es), copy its persistent storage, and boot it up as a new VM. This already exists in with the virt-clone tool, it just needs a GUI.
- Export as image -- Export existing guests as a 'template image' suitable for distributing and using with 'virt-image' tool
- Rework Guest Creation Wizard -- The guest creation wizard is slowly accumulating lots of options. Factoring in remote storage management, adding multiple or no disk devices, converging install options for PV and FV guests, and building a guest from an existing guest, there is probably a cleaner way we can incorporate all this to make the wizard simpler.
- Add Disk and Network stat tracking -- There is support for this in libvirt, just not sure how exhaustive the coverage for this in with respect network and disk types.
- Allow custom key combos for console -- The current situation with adding key combinations to the virt-manager menu is non scalable. There should really be a way for users to add custom key combinations to their menu.
[edit]
Wishlist
This is an unprioritized grab bag of features with no immediate timetable that require varying levels of development. Feel free to add any ideas below:
- Persist changes to a running guest -- Inactive domain support lets us persist config changes to a non-running guest. However with the current virtualization implementation in Fedora, changes to a running guest do not persist after the guest is shut down. We need to determine how we can get the back end to update guest config when changes are made to a running guest.
- VCPU use percentage, pin/weight/cap status -- We can get this information from the hypervisor but we have not added the API to libvirt yet. Once the API is in libvirt, we can display the information in virt-manager.
- Scaling of the virtual console to fit the screen
- PXE boot for paravirtualized guests
- Cobbler Integration
- URLS and kickstarts for PV installs -- Now that we have the user choosing a guest OS type, we could use that choice to preload some sensible default tree and kickstart URLs into the install tree and kickstart pulldowns for paravirt guests. The default choices should go into gconf and be accessible via the preferences window.
- VM State Reporting -- We would like to get better defined state reporting for VMs. Right now we can see stopped, starting, running, paused, and shutting down; but support for things like "rebooting," "backing up," "restoring," "creation," "being cloned," "changing resources" would be helpful for larger scale management with libvirt. However, all of these states will require upstream changes followed by additional work in libvirt, so we have to wait for that to happen first.
- SPECTRE client -- We would like to add a SPECTRE client to virt-manager that would display system monitoring information collected by the SPECTRE monitoring agent on each guest. This information could also include guest audit history collected via other means.
- sysreport -- We would like to have a way to automatically generate something like a sysreq -t for a guest. We should involve support folks in defining exactly what this means.
- Web UI for non-Linux clients -- Remote clients or Windows clients may want a web-based UI mimicking virt-manager. Obviously this is a major undertaking, but since virt-manager depends only on libvirt it would not be impossible to duplicate it with a web-based UI.
- Group operations -- We would like to be able to select multiple guests at once for certain operations (startup and shutdown, for example). We could handle this by allowing users to highlight multiple guests in the manager window, or by putting a checkbox-and-action-button style interface in the manager window. The first choice is probably more consistent with the UI in the rest of the application.
- Dogtail tests -- We need a full set of UI tests now that the UI is somewhat stabilized. We can add any regression tests, UI or otherwise, to the RHTS framework that runs every time the project gets built.
- V2P -- We would like to be able to take a virtualized guest, copy its persistent storage to a block device somewhere, and then boot it as a host OS. This could be developed outside of virt-manager altogether.
- Sessionable from GDM/KDM/other Display Manager login -- When I'm at my linux distro's GDM login screen, from the "Options" menu, I can choose "Select Session" (choosing between Gnome, KDE, or XFCE). But what if I'm only interested in managing/connecting to a certain Virtual Machine (to save system resources, and/or simplify the user experience)? virt-manager should be a choice in the "Select Session" dialog of GDM. That is to say, virt-manager should behave, and be treated like a "Desktop Environment" (in its own right) as far as a given Display Manager is concerned. More rationale here.
- USB Hardware management ? Virsh already supports that
- Features Enable/Disable depending on underlying virtual technology
Views
Personal tools
Toolbox
