Bug 512843

Summary: Configuration for kvm modules loading
Product: [Fedora] Fedora Reporter: Jean-Francois Saucier <jsaucier>
Component: kvmAssignee: Glauber Costa <gcosta>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 11CC: berrange, clalance, ehabkost, gcosta, markmc, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-08-07 11:00:48 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
kvm configuration file
none
kvm script to load modules none

Description Jean-Francois Saucier 2009-07-20 18:58:00 EDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1) Gecko/20090630 Fedora/3.5-1.fc11 Firefox/3.5

The kvm module load automatically at each boot after installation. I have found no easy way to disable this with configuration files.

The problem with this is if that you want to run something else for virtualization (like VirtualBox or Vmware for example), they cannot utilize the processor virtualization if kvm is loaded.

The fix I propose is to add a simple line at the start of /etc/sysconfig/modules/kvm.modules and a new config file at /etc/sysconfig/kvm. They are both attached with this bug.

Reproducible: Always

Steps to Reproduce:
1.Install kvm
2.reboot
3.See the module kvm loaded automatically
Actual Results:  
I see no way to configure this

Expected Results:  
Permit to override this with a configuration file
Comment 1 Jean-Francois Saucier 2009-07-20 18:58:37 EDT
Created attachment 354402 [details]
kvm configuration file
Comment 2 Jean-Francois Saucier 2009-07-20 18:59:08 EDT
Created attachment 354403 [details]
kvm script to load modules
Comment 3 Glauber Costa 2009-07-20 20:35:54 EDT
Although I'm sympathetic to your request, I don't see the need for creating another file just for that. 

what do you think about this:
kvm.modules:

KVM_ENABLE=1

if [ $KVM_ENABLE -eq 0 ]; then
  exit 0
fi

if [ $(grep -c vmx /proc/cpuinfo) -ne 0 ]; then 
    modprobe kvm-intel >/dev/null 2>&1
fi

if [ $(grep -c svm /proc/cpuinfo) -ne 0 ]; then 
    modprobe kvm-amd >/dev/null 2>&1
fi

I do understand that a configuration file provides a more well defined location for this, but besides this, there is really not to much to configure in kvm, and your case is a special one. This might change in the future, though...
Comment 4 Daniel Berrange 2009-07-21 06:10:32 EDT
IIRC, the latest upstream KVM modules have been changed to not grab the virtualization capability until a guest is actually started. So merely loading the modules should not cause problems.  As such I think it is not desirable adding this configuration parameter as a one off for F11. We'd be better to update the kernels to match latest upstream behaviour, which is more useful because it will 'just work(tm)' without requiring the user to know about magic config settings.
Comment 5 Jean-Francois Saucier 2009-07-21 10:23:12 EDT
If the new kvm module behave like Daniel said, it's ok with me, I have no problem with it. I don't mind the module being loaded if it don't grab the virtualization capability.

If not, I think the solution Glauber gave is good for this. Adding a configuration file like my previous solution may be a little bit overkill.

Thank you for your time.
Comment 6 Mark McLoughlin 2009-08-07 11:00:48 EDT
(In reply to comment #5)
> If the new kvm module behave like Daniel said, it's ok with me, I have no
> problem with it. I don't mind the module being loaded if it don't grab the
> virtualization capability.

Okay, I'll close this as WORKSFORME, then

An alternative workaround is just to remove the qemu-system-x86 package
Comment 7 Mark McLoughlin 2009-08-17 11:58:28 EDT
A simple way of supporting this is to use 'modprobe -b' in the kvm.modules script, see bug #517866

*** This bug has been marked as a duplicate of bug 517866 ***