LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 10-04-2010, 10:40 AM   #31
Chuck56
Member
 
Registered: Dec 2006
Location: Colorado
Distribution: Slackware
Posts: 422

Rep: Reputation: 58

Squall90,

With all the package installing and uninstalling you've gone through, which version of kvm and kvm-amd are you running? Here's mine from a stock 13.1 x86_64 generic kernel.

Code:
root@slackware:# modinfo kvm
filename:       /lib/modules/2.6.33.4/kernel/arch/x86/kvm/kvm.ko
license:        GPL
author:         Qumranet
depends:        
vermagic:       2.6.33.4 SMP mod_unload 
parm:           oos_shadow:bool
parm:           ignore_msrs:bool
Code:
root@slackware:# modinfo kvm-amd
filename:       /lib/modules/2.6.33.4/kernel/arch/x86/kvm/kvm-amd.ko
license:        GPL
author:         Qumranet
depends:        kvm
vermagic:       2.6.33.4 SMP mod_unload 
parm:           npt:int
parm:           nested:int
 
Old 10-06-2010, 12:43 AM   #32
Ramurd
Member
 
Registered: Mar 2009
Location: Rotterdam, the Netherlands
Distribution: Slackwarelinux
Posts: 555

Rep: Reputation: 75
Just my 2 cents worth of comments:

If kvm-amd is not running, you probably don't have virtualization enabled in your BIOS. No need -normally- to update the BIOS, but you'll have to enter the BIOS to enable it. Normally this switched off. It's just a toggle on/off thing, so nothing major and you'll not notice anything else that would stop working or so.

Second: I noticed a stiff drop on performance recently due to using the wrong disk image type... I used qcow instead of qcow2; Which disk image type do you use? (please provide the output of
Code:
qemu-img info <disk image file>
Could you also provide the outcome of a short investigation on where the performance comes to a grinding halt? Is there much wait-io (which would point towards disk issues), is there enough memory allocated, or is your virtual machine swapping? Performance tools like sar and top will help much here.
 
Old 10-06-2010, 01:16 AM   #33
Chuck56
Member
 
Registered: Dec 2006
Location: Colorado
Distribution: Slackware
Posts: 422

Rep: Reputation: 58
What I was getting at with my last post regarding the modules was this. If the OP installed the KVM package (which was reported earlier in the thread) and did not remove the KVM package or did not run "depmod -a" after removing the KVM package then that could be part of the slowness problem. The OP could be running the older KVM modules and not the current kernel modules. There hasn't been a reply from the OP so it must not be an issue anymore.
 
Old 10-06-2010, 02:43 AM   #34
Squall90
Member
 
Registered: Oct 2009
Distribution: Currently several distros :S
Posts: 148

Original Poster
Rep: Reputation: 29
Quote:
Originally Posted by Ramurd View Post
If kvm-amd is not running, you probably don't have virtualization enabled in your BIOS. No need -normally- to update the BIOS, but you'll have to enter the BIOS to enable it. Normally this switched off. It's just a toggle on/off thing, so nothing major and you'll not notice anything else that would stop working or so.
kvm is running, otherwise qemu would print some errors. I looked for some virtualization options in the BIOS but I couldn't find any. (And, as I already said, I'll never ever update a BIOS if it's not 100% required.)

Quote:
Originally Posted by Ramurd View Post
Second: I noticed a stiff drop on performance recently due to using the wrong disk image type... I used qcow instead of qcow2; Which disk image type do you use? (please provide the output of
Code:
qemu-img info <disk image file>
I'm using raw format created with `dd'.

Quote:
Originally Posted by Ramurd View Post
Could you also provide the outcome of a short investigation on where the performance comes to a grinding halt? Is there much wait-io (which would point towards disk issues), is there enough memory allocated, or is your virtual machine swapping? Performance tools like sar and top will help much here.
For example, it stops while booting the Slackware DVD.
qemu-kvm.png

Quote:
Originally Posted by Chuck56 View Post
What I was getting at with my last post regarding the modules was this. If the OP installed the KVM package (which was reported earlier in the thread) and did not remove the KVM package or did not run "depmod -a" after removing the KVM package then that could be part of the slowness problem. The OP could be running the older KVM modules and not the current kernel modules. There hasn't been a reply from the OP so it must not be an issue anymore.
I didn't run "depmod -a" but now, after I run it, nothing changed.
 
Old 10-06-2010, 03:26 AM   #35
disturbed1
Senior Member
 
Registered: Mar 2005
Location: USA
Distribution: Slackware
Posts: 1,133
Blog Entries: 6

Rep: Reputation: 223Reputation: 223Reputation: 223
Use a different -cpu option. There's a bug in qemu/kvm and AMD CPUs.

qemu-system-x86_64 -cpu core2duo $YOUR-OTHER-OPTIONS
 
1 members found this post helpful.
Old 10-06-2010, 11:57 AM   #36
Squall90
Member
 
Registered: Oct 2009
Distribution: Currently several distros :S
Posts: 148

Original Poster
Rep: Reputation: 29
If I do not start kvm-amd module qemu works fine -- not fast, but it works. If I start the module, I only come this far: Attachment 4782
 
Old 10-06-2010, 12:07 PM   #37
Chuck56
Member
 
Registered: Dec 2006
Location: Colorado
Distribution: Slackware
Posts: 422

Rep: Reputation: 58
Quote:
Originally Posted by Squall90 View Post
If I do not start kvm-amd module qemu works fine -- not fast, but it works. If I start the module, I only come this far: Attachment 4782
Makes me think that there is a mismatch between the kvm modules and the userspace programs. When you checked the kvm modules using the modinfo command did the output match what I listed earlier? I'm wondering if you have an older batch of modules that don't work well with the newer userspace tools.
 
Old 10-06-2010, 12:29 PM   #38
Squall90
Member
 
Registered: Oct 2009
Distribution: Currently several distros :S
Posts: 148

Original Poster
Rep: Reputation: 29
Quote:
root@tux:/home/christian# modinfo kvm
filename: /lib/modules/2.6.35.4-smp/kernel/arch/x86/kvm/kvm.ko
license: GPL
author: Qumranet
depends:
vermagic: 2.6.35.4-smp SMP mod_unload K8
parm: oos_shadow:bool
parm: ignore_msrs:bool
root@tux:/home/christian# modinfo kvm-amd
filename: /lib/modules/2.6.35.4-smp/kernel/arch/x86/kvm/kvm-amd.ko
license: GPL
author: Qumranet
depends: kvm
vermagic: 2.6.35.4-smp SMP mod_unload K8
parm: npt:int
parm: nested:int
This kernel is almost a standard huge-smp kernel, just newer and I deactivated some Intel stuff -- I only need snd_hda_intel.
 
Old 10-06-2010, 12:34 PM   #39
Chuck56
Member
 
Registered: Dec 2006
Location: Colorado
Distribution: Slackware
Posts: 422

Rep: Reputation: 58
Quote:
Originally Posted by Squall90 View Post
This kernel is almost a standard huge-smp kernel, just newer and I deactivated some Intel stuff -- I only need snd_hda_intel.
Have you tried to run with a generic kernel and an initrd? Running a recompiled huge kernel may not be helping the situation. At this point I'm out of ideas.
 
Old 10-06-2010, 04:20 PM   #40
Squall90
Member
 
Registered: Oct 2009
Distribution: Currently several distros :S
Posts: 148

Original Poster
Rep: Reputation: 29
Quote:
Originally Posted by Chuck56 View Post
Have you tried to run with a generic kernel and an initrd? Running a recompiled huge kernel may not be helping the situation. At this point I'm out of ideas.
It is not re-compiled. I downloaded the current version of the kernel from kernel.org and then I run "make oldconfig" with the standard huge-smp config.

However, I'll try the generic kernel later ~ now I'm about to go to bed.

Do I have to regard something while building the initrd except for the drivers for my partitions?
 
Old 10-06-2010, 04:45 PM   #41
Chuck56
Member
 
Registered: Dec 2006
Location: Colorado
Distribution: Slackware
Posts: 422

Rep: Reputation: 58
Quote:
Originally Posted by Squall90 View Post
Do I have to regard something while building the initrd except for the drivers for my partitions?
Not for kvm but you know your setup best. I usually just run and copy the output from...
Code:
/usr/share/mkinitrd/mkinitrd_command_generator.sh
You have to run lilo afterward but I think it reminds you.
 
Old 10-06-2010, 07:13 PM   #42
Ramurd
Member
 
Registered: Mar 2009
Location: Rotterdam, the Netherlands
Distribution: Slackwarelinux
Posts: 555

Rep: Reputation: 75
Raw images should work good, used them in the past, but went for the qcow2 format. Matter of taste kind of stuff

It amazes me that your VM comes to a grinding halt after loading the kernel but before the boot scripts are ran;

If you started your VM like this (with or without the running module):
Code:
qemu-system-x86_64 -monitor stdio -vga vmware -cpu qemu64 -soundhw all -m 2048 -localtime -drive file=./Qemu/slackware13.1.img,if=ide -cdrom ./Downloads/slackware-13.1-install-dvd.iso -name "virtual_slack" -enable-kvm
NB: I allocated a different cpu, vga card and memory is exactly 2G instead of 1 MB less (could this cause an issue?), gave the machine a name and requested to use kvm stuff. in fact, I've just been a bit more precise in the definition of the virtual machine

Does this give a different performance?
If it does: determining which parameter makes the difference will be interesting; try to tweak above command line removing / altering parameters according to the command line you used before, one parameter at a time.

If it doesn't, look at the host: any stress to determine there? (sar / top for memory issues, io waits etc)

Hope we get the solution.
 
Old 10-06-2010, 10:23 PM   #43
the3dfxdude
Member
 
Registered: May 2007
Posts: 332

Rep: Reputation: 100Reputation: 100
Quote:
Originally Posted by Squall90 View Post
No, it's the only message.
I traced through the qemu-kvm code, and found there are only two possibilities that can cause that exact output. 1) There is an error with an ioctl for KVM_GET_MSR_INDEX_LIST or 2) setting up irq routing. If you could trace the code, you can find an exact answer to your problem to go on if you talk to the kvm people.

I would definitely try to make sure your userspace is set up correctly, and also that you did not accidentally use the wrong kvm headers.
 
Old 11-14-2010, 11:51 AM   #44
Squall90
Member
 
Registered: Oct 2009
Distribution: Currently several distros :S
Posts: 148

Original Poster
Rep: Reputation: 29
Hmm.. somehow, the standard 13.1 huge smp kernel works. I mean, kvm seam to work with it.
 
  


Reply

Tags
kvm, slackbuilds


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Slackbuilds - Net-SSLay building problem hua Slackware 4 08-01-2010 06:44 AM
[SOLVED] Problem building from slackbuilds ~sHyLoCk~ Slackware 14 05-18-2010 02:48 PM
Building slackbuilds.org packages with gcc 4.4.2 ponce Slackware 1 11-05-2009 12:07 PM
building kdebluetooth from Slackbuilds on Slackware64-current gtludwig Slackware 5 06-27-2009 06:59 PM
KVM-85 and using SlackBuilds kvm (83) script Chuck56 Slackware 2 04-22-2009 02:24 PM


All times are GMT -5. The time now is 12:34 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration