qemu/kvm, virt-manager (poor performance) and aqemu (many segmentation faults)
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
qemu/kvm, virt-manager (poor performance) and aqemu (many segmentation faults)
Hi,
Until now I used VirtualBox to virtualize Windows and other systems on my Slackware64 box. After upgrading to 13.1 I decided to give kvm a try.
I have a few questions regarding virtualization with qemu-kvm.
1)
In this thread, http://www.linuxquestions.org/questi...1-64-a-814431/, I read that the virtio module is used by the guest.
Does this mean that I don't have to load this module on the host system, but only in a Linux guest?
2)
Is the kqemu acceleration module only for use with the "normal" qemu or is it also useful for virtualization with qemu-kvm?
Should I build and load this too?
3)
Actually I have installed qemu-kvm and virt-manager with all it's dependencies from slackbuilds.org. I created the kvm and libvirt group and added my user to the groups. Then I loaded the modules kvm, kvm-intel, virtio and started libvirtd.
When I started virt-manager I got this warning "warning : qemudStartup:1099 : Unable to create cgroup for driver: No such device or address".
Is it a problem or can I ignore it?
4)
Then I created my first virtual machine, in which I just bootet slax from a local iso file.
But the performance was very poor. It took really long to boot and even when the system was up it was very slow.
Any idea what's going wrong here?
5)
I also gave aqemu a try.
It's a good GUI for kvm in my eyes (similar to VirtualBox) and would perfectly fit my needs, because I don't need to have remote access to a virtual machine like it's possible with virt-manager.
I built the version 0.7.3 with a self written build-script, without any problems.
And if I get to the point where I can start a virtual machine without getting a segmentation fault before (which kills aqemu), the performance of booting slax again was really good, also if compared with VirtualBox.
Does anyone know how to get rid of the many segmentation faults?
I also tried the binaries, which also were available at the projects sourceforge site, but also got segmentation faults.
Are they architecture dependent? Would it help to make my system multilib and try to compile and run it in 32 bit mode?
6)
I don't understand the different behaviour regarding the performance of aqemu and virt-manager, because I thought they are both just a GUI for qemu-kvm and the virtualization resources would be provided by qemu-kvm. Therefore I think that there is something wrong with the installation or configuration of virt-manager, but I have no idea what it could be.
In the end, I think, if I would get aqemu running smoothly, it would be the tool of my choice.
Therefore I think, I will give the development snapshot of aqemu 0.8 a try. Hopefully this will help to get rid of at least some of the segmentation faults :-)
I actually grabbed the source of the development version 0.8alpha from the git repository and built a package.
Now the segmentation faults are gone so far. There are still two error messages indeed, but you can at least get rid of these, with copying the needed data (icon set and templates) in place.
So, one will notice that it's still a development release, but now much more stable, at least for me :-)
1)
In this thread, http://www.linuxquestions.org/questi...1-64-a-814431/, I read that the virtio module is used by the guest.
Does this mean that I don't have to load this module on the host system, but only in a Linux guest?
That's right. Host system doesn't need virtio modules.
Quote:
Originally Posted by integrale16
2)
Is the kqemu acceleration module only for use with the "normal" qemu or is it also useful for virtualization with qemu-kvm?
Should I build and load this too?
With kvm module you don't need kqemu. Kqemu is only used on computer without virtualization on processor.
Quote:
Originally Posted by integrale16
3)
Actually I have installed qemu-kvm and virt-manager with all it's dependencies from slackbuilds.org. I created the kvm and libvirt group and added my user to the groups. Then I loaded the modules kvm, kvm-intel, virtio and started libvirtd.
When I started virt-manager I got this warning "warning : qemudStartup:1099 : Unable to create cgroup for driver: No such device or address".
Is it a problem or can I ignore it?
I don't know because I use only qemu-kvm. Now you can disable virtio on your host system.
Quote:
Originally Posted by integrale16
4)
Then I created my first virtual machine, in which I just bootet slax from a local iso file.
But the performance was very poor. It took really long to boot and even when the system was up it was very slow.
Any idea what's going wrong here?
Are you sure virtualization is enable in your bios ?
I have a Core 2 Duo T7200 and procinfo shows me the vmx flag.
And the second thing is, that the performance with aqemu is okay, compared with Virtualbox.
Boot time of Slax with VirtualBox is something about 85 seconds and with aqemu about 55 seconds.
And as I wrote, I thought that virt-manager and aqemu are just GUIs and the virtualization is done by qemu-kvm, and therefore I wouldn't have expected a performance difference, especially not so extremely.
I have found the same faults with points 3 and 4 that you made, they make the use of virt-manager unsustainable in my opinion. You are correct that it is qemu-kvm that does the work and it is relatively easy to run a virtual machine from the command line. However it is often easier just to point and click and personally I like the option to do both. So it would be nice if the GUI managers performance was a bit better.
I have the same fault with point 3 as you have, but I installed "Linux Mint" as guest and it boots in 15s !!
I have never experienced anything that fast before...the only thing (without testing to much) is that the mouse is a little unresponsive.
OK just created an image and installation, from the command line, of SalixOS (32-bit) on my Slackware64-13.1 (multi-lib) system. I also ran it from the command line and it runs at near native speeds.
The version installed and run by Virtual Machine Manager doesn't even boot-up.
From this I would deduce that kvm-qemu has compiled and installed properly but virt-manager et al have either not compiled properly or are configured incorrectly.
As I am only going to use this on rare occasions I think I will have a look at aqemu.
As I wrote above, the development branch of aqemu performs at least better than VirtualBox.
I think I will stick with aqemu for now to play around with it and follow the development branch as far as a release is stable enough for me.
But would still be interested, what could be wrong with virt-manager (on Slackware64 13.1), that it performs that bad (on my system).
Maybe you are right and it's a thing with live-cd in virt-manager, but in aqemu the performance is okay.
The next thing is, that aqemu has no additional dependencies in contrast to virt-manager. This is also a plus for aqemu in my eyes.
I tried Aqemo, cant get any "picture" in display-tab, but when slax has booted I can see it if I view "Full Screen"...and then it runs OK.
I need same help with the "command-line", the man-page is b_i_g and not so easy to understand. I found this... http://www.askarali.org/qemu_howto.html
..but when I tried to start (I created salix.img)..
Code:
bash-4.1# qemu -hda salix.img -cdrom /home/spiken/Download/salix-13.1.iso -boot d
No protocol specified
No protocol specified
qemu: hardware error: register_ioport_write: invalid opaque
..any help is much appreciated.
From "samac"..
Quote:
virt-manager et al have either not compiled properly or are configured incorrectly.
I think so too, I installed Fedora Core and there "Slax" works OK in Fedoras's "Virt-manager"
At last, is it correct that I should only have "qemu-kvm" (and not "qemu") installed when I use kvm (kvm, kvm-intel modules)?
qemu-system-x86_64 is for KVM, qemu is full virtualization, and is slow.
Double check the kvm modules are loaded. Should have kvm and kvm-$CPU. Also check that permissions are correct. If you set up qemu-kvm correctly with a udev rule, and added your self to the kvm group, everything should be good to go.
Code:
lsmod | grep kvm
ls -l /dev/kvm
Then launch qemu-system-x86_64. I've included some extra options. Spend some trial and error time with the man page, kvm wiki, and terminal. It's not that hard once you've used it a few times
The -usbdevice tablet helps with mouse syncing on some systems.
Instead of using -sdl, which launches in it's own application window, I like to use vnc. Replace -sdl with -vnc :1. Then you can launch vncviewer in another terminal tab.
If you have an AMD CPU, using -cpu host,phenom,qemu64, or kvm64 will cause a kernel oops in some cases. You'll have to use -cpu core2duo.
I see that you defined -hda as salix.img. Make sure the image actually exists and is correct. If you wanted to create a 20G raw image named salix.img, here's the command for that.
Code:
qemu-img create -f raw salix.img 20G
Using qemu-kvm directly from the command line means you only have to manually track, update, build, use, troubleshoot and install a single package. Tightvnc is in extra/. The KVM modules have been included in the kernel for some time now.
Personally I find qemu-kvm slightly faster than VMware when it comes to hard drive throughput. It's what I run my build boxes on. I need to build packages for P3's, AMD x86_64, and Intel Core2Duo's. KVM allows me to specify cpuinfo, and optimize packages for each system.
VMware on the other hand, has a fancy easy to use GUI, better graphics support, and simple to configure advanced networking options.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.