KVM - Recent changes [en]

Projects/auto-ballooning

2013-06-17T21:09:58Z

Revision as of 21:09, 17 June 2013		Current revision
Line 5:		Line 5:
	When a Linux host is running out of memory, the kernel will take action to ''reclaim'' memory. This action may be detrimental to KVM guests performace (eg. swapping) or even extreme to the point where the kernel may kill a VM or an important virt stack component.		When a Linux host is running out of memory, the kernel will take action to ''reclaim'' memory. This action may be detrimental to KVM guests performace (eg. swapping) or even extreme to the point where the kernel may kill a VM or an important virt stack component.

-	To help avoiding this situation, a KVM guest could automatically return memory to the host when the host is facing memory pressure (automatic inflate). By doing so the guest may also get into memory pressure so we also need a way to allow the guest to automatically get memory back (automatic deflate).	+	To help avoiding this situation, a KVM guest could automatically return memory to the host when the host is facing memory pressure. By doing so the guest may also get into memory pressure so we also need a way to allow the guest to automatically get memory back.

	That's what the automatic ballooning project is about. The next section will dive into ways of implementing it. The following section will provide instructions on how to try current patches.		That's what the automatic ballooning project is about. The next section will dive into ways of implementing it. The following section will provide instructions on how to try current patches.
Line 20:		Line 20:
	=== Automatic Deflate ===		=== Automatic Deflate ===

-	Automatic deflate is performed by the virtio-balloon driver in the guest. There's also two ways of implementing this:	+	Automatic deflate is performed by the virtio-balloon driver within the guest. There's also two ways of implementing this:

	# The virtio-balloon driver registers a callback with the shrinker API. That callback is called when the guest kernel is facing memory pressure. The number of pages to be returned to the kernel is passed to the callback, so that the callback can deflate the balloon by that amount. This is what the current patchset does		# The virtio-balloon driver registers a callback with the shrinker API. That callback is called when the guest kernel is facing memory pressure. The number of pages to be returned to the kernel is passed to the callback, so that the callback can deflate the balloon by that amount. This is what the current patchset does
Line 26:		Line 26:

	== Testing ==		== Testing ==
		+
		+	You have to do three things to play with automatic-ballooning:
		+
		+	# Install kernel 3.10-rc1 or higher in the host. Make sure to enable CONFIG_CGROUPS and CONFIG_MEMCG
		+	# Clone QEMU from ''git://repo.or.cz/qemu/qmp-unstable.git balloon/auto-ballooning/rfc.v2'' (or grab the patch [http://repo.or.cz/w/qemu/qmp-unstable.git/commit/59fec94e6396d6c32cdce47777440c3a988be63d here])
		+	# Install the following kernel on your guest ''git://repo.or.cz/linux-2.6/luiz-linux-2.6.git virtio-balloon/auto-deflate/rfc'' (or grab the patches from the [http://repo.or.cz/w/linux-2.6/luiz-linux-2.6.git/shortlog/refs/heads/virtio-balloon/auto-deflate/rfc web interface])
		+
		+	After setting up the above, do the following to experiment with automatic deflate (which is easy to reproduce):
		+
		+	# Pass ''-balloon virtio,auto-balloon=true'' when starting QEMU
		+	# Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)
		+	# Switch to QEMU's monitor and decrease guest memory (say from 1G to 200MB)
		+	# Watch the guest increase its memory by repeatedly running "info balloon" on QEMU's monitor
		+
		+	To see automatic inflate and automatic deflate in action, you can run several VMs in parallel doing some heavy memory workload. Make sure to over commit host memory. Say your host has 4GB, run 6 VMs with 1GB each.
		+
		+	Another idea is to run one VM, but generate pressure in the host some way like a big kernel build or an application that allocates lots of memory.

OVMF

2013-06-15T13:44:24Z

fix typo in Gerd's name

(Difference between revisions)

Projects/auto-ballooning

2013-06-13T21:11:26Z

Revision as of 21:11, 13 June 2013		Current revision
Line 1:		Line 1:
-	= Auto-ballooning =	+	= Automatic Ballooning =

-	When a Linux host is running out of memory, the kernel will take action to ''reclaim'' memory. This action may be detrimental to kvm guests performace (eg. swapping) or even extreme to the point where the kernel kills user-space processes (which could be a kvm guest itself or a virt stack component).	+	== Introduction ==

-	To help avoiding this situation, a kvm guest could automatically inflate its balloon (thus returning memory to the host) when the host is facing memory pressure. Likewise, a kvm guest could automatically deflate its balloon when the guest itself is facing memory pressure (maybe due to automatic inflate).	+	When a Linux host is running out of memory, the kernel will take action to ''reclaim'' memory. This action may be detrimental to KVM guests performace (eg. swapping) or even extreme to the point where the kernel may kill a VM or an important virt stack component.

-	The goal of this page is to collect ideas on how to implement auto-ballooning.	+	To help avoiding this situation, a KVM guest could automatically return memory to the host when the host is facing memory pressure (automatic inflate). By doing so the guest may also get into memory pressure so we also need a way to allow the guest to automatically get memory back (automatic deflate).
-	Currently, there is only one proposal, which is the "automatic balance" idea,	+
-	mostly designed by Rik van Riel.	+

-	== Automatic balance ==	+	That's what the automatic ballooning project is about. The next section will dive into ways of implementing it. The following section will provide instructions on how to try current patches.

-	In automatic balance, the hypervisor (eg. QEMU) must have a way to detect that the host is under memory pressure. When this happens, QEMU could automatically inflate the guest's balloon to some value (say 10MB). When it's the guest that's facing memory pressure, its balloon driver could automatically deflate the memory balloon.	+	== Design ==

-	It's expected that inflate and deflate will balance each other over time.	+	=== Automatic Inflate ===

-	Next sections describe the implementation details of this idea.	+	Automatic inflate is performed by QEMU, that is, the KVM host. There are two ways I'm playing with automatic inflate, in both of them QEMU registers for [http://lwn.net/Articles/544652/ memory pressure] events to learn when the host is under memory pressure:

-	=== auto-inflate ===	+	# QEMU registers for the VMPRESSURE_MEDIUM event and inflates the balloon by an user specified value when the event is received. That value value could default to 16MB or 32MB. This is what the current patchset does
		+	# QEMU registers for the three memory pressure events and inflates the balloon accordingly. Say, it could inflate the balloon by 1MB on VMPRESSURE_LOW; 16MB on VMPRESSURE_MEDIUM and 128MB on VMPRESSURE_CRITICAL. This is not done yet because there's a small limitation in the memory pressure code which doesn't allow this. I'll fix it

-	There are two components needed to make auto-inflate work.	+	=== Automatic Deflate ===

-	* A (host) kernel API to let user-space processes know when the kernel is facing memory pressure	+	Automatic deflate is performed by the virtio-balloon driver in the guest. There's also two ways of implementing this:

-	* QEMU changes to use the host kernel API, and to inflate the guest's balloon when the host kernel is facing memory pressure	+	# The virtio-balloon driver registers a callback with the shrinker API. That callback is called when the guest kernel is facing memory pressure. The number of pages to be returned to the kernel is passed to the callback, so that the callback can deflate the balloon by that amount. This is what the current patchset does
		+	# The virtio-balloon driver registers for an in-kernel memory pressure event (not upstream yet) and deflates the balloon by some fixed amount (maybe the same amount used in automatic inflate)

-	=== auto-deflate ===	+	== Testing ==
-		+
-	Only one component is needed for auto-deflate	+
-		+
-	* The guest virtio-balloon driver must be changed to automatically deflate the balloon when the guest is facing memory pressure	+
-		+
-	=== status ===	+
-		+
-	'''FIXME''': add tree.	+
-		+
-	=== testing ===	+
-		+
-	'''FIXME''': describe.	+

Multiqueue

2013-06-13T05:44:16Z

Revision as of 05:44, 13 June 2013		Current revision
Line 214:		Line 214:

	* ...		* ...
		+
		+	== Enable MQ feature ==
		+	* create tap device with multiple queues, please reference
		+	Documentation/networking/tuntap.txt:(3.3 Multiqueue tuntap interface)
		+	* enable mq in qemu cmdline: -device virtio-net-pci,mq=on,...
		+	* enable mq in guest by 'ethtool -L eth0 combined $queue_num'

	== Test ==		== Test ==

User:ErnestoMT

2013-06-11T14:23:14Z

New page

There is nothing to tell about myself really. Also visit my web blog :: [http://ralphlaurenpolo4shirts.webs.com/ cheap ralph lauren polo shirts]

NetworkingTodo

2013-06-10T07:06:47Z

Revision as of 07:06, 10 June 2013		Current revision
Line 105:		Line 105:

	=== projects that are not started yet - no owner ===		=== projects that are not started yet - no owner ===
		+
		+	* Enable GRO for packets coming to bridge from a tap interface
		+
		+	* Better support for windows LRO
		+	Extend virtio-header with statistics for GRO packets:
		+	number of packets coalesced and number of duplicate ACKs coalesced

	* netdev polling for virtio.		* netdev polling for virtio.
Line 195:		Line 201:
	Reduce the number of interrupt		Reduce the number of interrupt

		+	* bridging on top of macvlan
		+	add code to forward LRO status from macvlan (not macvtap)
		+	back to the lowerdev, so that setting up forwarding
		+	from macvlan disables LRO on the lowerdev

		+	* preserve packets exactly with LRO
		+	LRO is not normally compatible with forwarding.
		+	virtio we are getting packets from a linux host,
		+	so we could thinkably preserve packets exactly
		+	even with LRO. I am guessing other hardware could be
		+	doing this as well.

	=== testing projects ===		=== testing projects ===

KVM Forum 2012

2013-06-07T12:00:29Z

Revision as of 12:00, 7 June 2013		Current revision
Line 29:		Line 29:
	\|2:30pm \|\| [[Media:2012-forum-Fernando-NTT-KVM-early-adopter.pdf \| KVM in the Enterprise: An Early Adopter's Take]] \|\| Fernando Luis Vazquez Cao, NTT \|\| [[Media:2012-forum-live-migration.pdf \| Live Migration: Even faster, Now With a Dedicated Thread!]] \|\| Orit Wasserman, Red Hat		\|2:30pm \|\| [[Media:2012-forum-Fernando-NTT-KVM-early-adopter.pdf \| KVM in the Enterprise: An Early Adopter's Take]] \|\| Fernando Luis Vazquez Cao, NTT \|\| [[Media:2012-forum-live-migration.pdf \| Live Migration: Even faster, Now With a Dedicated Thread!]] \|\| Orit Wasserman, Red Hat
	\|-		\|-
-	\|3:30pm \|\| [[Media:2012-forum-qemu-usb-status-update.pdf \| Qemu USB Status Report 2012]] \|\| Gerd Hoffman, Red Hat \|\| [[Media:2012-forum-postcopy.pdf \| Yabusame Update on Postcopy Live Migration for QEMU/KVM]] \|\| Isaku Yamahata, VA Linux Systems Japan K.K.	+	\|3:30pm \|\| [[Media:2012-forum-qemu-usb-status-update.pdf \| Qemu USB Status Report 2012]] \|\| Gerd Hoffmann, Red Hat \|\| [[Media:2012-forum-postcopy.pdf \| Yabusame Update on Postcopy Live Migration for QEMU/KVM]] \|\| Isaku Yamahata, VA Linux Systems Japan K.K.
	\|-		\|-
	\|4:00pm \|\| [[Media:2012-forum-yoshikawa.pdf \| How to Use KVM's Reverse Mappings to Improve Scalability]] \|\| Takuya Yoshikawa, NTT \|\| [[Media:Spice-kvm-forum-2012.pdf \| Spice Status Update]] \|\| Hans de Goede, Red Hat		\|4:00pm \|\| [[Media:2012-forum-yoshikawa.pdf \| How to Use KVM's Reverse Mappings to Improve Scalability]] \|\| Takuya Yoshikawa, NTT \|\| [[Media:Spice-kvm-forum-2012.pdf \| Spice Status Update]] \|\| Hans de Goede, Red Hat

GuestProgrammableMacVlanFiltering

2013-06-05T11:59:12Z

Revision as of 11:59, 5 June 2013		Current revision
Line 8:		Line 8:
	* set promiscuous mode on guest virtio-net device		* set promiscuous mode on guest virtio-net device
	* all this controllable by host admin		* all this controllable by host admin
		+
		+
		+
		+

	TODO:		TODO:
Line 17:		Line 21:

	* Control should be done via qemu/virtio features. Need a way to disable access that qemu can't override unless it has net admin capability.		* Control should be done via qemu/virtio features. Need a way to disable access that qemu can't override unless it has net admin capability.
		+
		+
		+	QEMU:
		+
		+	* Amos Kong works on QEMU side [http://lists.nongnu.org/archive/html/qemu-devel/2013-06/msg00658.html] to add event notification when guest change rx-filter config (main-mac, rx-mode, mac-table, vlan-table). Libvirt will query the rx-filter config from monitor (query-rx-filter), then sync the change to host device.

HOWTO

2013-05-31T12:49:32Z

Add kvm-simple-init to Scripting & Software section

Revision as of 12:49, 31 May 2013		Current revision
Line 86:		Line 86:
	* [http://pve.proxmox.com/wiki/Bare-metal_ISO_Installer Bare-metal] installer with KVM		* [http://pve.proxmox.com/wiki/Bare-metal_ISO_Installer Bare-metal] installer with KVM
	* [[kvmtools\|Python scripts to manage qemu-kvm guest from cmdline]] - yet another qemu-kvm script		* [[kvmtools\|Python scripts to manage qemu-kvm guest from cmdline]] - yet another qemu-kvm script
		+	* [https://github.com/tmartinfr/kvm-simple-init kvm-simple-init] - Simple init script to manage KVM virtual machines

	=== libvirt ===		=== libvirt ===

NetworkingTodo

2013-05-30T17:10:16Z

Revision as of 17:10, 30 May 2013		Current revision
Line 201:		Line 201:

	* Run weekly test on upstream HEAD covering test matrix with autotest		* Run weekly test on upstream HEAD covering test matrix with autotest
		+	* Measure the effect of each of the above-mentioned optimizations
		+	- Use autotest network performance regression testing (that runs netperf)
		+	- Also test any wild idea that works. Some may be useful.

	=== non-virtio-net devices ===		=== non-virtio-net devices ===

Guest Support Status

2013-05-25T09:47:41Z

Win98-3: added -no-kvm (sometimes needed)

Revision as of 09:47, 25 May 2013		Current revision
Line 345:		Line 345:
	\| no way		\| no way
	\| install crashes		\| install crashes
		+	\|-
		+
		+	\| Windows 98SE
		+	\| 32
		+	\| kvm-1.12.5
		+	\| AMD
		+	\| 32, 64
		+	\| works with a trick
		+	\| copy an existing installation with qemu-img
		+	opts: -no-kvm, smp 1, nic,model=ne2k_pci, soundhw none, vga=cirrus+cirrus-Win95-Driver
		+	tested by hiekjoha
	\|-		\|-

Line 1,108:		Line 1,119:
	\| Works		\| Works
	\|		\|
		+	\|-
		+
		+	\| Knoppix 6.2
		+	\| 32
		+	\| kvm-1.12.5
		+	\| AMD
		+	\| 32, 64
		+	\| Works
		+	\| tested by hiekjoha
		+	\|-
		+
		+	\| Knoppix 6.7.1
		+	\| 32
		+	\| kvm-1.12.5
		+	\| AMD
		+	\| 32, 64
		+	\| Works
		+	\| tested by hiekjoha
	\|}		\|}

Line 2,317:		Line 2,346:
	\| tested by Anna.L Karl /		\| tested by Anna.L Karl /
	[http://www.vittleende.se/ Tandblekning]		[http://www.vittleende.se/ Tandblekning]
		+	\|-
		+
		+	\| clonezilla-live-1.2.* - iso
		+	\| 32
		+	\| kvm-1.12.5
		+	\| AMD
		+	\| 32, 64
		+	\| Works
		+	\| tested by hiekjoha
		+	\|
	\|}		\|}

NetworkingTodo

2013-05-24T14:02:25Z

another project with no owner

Revision as of 14:02, 24 May 2013		Current revision
Line 136:		Line 136:
	* more GSO type support:		* more GSO type support:
	Kernel not support more type of GSO: FCOE, GRE, UDP_TUNNEL		Kernel not support more type of GSO: FCOE, GRE, UDP_TUNNEL
		+
		+	* ring aliasing:
		+	using vhost-net as a networking backend with virtio-net in QEMU
		+	being what's guest facing.
		+	This gives you the best of both worlds: QEMU acts as a first
		+	line of defense against a malicious guest while still getting the
		+	performance advantages of vhost-net (zero-copy).
		+	In fact a bit of complexity in vhost was put there in the vague hope to
		+	support something like this: virtio rings are not translated through
		+	regular memory tables, instead, vhost gets a pointer to ring address.
		+	This allows qemu acting as a man in the middle,
		+	verifying the descriptors but not touching the packet data.
		+

	=== vague ideas: path to implementation not clear		=== vague ideas: path to implementation not clear

User:KassieKen

2013-05-24T13:05:12Z

New page

Got nothing to write about myself really. Lovely to be a part of this community. I really hope I am useful at all Feel free to surf to my homepage; [http://www.pratiquemaroc.com/ location de voiture a casablanca aeroport]

NetworkingTodo

2013-05-24T11:06:27Z

Revision as of 11:06, 24 May 2013		Current revision
Line 107:		Line 107:

	* netdev polling for virtio.		* netdev polling for virtio.
		+	There are two kinds of netdev polling:
		+	- netpoll - used for debugging
		+	- proposed low latency net polling
	See http://lkml.indiana.edu/hypermail/linux/kernel/1303.0/00553.html		See http://lkml.indiana.edu/hypermail/linux/kernel/1303.0/00553.html

NetworkingTodo

2013-05-24T09:34:53Z

Revision as of 09:34, 24 May 2013		Current revision
Line 23:		Line 23:
	Multiqueue causes regression in some workloads, thus		Multiqueue causes regression in some workloads, thus
	it is off by default. Detect and enable/disable		it is off by default. Detect and enable/disable
-	automatically so we can make it on by default	+	automatically so we can make it on by default.
		+	This is because GSO tends to batch less when mq is enabled.
		+	https://patchwork.kernel.org/patch/2235191/
		+	Developer: Jason Wang
		+
		+	* rework on flow caches
		+	Current hlist implementation of flow caches has several limitations:
		+	1) at worst case, linear search will be bad
		+	2) not scale
		+	https://patchwork.kernel.org/patch/2025121/
		+	Developer: Jason Wang
		+
		+	* eliminate the extra copy in virtio-net driver
		+	We need do an extra copy of 128 bytes for every packets.
		+	This could be eliminated for small packets by:
		+	1) use build_skb() and head frag
		+	2) bigger vnet header length ( >= NET_SKB_PAD + NET_IP_ALIGN )
		+	Or use a dedicated queue for small packet receiving ? (reordering)
		+	Developer: Jason Wang
		+
		+	* make pktgen works for virtio-net ( or partially orphan )
		+	virtio-net orphan the skb during tx,
		+	which will makes pktgen wait for ever to the refcnt.
		+	Jason's idea: introduce a flat to tell pktgen not for wait
		+	Discussion here: https://patchwork.kernel.org/patch/1800711/
		+	MST's idea: add a .ndo_tx_polling not only for pktgen
		+	Developer: Jason Wang
		+
		+	* Add HW_VLAN_TX support for tap
		+	Eliminate the extra data moving for tagged packets
		+	Developer: Jason Wang
		+
		+	* Announce self by guest driver
		+	Send gARP by guest driver. Guest part is finished.
		+	Qemu is ongoing.
		+	V7 patches is here:
		+	http://lists.nongnu.org/archive/html/qemu-devel/2013-03/msg01127.html
	Developer: Jason Wang		Developer: Jason Wang

Line 94:		Line 130:
	support "reposting" buffers for mergeable buffers,		support "reposting" buffers for mergeable buffers,
	support pool for indirect buffers		support pool for indirect buffers
		+
		+	* more GSO type support:
		+	Kernel not support more type of GSO: FCOE, GRE, UDP_TUNNEL

	=== vague ideas: path to implementation not clear		=== vague ideas: path to implementation not clear
Line 108:		Line 147:
	core, need to teach it to allocate array of		core, need to teach it to allocate array of
	pointers and not array of queues.		pointers and not array of queues.
		+	Jason has an draft patch to use flex array.
		+	Another thing is to move the flow caches out of tun_struct.
		+	Developer: Jason Wang

	* irq/numa affinity:		* irq/numa affinity:
Line 130:		Line 172:
	* vlan filtering in bridge		* vlan filtering in bridge
	IGMP snooping in bridge should take vlans into account		IGMP snooping in bridge should take vlans into account
		+
		+	* tx coalescing
		+	Delay several packets before kick the device.
		+
		+	* interrupt coalescing
		+	Reduce the number of interrupt
		+

NetworkingTodo

2013-05-23T21:52:46Z

Revision as of 21:52, 23 May 2013		Current revision
Line 8:		Line 8:
	* vhost-net scalability tuning: threading for many VMs		* vhost-net scalability tuning: threading for many VMs
	Plan: switch to workqueue shared by many VMs		Plan: switch to workqueue shared by many VMs
-	www.mail-archive.com/kvm@vger.kernel.org/msg69868.html	+	http://www.mail-archive.com/kvm@vger.kernel.org/msg69868.html
-	Developer: Shirley Ma?, MST	+
		+	http://domino.research.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/479e3578ed05bfac85257b4200427735!OpenDocument
		+
		+	Developer: Shirley Ma?, MST?
	Testing: netperf guest to guest		Testing: netperf guest to guest

Line 79:		Line 82:

	* RDMA bridging		* RDMA bridging
		+
		+	* DMA emgine (IOAT) use in tun
		+	Old patch here: [PATCH RFC] tun: dma engine support
		+	It does not speed things up. Need to see why and
		+	what can be done.

	* use kvm eventfd support for injecting level interrupts,		* use kvm eventfd support for injecting level interrupts,
	enable vhost by default for level interrupts		enable vhost by default for level interrupts
-
-	* DMA emgine (IOAT) use in tun

	* virtio API extension: improve small packet/large buffer performance:		* virtio API extension: improve small packet/large buffer performance:
Line 98:		Line 104:

	* support more queues		* support more queues
-	We limit TUN to 8 queues	+	We limit TUN to 8 queues, but we really want
		+	1 queue per guest CPU. The limit comes from net
		+	core, need to teach it to allocate array of
		+	pointers and not array of queues.

	* irq/numa affinity:		* irq/numa affinity:

KVM Forum 2012

2013-05-23T18:49:41Z

Revision as of 18:49, 23 May 2013		Current revision
Line 61:		Line 61:
	\|2:30pm \|\| [[Media:2012-forum-glusterfs-stefanha.pdf \| GlusterFS for KVM Users and Developers]] \|\| Stefan Hajnoczi, Red Hat \|\| [[Media:2012-forum-megasas-vfio.pdf \| Megasas on Steroids: Qemu Device-Passthrough With VFIO]] \|\| Hannes Reinecke, SUSE		\|2:30pm \|\| [[Media:2012-forum-glusterfs-stefanha.pdf \| GlusterFS for KVM Users and Developers]] \|\| Stefan Hajnoczi, Red Hat \|\| [[Media:2012-forum-megasas-vfio.pdf \| Megasas on Steroids: Qemu Device-Passthrough With VFIO]] \|\| Hannes Reinecke, SUSE
	\|-		\|-
-	\|3:30pm \|\| [[Media:2012-forum-nakajima apicv.pdf \| Enabling Optimized Interrupt/APIC Virtualization in KVM]] \|\| Jun Nakajima, Intel \|\| QEMU Live Block Operations: Snapshots, Merging, and Mirroring \|\| Jeff Cody, Red Hat	+	\|3:30pm \|\| [[Media:2012-forum-nakajima apicv.pdf \| Enabling Optimized Interrupt/APIC Virtualization in KVM]] \|\| Jun Nakajima, Intel \|\| [[Media:2012-forum-Snapshots-Cody.pdf \| QEMU Live Block Operations: Snapshots, Merging, and Mirroring]] \|\| Jeff Cody, Red Hat
	\|-		\|-
	\|4:00pm \|\| [[Media:2012-forum-device-sharing-Bharat.pdf \| Efficient Sharing of Physical Devices Between KVM Guests and Host]] \|\| Bharat Bhushan, Freescale \|\| [[Media:2012-forum-virtio-blk-performance-improvement.pdf \| Virtio-blk Performance Improvement]] \|\| Asias He, Red Hat		\|4:00pm \|\| [[Media:2012-forum-device-sharing-Bharat.pdf \| Efficient Sharing of Physical Devices Between KVM Guests and Host]] \|\| Bharat Bhushan, Freescale \|\| [[Media:2012-forum-virtio-blk-performance-improvement.pdf \| Virtio-blk Performance Improvement]] \|\| Asias He, Red Hat

Special:Log/upload

2013-05-23T18:47:46Z

uploaded "[[Image:2012-forum-Snapshots-Cody.pdf]]"