FWN/Beats/Virtualization

Virtualization

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

Contributing Writer: Dale Bewley

Fedora Virtualization List

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

Guest Configuration with augeas and libguestfs

After blogging^[1] just last week that "Nothing much is coded at the moment", the prolific Richard Jones announced^[2] he has added support to augeas for his latest project, libguestfs^[3]. libguestfs "lets you examine and modify virtual machine disk images, so you can perform sysadmin tasks on virtual machines without needing to bring them up or log into them."

"Augeas is a configuration editing tool. It parses configuration files in their native formats and transforms them into a tree. Configuration changes are made by manipulating this tree and saving it back into native config files."^[4] Now libguestfs "supports Augeas, so you can use Augeas to edit configuration files within the virtual machine."

Richard will be working on creating a Fedora RPM of libguestfs this week.

Virtual Machine Backup virt-backup

The discussion of libguestfs led Jan ONDREJ to reveal^[1] a tool in development, virt-backup^[2].

This script can be used to

Make online backups, when virtual server is running.
Transfer partitions over the network while the virtual server is off.

Virtualization Technology Preview Repo

Daniel Berrange followed up the recent release scheduling conversation (FWN#169 ^[1]) with a "braindump"^[2].

"The obvious problem with what we do for libvirt at the moment, is that we are introducing major new features into the stable release stream". Adding "I think it would be desirable to get the stable Fedora releases onto a pretty strong bugfix only policy..."

Daniel suggested "a 'virt-preview' YUM repository for the most recent stable stream (ie F10, but not F9)" as a way to achieve this "bugfix only policy", and allow users access development versions of libvirt "without having to include & debug the rest of rawhide". Daniel summaried the "braindump".

"So in summary":

All new upstream releases built in rawhide
New upstream releases also built in stable preview branch if possible
Only bugfixes built in stable updates/updates-testing branch
In exceptional circumstances, rebase for preview branch can be built to updates/updates-testing after alot of positive testing

"This would":

Ensure users of stable Fedora release have high confidence in quality of the updates/updates-testing stream
Allow users to trivially test new upstream rebases while staying on the stable distro stream
Improve testing coverage of major new rawhide features without using the stable release stream users as guinea pigs

Mark McLoughlin thought^[3] "this would be hugely useful to people interested in the latest virt bits, but without a testing machine for running rawhide." And even proposed a name for the proposed repository, "How about 'virt-hide' ? :)". Mark also reverenced these FESCo approved guidelines^[4] relevant to package maintainers who wish to update a package on an already-released branch.

Fedora Virtualization Status Report

Mark McLoughlin reminds^[1] us "It's only a matter of days until the F11 tree freezes and the list of bugs isn't getting any shorter!"

Read on for more coverage of virtualization developments in the past week.

↑ http://www.redhat.com/archives/fedora-virt/2009-April/msg00055.html

Fedora Xen List

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

Experimental Dom0 Kernel Update

Michael Young I asked MY where he got his dom0 patches:

The patches were generated using git from the git repository 
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git combined with 
a mainline kernel git repository such as 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git
possibly with a bit of manual merging. So there isn't a single URL. I am 
not sure which is the best branch of the xen git to use at the moment, 
because the effort is focused on egtting the patches into the main kernel 
during the merge window.

If it helps Jeremy commented about the state of the xen repository in this 
email 
http://lists.xensource.com/archives/html/xen-devel/2009-04/msg00151.html
My most recent kernel was built using the push2/xen/dom0/master branch, 
though I think I might wait a week or so to see what gets merged before 
doing another update.

Libvirt List

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

libvirt-TCK Technology Compatibility Kit

In yet another "braindump" this week, Daniel Berrange penned^[1] "a very long email" purporting to be a "short guide" to the new libvirt "Technology Compatibility Kit".

libvirt provides a hypervisor or emulator neutral platform for manipulating virtual machine resources. This model leverages "drivers"^[2] for each emulator or backend system. The driver acts as a translator, converting libvirt API calls to the native API. For example, there are drivers for Xen, QEMU KVM, LXC, OpenVZ, User Mode Linux, and storage subsystems.

"The libvirt TCK provides a framework for performing testing of the integration between libvirt drivers, the underlying virt hypervisor technology, related operating system services and system configuration. The idea (and name) is motivated by the Java TCK"

"In particular the libvirt TCK is intended to address the following scenarios

Validate that a new libvirt driver is in compliance with the (possibly undocumented!) driver API semantics
Validate that an update to an existing driver does not change the API semantics in a non-compliant manner
Validate that a new hypervisor release is still providing compatability with the corresponding libvirt driver usage
Validate that an OS distro deployment consisting of a hypervisor and libvirt release is configured correctly

Thus the libvirt TCK will allow developers, administrators and users to determine the level of compatability of their platform, and evaluate whether it will meet their needs, and get awareness of any regressions that may have occurred since a previous test run."

The TCK will utilize Perl's testing frameworks and the libvirt Perl binding perl-Sys-Virt (FWN#169^[3]).

Daniel created "4 simple proof of concept scripts" which have already "highlighted some horrible problems" in remote, QEMU, and Xen drivers. There are even some results "in pretty HTML format":

Daniel goes on to describe how to try out the test suite, talk about what's still left todo, describe how TCK is expected to be used, and provide an introduction to writing tests.

Search

Contents