Tuesday, December 3, 2013

KVM migration from Fedora 17 to Fedora 21+ is not supported

With qemu 1.7.0 in rawhide/Fedora 21, we've dropped some non-upstream back compatibility patches that allow migration from Fedora 17 vintage qemu and earlier.

This affects not just live migration (which I doubt anyone cares about in this context), but also any qemu memory snapshots or libvirt 'save' data created on <= F17. Trying to restore this data on F21 will not work.

In reality I don't expect this to affect anybody really. If you have saved data or snapshots that are important, you can load/restore them on Fedora 20, fully poweroff the VM, virsh edit and change the machine= value to something newer like pc-1.6, start the VM, and recreate the data to the best of your ability. save data/memory snapshots created on F20 will load correctly on F21. I realize this isn't ideal but hopefully no one is affected and it doesn't matter in practice.

Some background: In Fedora 17 and earlier, we shipped a qemu package based on qemu-kvm.git, which was a fork of qemu.git containing KVM support and a few other bits. Over time the QEMU and KVM community worked to merge all the forked bits into mainline qemu, which was fully completed with the qemu 1.3 release. Fedora 18 was the first Fedora release to ship this merged codebase

Unfortunately, qemu-kvm.git had accumulated some unintentional incompatibilities with qemu.git: minor internal bits that affected migration but had little other functional impact. The end result was that a qemu-kvm-1.2 guest could not be migrated to the new merged qemu-1.3.

This sucked for Fedora where we had always shipped qemu-kvm.git: migration/saves/snapshots made on Fedora 17 would not work on Fedora 18, and there would be no easy upgrade path. So we decided to maintain this migration back compatibility with qemu-kvm.git. However this required non-upstream patches, which we obviously do not want to carry forever.

I think after 3 stable releases (F20 is out soon enough) this shouldn't have much practical impact, so bye bye non-upstream patches :)

Tuesday, November 19, 2013

qemu-system-x86_64: error while loading shared libraries: libGL.so.1: failed to map segment from shared object: Permission denied

Are you getting this error when trying to start a libvirt KVM VM on Fedora 20?

qemu-system-x86_64: error while loading shared libraries: libGL.so.1: failed to map segment from shared object: Permission denied

Seems to be caused by Nvidia proprietary drivers. Whatever black magic they are doing behind the scenes is upsetting the selinux restrictions qemu is run under.

The fix:

sudo setsebool -P virt_use_execmem=on


(update Jan 2016: the original bug that prompted this post had some follow up discussion about a possible cause, so maybe it's fixable: https://bugzilla.redhat.com/show_bug.cgi?id=966695)

Friday, October 4, 2013

Fedora 20 Virt Test Day is October 8th!

The Fedora 20 Virt Test Day is this coming Tuesday, October 8th. Check out the test day landing page:

https://fedoraproject.org/wiki/Test_Day:2013-10-08_Virtualization

If you're interested in trying out some new virt functionality, there's step by step instructions for:

* Snapshot UI in virt-manager
* Running ARM VMs on x86 with libvirt/virt-manager
* Libvirt ACLs for granting a user access to only a single VM

Even if you aren't interested in testing new features, we still need you! The test day is the perfect time to make sure your virt workflow is working fine on Fedora 20, as there will be several developers on hand to answer any questions, help with debugging, provide patches, etc. No requirement to run through test cases on the wiki, just show up and let us know what works (or breaks).

And to be clear, while it is preferred that you have a physical machine running Fedora 20, participating in the test day does NOT require it: you can test the latest virt bits on the latest Fedora release courtesy of the virt-preview repo. For more details, as well as easy instructions on updating to Fedora 20, see:

https://fedoraproject.org/wiki/Test_Day:2013-10-08_Virtualization#What.27s_needed_to_test

If you can't make the date of the test day, adding test case results to the wiki anytime next week is fine as well. Though if you do plan on showing up to the test day, add your name to the participant list on the wiki, and when the day arrives, pop into #fedora-test-day on freenode and give us a shout!

Wednesday, September 25, 2013

Fedora 20 Virt Test Day scheduled for Oct 8th

Just a quick note that the Fedora 20 Virt Test Day is scheduled for Tuesday, Oct 8th. The inprogress landing page is at:

https://fedoraproject.org/wiki/Test_Day:2013-10-08_Virtualization

So if you're interested in helping test new virt features, or just making sure the stuff you care about isn't broken, please mark your calendars.

Monday, May 27, 2013

Fedora 19 Virt Test Day is tomorrow, Tuesday May 28th

The Fedora 19 Virt Test Day is tomorrow, Tuesday May 28th. Check out the test day landing page:

https://fedoraproject.org/wiki/Test_Day:2013-05-28_Virtualization

If you're interested in trying out some new virt functionality, there's step by step instructions for:

* Live migrate a VM without the need for shared storage
* Virtio RNG, a paravirtual random number generator for VMs
* PCI device assignment using VFIO

Even if you aren't interested in testing new features, we still need you! The test day is the perfect time to make sure your virt workflow is working fine on Fedora 19, as there will be several developers on hand to answer any questions, help with debugging, provide patches, etc. No requirement to run through test cases on the wiki, just show up and let us know what works (or breaks).

If you can't make the date of the test day, adding test case results to the wiki anytime next week is fine as well. Though if you do plan on showing up to the test day, add your name to the participant list on the wiki, and when the day arrives, pop into #fedora-test-day on freenode and give us a shout!

Thanks,
Cole

Monday, January 28, 2013

Fedora 18 notification sound is now a 'drip' noise

One random change I noticed during the F18 cycle was that the default notification noise changed from an innocuous 'bell' sound to a 'water drip' noise. While I turn off all terminal noises, this sound still pops up in Firefox and Thunderbird when a ctrl-f quick search doesn't find a match, and in my F18 VMs with default configuration. And while I'm sure many developers just turn off all sound effects, I find them useful for email and IRC notifications.

This new sound is offensive to my ears, one small step below nails on a chalk board. Unfortunately there is no way to undo this change in gnome-control-center's Sound panel, just 2 choices for the drip noise ('default' and 'drip'), and some other comical choices like a dog 'bark'. Nothing as unoffensive as the previous default. I (just yesterday) filed a bug against control-center asking for a way to restore the old behavior.

However, if you want to revert it in a hacky way, this should cover you until the next time sound-theme-freedesktop is updated:

 sudo wget http://cgit.freedesktop.org/sound-theme-freedesktop/plain/stereo/bell.oga?id=38bc773912317a2163083b6f483fbc8e6fb61123 -O /usr/share/sounds/freedesktop/stereo/bell.oga

<rant>Why this was changed is really anyone's guess. The commit message is needlessly vague. I couldn't find any mailing list posting on freedesktop lists or gnome's desktop-devel-list, nor any bug report that might have spurned the change. The 'bell' noise was just overwritten in place, despite the fact that the new noise is not remotely a 'bell' sound, though I guess the bell name is about the action and not the sound content. The git repo had been unchanged for nearly 3 years, not an issue in itself, just makes the above bits stick out even more. And finally I really don't understand why the most common sound effect on a stock install would be a noise that is an annoyance by nature: a dripping/leaking faucet.</rant>