(Add link to testsuite git repo) |
m (→How To Test: Formatting) |
||
| Line 29: | Line 29: | ||
== How To Test == | == How To Test == | ||
There are quite a few ways to test the functionality: | There are quite a few ways to test the functionality: | ||
* Spawn a virtioconsole with new guest kernel and qemu images. Work on the console. | |||
* Spawn multiple virtioconsoles. | |||
* Transfer files from the host to the guest (and vice-versa) over virtio-serial ports and compare sha1sums of the files on the source and destination | |||
* Try all of the above at the same time | |||
* Try the above with different guest smp options | |||
* Try the testsuite at the link below for exercising various open/read/write/poll paths that test for various options | |||
Git repository for testsuite: | Git repository for testsuite: | ||
| Line 42: | Line 42: | ||
When starting qemu or kvm guests from the command line, add something like this: | When starting qemu or kvm guests from the command line, add something like this: | ||
<code> | |||
-device virtio-serial-pci -chardev socket,path=/tmp/foo,id=foo -device virtserialport,chardev=foo,name=org.fedoraproject.port.0 | -device virtio-serial-pci -chardev socket,path=/tmp/foo,id=foo -device virtserialport,chardev=foo,name=org.fedoraproject.port.0 | ||
</code> | |||
This will create a device and expose one serial port to the guest. The guest kernel should load the virtio_console.ko module and expose a /dev/vcon1 port to guest userspace app developers. A sysfs attribute is placed in <code>/sys/class/virtio-console/vcon1/name</code> that contains the text "org.fedoraproject.port.0" | |||
This will create a device and expose one serial port to the guest. The guest kernel should load the virtio_console.ko module and expose a /dev/vcon1 port to guest userspace app developers. A sysfs attribute is placed in /sys/class/virtio-console/vcon1/name that contains the text "org.fedoraproject.port.0" | |||
Data written into host's /tmp/foo (via a utility like socat) will then be relayed to the guest and a guest app should be able to read the data from /dev/vcon1. | Data written into host's /tmp/foo (via a utility like socat) will then be relayed to the guest and a guest app should be able to read the data from /dev/vcon1. | ||
Revision as of 10:03, 14 October 2009
Virtio-Serial
Summary
This feature adds a virtio-serial device to guests running on top of qemu and kvm. It exposes multiple ports to the guest in the form of simple char devices for simple IO between the guest and host userspaces.
Owner
- Name: Amit Shah
- email: amit.shah@redhat.com
Current status
- Targeted release: Fedora 13
- Last updated: 2009-08-04
- Percentage of completion: 70%
Detailed Description
Also known as 'vmchannel', a transport mechanism is needed for communication between the host userspace and guest userspace for achieving things like making clipboard copy/paste work seamlessly across the host and guest, locking the guest screen in case the vnc session to the guest is closed and so on. This can be used in offline cases as well, for example with libguestfs to probe which file systems the guest uses, the apps installed, etc.
Virtio-serial is just the transport protocol that will enable such applications to be written. It has two parts: (a) device emulation in qemu that presents a virtio-pci device to the guest and (b) a guest driver that presents a char device interface to userspace applications.
Benefit to Fedora
Some benefits include:
- a communication channel between the guest and the host even when guest networking is disabled
- applications can be written on top of the transport to achieve better guest-host cooperation, eg., clipboard copy/paste support between the host and the guest
- libguestfs currently uses a low-performing vmchannel interface. Updating libguestfs to use this interface will achieve better speeds.
Scope
Changes are required in QEMU and Linux. A few udev rules will have to be added to dynamically create ports for the device.
How To Test
There are quite a few ways to test the functionality:
- Spawn a virtioconsole with new guest kernel and qemu images. Work on the console.
- Spawn multiple virtioconsoles.
- Transfer files from the host to the guest (and vice-versa) over virtio-serial ports and compare sha1sums of the files on the source and destination
- Try all of the above at the same time
- Try the above with different guest smp options
- Try the testsuite at the link below for exercising various open/read/write/poll paths that test for various options
Git repository for testsuite:
http://fedorapeople.org/gitweb?p=amitshah/public_git/test-virtserial.git
When starting qemu or kvm guests from the command line, add something like this:
-device virtio-serial-pci -chardev socket,path=/tmp/foo,id=foo -device virtserialport,chardev=foo,name=org.fedoraproject.port.0
This will create a device and expose one serial port to the guest. The guest kernel should load the virtio_console.ko module and expose a /dev/vcon1 port to guest userspace app developers. A sysfs attribute is placed in /sys/class/virtio-console/vcon1/name that contains the text "org.fedoraproject.port.0"
Data written into host's /tmp/foo (via a utility like socat) will then be relayed to the guest and a guest app should be able to read the data from /dev/vcon1.
/dev/vcon0 is reserved for the first virtio console.
User Experience
Virtio-serial is just the transport and by itself won't be user-visible. Applications written on top of virtio-serial to communicate data between the host and guest OSes will bring user-visible changes.
Dependencies
This feature depends on acceptance of the patches by the QEMU and Linux kernel communities.
Contingency Plan
QEMU currently contains an alternative implementation of vmchannel using userland networking which is slower but similar in feature set. Continue using that interface in case virtio-serial is not ready.
Documentation
http://www.linux-kvm.org/page/VMchannel_Requirements
Release Notes
- New virtio-serial pci device exposed to guests running on top of qemu and kvm. A single device exposes multiple serial ports for simple guest <-> host communication.