- 9comments
- 44comments
- 27comments
- 567comments
- 133comments
- 222comments
- 82comments
- 169comments
- 34comments
- 70comments
- 1comments
- 2comments
- 233comments
- 155comments
- 11comments
- 6comments
- 102comments
- 24comments
- 57comments
- 58comments
- 26comments
- —discuss
- 41comments
- 11comments
- 370comments
- 107comments
- 39comments
- 49comments
- 42comments
- 10comments
I'd like to hear stories about people using QEMU in production. Do people think it is a viable option for automated ARM Android testing?
Er, what? QEMU is used very frequently with KVM. There are many companies providing KVM instances, so QEMU is pretty widely used in production. Did you have a more specific question?
Xen also uses QEMU, in pretty much the same manner as KVM.
That's not entirely true. Xen uses QEMU only to execute I/O. It gets I/O requests on a ring buffer and services them. CPUs are handled by the hypervisor.
With KVM, QEMU actually runs the code for the virtual machine; it just does that inside the KVM kernel module.
This means, for example, that only with KVM you can profile each VCPU simply using "perf". Also, features that require code to run in the CPU threads (for example slowing down CPUs so that migration can converge better) will not work with Xen.
I've worked on 2 large telecoms projects where automated full-system testing occurred using ARM emulators. Also, the stock Android emulator is Qemu (or at least was, last time I checked), and many people do automated testing using that.
I'm pretty sure digital ocean uses it in production
I believe the Android emulator is now quite different from mainline QEMU. No efforts have been made to merge patches back into QEMU, so the Android emulator is basically a fork of QEMU.
That said, ARM development in QEMU is very active right now and its only a matter of time before one of the supported QEMU ARM targets also happens to be a platform with good Android support.
TL;DR consider sticking to the official Android emulator for now but keep an eye on QEMU.
Can someone explain in technical-but-not-necessarily-domain-expert terms what the relationship between QEMU and KVM is? Is one a dependency of the other, or could they each work independent of the other?
KVM (Kernel Virtual Machine) is a Linux kernel module that allows a user space program to utilize the hardware virtualization features of various processors.
QEMU is a machine emulator.
QEMU can make use of KVM when running a target architecture that is the same as the host architecture (which gives significant performance advantages).
KVM is not strictly dependent on QEMU but they are usually used together. If you don't need the kernel level hw support (i.e. emulating a different architecture to the host platform) then QEMU can be used independently.
Thank you, that's pretty much perfect :)
Certainly, you can use QEMU without KVM. It's just slower that way. I'm not sure about the other way around.
Let me know when we can compile QEMU with a modest amount of RAM. Last time I tried, on a memory constrained laptop, it took over 1GB of RAM! That's a lot of memory just to compile a single program. By comparison, I can compile a kernel loaded down with heaps of unneeded drivers with less than 200MB of RAM. I suspect this situation will only get worse with future QEMU releases.
Although I agree with you, requirement of 1 GB RAM is not much in these days, so probably it will never be optimized.
Try again with QEMU 1.7 and recent gcc. There has been a known gcc issue triggered by one of the QEMU source files that requires a lot of memory. A workaround went into QEMU a while back using the gcc -fno-gcse flag for that particular source file.
Does anyone know if QEMU can do virtualization on hosts other than Linux (via KVM)? I'd love to ditch Virtualbox for it.
I've used Qemu on Windows and OpenBSD. I don't think either supports KVM acceleration though.