- 80comments
- 6comments
- 124comments
- 52comments
- 34comments
- 595comments
- 139comments
- 12comments
- 237comments
- 84comments
- 170comments
- 73comments
- 6comments
- 234comments
- 42comments
- —discuss
- 4comments
- 121comments
- 3comments
- 159comments
- 13comments
- 25comments
- 62comments
- 29comments
- 45comments
- —discuss
- 374comments
- 40comments
- 120comments
- 49comments
Why not link directly to the actual announcement?
http://permalink.gmane.org/gmane.comp.emulators.qemu/194776
And the full changelog here:
http://wiki.qemu.org/ChangeLog/1.4
Interesting gems there like more support for Mac OS X PPC guest OS's, and details on the block device changes.
If anybody has simple and beautiful :) use cases of QEMU please share. I used it to run Debian Squeeze MIPS images, so that I could have gcc output in MIPS assembly.
We are testing [0] our Sparc v8 compiler backend. Apparently, a 3GHz i7 core emulating Sparc is significantly faster than an FPGA synthesized Sparc.
[0] http://pp.info.uni-karlsruhe.de/git/firm-testsuite/
Schedule change. Today's project is to see is qemu running a big endian PPC delivers acceptable performance for testing software in a bigendian environment. I could retire an old Mac Mini PPC running Debian.
Good idea might try that too...
What kind of FPGA package were you previously using?
Many FPGA CPU simulators attempt to be cycle-accurate for the purpose of architecture development, where the emulator has the leeway of treating instructions as atomic units and abstracting the rest.
Would have to ask my colleague about the details, but yes it is cycle-accurate. It is running 50 or 80 MHz, so it is expected to run slower.
I'd be curious if anyone has a Sparc guest running Solaris 10/11 on a Mac..
I use it all the time for Raspberry Pi images - configure / setup, backup, etc. if you don't have hardware yet, you can get everything ready, and then just push it onto an SD card when the hardware arrives.
I made an arch-usb image I carry-around after customising the full thing in qemu and converting qemu-img to usb, still use it in emergency places
We used QEMU/KVM at Sauce to build out our OS X / iOS cloud.
I never miss a chance to pimp Sauce to everyone I can. I love that service, it's stupid fast and as simple as launching any other app. We're going to be purchasing a paid account next week to do more extensive testing on some sites we are building out.
It's a startling upgrade over using Adobe BrowserLab or local virtual machines, which were our previous strategies.
Great stuff! Your blog post mentioned you use Mac Pros---would the QEMU/KVM patches also work on the Mac mini? Any luck getting them upstreamed?
I don't know why they wouldn't work on a Mac Mini. I'm not the one who did the work, so I'm not sure about upstream status. Best people to ask are Alexander Graf and René Rebe. But if anyone wants to grab the patches and advocate for them upstream, that would be awesome.
Been looking for running OsX on qemu/kvm for a while now but could not find a place for current patches nor a description of its status at all. not even on Graf's page. Any hint where to go ? tnx in advance.
http://sauceio.com/index.php/2012/08/apple-sauce-android-sau... https://github.com/saucelabs/mac-osx-on-kvm
Thanks a lot !
Hardened embedded systems.
libguestfs uses qemu to open and edit disk images. http://libguestfs.org
I have used QEMU to develop and debug a hobby operating system kernel. GDB and QEMU makes things so much easier than making a floppy image and booting it on real hardware (like Linus worked on Linux kernel in the early 1990's).
Making a multiboot-compatible kernel image that you can boot with QEMU (and with real iron using GRUB) requires only a few dozen lines of assembly code and a simple linker script.
Do I understand this correctly? Windows in Quemu will feel as fast as installed directly?
If thats the case, I would buy a windows 8 CD just to play around with it without having to leave Debian. Will Windows 8 run in Qemu?
Does this latest Qemu run under Debian 6?
There is no need to buy Windows 8, just download the free trial. It runs without problems under qemu. See also: http://www.linux-kvm.org/page/Guest_Support_Status#Windows_F...
Or, you can just use VirtualBox to test it? I don't know if they already support it.
They support Windows 8.
Probably it's true that it will run as fast as 95% of native speed. However, you still have a host OS running in parallel... so it won't be the same as running either as full native I guess.
This isn't just the fact as of this release. Xen is based on Qemu which can run e.g. Win7 paravirtualized on the same machine obtaining complete gfx or othe pci(-e) devices and run almost full speed. I am curious about the impact now that it is even faster.
Is that really paravirtualization? How does Xen run a binary OS as paravirtualized?
I think you're right and the guy you replied to misspoke. Xen running Windows is called HVM which seems to be distinct from paravirtualization.
How does, say, Photoshop perform?
Xen is not based on QEMU. Xen can use QEMU for emulating some devices when doing full virtualization, but when doing paravirtualization (most useful case) it doesn't use QEMU at all.
No, "experimental threaded backend for virtio-blk-pci achieving up to a 900% increase in IOP rate on very large storage devices" does not translate to "Windows in Quemu will feel as fast as installed directly".
The GPU is still emulated in software, so it's likely to be quite slow.
Does this point the way for better disk performance for potentially all VM software? VirtualBox and Xen sure leave me cold when it comes to I/O. (Disclaimer: I haven't tried the alternatives, so I'm not really calling them out specifically.)
This is ultimately about scalability. To achieve this kind of IOP rate, you need to be able to scale very large guests very well. KVM has always been exceptionally good at this and QEMU was really the bottle neck. We've now overcome this problem in QEMU (at least for block performance).
KVM is able to achieve this level of scalability because it leverages Linux which is already very good at scaling to large systems. I wouldn't expect this kind of scalability from other hypervisors any time soon.
Not just Linux. This announcement makes SmartOS even that much more attractive an option?
For anyone who needs background on this-
SmartOS: virtualization with ZFS and KVM https://lwn.net/Articles/459754/
So... does this preclude enjoying this sort of speed-boost on *BSD (I care about NetBSD specifically).
I'm a KVM user (snd ex-Xen early adopter) but not very knowledgeable about all this. (I'm using VMs because I need them to test software in different environments)
Does this latest QEMU patch have implications for KVM? Will KVM "Linux inside Linux" and "Windows inside Linux" virtual machines be now faster under KVM thanks to this latest QEMU patch? And if so, why?
(thanks for all the good work to the QEMU and KVM teams btw)
Is this with visualization extensions?
Although something tells me I won't be able to play games in W8 under QUEMU right?
Request: binaries for download.
Qemu is ridiculously easy to compile on every Linux. Really. Just git clone, ./configure && make. The number of dependencies is tiny.
It's also available in every Linux & *BSD distro of significance as a binary.
It's also pretty easy to compile on Windows, although of course Windows lacks a compiler out of the box, but that's entirely the fault of Windows.
At risk of nit-picking, I have a OS X and no default compiler.
QEMU is configured at compile time (with arguments to ./configure). It does not make sense to make a one-size-fits-all binary.
Grabbing the source from git and compiling it takes only a moment anyway.
Does this performance apply to using x86 apps on ARM devices, in Linux?
Works great, played around with plan9 on it.
I'm a bit skeptical of the purported 95% of native IO performance. Especially, as in the mailing list thread, the maintainer claimed that it should already have been 95% on local storage, but that this latest version makes that applicable to large storage arrays as well.
https://plus.google.com/101344524535025574253/posts/Dbu4e6ff...
It will be very interesting to see the benchmark configurations and results.
Does that means Android emulator is going to be usable now?
The x86 android emulator with the intel HAX thing isn't too bad, already.
android-x86 is already very usable in qemu.