From Fedora Project Wiki

< FWN‎ | Beats

Revision as of 02:41, 2 March 2009 by Dale (talk | contribs) (→‎Libvirt List: add VirtualBox Support, Run QEMU Guests Within a CGroup)


In this section, we cover discussion on the @et-mgmnt-tools-list, @fedora-xen-list, @libvirt-list and @ovirt-devel-list of Fedora virtualization technologies.

Contributing Writer: Dale Bewley

Enterprise Management Tools List

This section contains the discussion happening on the et-mgmt-tools list

virt-manager Redesigned 'New VM' Wizard

Cole Robinson with the help of Tim Allen and Jeremy Perry started[1] work on a resdesign of the Package-x-generic-16.pngvirt-manager guest creation wizard, because "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." See the post for full details on the long list of changes and screenshots[2].

Hot Add USB Device to Guest

Cole Robinson answered[1] a question about hot adding a USB device to a running guest. The steps are "Use 'lsusb' to determine the bus and device", use this to create an XML snippet[2], and then feed that snippet to 'virsh attach-device.

Fedora Virtualization List

This section contains the discussion happening on the fedora-virt list.

Fedora Virt Status Update

Mark McLoughlin posted[1] another weekly status update including details on numerous virtualization developments and bugs.

Improved Guest Mouse Pointer Movement

Daniel P. Berrange announced[1] an improvement to mouse pointer movement in Fedora 10 and 11 KVM guests.

"The default mouse for KVM guests is a PS/2 mouse. This causes pain for users because it only works with relative coordinates, which means we are forced to grab the mouse pointer in the VNC client.

KVM can emulate a USB graphics tablet which works in absolute coordinate mode, and thus gives flawless mouse motion tracking without needing any grab in the client." [2]

USB tablet will now be used by default Package-x-generic-16.pngpython-virtinst in F11.

Approved F11 Virtualization Features

Chris Lalancette relayed[1] the outcome of the FESCO meeting on February 27[2] as it relates to virtualization.

Features approved for inclusion in Fedora 11 at this time are:

Deferred to Fedora 12 was:

On the KVM and QEMU merge, Daniel P. Berrange explained[3] that "The QEMU upstream release will be so close to the feature freeze, that we don't want to risk causing KVM regressions by trying to then merge the two. Hopefully come F12, more of the KVM bits will be in QEMU mainline, so work we need todo to merge would be minimal."

Fedora Xen List

This section contains the discussion happening on the fedora-xen list.

dom0 Kernel Experimentation Continues

Michael Young made his work more accessible when he began[1] creating experimental dom0 kernel builds[2] within Koji. This latest kernel has gotten as far as booting in single user mode.

Libvirt List

This section contains the discussion happening on the libvir-list.

About Libvirt VirtIO and Xen

Patrick Archibal had a few questions[1] about virtualization and the relation of libvirt[2], VirtIO[3], KVM[4], and Xen[5]. Daniel P. Berrange took the time to provide a detailed response[6] to each of Patrick's questions. A selection follows.

  • What is the difference between libvirt and virtio?

"libvirt provides a API for the host OS, allowing management of virtual machines, storage, networking, host devices, etc.

virtio is basically providing paravirtualized device drivers between guest and host, and has several aspects

A generic infrastructure layer in guest kernel for writing device drivers that talk to the host
A generic host<->guest data transport running as a PCI device
A generic host<->guest data transport using a ring buffer
Guest implementations for paravirt network, disk & memory balloon drivers
QEMU host backends for network, disk & memory balloon drivers"
  • Why must hypervisor developers (Xen and KVM) develop drivers each time there are new devices?

"The virtio infrastructure is intended to provide generic drivers that can be used on any hypervisor. Currently supports KVM and LGuest. Xen has its own device drivers because they were developed years ago outside the context of the Linux kernel community just for Xen's needs."

  • Can we use VirtIO with Xen?

"VirtIO is currently only supported for KVM and LGuest. It could in theory be implemented for Xen too, but its not clear if it is worth the effort."

Encrypted VNC to Guests and TLS

Michael Kress wanted[1] to encrypt the session between a windows VNC client and a KVM guest. The thread was long with a lot of back and forth touching on windows clients, certificate setup, and Package-x-generic-16.pngstunnel.

Daniel P. Berrange pointed out libvirt's RemoteTLS[2] documentation and described[3] the Fedora 11 feature VirtVNCAuth[4] which dovetails with VeNCrypt[5] to "Define a mapping of SASL authentication into the VNC protocol, and implement it for QEMU and GTK-VNC, providing strongly authenticated, securely encrypted remote access of virtual guest consoles."

VirtualBox Support

Pritesh Kothari has been working[1] on adding Virtualbox[2] support to libvirt. Most of the functionality is complete, but Pritesh sought help with working out the domain XML format[3].

Run QEMU Guests Within a CGroup

Daniel P. Berrange posted[1] a proof of concept patch set with this explaination.

"Recent Linux kernels have a new concept of 'CGroups'[2] which is a way to group tasks on the system and apply policy to them as a whole. We already use this in the LXC container driver(FWN#146[3]), to control total memory usage of things runing within a container.

This patch series is a proof of concept to make use of CGroups in the QEMU driver. The idea is that we have a 3 level cgroup hierarchy

  • Top level; contains the libvirtd daemon itself
  • 2nd level: one per libvirt driver, but dos not contain any processes.
  • 3rd level: one per guest VM. Contains the QEMU process

The host admin can do control on the top level and 2nd level to set an overall system policy. libvirt will then provide APIs / capabilities to control individual VMs policy."