[fedora-virt] Fedora virtualization status
markmc at redhat.com
Thu Apr 9 17:58:28 UTC 2009
2009-04-14 Final freeze
It's only a matter of days until the F11 tree freezes and we the list
of bugs isn't getting any shorter!
Now is a good time for people to jump in and help out :-)
Dale Bewley continues to churn out useful virtualization sections for
Fedora Weekly News. This weeks edition is here:
Dan Berrange posted an excellent write up on the soul searching some
of us have been doing around our update process for Fedora packages:
The upshot of this is:
1) We will continue to immediately push the latest upstream releases
2) We will create a "virt preview" yum repository which will contain
the latest rawhide packages rebuilt for the current Fedora stable
3) We will try a lot harder to keep the Fedora stable branch
... well ... stable. That means we'll only rebase to a newer
upstream version in exceptional circumstances and we'll do our
best to backport important fixes to the stable branch.
Three cheers for sanity prevailing!
Dan didn't stop there. Later on in the week he posted details of his
efforts to lay the groudwork for serious automated testing of
libvirt. He calls it the libvirt Technology Compatibility Kit (TCK)
and compares it to the Java TCK:
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
- 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
In a similar vein, upstream KVM developers have been working to create
an automated testing harness for KVM called kvm-autotest.
Fedora virtualization users can help improve KVM by running
kvm-autotest on their own hardware using Fedora's version of KVM:
Things are looking up on the QA front for virtualization!
As mentioned last week, Rich Jones is working on to create an API to
allow accessing and modifing guest images. Well, Rich blogged this
week about the progress he is making:
Rich Jones blogged on his libguestfs progress:
He also posted some details of how he has integrated Augeus with
libguestfs to simplify the task of editing config files in guest
Vote +1 :: Rich Jones For Sponsor
Rich has requested to be approved as a Fedora Package Sponsor:
Clearly this is just a formality, but just in case ... we think
everyone should email their local FESCo representative and threaten
severe retribution if they don't "Vote +1 for Rich!" :-)
(I got carried away? Really?)
Robert P. J. Day posted to the fedora-virt detailing his intention to
write a beginner's guide to virtualization on Fedora:
Discussion continued later in the week discussing what the "Fedora
virtualization experience" should be:
Dan Berrange edged sVirt closer to perfection this week with a couple
of fixes to python-virtinst:
* Fri Apr 3 2009 Daniel P. Berrange <berrange at redhat.com> -
- Attempt to fix SELinux labelling on CDROM ISOs used for installation
* Fri Apr 3 2009 Daniel P. Berrange <berrange at redhat.com> -
- Set SELinux context on $HOME/.virtinst to make kernel/initrd boot
work (rhbz #491052)
Dan Walsh also posted his thoughts on a configuration file for sVirt:
Dell's Matth Domsch requested add support in QEMU for booting gPXE
boot ROMs so as to allow PXE booting directly from an iSCSI LUN:
Update QEMU to use gPXE roms for iSCSI boot support
Glauber has been working away at the problem. First he got a patch into
upstream QEMU which creates enough ROM space to allow gPXE to be
used. However, it turns out this breaks QEMU's '-vga std' option:
qemu ROM space increase breaks WinXP guests
He has posted a patch upstream to fix this issue, but the patch has
triggered a debate which might lead to the original patch for gPXE
being reverted temporarily until a "perfect" solution is found some
time in the future.
Also, Glauber tracked down a kvm.ko bug which prevented gPXE ROMs for
qemu-kvm fails to boot gPXE ROMs
He has posted a number of patches upstream to resolve this issue, and
the debates are ongoing.
Contributing to the Fedora Kernel
Marcelo had some patches from upstream to KVM's timer interrupt
injection code which he wanted to get into F11 in order to fix:
Unable to run RHEL-5 Xen within KVM guest
Marcelo decided it was time to bite the bullet and figure out the
fairly involved list of steps to allow him to commit fixes to the
Fedora kernel i.e.:
- Get a FAS account
- Accept the CLA
- Download a cert for Koji
- Upload an SSH key for CVS
- Request commit access to the kernel package
- Email the proposed patch to fedora-kernel-list
- Check the kernel out from CVS
- Add the patch to the spec file and commit
- Tag and build in Koji
Whew! And after figuring all that out, we realised the kernel folks
already had written up some notes on this process:
It seems these kernel folks aren't so nasty after all ...
DOOM-O-METER: 192 bugs last week, 184 this week. Yeah!
Okay, it's holiday time so I couldn't be bothered making the bugs
summary a bit more palatable :-)
qemu-kvm segfaults on startup in SDL_memcpyMMX/SSE
The fix from upstream has been backported to rawhide and is
available in SDL-1.2.3-9.fc11.
Unable to create a new guest using a Live iso from a directory
Looks like a case where a the ISO was copied into the pool's
directory and, so, not seen by virt-manager. Solution could be to
have virt-manager refresh before probing.
Virtual machine fails to start without cdom - qemu: could not
open disk image /dev/sr0
Common problem with Windows guests not starting when no cdrom is
available because virtinst must leave it attached post-install.
Cole dug in and found that the problem was in qemu itself -
relying on the cdom device path being /dev/cd - and came up with a
Unable to boot because libvirt uses '-cpu qemu32' with x86_64
Somewhere along the line libvirt or virtinst was creating guest
configuration files with arch='i686' on x86_64 hosts. This worked
fine in the past because we just ignored the arch, but now it's
biting us in the ass. It's still not clear where the original bug
Fedora 9 does not have virtio PXE ROM - PXE booting Fedora 10
guests under virt-manager fails
We've rebased virt-manager in Fedora 9 and the new version tries
to PXE boot guests with virtio. Problem is that QEMU in F9 does
not have virtio PXE ROM.
qemu-img crashes creating 5TB qcow2 file
cdub posted his patch to qemu-devel and Anthony committed to the
stable branch. Glauber cherry-picked into rawhide.
EFI BIOS support in qemu
This weeks Fedora Test Day is testing Fedora's EFI support. This
would be a lot easier if qemu had EFI support. A link to xen
related code supposedly implementing this was posted to the bug.
Windows installs (ex: Win 2008) reboot media as soon as install
Looks like Win2008 under QEMU sees the cdrom as being ejected for
virt-viewer no longer auto adjusts to guest screen size
Jesse provided more info for Cole on how to reproduce this
openbios bug causes qemu-system-ppc "invalid/unsupported opcode"
It looks like an openbios bug is breaking qemu's ppc target. A
potential fix has been identified upstream.
qemu vga segfault under kvm-autotest
Avi followed up his huge patch for this issue with a beautiful one
line fix which has now been built in rawhide.
KVM isn't used by qemu launched by Virtual Machine Manager
A report of kvm_intel not being loaded at boot. Further confusion
by libvirtd not noticing kvm is available after it had been loaded
as per bug #460649.
E1000 PXE boot fails with "No IP address"
Apparently etherboot's e1000 PXE ROM is failing to acquire a DHCP
Server down after 1-2 days, many of processes in state "D". (xen
A hard to reproduce issue on F10 xen pv_ops DomU guests where some
processes get stuck in uninterruptible sleep.
virt-manager/virtinst should not set a keymap unless one is
Cole has now fixed this in rawhide - virtinst and virt-manager
don't specify a keymap for qemu to use unless explicitly asked to
do so by the user.
Now, the raw scancode extension should be used by default, fixing
keyboard issues seen by several people.
Can't use API to create virtual floppy drive with correct device
Cole cherry-picked the fix for upstream into rawhide. Now virtinst
should properly create floppy drives for guests.
More information about the Fedora-virt