This project is about porting virtio drivers for DragonFlyBSD from NetBSD source code.

NetBSD_code/: original code, under BSD license.

This project is forked from the work of Pratyush Kshirsagar and Tim Bisson.
See on gitorious: https://gitorious.org/virtio-drivers/virtio-drivers/trees/master


blk/: the block device driver
net/: the net device driver - being tested, it currently fails when executing a vioif_start, because the flag NO_NOTIFY is set in QEMU when we enqueue & commit the packets for transmission.
balloon/: the memory ballooning device driver - being tested, the driver receives no requests when we use the QEMU monitor console to ask for some amount of memory.



Documentation

Using virtio paravirtualized drivers for QEMU/KVM with DragonFly BSD guest machines

Virtio is supported by QEMU and KVM.
You'll find information on the official web page of KVM (http://www.linux-kvm.org/page/Virtio) about configuring the host machine to use virtio devices drivers. Network, block and balloon (memory ballooning) devices are supported for KVM.
Linux kernel supports virtio devices in KVM since kernel 2.6.25.


Here is an example of a configuration with kvm to start your guest machine:
kvm -cpu Nehalem -k fr -m 1024 -drive file=/home/arroway/kvm/disk-virtio1.img,if=virtio,format=qcow2 -hda ~arroway/kvm/disk.img -hdb ~arroway/kvm/disk2.img -device rtl8139,netdev=mynet0 -netdev type=user,id=mynet0,net=192.168.42.0/24,restrict=n,host=192.168.42.1,hostfwd=::2200-192.168.42.15:22 -device virtio-net-pci,netdev=virtio,mac=52:54:42:42:42:42 -netdev type=user,id=virtio,net=192.168.43.0/24,restrict=n,host=192.168.43.1 -balloon virtio -nographic

You can specified the cpu which is used by the guest machine with "-cpu".
You can specified the keyboard language with "-k".
You can choose the amount of RAM used with "-m".

Then, options about the block devices and the network devices follow.
There are three disks: the first one is a virtio block device (disk-virtio1.img), the others are classic block devices (disk.img, disk2.img).
There are two network cards: the first one is of type rtl8139, the second one is a virtio device.

"-nographic" option is used if you don't want to use SDL (e.g. if you have no graphic interfaces). Open a SSH session to connect on the machine.
You can also use "-curses" in a non-graphic mode, you'll don't have to open a second tab, but you won't be able to scroll up and down in your guest terminal window.

See man page for qemu for more detailed commands: http://linux.die.net/man/1/qemu
and for more information about qemu http://wiki.qemu.org/



To check on your system if virtio pci devices are present or not, do:

# pciconf -lv
[...]
virtiobus0@pci0:0:5:0:    class=0x010000 card=0x00021af4 chip=0x10011af4 rev=0x00 hdr=0x00
    vendor     = 'Red Hat, Inc'
    device     = 'Virtio block device'
    class      = mass storage
    subclass   = SCSI


At the moment, the drivers have to be manually loaded in the kernel of the guest machine, so be sure to boot on a non-virtio disk.

*Creating a disk image*
# qemu-img create -f qcow2 <image_name> <size>

*Install the guest OS from a ISO image*
#qemu-kvm -hda <image_name> -m 512 -cdrom <path to the iso image> -boot -vga std

The drivers have to be in src/sys/dev/virtio

The virtio driver (virtio.ko) has to be loaded first. It is the parent device. It creates one child device for network, block or balloon devices. Then the appropriate device driver will have to be loaded (virtio-blk.ko, virtio-net.ko or virtio-mb.ko).

e.g. :
*loading the virtio device driver*
# cd virtio
# make
# kldload -v ./virtio.ko

*loading the virtio net device driver*
# cd net
# make
# kldload -v ./virtio-net.ko




* Network device driver

Configuration in KVM.
The "-net" option in qemu is deprecated. Use "netdev" or "tap" instead. http://wiki.qemu.org/Documentation/Networking

-device virtio-net-pci,netdev=virtio,mac=52:54:*:*:*:* -netdev type=user,id=virtio,...


* Block device driver

-drive file=/home/arroway/kvm/disk-virtio1.img,if=virtio,format=qcow2

Before loading the block device driver in DragonFly BSD, you'll have to format your block device (UFS or Hammer) and mount it:
# newfs -f -L disk-virtio /dev/vdb0s0
# mount /dev/vdb0s0 my-mount-point

or with Hammer FS:

# newfs_hammer -f -L disk-virtio /dev/vdb0s0
# mount_hammer /dev/vdb0s0 my-mount-point

Just be careful that your Hammer partition is big enough, or it will create problems for r/w, unmount operations if the disk becomes full.


Then load the driver:
# cd virtio
# make
# kldload -v ./virtio.ko
# cd blk
# make
# kldload -v ./virtio-blk.ko

To unload the driver:
First unmount the block device, or it will freeze the session and you'll have to kill the machine.
# unmount my-mount-point
# cd virtio/blk
# kldunload -v ./virtio-blk.ko
# klduload -v ./virtio.ko


* Memory Ballooning

-balloon virtio

You can use memory ballooning to over-commit the memory resources of a guest operating system. The hypervisor may asks for some memory to the guest OS (i.e. to deflate its "balloon" of memory"). 

Interesting information there: http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaat/liaatbpballooning.htm


** Using the monitor console in QEMU

You can use the monitor console in qemu to get some information about the running guest machine.
You can access it by pressing CTRL + ALT + 2 from the guest VM. Te return back to QEMU from the monitor console, press CTRL + ALT + 1.

This may not be working in some cases. Here is what I did to have an access anyway. Add the following option on the command line to launch the VM:
-monitor tcp:port, server # where port is a big number, e.g.4444

It will wait a connection, so open a new tab in your terminal, or a new SSH session, and type:
# telnet localhost 4444
You have  now access to a QEMU monitor console. Just be careful, for closing the monitor console will kill the VM.

You can get information many information from the console, and in particular some about virtio balloon (wether it is enabled or not):
#info balloon

If the balloon device is enabled, you can request an amount of memory from the command line:
#balloon memory_in_MB





-------------


Notes 

* KVM and the OOM Killer

If your KVM host machine runs out of LOWMEM, even if it has enough RAM and swap memory left, the OOM Killer may begin to kill applications - such as the one running your virtual guests machines.


Dev

To see debug messages: start the virtual machine in a screen