Improved Virt Console in Fedora 11

Date	Status report
Next action: Get answers to print questions, and set up for podcast.

Return to Category:F11 in-depth features page

Interviews

Print interview

1. Please introduce yourself and what you do and how you got started working on virtualization stuff.

I'm one of the lead developers for the libvirt project and am actively involved in many related areas of open source development (qemu/kvm, xen, gtk-vnc, virt-manager, to name but a few). I also co-maintain many of these packages in Fedora and RHEL, along with many others in Red Hat's virtualization team.

More than three years ago (shortly after transferring into Red Hat's Engineering team, from consulting services) I was working on the OLPC project. We needed a way to easily test the OS images we were building without needing real hardware. As a proof of concept, I hacked up a simple GTK application to run images them under QEMU. At around the same time Daniel Veillard had started the libvirt project and there was a desire for a desktop application to manage Xen using libvirt. So I switched over to the virtualization team, wrote virt-manager for Fedora 6, and my involvement in all areas of open source virtualization grew from there.

2. Many people view the work being done on virtualization as a feature set of major importance and significance. Can you give us a brief overview of some of the changes that we can expect to see in F11? (you can be as general as possible, I'll ask some more in depth question about certain things below, also could talk briefly about the virtual console improvements here?)

The open source virtualization development effort is so large now, that it is useful to discuss each stream in turn.

At the lowest layer is obviously the Linux kernel & KVM/QEMU. There has been a major acceleration of development in QEMU and push to merge KVM into the official QEMU source repository. There's ever continuing work on performance, stability, scalability & reliability in KVM. PCI device passthrough is one new feature we're highlighting for Fedora 11. The return of Xen Dom0 was not to be, as the Dom0 paravirt_ops merge with the upstream Linux kernel is still an ongoing process.

At the middle layer is libvirt, providing a consistent management API across different virtualization technologies. New features in libvirt, since F10, include PCI device passthrough for Xen and KVM, the sVirt security driver using SELinux to protect KVM guests from each other, thread safety of all libvirt APIs, improved scalability, reliability and debugging for the libvirtd daemon and support for SCSI HBAs and copy-on-write volumes in the storage management APIs.

The top layer covers end user tools such as virt-install & virt-manager. virt-manager is undergoing a significant (and ongoing) overhaul of its user interface. The first improvements arriving for Fedora 11 are in the guest installation process and storage management capabilities. As guest installation is first task most users try, ensuring this is simple and reliable is key to making a good first impression. Guest desktop interaction is another historical pain point which has been a focus for improvements in Fedora 11.

With every release we also try to make a significant step forward in security of the virtualization stack. In Fedora 11 the focus has been on SELinux to protect guests from each other and SASL to authenticate VNC users.

3. There have been some large changes in virt-manager and libvirt, which are at the core of the user experience when it comes to virtualization. Can you talk to use about those some more?

The guest installation process and desktop interaction are the most critical areas for making a good first impression. In the virt-manager re-design the wizard used for installing new guests has been streamlined, cutting out three redundant steps. Where possible, it will automatically detect the type of operating system being installed and choose the best configuration options to optimize for this OS, no longer requiring the user to figure this out for themselves. The installation process now directly utilizes the libvirt storage management APIs to allow easy creation of files in a variety of formats (raw, qcow2, vmdk, etc), allocation of new local disk partitions or LVM volumes and access to LUNs exported by iSCSI targets. This is particularly useful when remotely managing virtualization hosts, allowing regular administrator tasks to be performed from the virt-manager UI without resorting to command line SSH sessions.

The mouse pointer has been a constant source of trouble for virtualization management applications. Getting the guest mouse pointer to track the host pointer is essentially impossible with the standard emulated PS/2 mouse. The solution is to provide a pointer device that supports absolute motion events, instead of relative events that the PS/2 mouse provides. For KVM and Xen, this means adding a USB tablet device, but historically Xorg has not been able to automatically configure this correctly. This is resolved with Fedora 11 guests, finally providing a guest pointer that moves in perfect sync with the host, not requiring the pointer to be confined to the guest window.

Users with non-US layout keyboards have also had a hard time getting their guests to support input of accented/special characters. The VNC protocol has now been extended to allow the hardware keycodes to be passed directly from the VNC client to the guest OS without any intermediate translation step. This should allow the guest OS complete control over the keyboard layout mapping, without a need for any special settings on the host.

The final piece of work was to increase the guest desktop resolution. The real Cirrus video card that QEMU emulates would never have done more than 800x600, but there are tricks that can be done in a virtual world. Thus a simple change to the Xorg cirrus driver allows it to detect that it is using a Cirrus card emulated by QEMU and increase the guest desktop resolution to 1024x768. Still not great by today's standards, but better than before. Longer term plans involve replacing the cirrus driver in QEMU with something more virtualization friendly.

4. Also, as people should take note of, there has been a lot of work done surrounding KVM and getting that well integrated into the whole virtualization setup in Fedora. How has that work been going and has anything significant been done in that area in this release.

Fedora was the first major Linux distribution to integrate KVM back in the Fedora 7 release. It became the default virtualization technology in Fedora 9, when it became clear we could no longer maintain the separate Xen host kernel until it was merged in the upstream Linux kernel. The great benefit of KVM from an distro integration point of view, is that it is there by default in all new Linux kernels. All that was required in Fedora was to turn on the module build and make sure the modules are always loaded when compatible CPUs are found. libvirt and virt-manager have also both supported KVM since it was first added to Fedora. Thus there hasn't been a need for much additional integration work for KVM. The focus has simply been on improving features available to KVM users via libvirt and virt-manager.

5. Glauber Costa has also done significant work merging KVM and QEMU. Can you explain to us what QEMU is and why the choice was made to merge it with QEMU and how that is of benefit to the user base?

Earlier Fedora releases have have suffered from the divergance of QEMU and KVM codebases. Upstream QEMU has had releases almost 1 year apart, while KVM has been releasing at least once a month, if not more, using snapshots of the QEMU source repository. Thus the features available in QEMU were far behind those available in KVM even though they both shared the same fundamental codebase and upstream development stream. It also doubled the work package maintainers had todo for security & bug fixes.

Since Fedora 10 though, the upstream QEMU community has accelerated its release schedule significantly and many of the KVM features have been merged back into the main QEMU codebase. Thus we judged that the time was right to attempt to ship a single package containing both QEMU and KVM built from a single codebase. For users this means that parity of features between QEMU and KVM, while the reduced burden on our Fedora package maintainers, ensures more timely security and bug fixes. Glauber also took the opportunity to split out all the virtual BIOS files and ROMs from QEMU into separate packages and ensure all are fully built from source using appropriate upstream source releases.

6. Virtualization and Security are two things that are being discussed more or less hand in hand these days, as the ability to create and use virtualized machines expands there are many security risks involved. Can you speak a bit to the work that was done one improving security both at the kernel level (sVirt) and also the user level with things like SASL for VNC Auth?

In each Fedora release we try to make at least one significant step forward in the security of our virtualization technology. In Fedora 8, libvirt gained support for secure remote management using TLS for encryption and x509 client certificates for authentication, while GTK-VNC, QEMU, KVM and Xen were also all extended to add a VNC extension for TLS encryption providing a secure remote desktop. In Fedora 9 libvirt was further extended to support SASL enabling secure remote managment with Kerberos for authentication and PolicyKit for local desktop authentication. Fedora 9 and 10 also increased use of SELinux to protect the host operating system from a compromised or malicious QEMU/KVM process.

The latter still did not provide any protection between guests, so one compromised QEMU process would still potentially be able to compromise another on the same host. Thus James Morris started work on a project known as sVirt, the first results of which are appearing in Fedora 11. The focus has been to provide isolation between guests running on a single host. libvirt directly integrates with SELinux to ensure every QEMU process it launches runs within a dedicated security context, only able to access its own assigned disk images. This protection is enabled by default on all Fedora 11 hosts using libvirt for management. As well as the security benefits, the end user experiance is improved because libvirt will automatically manage SELinux labelling for all guest disks, eliminating a major source of bug reports from previous Fedora releases.

7. These features have all sort of evolved over time and over the previous Fedora releases and Fedora, as a distribution, has always been a leader in the virtualization realm. Can you talk a bit now about the actual process of developing these features and how many of the improvements and enhancements to virtualization have come about as a direct result of the work done previously? Also, what does the future look like.

Virtualization technology in Fedora is reaping the benefit of very active upstream projects and the significant developer resources of Red Hat's Virtualization Engineering team. The combination of these provide great opportunities for new features to have their debut in Fedora releases.

The ideas for new features come from many sources, some from Fedora end-user experiances & consequent bug reports, some magically arrive on cue from upstream projects, while others are things that look to be important for future RHEL releases. With the PCI device passthrough feature in F11, the core support was all already done by the upstream KVM community. This is a important feature for future RHEL, so Red Hat put resources into a F11 feature to add support to libvirt for PCI passthrough with KVM and Xen and then expose this in virt-manager.

The feature aiming to improve the guest desktop interaction was a result of the persistent stream of bug reports from Fedora users. We had been considering ways to address this over course of several Fedora releases, but it was not until Fedora 11 that all the pieces of the solution finally came together from the various upstream projects.

The security improvements in virtualization have a different origin. Very few end users ever file explicit bug reports asking for the addition of more authentication / encryption features or to use more SELinux. If anything users ask for ability to more easily turn off existing security features. This is a case where the user is not always right. They do want more security, but they just don't know it yet! As a developer it is neccessary to be very proactive with security improvements. This can be particularly challenging work because the solutions often involve working across multiple upstream communities.

Take the VNC SASL authentication feature in Fedora 11 as an example. The first step was to write a specification for a new VNC security extension, have it reviewed & get a code for it allocated by RealVNC. Work on QEMU was required to implement the server side. Work on GTK-VNC was needed for client side. For management tools, work on libvirt was required to get the new security type enabled for guests it launches and finally virt-manager was extended such that it knows how to login. That's give different projects involved for one feature. This is only practical by having a close working relationship with all the upstream communities and carefully coordinating the work there so it all arrives in time for the next Fedora release.

For the future we're happy that libvirt gained support for managing VirtualBox recently and likely to soon have a driver for the Open Nebular cloud management project. Expect more advancements in sVirt, allowing for tighter controls on what a virtual machine can do, for example, ability to restrict network access of guests. libvirt will also gain the ability to manage host network configuration in Fedora 12, removing the need to manually configure bridge devices. Container based virt may make a more formal appearance in Fedora 12 as the native Linux container (LXC) support improves in the kernel and libvirt. The overhaul of the virt-manager user interface also continues.

8. Working on Virtualization must be awfully time consuming and very involved. Do you enjoy it? What do you do to get away from the pressures of hacking?

Working on open source virtualization technology is a great experiance because it is a really interesting & challenging field, having plenty of talented developers to work with & learn from. There is plenty of work still to be done at all levels of the stack from kernel/hypervisor right through to end user applications & not nearly enough time todo it all. I'm fortunate to be able to spread my work between upstream projects, the Fedora community and RHEL releases and maintainence. As for free time ? What free time  :-) I try to find time for a photography, with 4 out of my 5 cameras still using film, rather than digital.