Just a few hours ago, the latest version of qemu-kvm-0.12.5 was released based on the recent release of upstream qemu 0.12.5 a few days ago. This release contains mostly bugfixes to 0.12.4 so it is considered a stable release. The announcement lists the following changelog from qemu-kvm 0.12.4
- audio/alsa: Handle SND_PCM_STATE_SETUP in alsa_poll_handler
- block: Handle multiwrite errors only when all requests have completed
- block: Fix early failure in multiwrite
- vpc: Use bdrv_(p)write_sync for metadata writes
- vmdk: Use bdrv_(p)write_sync for metadata writes
- qcow2: Use bdrv_(p)write_sync for metadata writes
- qcow: Use bdrv_(p)write_sync for metadata writes
- block: Add bdrv_(p)write_sync
- qcow2: Restore L1 entry on l2_allocate failure
- block/vdi: Fix image opening and creation for odd disk sizes
- block/vpc: Fix conversion from size to disk geometry
- qcow2: Remove abort on free_clusters failure
- vmdk: Fix COW
- qcow2: Fix creation of large images
- vmdk: fix double free
- qemu-options: add documentation for stdio signal=on|off
- target-arm : fix parallel saturated subtraction implementation
- target-arm : fix thumb2 parallel add/sub opcode decoding
- target-arm: fix addsub/subadd implementation
- target-i386: fix xchg rax,r8
- block/vvfat.c: fix warnings with _FORTIFY_SOURCE
- audio/alsa: Spelling typo (paramters)
- target-mips: fix DINSU instruction
- Correct definitions for FD_CMD_SAVE and FD_CMD_RESTORE
- qcow2: Fix corruption after error in update_refcount
- qcow2: Fix corruption after refblock allocation
- block: Fix multiwrite with overlapping requests
- qcow2: Fix error handling in l2_allocate
- qcow2: Clear L2 table cache after write error
- ide: Fix ide_dma_cancel
- usb-bus: fix no params
- Avoid crash on '-usbdevice <device>' without parameters
- Fix -usbdevice crash
- Fix multiboot compilation
- Fix missing symbols in .rel/.rela.plt sections
- target-ppc: fix RFI by clearing some bits of MSR
- Fix typo in balloon help
- arm_timer: fix oneshot mode
- arm_timer: reload timer when enabled
- qemu-sockets: avoid strlen of NULL pointer
- block: fix aio_flush segfaults for read-only protocols (e.g. curl)
- virtio-blk: fix barrier support
- block: fix sector comparism in multiwrite_req_compare
- pci: irq_state vmstate breakage
- qemu-img: use the heap instead of the huge stack array for win32
You can download this latest release at the following link
http://sourceforge.net/projects/kvm/files/qemu-kvm/0.12.5/qemu-kvm-0.12.5.tar.gz/download
Comments
Slow screen refresh rate (with vga -std)
Wednesday, July 28, 2010 - 12:50 slubmanUnfortunately, the vga display slowness is still there (exist since 0.12.3), so unusable for desktop virtualization :(
I'm still using 0.12.2 version, the last one with reasonable screen refresh rate.
Re: Slow screen refresh rate (with vga -std)
Thursday, July 29, 2010 - 12:29 Kenni Lundslubman, have you reported the regression on the kvm-devel list or is it a well known bug? If the developers don't know about a specific bug, it will for sure never get fixed, no matter how long you wait.
Which OS as a guest OS? win?
Sunday, August 1, 2010 - 10:07 Anonymous (not verified)Which OS as a guest OS? win? linux?
if the guest OS is linux, did you try -vga vmware?
it work for me.
KVM not really usable for normal users
Monday, August 2, 2010 - 07:51 Matthias (not verified)I'm a newbie in virtualization and now using qemu-kvm cause xen won't longer be supported by some big linux distributions. And surely, kvm is a big goal cause it's part of the linux kernel. But at this time kvm is unusable for normal users. Never bevore i've seen a software in a stable distribution that comes with so much bugs: no working alsa sound, no mouse on older Windows systems, standard vga unusable, vmware vga very slow by viewing flash videos while the picture is flickering. RadHat, Debian etc. what did you done? Under no circumstances this is a stable virtualization solution.
KVM works really well if you
Monday, August 2, 2010 - 12:02 Anonymous (not verified)KVM works really well if you want to virtualize RHEL 5.5 for server applications using ssh -Y for connectivity. Remote desktop virtualization will eventually work OK using SPICE, but various architectural issue with SPICE have resulted in a net two year delay in the release of RHEL6 (where these two use cases are considered key features).
The far, far more common use case of XP locally virtualized and displayed and connected to USB has been completely ignored from a configuration and performance standpoint since normal Linux users won't pay. Apparently the people funding development of KVM have forgotten that Linux support is from the grassroots, and ignoring these people in favor of direct revenue will loose an underpinning of community support and development.
Oh, yeah, and the CPUs without SVM/VT (like those on current netbooks) won't work at all with KVM and QEMU doesn't leverage the nice kernel level optimization being developed for KVM.
VirtualBox OSE a far superior open source solution for everything except the two use cases noted at the start of this message, and the closed source version has limited USB support too. VMWare Workstation is another pretty good closed source solution. Perhaps someday libvirt and KVM will provide good integration, support, and performance for locally hosted XP and W7 running on a netbook CPU with USB printing support... Sigh.
RE: KVM works really well if you
Monday, August 2, 2010 - 12:13 Anonymous (not verified)BTW this assessment (the good and the bad) is based on the using twenty-four and nine month old (kernel 2.6.32 with corresponding libvirt) versions of KVM on a daily basis for current XP and CentOS5 installations. Please tell me that things have changed... ?
RE: KVM works really well if you
Thursday, August 5, 2010 - 03:37 Kenni LundDon't feed anonymous trolls on the Internet...but here we go anyway :)
> KVM works really well if you want to virtualize RHEL 5.5 for
> server applications using ssh -Y for connectivity.
"Server applications" and "ssh -Y"??? Something doesn't match.
> Remote desktop virtualization will eventually work OK using SPICE
Don't use Xorg on Linux servers and use RDP on Windows Servers, and you'll be perfectly fine. Eventually at some point you can probably switch to SPICE.
> The far, far more common use case of XP locally virtualized and
> displayed and connected to USB
I'm not going to comment on the "far, far more common use case", but again, use RDP for graphical control of Windows clients. I run a local virtual Windows XP machine at work and a local Windows 7 at home with RDP. I agree on the USB issues.
> Oh, yeah, and the CPUs without SVM/VT (like those on current netbooks)
> won't work at all
That's a big advantage in my opinion. Don't waste development time on deprecated hardware or hardware which isn't meant for virtualization. Time will kill that hardware anyway, use another virtualization solution if you want support for deprecated or cheap hardware.
> VirtualBox OSE a far superior open source solution for everything
> except the two use cases noted at the start of this message
Or as I would have said it: VirtualBox has better emulated USB support than KVM, but entirely lacks Intel VT-d support for PCI/PCIe passthrough. If you like VirtualBox better, feel free to use it. We don't force you to use KVM :-D
Works Really Well if You What?
Wednesday, September 8, 2010 - 21:48 Curt Sampson (not verified)Speaking from the server admin point of view, KVM was also a terrible move; it's to this date still not nearly as mature as Xen for server virtualization. Not only doesn't it work on non-VT hardware, which is important for older servers, especially when they are hard to replace and otherwise fine, but it went for ages using slow emulated hardware to work with hardware drivers for IDE and network. Now, it finally gets drivers that directly talk to the hypervisor, and they go and corrupt your disks! (See this bug report.) Perhaps that's fixed in this release, perhaps not, but all of this stuff has been working very well in Xen for years now.
I don't know who over at Ubuntu made the decision to drop Xen support a few releases ago, but I've had plenty of time to curse them while buying and installing new servers and/or motherboards (some motherboards can use VT CPUs but don't allow you to enable VT), recovering corrupted disks, and in general babying the systems along. I should have done the extra work to avoid ever moving away from Xen.
Post new comment