Problems with qemu
- Login o registrati per inviare commenti
Greetings ladies and gentlemen, I'm trying to avoid Virtualbox because non-free compilers is now required. Well, I knew that Oracle was not trustworthy.
Now I'm trying to use qemu for my emulation but the results are not as good as I think it would. Slow performance even with the raw format. Specially when I run ReactOS (I need Windows for using some programs in the university and I want to try to stay as much "free as in freedom" as I can).
Please, do you know if it is possible to improve qemu's performance?
The command I'm running to emulate ReactOS is (with the help of aqemu):
/usr/bin/qemu -monitor stdio -smp 2 -cpu coreduo -soundhw es1370 -M pc -k es -enable-kvm -m 2005 -localtime -cdrom /home/user/VirtualMachines/ReactOS-BootCD.iso -hda realization -boot once=d,menu=off -net none -alt-grab -name "reactos" -net user -net nic,model=ne2k_pci
The "-net nic,model=ne2k_pci" and "-net user" options is something I added because it's the only way I've found to activate ReactOS internet connection.
Does your hardware support virtualization, i.e. does the following command give you output?
grep -E 'svm|vmx' /proc/cpuinfo
If yes, you might get better results with http://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine
Yes, the command gave me output:
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm dtherm tpr_shadow vnmi flexpriority
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm dtherm tpr_shadow vnmi flexpriority
And I've tried to use kvm with the command:
/usr/bin/kvm -monitor stdio -smp 2 -cpu coreduo -soundhw es1370 -M pc -k es -enable-kvm -m 2005 -localtime -cdrom /home/user/VirtualMachines/ReactOS-BootCD.iso -hda realization -boot once=d,menu=off -net none -alt-grab -name "reactos" -net user -net nic,model=ne2k_pci
The result is practically the same, when I try to use internet on ReactOS In the virtual machine, the system go much slower.
I've tried Trisquel, works better but not as much.
OSes run much better on Virtualbox... sadly.
Please, more suggestions to improve KVM or qemu emulation.
I suspect that the user mode network causes the slowdowns. Usually KVM and VBox are on par.
From: http://wiki.qemu.org/Documentation/Networking
User Networking (SLIRP)
This is the default networking backend and generally is the easiest to use. It does not require root / Administrator privileges. It has the following limitations:
- there is a lot of overhead so the performance is poor
- ICMP traffic does not work (so you cannot use ping within a guest)
the guest is not directly accessible from the host or the external network
It is a better option to use a network bridge on your physcial NIC and TAP devices for each VM.
Oh yeah, and the driver / NIC model you use for the VM is also important.
VirtIO works with best performance but might not be supported by any guest OS.
I've tried to run Trisquel on qemu with the "-net none" option in order to test if it was the internet that was causing all the troubles but the OS run by qemu/KVM is still very slow and I don't know why. On youtube I see people running VM on qemu very well.
Check your BIOS setup, perhaps the virtualization support is turned off?
Honestly slow performance is not normal for KVM running with hardware virtualisation. That is really strange. On my AMD E350 (2x1.6GHz) with 8 GB RAM I can run Debian or Trisquel inside a VM and it feels like a physical system. Of course only until you do something CPU or I/O intense :)
I've looked up the virtualization option in the Bios, and then checked if the service related with kvm could start without problems and all seems ok.
I don't know what is happening, ¿could you tell me the parameters you put on the comand line to launch the image?
Oh, nothing really fancy...
Mostly something like:
qemu -m 1024 -cdrom /path/to/Trisquel.iso.iso -boot d
I rarely use anything special here....
If qemu behaves REALLY slow this strongly indicates that KVM is not working. You might check out the ArchWiki on that:
https://wiki.archlinux.org/index.php/KVM
https://wiki.archlinux.org/index.php/Qemu#Enabling_KVM
Unfortunately my two Trisquel systems are not new enough to support hardware virtualisation. My main box runs Xubuntu 12.04. I am not shure how representative any commands here compared to Trisquel.
Sorry....
Don't worry, you are helping me a lot.
this is what I will do:
I will be trying to change the network mode and see if it works.
Then, I will investigate what could be happening.
This will take me a while, and if I find the solution, i will be sharing the solution with you.
- Login o registrati per inviare commenti