Friday, February 27, 2009

virt-manager in Fedora 11: 'New VM' wizard redesign

There are some pretty big changes queued up for virt-manager in Fedora 11: foremost among them is a completely redesigned 'New Virtual Machine' wizard.

The current wizard has clearly started to show its age. The original design was largely based on xen specific assumptions and the state of libvirt/virtinst at the time: many of those assumptions don't apply today, or require a bit more thought since we now support both xen and qemu based VMs.

So, some screenshots!

Page 1: VM Name and Install method

We scrapped the 'intro' page: I don't think anyone will miss it. Having the 'name' box occupy an entire page by itself was also a bit overkill, so we did away with that as well.

One of the biggest changes we've made from the old design is that we no longer ask upfront about paravirt vs. fullvirt, VM architecture, or qemu vs. kvm vs. xenner. For new users, this has been an endless pain point ("Why can't I install a PV kvm guest?" among others) and is really a distinction we don't need to force on people: we are certainly in a position to choose sensible defaults (and for kvm, paravirt/virtio has always been setup in the background depending on what OS version is being installed). The logic for the defaults are now as follows:
  • For the qemu libvirt driver, use the first available of the following: kvm, plain qemu, xenner.
  • For the xen libvirt driver, use paravirt if the user selects a URL install and the tree supports it, otherwise use fullvirt.
  • Always default to the host architecture for new VMs.
We allow the user to deviate from these defaults in the final screen under the 'Advanced Options' section.

Also, you'll notice there is a generic 'Computer' icon in the wizard header: this will soon be replaced by a custom icon.

The one new piece here is the option to choose the libvirt connection to install on. Rather than have the 'New' button on the main manager window be conditionally sensitive, the user can now always launch the wizard, choosing the connection from there.

Page 2: Install media info


URL Install

This hasn't deviated much from the current options: the one difference is that the OS Type/Variant choice has been moved to these screens. This will allow us in the future to offer automatic distro detection based on the selected install media (we may have this for URL installs by the time the release goes out).

Since PXE installs require no extra input, the screen will only have the OS Type/Variant option listed.

Page 3: CPU + Mem details

We dropped the max memory vs. default memory split that is in the existing wizard: it doesn't have much meaning the qemu/kvm world, and even for xen it isn't something that needs to be asked up front. The user can always change it later.

Also, rather than list tons of warning information about overcommitting vcpus, we simply cap the amount at the number available on the host. If for some reason a user wants to allocate more than the host amount of virtual cpus to a VM (say for development purposes) it can easily be done post-install.

Page 4: Storage

The main change here is that we removed the block device vs. file device dichotomy: we are pretty capable of making this distinction behind the scenes.

The option is also now available to skip adding storage altogether: this is useful in the case of Live CDs or diskless PXE booting.

When adding storage, the two options are now:

1 - "Create a disk image on the computer's hard drive": We set up a libvirt storage pool behind the scenes to point to the default location (if using PolicyKit or running as root, this is /var/lib/libvirt/images) and allocate a disk image based on the requested size.

In the future, the default location will be configurable with a global preference.

2 - "Use managed or other existing storage" : This allows pointing to an existing path, or provisioning more complex storage on demand (this is dependent on a libvirt storage API aware browser dialog, which is ongoing work. For the time being, this just launches a local GTK file browser).

The one piece not shown here is the option to choose sparse Vs. non-sparse. We will be putting this back in before the final version is done.

Page 5: Summary and Advanced Options

The summary section is pretty straight forward, no surprises here. The 'Advanced Options' section encompasses networking, hypervisor, and architecture options. The hypervisor and arch defaults were explained above.

For networking, the default is:
  • A bridge device if any exist, else
  • Virtual Network 'default' (comes with libvirt), else
  • First available virtual network, else
  • No networking!
This logic will be globally configurable at some point, e.g. if you wanted to use a specific bridge device or virtual network for all new VMs. We also decided to put all the available networking options into 1 drop down, rather than have 2 separate sections for bridges vs. virtual networking.

I think that covers all the significant bits, hopefully other than that the screenshots speak for themselves. I hope you'll agree it's a much simpler and usable layout. This design was largely done by Tim Allen (former Red Hatter) and Jeremy Perry (current Red Hatter), so a big thank you to them.

Any feedback is appreciated: none of this set in stone.



  1. hi, looks really good except that i still miss virt-manager supporting routed networking.

    ps, commenting does not work properly in your blog which is weird.

  2. Revamping the 'Add Virtual Network' wizard is coming at some point, which will give the option to create a routed network.

    Also, comments fixed now (was some broken custom changes I made). Thanks for the heads up.

  3. FYI, in Fedora 11, KVM will now support the memory balloon VirtIO device. I've done some work to hook this up in libvirt, so the memory vs max-memory limits will soon work for both Xen and KVM. You are correct though, that this isn't soo important for the initial install - just allocate the amount of RAM actually needed for install & its easy to increase the maxmem post-install if desired.

  4. it would be nice to show at the fifth step, in the summary section, an indication of where the xml file reflecting the configuration will be saved ... to let the people know where to search (in case they want) for further details and manual changes

  5. The screens look great. I can't think of any OS specific options that might be needed here. I'm wondering if providing more information about possible disk space allocations for the new VM makes sense. For example if the user wants to create an F11 virtual machine, that needs a minimum total amount of disk space, and the minimum could be mentioned in some way. Overall your redesigned screens look great to me.

  6. One thing I never really understood is how choosing OS Type and Version affects the the VM configuration. Are those really needed?

  7. Different operating systems expect different hardware devices at installation time. Some of these can have very complex requirements. I don't understand or appreciate all the differences myself but VMWare, for example, has prebuilt virtual machine choices for all the common operating systems.

  8. Giulivo:

    Where the XML file is stored should really never be relevant to a libvirt user. This seems to be a really common misconception.

    Libvirt provides a mechanism to edit and apply changes to a VM configuration: via virsh, these are the 'edit' and 'define' commands ('edit' is really a wrapper around 'dumpxml' and 'define')

    Editting a VM config in place where libvirt stores them (/etc/libvirt/...) has a large potential for problems: any syntax errors and libvirt won't be able to warn you of them, things will suddenly just start going wrong, and the VM won't show up if libvirtd is restarted.

  9. Bob (re disk space):

    I think that's a good idea, I know Parallels and VMWare Workstation provide similar recommendations. It would just require a concerted effort to round up all that information.

    One of the things that we plan to address going forward is having more fine grained and info rich OS Type / Variant data, which is where disk size / ram recommendations would live.

  10. Gianluca:

    OS Type / Variant tells virt-manager a lot of info: whether we can enable virtio on KVM (yields much better performance), pointer devices (windows and Fedora 11 support a tablet mouse out of the box, which tracks 1-for-1 in the vnc window), and some lower level stuff like clock type, default ACPI and APIC settings, etc.

    Going forward, it will only be used to associate more info, so I'd recommend making use of it as much as possible.

    We are also looking into doing distro auto-detection of the install media (currently working for most Red Hat based distros if installing off a URL), so this should be automatic in the future.

  11. In step 3, while I think it makes sense to allow the cpus to max out to what is physically available, as you state in the text below the screenshot, there are times that you want more because the VM is to be deployed elsewhere. Why don't you include verbage to reflect that - for it will reduce any questions.

    Are there plans to provide a hover-over-help-bubble for some of the options?