Description of problem: I upgraded to qemu-1.0-0.5.svn6666.fc11.x86_64 and I've experienced several problems. First, qemu-common contains files that are also in the kvm package. This is probably ok because the new qemu package is intended to replace kvm. However, if this is the case, the new qemu should obsolete kvm. Second, while qemu itself works, if you enable kvm support, none of my existing VMs will start. Windows complains that the CPU lacks cmpxchg8b support. Other OSes crash in a variety of ways. Version-Release number of selected component (if applicable): qemu-1.0-0.5.svn6666.fc11.x86_64 How reproducible: Every time Steps to Reproduce: 1. Upgrade to qemu-1.0-0.5.svn6666.fc11.x86_64 2. Try and boot an old Windows guest using kvm support 3. Watch it start to boot Actual results: FAIL Expected results: !FAIL :) Additional info:
This is expected. We're trying to make qemu and kvm use the same package, and while we don't succeed (I have a local build, but koji is playing tricks on me for the whole day), this things are indeed likely to happen. stay tuned.
That's what I figured, but I wanted to make sure you had a bug to track against. :)
I upgraded my virt test server to: qemu*0.10-0.4.kvm20090303git.fc11 version today. Found the following issues: - The kvm-intel module is never loaded, so even though qemu-kvm is running for my guests, they can't use kvm. The libvirt log files have: open /dev/kvm: No such file or directory Could not initialize KVM, will disable KVM support - Even correcting that and loading manually before libvirtd starts, all guests consume 100% of a cpu all the time (or 200% for those guests with 2 cpus defined, etc). The guests eventually come up and you can see that 'irqbalance' is sucking up 100% cpu in the guest. - All the guests have: libvir: Security Labeling error : SELinuxSetSecurityLabel: unable to set security context 'system_u:system_r:svirt_t:s0:c17,c404': Invalid argument. libvir: Security Labeling error : SELinuxSetSecurityLabel: unable to set security context 'system_u:object_r:virt_image_t:s0:c17,c404' on (null): Bad address. in their logs. - The machine usually hard locks about 15-30min later with a large scrolling oops. I can try and capture via camera if you like. Removing the new qemu* packages and re-installing kvm and everything goes back to normal. ;)
Oh, forgot to mention another one: /etc/sysconfig/modules/kvm.modules is a init script. This is wrong. Scripts in this area are run early and are expected to just load modules. with this script installed I always get a usage message on boot because it's being run without any arguments, and it's expecting a 'start' or something.
My WinXP VMs "fail to boot" with the new qemu packages with "KVM initialized" (i.e., with /dev/kvm created): [tbl@tlondon ~]$ ls -l /dev/kvm crw-rw----. 1 root kvm 10, 232 2009-03-09 06:15 /dev/kvm [tbl@tlondon ~]$ qemu-kvm starts nicely, and the WinXP guest "boots" for 10 seconds or so before freezing every time after cycling at the WinXP boot screen (the "slider" has cycled several times before the freeze). I have to remove the "new" qemu packages: Removing: qemu-common x86_64 2:0.10-0.4.kvm20090303git.fc11 installed 2.1 M qemu-system-x86 x86_64 2:0.10-0.4.kvm20090303git.fc11 installed 5.4 M and install kvm-84-1.fc11.x86_64.rpm to get them to boot. I see no messages in /var/log/messages nor in /var/log/audit/audit.log. Running in SELinux permissive mode does not help. Here is the command I use to run one VM: qemu-kvm -localtime -vga std -m 512 -usbdevice tablet -name "Windows XP" -hda ~/VirtualMachines/raw.img -k en-us Is this "supposed to work", or is kvm support still pending? If the latter, what additional info can I provide?
(In reply to comment #4) > Oh, forgot to mention another one: > > /etc/sysconfig/modules/kvm.modules is a init script. This is wrong. Scripts in > this area are run early and are expected to just load modules. with this script > installed I always get a usage message on boot because it's being run without > any arguments, and it's expecting a 'start' or something. This was reported at bug #489432.
This bug is a mess - please only report one issue per bug report in the future. - The clashing qemu-img problem is now resolved, since kvm has been blocked from rawhide repos. Re Vista not working (initial reporter/comment #5), there was a bug in the QEMU package with it using the wrong BIOS files. Can you update to qemu-2:0.10-0.7.kvm20090310git and try again. This should be at least as functional as the old kvm-84 package now.
qemu-system-x86-0.10-0.7.kvm20090310git.fc11.x86_64 qemu-common-0.10-0.7.kvm20090310git.fc11.x86_64 qemu-kvm-tools-0.10-0.7.kvm20090310git.fc11.x86_64 I can confirm they "work for me" with both WinXP and WinVista guests. Thanks.....
Works for me with the latest build! You guys are seriously rocking with the new qemu package, congrats...
Hi, Sorry for the (possibly) silly question, but where can I find those latest packages ? I am running "yum update", am using the Rawhide repos, but I don't get any package newer than qemu-[...]-x86-0.10-0.4.kvm20090303git.fc11.x86_64. Any thoughts ? Thanks, George Iosif
Get them direct from the buildsystem: http://koji.fedoraproject.org/koji/packageinfo?packageID=3685 We are in beta freeze, so packages have to request breaking the freeze to get into rawhide right now, and those qemu packages have not requested that that I know of.
Ok, got them. Thank you ! Regards, George