[arch-general] qemu-kvm vs. qemu upstream
On Wed, Feb 23, 2011 at 7:38 PM, Allan McRae <allan@archlinux.org> wrote:
If this is virtualbox specific, I'd try qemu-kvm.
hey, i was just trying to get a concrete answer about this the other day, so maybe you can clarify because i keep reading conflicting and/or outdated information. AFAICS, qemu-kvm is still _different_ from upstream kvm support in qemu, correct? i tried rebuilding qemu several times, ensuring i had all the options i wanted (SPICE/kvm/etc) and i was getting absolutely <expletive deleted> performance -- switch to qemu-kvm and she's blazing again, yet many places seem to suggest they are one and the same. i see they definitely have different sources, but would you/anyone care to elaborate on the relationship? C Anthony
On Thu, 2011-02-24 at 10:33 -0600, C Anthony Risinger wrote:
On Wed, Feb 23, 2011 at 7:38 PM, Allan McRae <allan@archlinux.org> wrote:
If this is virtualbox specific, I'd try qemu-kvm.
hey,
i was just trying to get a concrete answer about this the other day, so maybe you can clarify because i keep reading conflicting and/or outdated information.
AFAICS, qemu-kvm is still _different_ from upstream kvm support in qemu, correct? i tried rebuilding qemu several times, ensuring i had all the options i wanted (SPICE/kvm/etc) and i was getting absolutely <expletive deleted> performance -- switch to qemu-kvm and she's blazing again, yet many places seem to suggest they are one and the same.
i see they definitely have different sources, but would you/anyone care to elaborate on the relationship?
C Anthony IIRC
qemu-kvm is the QEMU + KVM provided by the kvm project and normal QEMU can use KVM as virtualizer. (correct me if i am wrong ) from wikipedia: By itself, KVM does not perform any emulation. Instead, a user-space program uses the /dev/kvm interface to set up the guest VM's address space, feeds it simulated I/O and maps its video display back onto the host's. At least two programs exploit this feature: a modified version of Qemu, and Qemu itself since version 0.10.0. In short, if you have VT extensions, use qemu-kvm, if not use qemu since it emulates ( costs much cpu though ). QEMU/KVM is for me the best way to run windows, KVM is in the kernel so now rebuilding of modules, completely open source and it has nice features. -- Jelle van der Waa
On Thu, Feb 24, 2011 at 10:53 AM, Jelle van der Waa <jelle@vdwaa.nl> wrote:
On Thu, 2011-02-24 at 10:33 -0600, C Anthony Risinger wrote:
On Wed, Feb 23, 2011 at 7:38 PM, Allan McRae <allan@archlinux.org> wrote:
If this is virtualbox specific, I'd try qemu-kvm.
hey,
i was just trying to get a concrete answer about this the other day, so maybe you can clarify because i keep reading conflicting and/or outdated information.
AFAICS, qemu-kvm is still _different_ from upstream kvm support in qemu, correct? i tried rebuilding qemu several times, ensuring i had all the options i wanted (SPICE/kvm/etc) and i was getting absolutely <expletive deleted> performance -- switch to qemu-kvm and she's blazing again, yet many places seem to suggest they are one and the same.
i see they definitely have different sources, but would you/anyone care to elaborate on the relationship?
IIRC
qemu-kvm is the QEMU + KVM provided by the kvm project and normal QEMU can use KVM as virtualizer. (correct me if i am wrong )
from wikipedia: By itself, KVM does not perform any emulation. Instead, a user-space program uses the /dev/kvm interface to set up the guest VM's address space, feeds it simulated I/O and maps its video display back onto the host's. At least two programs exploit this feature: a modified version of Qemu, and Qemu itself since version 0.10.0.
In short, if you have VT extensions, use qemu-kvm, if not use qemu since it emulates ( costs much cpu though ).
QEMU/KVM is for me the best way to run windows, KVM is in the kernel so now rebuilding of modules, completely open source and it has nice features.
hmm, soo qemu doesn't actually use the VT extensions? wtf is the point then? this is what i don't understand; if qemu supports KVM via the `-enable-kvm` switch why does it suck so much -- it seems just as slow to me as no KVM support at all. I have a server that runs several KVM/libvirt instances (windows being one of them purely for ... i dont even know) so i'm pretty familiar with it all, but i'm just trying to get solid info why there is such a huge performance gap when the both "use KVM". i thought KVM itself did all the VT handling. C Anthony
On Thu, 2011-02-24 at 11:07 -0600, C Anthony Risinger wrote:
On Thu, Feb 24, 2011 at 10:53 AM, Jelle van der Waa <jelle@vdwaa.nl> wrote:
On Thu, 2011-02-24 at 10:33 -0600, C Anthony Risinger wrote:
On Wed, Feb 23, 2011 at 7:38 PM, Allan McRae <allan@archlinux.org> wrote:
If this is virtualbox specific, I'd try qemu-kvm.
hey,
i was just trying to get a concrete answer about this the other day, so maybe you can clarify because i keep reading conflicting and/or outdated information.
AFAICS, qemu-kvm is still _different_ from upstream kvm support in qemu, correct? i tried rebuilding qemu several times, ensuring i had all the options i wanted (SPICE/kvm/etc) and i was getting absolutely <expletive deleted> performance -- switch to qemu-kvm and she's blazing again, yet many places seem to suggest they are one and the same.
i see they definitely have different sources, but would you/anyone care to elaborate on the relationship?
IIRC
qemu-kvm is the QEMU + KVM provided by the kvm project and normal QEMU can use KVM as virtualizer. (correct me if i am wrong )
from wikipedia: By itself, KVM does not perform any emulation. Instead, a user-space program uses the /dev/kvm interface to set up the guest VM's address space, feeds it simulated I/O and maps its video display back onto the host's. At least two programs exploit this feature: a modified version of Qemu, and Qemu itself since version 0.10.0.
In short, if you have VT extensions, use qemu-kvm, if not use qemu since it emulates ( costs much cpu though ).
QEMU/KVM is for me the best way to run windows, KVM is in the kernel so now rebuilding of modules, completely open source and it has nice features.
hmm, soo qemu doesn't actually use the VT extensions? wtf is the point then? QEMU is an emulator -> so for ARM for example this is what i don't understand; if qemu supports KVM via the `-enable-kvm` switch why does it suck so much -- it seems just as slow to me as no KVM support at all. Here it's not, are you using qemu-kvm or some selfcompiled version? I have a server that runs several KVM/libvirt instances (windows being one of them purely for ... i dont even know) so i'm pretty familiar with it all, but i'm just trying to get solid info why there is such a huge performance gap when the both "use KVM". i thought KVM itself did all the VT handling.
C Anthony
Another tip for kvm usage is installing your OS on virtio [1] [1] http://www.linux-kvm.org/page/Using_VirtIO_NIC -- Jelle van der Waa
On Thu, Feb 24, 2011 at 11:23 AM, Jelle van der Waa <jelle@vdwaa.nl> wrote:
On Thu, 2011-02-24 at 11:07 -0600, C Anthony Risinger wrote:
hmm, soo qemu doesn't actually use the VT extensions? wtf is the point then? QEMU is an emulator -> so for ARM for example this is what i don't understand; if qemu supports KVM via the `-enable-kvm` switch why does it suck so much -- it seems just as slow to me as no KVM support at all.
Here it's not, are you using qemu-kvm or some selfcompiled version?
qemu-kvm is always fast. qemu is never fast -- libvirt uses `-enable-kvm` when i tell it to, ie. for either package. i've tried recompiling the regular `qemu` package with explicit KVM support, and the speed is still absolutely abysmal.
I have a server that runs several KVM/libvirt instances (windows being one of them purely for ... i dont even know) so i'm pretty familiar with it all, but i'm just trying to get solid info why there is such a huge performance gap when the both "use KVM". i thought KVM itself did all the VT handling.
Another tip for kvm usage is installing your OS on virtio [1]
already do :-) i use all the virtio drivers -- when i say perf is bad i mean it's like KVM isnt even working. i haven't `lsof` yet to make sure qemu (not qemu-kvm!!) is actually opening the /dev/kvm device. i read thru the packages of both. i tried symlinking `/usr/bin/qemu-kvm -> qemu-system-x86_64` (this is what qemu-kvm package does) ... no difference. so my real question is, is anyone using the upstream package `qemu`, with KVM, and getting proper results? are good results expected? what am i missing here. C Anthony
On Thu, 24 Feb 2011 11:43:33 -0600 C Anthony Risinger <anthony@extof.me> wrote:
On Thu, Feb 24, 2011 at 11:23 AM, Jelle van der Waa <jelle@vdwaa.nl> wrote:
On Thu, 2011-02-24 at 11:07 -0600, C Anthony Risinger wrote:
hmm, soo qemu doesn't actually use the VT extensions? wtf is the point then? QEMU is an emulator -> so for ARM for example this is what i don't understand; if qemu supports KVM via the `-enable-kvm` switch why does it suck so much -- it seems just as slow to me as no KVM support at all.
Here it's not, are you using qemu-kvm or some selfcompiled version?
qemu-kvm is always fast. qemu is never fast -- libvirt uses `-enable-kvm` when i tell it to, ie. for either package. i've tried recompiling the regular `qemu` package with explicit KVM support, and the speed is still absolutely abysmal.
I have a server that runs several KVM/libvirt instances (windows being one of them purely for ... i dont even know) so i'm pretty familiar with it all, but i'm just trying to get solid info why there is such a huge performance gap when the both "use KVM". i thought KVM itself did all the VT handling.
Another tip for kvm usage is installing your OS on virtio [1]
already do :-) i use all the virtio drivers -- when i say perf is bad i mean it's like KVM isnt even working. i haven't `lsof` yet to make sure qemu (not qemu-kvm!!) is actually opening the /dev/kvm device.
i read thru the packages of both. i tried symlinking `/usr/bin/qemu-kvm -> qemu-system-x86_64` (this is what qemu-kvm package does) ... no difference.
so my real question is, is anyone using the upstream package `qemu`, with KVM, and getting proper results? are good results expected? what am i missing here.
C Anthony This is quite strange, I use qemu-system-x86_64 --enable-kvm regulary, and I get near native speed in the vm. [oh@Alice][~]% pacman -Q qemu qemu 0.14.0-1
On 24-02-2011 17:07, C Anthony Risinger wrote:
hmm, soo qemu doesn't actually use the VT extensions? wtf is the point then? this is what i don't understand; if qemu supports KVM via the `-enable-kvm` switch why does it suck so much -- it seems just as slow to me as no KVM support at all. I have a server that runs several KVM/libvirt instances (windows being one of them purely for ... i dont even know) so i'm pretty familiar with it all, but i'm just trying to get solid info why there is such a huge performance gap when the both "use KVM". i thought KVM itself did all the VT handling.
C Anthony
AFAIK qemu-kvm is the 'plain' qemu patched to have a more up-to-date and complete kvm support. At least it's what is on the great arch wiki [1] :p There are also other small tweaks, such as kvm support being enabled by default in qemu-kvm so you don't need to specify -enable-kvm, it will still fallback to using emulation is kvm support is not found or can't be used. [1] https://wiki.archlinux.org/index.php/QEMU#Using_the_Kernel-based_Virtual_Mac... -- Mauro Santos
participants (4)
-
C Anthony Risinger
-
Jelle van der Waa
-
Mauro Santos
-
Øyvind Heggstad