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!
https://bugzilla.redhat.com/showdependencytree.cgi?id=F11VirtBlocker&hid... https://bugzilla.redhat.com/showdependencytree.cgi?id=F11VirtTarget&hide...
Now is a good time for people to jump in and help out :-)
FWN ===
Dale Bewley continues to churn out useful virtualization sections for Fedora Weekly News. This weeks edition is here:
http://fedoraproject.org/wiki/FWN/Issue170#Virtualization
Update Process ==============
Dan Berrange posted an excellent write up on the soul searching some of us have been doing around our update process for Fedora packages:
http://www.redhat.com/archives/fedora-virt/2009-April/msg00008.html
The upshot of this is:
1) We will continue to immediately push the latest upstream releases to rawhide
2) We will create a "virt preview" yum repository which will contain the latest rawhide packages rebuilt for the current Fedora stable branch
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!
libvirt-TCK ==========
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:
http://www.redhat.com/archives/libvir-list/2009-April/msg00176.html
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
KVM Autotest ============
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:
https://fedoraproject.org/wiki/Testing_KVM_with_kvm_autotest
Things are looking up on the QA front for virtualization!
libguestfs ==========
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:
http://rwmj.wordpress.com/2009/04/08/libguestfs-ocaml-bindings/ http://rwmj.wordpress.com/2009/04/08/libguestfs-perl-bindings/ http://rwmj.wordpress.com/2009/04/07/libguestfs-lvm-support/ http://rwmj.wordpress.com/2009/04/04/more-libguestfs-progress/ http://rwmj.wordpress.com/2009/04/04/libguestfs-modifying-a-guest-image/
He also posted some details of how he has integrated Augeus with libguestfs to simplify the task of editing config files in guest images:
http://www.redhat.com/archives/fedora-virt/2009-April/msg00045.html
Vote +1 :: Rich Jones For Sponsor =================================
Rich has requested to be approved as a Fedora Package Sponsor:
https://fedorahosted.org/fesco/ticket/130
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?)
Virt Tutorial =============
Robert P. J. Day posted to the fedora-virt detailing his intention to write a beginner's guide to virtualization on Fedora:
http://www.redhat.com/archives/fedora-virt/2009-April/msg00009.html
Discussion continued later in the week discussing what the "Fedora virtualization experience" should be:
http://www.redhat.com/archives/fedora-virt/2009-April/msg00049.html
sVirt =====
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@redhat.com - 0.400.3-4.fc11 - Attempt to fix SELinux labelling on CDROM ISOs used for installation
* Fri Apr 3 2009 Daniel P. Berrange berrange@redhat.com - 0.400.3-3.fc11 - 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:
http://www.redhat.com/archives/libvir-list/2009-April/msg00107.html
gPXE ====
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:
https://bugzilla.redhat.com/457979 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:
https://bugzilla.redhat.com/494376 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 booting:
https://bugzilla.redhat.com/494469 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:
https://bugzilla.redhat.com/491625 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:
https://fedoraproject.org/wiki/Kernel#Contributing_to_the_Fedora_kernel
It seems these kernel folks aren't so nasty after all ...
Bugs ====
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 :-)
https://bugzilla.redhat.com/487720 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.
https://bugzilla.redhat.com/494005 Unable to create a new guest using a Live iso from a directory storage pool
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.
https://bugzilla.redhat.com/473154 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 straightforward patch.
https://bugzilla.redhat.com/494286 Unable to boot because libvirt uses '-cpu qemu32' with x86_64 virtual machine
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 was.
https://bugzilla.redhat.com/493518 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.
https://bugzilla.redhat.com/491943 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.
https://bugzilla.redhat.com/477035 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.
https://bugzilla.redhat.com/493410 Windows installs (ex: Win 2008) reboot media as soon as install starts
Looks like Win2008 under QEMU sees the cdrom as being ejected for some reason.
https://bugzilla.redhat.com/491683 virt-viewer no longer auto adjusts to guest screen size
Jesse provided more info for Cole on how to reproduce this problem.
https://bugzilla.redhat.com/494075 openbios bug causes qemu-system-ppc "invalid/unsupported opcode" failure
It looks like an openbios bug is breaking qemu's ppc target. A potential fix has been identified upstream.
https://bugzilla.redhat.com/494002 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.
https://bugzilla.redhat.com/494739 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.
https://bugzilla.redhat.com/494541 E1000 PXE boot fails with "No IP address"
Apparently etherboot's e1000 PXE ROM is failing to acquire a DHCP address.
https://bugzilla.redhat.com/478414 Server down after 1-2 days, many of processes in state "D". (xen domU)
A hard to reproduce issue on F10 xen pv_ops DomU guests where some processes get stuck in uninterruptible sleep.
https://bugzilla.redhat.com/487735 virt-manager/virtinst should not set a keymap unless one is explicitly requested
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.
https://bugzilla.redhat.com/493408 Can't use API to create virtual floppy drive with correct device name
Cole cherry-picked the fix for upstream into rawhide. Now virtinst should properly create floppy drives for guests.
-
Mark McLoughlin