VMchannel Requirements - Revision history

Amit: Update link to test-virtserial.git, remove TODO section - we don't need this anymore

2013-02-04T18:28:23Z

Update link to test-virtserial.git, remove TODO section - we don't need this anymore

← Older revision		Revision as of 14:28, 4 February 2013
Line 131:		Line 131:
	A repository containing test code is put up at		A repository containing test code is put up at

	http://fedorapeople.org/~~gitweb?p=~~amitshah/public_git/test-virtserial.git		http://fedorapeople.org/cgit/amitshah/public_git/test-virtserial.git/

	This repo contains manual as well as automated testsuites that can be run to verify the functionality. The test-virtserial.c file also documents the various options and the ways in which they can be tested.		This repo contains manual as well as automated testsuites that can be run to verify the functionality. The test-virtserial.c file also documents the various options and the ways in which they can be tested.
Line 140:		Line 140:
	== API ==		== API ==
	The [[virtio-serial API]] page has information on the API exposed by Linux as well as Windows guests for application programmers to use the channel.		The [[virtio-serial API]] page has information on the API exposed by Linux as well as Windows guests for application programmers to use the channel.

	~~<br />~~
	~~== TODO ==~~
	~~A few items from my TODO list. Please drop me a note at <amit.shah@redhat.com> if you're planning to pick something from here so that there's no duplication of work. Thanks!~~

	* Host device
	** Convert to VMState

Amit: Add a section on API

2010-09-02T10:23:33Z

Add a section on API

← Older revision		Revision as of 06:23, 2 September 2010
Line 136:		Line 136:

	See also the Fedora 13 Feature Page for more information: https://fedoraproject.org/wiki/Features/VirtioSerial#How_To_Test		See also the Fedora 13 Feature Page for more information: https://fedoraproject.org/wiki/Features/VirtioSerial#How_To_Test

			<br />
			== API ==
			The [[virtio-serial API]] page has information on the API exposed by Linux as well as Windows guests for application programmers to use the channel.

	<br />		<br />

LonHohberger at 14:20, 12 May 2010

2010-05-12T14:20:51Z

← Older revision		Revision as of 10:20, 12 May 2010
Line 68:		Line 68:
	*** [http://git.fedorahosted.org/git/?p=fence-agents.git;a=tree;f=fence/agents/xvm fence_xvm] -> tracks migrations, but requires multicast between guest/host; distributed key recommended but not required		*** [http://git.fedorahosted.org/git/?p=fence-agents.git;a=tree;f=fence/agents/xvm fence_xvm] -> tracks migrations, but requires multicast between guest/host; distributed key recommended but not required
	** Using VMChannel-Serial, the requirement of guest-host can be avoided		** Using VMChannel-Serial, the requirement of guest-host can be avoided
			*** [http://fence-virt.git.sourceforge.net fence-virt] has a plugin which uses serial VMchannel to tunnel through to the host.
	** Key distribution of any sort can be avoided, making this easier to configure than existing solutions		** Key distribution of any sort can be avoided, making this easier to configure than existing solutions

Amit: Remove module removal todo; update kernel release to 2.6.35

2010-04-28T05:48:19Z

Remove module removal todo; update kernel release to 2.6.35

← Older revision		Revision as of 01:48, 28 April 2010
Line 124:		Line 124:
	The code for the qemu device has been merged in qemu upstream sources on 20 Jan 2010, starting from commit 98b19252cf1bd97c54bc4613f3537c5ec0aae263. The feature will be available in the next major QEMU release after 0.12.		The code for the qemu device has been merged in qemu upstream sources on 20 Jan 2010, starting from commit 98b19252cf1bd97c54bc4613f3537c5ec0aae263. The feature will be available in the next major QEMU release after 0.12.

	The corresponding kernel driver will be available in the Linux kernel 2.6.34 release.		The corresponding kernel driver will be available in the Linux kernel 2.6.35 release.

	<br />		<br />
Line 139:		Line 139:
	== TODO ==		== TODO ==
	A few items from my TODO list. Please drop me a note at <amit.shah@redhat.com> if you're planning to pick something from here so that there's no duplication of work. Thanks!		A few items from my TODO list. Please drop me a note at <amit.shah@redhat.com> if you're planning to pick something from here so that there's no duplication of work. Thanks!
	* Guest kernel driver
	** Allow module removal

	* Host device		* Host device
	** Convert to VMState		** Convert to VMState

Amit: Add link to F13 test page

2010-02-16T04:33:31Z

Add link to F13 test page

← Older revision		Revision as of 00:33, 16 February 2010
Line 133:		Line 133:

	This repo contains manual as well as automated testsuites that can be run to verify the functionality. The test-virtserial.c file also documents the various options and the ways in which they can be tested.		This repo contains manual as well as automated testsuites that can be run to verify the functionality. The test-virtserial.c file also documents the various options and the ways in which they can be tested.

			See also the Fedora 13 Feature Page for more information: https://fedoraproject.org/wiki/Features/VirtioSerial#How_To_Test

	<br />		<br />

Amit: Add information about udev rule being in upstream release

2010-02-16T04:21:37Z

Add information about udev rule being in upstream release

← Older revision		Revision as of 00:21, 16 February 2010
Line 96:		Line 96:
	</pre>		</pre>

	A simple udev rule can create a symlink to the actual device from this name~~: eg~~, ~~create~~ a new file in <code>/etc/udev/rules.d</code>, eg, <code>90-virtio-ports</code>~~. Put~~ the following code in it:		A simple udev rule can create a symlink to the actual device from this name. The rule for creating these symlinks has been included in udev-151. If you have an older version of udev, you can do this locally by creating a new file in <code>/etc/udev/rules.d</code>, eg, <code>90-virtio-ports</code> and put the following code in it:

	<pre>		<pre>

Amit: Add 'code' section, remove 'bytes_limit' param

2010-01-21T06:31:35Z

Add 'code' section, remove 'bytes_limit' param

← Older revision		Revision as of 02:31, 21 January 2010
Line 77:		Line 77:
	-device virtio-serial \		-device virtio-serial \
	-device virtserialport,chardev=...,name=org.linux-kvm.port.0 \		-device virtserialport,chardev=...,name=org.linux-kvm.port.0 \
	-device virtserialport,chardev=...,name=org.linux-kvm.port.1~~,byte_limit=1048576~~		-device virtserialport,chardev=...,name=org.linux-kvm.port.1
	</pre>		</pre>

Line 88:		Line 88:

	The ports are assigned some properties:		The ports are assigned some properties:
	* byte_limit: This property specifies the max. number of bytes that can be cached before no more data is pushed out. This is to prevent OOM conditions from happening inside the host. The guest doesn't need this mechanism as the number of outstanding buffers are controlled by the host when it initializes the virtqueues.

	* name: This property puts the string in the guest's sysfs entries for it to be found by udev rules to create symlinks to the actual device. This is useful for guest applications discovering the ports of their interest. For example,		* name: This property puts the string in the guest's sysfs entries for it to be found by udev rules to create symlinks to the actual device. This is useful for guest applications discovering the ports of their interest. For example,

Line 121:		Line 119:

	Multiple console ports can be specified on the command line and they will be available as /dev/hvc0, /dev/hvc1...		Multiple console ports can be specified on the command line and they will be available as /dev/hvc0, /dev/hvc1...

			<br />
			== Code ==
			The code for the qemu device has been merged in qemu upstream sources on 20 Jan 2010, starting from commit 98b19252cf1bd97c54bc4613f3537c5ec0aae263. The feature will be available in the next major QEMU release after 0.12.

			The corresponding kernel driver will be available in the Linux kernel 2.6.34 release.

	<br />		<br />
Line 138:		Line 142:
	* Host device		* Host device
	** Convert to VMState		** Convert to VMState
	** Generic chardev infrastructure: During migration, make sure if the other endpoint didn't receive data, resend it

Amit: Drop 'cache_buffers', use 'virtio-serial' alias instead of 'virtio-serial-pci'

2010-01-14T11:47:12Z

Drop 'cache_buffers', use 'virtio-serial' alias instead of 'virtio-serial-pci'

← Older revision		Revision as of 07:47, 14 January 2010
Line 75:		Line 75:

	<pre>		<pre>
	-device virtio-serial~~-pci~~ \		-device virtio-serial \
	-device virtserialport,chardev=...,name=org.linux-kvm.port.0 \		-device virtserialport,chardev=...,name=org.linux-kvm.port.0 \
	-device virtserialport,chardev=...,name=org.linux-kvm.port.1~~,cache_buffers=0 \~~		-device virtserialport,chardev=...,name=org.linux-kvm.port.1,byte_limit=1048576
	~~-device virtserialport,chardev=...,name=org.linux-kvm.port.2~~,byte_limit=1048576
	</pre>		</pre>

	This creates ~~three~~ ports. The guest sees them as:		This creates two ports. The guest sees them as:

	<pre>		<pre>
	/dev/vport0p1		/dev/vport0p1
	/dev/vport0p2		/dev/vport0p2
	~~/dev/vport0p3~~
	</pre>		</pre>

	The ports are assigned some properties:		The ports are assigned some properties:
	* cache_buffers: default 1. This property specifies whether ports retain data received when the char device is closed on the guest or when the qemu chardev connection is closed on the host.

	* byte_limit: This property specifies the max. number of bytes that can be cached before no more data is pushed out. This is to prevent OOM conditions from happening inside the host. The guest doesn't need this mechanism as the number of outstanding buffers are controlled by the host when it initializes the virtqueues.		* byte_limit: This property specifies the max. number of bytes that can be cached before no more data is pushed out. This is to prevent OOM conditions from happening inside the host. The guest doesn't need this mechanism as the number of outstanding buffers are controlled by the host when it initializes the virtqueues.

Line 114:		Line 110:

	<pre>		<pre>
	-device virtio-serial~~-pci~~ \		-device virtio-serial \
	-device virtconsole,chardev=...,name=console.0		-device virtconsole,chardev=...,name=console.0
	</pre>		</pre>

Amit: Update for latest rev of patches: devices are now at /dev/vport0p1..

2009-12-23T06:12:16Z

Update for latest rev of patches: devices are now at /dev/vport0p1..

← Older revision		Revision as of 02:12, 23 December 2009
Line 84:		Line 84:

	<pre>		<pre>
	/dev/~~vcon1~~		/dev/vport0p1
	/dev/~~vcon2~~		/dev/vport0p2
	/dev/~~vcon3~~		/dev/vport0p3
	</pre>		</pre>

Line 92:		Line 92:
	* cache_buffers: default 1. This property specifies whether ports retain data received when the char device is closed on the guest or when the qemu chardev connection is closed on the host.		* cache_buffers: default 1. This property specifies whether ports retain data received when the char device is closed on the guest or when the qemu chardev connection is closed on the host.

	* byte_limit~~, guest_byte_limit~~: ~~These properties specify~~ the max. number of bytes that can be cached before no more data is pushed out. This is to prevent OOM conditions from happening inside the host or the ~~guest~~.		* byte_limit: This property specifies the max. number of bytes that can be cached before no more data is pushed out. This is to prevent OOM conditions from happening inside the host. The guest doesn't need this mechanism as the number of outstanding buffers are controlled by the host when it initializes the virtqueues.

	* name: This property puts the string in the guest's sysfs entries for it to be found by udev rules to create symlinks to the actual device. This is useful for guest applications discovering the ports of their interest. For example,		* name: This property puts the string in the guest's sysfs entries for it to be found by udev rules to create symlinks to the actual device. This is useful for guest applications discovering the ports of their interest. For example,

	<pre>		<pre>
	$ cat /sys/class/virtio-~~console~~/~~vcon1~~/name		$ cat /sys/class/virtio-ports/vport0p1/name
	org.linux-kvm.port.0		org.linux-kvm.port.0
	$		$
	</pre>		</pre>

	A simple udev rule can create a symlink to the actual device from this name: eg, create a new file in <code>/etc/udev/rules.d</code>, eg, <code>90-virtio-~~console~~</code>. Put the following code in it:		A simple udev rule can create a symlink to the actual device from this name: eg, create a new file in <code>/etc/udev/rules.d</code>, eg, <code>90-virtio-ports</code>. Put the following code in it:

	<pre>		<pre>
	KERNEL=="~~vcon~~*", SYMLINK+="virtio-~~console~~/$ATTR{name}"		KERNEL=="vport*", SYMLINK+="virtio-ports/$ATTR{name}"
	</pre>		</pre>

	In the above example, a symlink, <code>/dev/virtio-~~console~~/org.linux-kvm.port.0</code> will be created that points to <code>/dev/~~vcon1~~</code>		In the above example, a symlink, <code>/dev/virtio-ports/org.linux-kvm.port.0</code> will be created that points to <code>/dev/vport0p1</code>


Line 138:		Line 138:
	A few items from my TODO list. Please drop me a note at <amit.shah@redhat.com> if you're planning to pick something from here so that there's no duplication of work. Thanks!		A few items from my TODO list. Please drop me a note at <amit.shah@redhat.com> if you're planning to pick something from here so that there's no duplication of work. Thanks!
	* Guest kernel driver		* Guest kernel driver
	** ~~Check the device~~ removal ~~path, especially for console (hvc) ports~~		** Allow module removal

	* Host device		* Host device
	** Convert to VMState		** Convert to VMState
	** Generic chardev infrastructure: During migration, make sure if the other endpoint didn't receive data, resend it		** Generic chardev infrastructure: During migration, make sure if the other endpoint didn't receive data, resend it

Amit: Update TODO: hot-unplug done

2009-11-06T05:53:25Z

Update TODO: hot-unplug done

← Older revision		Revision as of 01:53, 6 November 2009
Line 138:		Line 138:
	A few items from my TODO list. Please drop me a note at <amit.shah@redhat.com> if you're planning to pick something from here so that there's no duplication of work. Thanks!		A few items from my TODO list. Please drop me a note at <amit.shah@redhat.com> if you're planning to pick something from here so that there's no duplication of work. Thanks!
	* Guest kernel driver		* Guest kernel driver
	** Check the device removal path, especially for ~~virtio-~~console (hvc) ~~ports~~		** Check the device removal path, especially for console (hvc) ports
	** Hot unplug ports

	* Host device		* Host device
	** Hot unplug ports
	** Convert to VMState		** Convert to VMState
	** Generic chardev infrastructure: During migration, make sure if the other endpoint didn't receive data, resend it		** Generic chardev infrastructure: During migration, make sure if the other endpoint didn't receive data, resend it