| | 270 | == Using Virtio devices == |
| | 271 | Instead of completely emulating existing hardware devices (network interface, block device, GPU, ...), Qemu allows to present virtual devices to the guest, which directly access host's hardware. This allows to get near bare metal performance in virtual machines. Those devices are known as ''virtio'' devices, and the kernel has powerful drivers for them. |
| | 272 | |
| | 273 | === Virtio block device === |
| | 274 | Qemu command line options are numerous and redundant. There are often several ways to do the same thing. I'll describe "stacking" block devices, and using this stack as a device on the guest. For more information, have a look at the qemu documentation. Usually, a whole disk on the guest is actually only a file on the host. Suppose a qcow2 image has been created with qemu-img as /path/to/image.qcow2. Then the first level of the stack is given by: |
| | 275 | {{{ |
| | 276 | -blockdev driver=file,node-name=img1,filename=/path/to/image.qcow2 |
| | 277 | }}} |
| | 278 | It just says that you want to access a file name ''/path/to/image.qcow2'', and creates a handle (the "node-name") that the second level of the stack can use. The second level is given by: |
| | 279 | {{{ |
| | 280 | -blockdev driver=qcow2,file=img1,node-name=disk1 |
| | 281 | }}} |
| | 282 | Now, it says that the file will be accessed as a qcow2 img, and provides a handle to the next level. The stack as a whole describes a disk drive, that we can use as a device on the guest. This device is defined as ''virtio-blk'': |
| | 283 | {{{ |
| | 284 | -device virtio-blk,drive=disk1 |
| | 285 | }}} |
| | 286 | Now that we have the machine we need to enable the appropriate options in the guest kernel (TODO). |
| | 287 | |
