I don't recompile the host kernel to use virtio drives with the guests. I use the generic kernel on the host and guests. I get virtio working using a roundabout process that installs the initrd on the guest with the virtio_pci and virtio_blk drivers. Roundabout is a kind description, it's a pain in the butt and I've screwed it up more than a few times.

I was talking about the guest, not the host. The kernel used by 13.1 and -current installer needs to be recompiled because virtio-blk isn't enabled by default for whatever reason.

tbh i prefer the roudabout process over customizing the installer kernel, after all i don't deal with installations very often because I just make a snapshot after the installation per se and if i need a new box i just copy the disk image, revert to the "post-inst" snapshot and carry on.

Hmm... If I start qemu-system-x86_64 without a running kvm-amd daemon it prints But even if kvm-amd is running qemu is still veeeeeeeery slow. Probably my mainboard doesn't support it as mentioned before? I looked in the BIOS configuration but I couldn't find anything about virtualization.
I have an Asus M4N75TD mainboard.

What I'm saying is that you never need to recompile a host or guest kernel to get virtio_blk working. In a nutshell...

Phase 1:
standard install of guest generic kernel using /dev/sd# drives, change fstab from /dev/sda# to /dev/vda#, do mkinitrd using /dev/sda# drives and add the virtio_pci and virtio_blk drivers, run lilo,

Phase 2:
reboot but add boot=/dev/vda root/dev/vda# at the lilo prompt (use 5 second delay option), make many changes to lilo.conf (I'll list if interested), redo mkinitrd using /dev/vda# drives and add again virto_pci and virtio_blk drivers, run lilo

You are good to go unless you screw it up like I do regularly!

kvm-amd is a module, not a daemon. You definitely need to load kvm-amd before launching qemu-system-x86_64 otherwise it falls back to super slow qemu only mode.

Sure you can do a lot of stuff to work around the kernel compilation - i do it myself, pretty much like you described - but my point was that using a stock kernel won't work as in "just install and use it, like an ide or scsi disk".

Of course, you're right. I was tired while I was writing this post. I meant module.

Have you added your user to the 'kvm' group? You need to be a member of the said group to access /dev/kvm and thus use the kvm capabilities.

The name 'kvm' may be different in your setup, it is the group you listed in $KVMGROUP when you ran the slackbuild. If you have not created the 'kvm' group nor set $KVMGROUP to anything different, create it and add your user to it:

The GID 221 is suggested by the UID/GID list maintained by slackbuilds.org [1].


[1] - http://slackbuilds.org/uid_gid.txt

Yep, I'm also in the group.

Are you loading the virtualbox modules? Can they conflict with kvm?

Nope, I uninstalled VirtualBox. Only the group remains.

Are there any messages prior to this? Or is it the only message?

No, it's the only message.

Does device /dev/kvm exist?
if not do

/sbin/mknod /dev/kvm c 10
chown root.kvm /dev/kvm

this is a one time creation. you should use udev to create the device on each reboot
ala
KERNEL=="kvm", GROUP="kvm", MODE="0660"
this should be in /lib/udev/rules.d

john

Jep, it exists...