Bug 684777

Summary: /dev/kvm not created when booting with systemd-20-1.fc15.x86_64; works with systemd-18-1.fc16.x86_64
Product: [Fedora] Fedora Reporter: Tom London <selinux>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: iarlyy, ipilcher, johannbg, jonathan, lpoetter, metherid, mschmidt, notting, plautrba, rtguille, rvokal, sven
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: initscripts-9.27-1.fc15 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-03-19 05:51:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tom London 2011-03-14 13:41:41 UTC
Description of problem:
[Not sure this is a systemd issue; please reassign if I got it wrong.]

I noticed that /dev/kvm was not being created when booting with systemd-20-1.fc15.x86_64.  Appears that /etc/sysconfig/modules/kvm.modules is not being run.

If I reinstall or update qemu-kvm package, /dev/kvm is created, but not on reboot.

If I downgrade to systemd-18-1.fc16.x86_64, /dev/kvm is again created on boot.

Version-Release number of selected component (if applicable):
systemd-20-1.fc15.x86_64

How reproducible:
Every boot

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Tom London 2011-03-14 13:43:23 UTC
I should have added that I'm running 'mostly rawhide':

Running

qemu-img-0.14.0-2.fc16.x86_64
qemu-kvm-tools-0.14.0-2.fc16.x86_64
qemu-system-x86-0.14.0-2.fc16.x86_64
qemu-debuginfo-0.14.0-2.fc16.x86_64
qemu-common-0.14.0-2.fc16.x86_64
qemu-kvm-0.14.0-2.fc16.x86_64

and

kernel-2.6.38-0.rc8.git0.1.fc15.x86_64

Comment 2 Michal Schmidt 2011-03-14 13:48:12 UTC
Probably will be fixed as soon as new initscripts are built with this upstream fix:

http://git.fedorahosted.org/git/?p=initscripts.git;a=commit;h=89032e9049921024fa65c292adb48bc8eba1e5a0

Comment 3 iarly selbir 2011-03-14 19:31:40 UTC
Can you confirm it for us Tom?

Thanks in advance.

--
Fedora Bugzappers Team Member

Comment 4 Tom London 2011-03-15 02:04:56 UTC
I manually updated the two files mentioned in http://git.fedorahosted.org/git/?p=initscripts.git;a=commit;h=89032e9049921024fa65c292adb48bc8eba1e5a0

I also updated systemd back to systemd-20-1.fc15.x86_64 and rebooted.

[tbl@tlondon ~]$ ls -l /dev/kvm
crw-rw-rw-+ 1 root kvm 10, 232 Mar 14 19:01 /dev/kvm
[tbl@tlondon ~]$ 

So, /dev/kvm is now being created again.

Thanks!

Comment 5 Lennart Poettering 2011-03-15 02:26:54 UTC
Hmm, there were plans to add module autoloading to the kernel based on CPU features. I wonder what happened to that...

Comment 6 Reartes Guillermo 2011-03-15 19:30:17 UTC
I am running F15 Alpha, updated a few hours ago.

# ls -l /dev/kvm
ls: cannot access /dev/kvm: No such file or directory

systemd.x86_64         20-1.fc15  @updates-testing
systemd-units.x86_64   20-1.fc15  @updates-testing

gpxe-roms-qemu.noarch   1.0.1-4.fc15     @fedora
qemu-common.x86_64      2:0.14.0-2.fc15  @fedora
qemu-img.x86_64         2:0.14.0-2.fc15  @fedora
qemu-kvm.x86_64         2:0.14.0-2.fc15  @fedora
qemu-system-x86.x86_64  2:0.14.0-2.fc15  @fedora

Virt-Manager says there was no kvm.


Executing by hand /etc/sysconfig/modules/kvm.modules
creates the device, virt-manager detects kvm.

But when creating a vm, the following error appears:
Error launching details: value is wrong type for this column

raceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 637, in _do_show_details
    details = self._get_details_dialog(uri, uuid)
  File "/usr/share/virt-manager/virtManager/engine.py", line 617, in _get_details_dialog
    obj = vmmDetails(con.get_vm(uuid), self)
  File "/usr/share/virt-manager/virtManager/details.py", line 444, in __init__
    self.refresh_vm_state()
  File "/usr/share/virt-manager/virtManager/details.py", line 1056, in refresh_vm_state
    self._refresh_runtime_pinning()
  File "/usr/share/virt-manager/virtManager/details.py", line 2054, in _refresh_runtime_pinning
    vcpu_model.append([vcpu, vcpucur, vcpupin])
TypeError: value is of wrong type for this column


so no kvm for now.
selinux is set to permissive prior to launching the vm (normally enforcing)

Comment 7 Ian Pilcher 2011-03-15 19:38:06 UTC
(In reply to comment #6)
> But when creating a vm, the following error appears:
> Error launching details: value is wrong type for this column
> 
> raceback (most recent call last):
>   File "/usr/share/virt-manager/virtManager/engine.py", line 637, in
> _do_show_details
>     details = self._get_details_dialog(uri, uuid)
>   File "/usr/share/virt-manager/virtManager/engine.py", line 617, in
> _get_details_dialog
>     obj = vmmDetails(con.get_vm(uuid), self)
>   File "/usr/share/virt-manager/virtManager/details.py", line 444, in __init__
>     self.refresh_vm_state()
>   File "/usr/share/virt-manager/virtManager/details.py", line 1056, in
> refresh_vm_state
>     self._refresh_runtime_pinning()
>   File "/usr/share/virt-manager/virtManager/details.py", line 2054, in
> _refresh_runtime_pinning
>     vcpu_model.append([vcpu, vcpucur, vcpupin])
> TypeError: value is of wrong type for this column

You're looking for bug #681249.

Comment 8 Fedora Update System 2011-03-18 19:12:57 UTC
initscripts-9.27-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/initscripts-9.27-1.fc15

Comment 9 Reartes Guillermo 2011-03-18 21:21:58 UTC
Updated to initscripts.x86_64  9.27-1.fc15 & reboot.
ok, /dev/kvm is created at boot.

kvm is correctly avaiable in new vm in libvirt, at least for me.

Comment 10 Fedora Update System 2011-03-19 05:51:48 UTC
initscripts-9.27-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.