(: add xen pci) |
|||
| Line 42: | Line 42: | ||
for detaching/reattaching PCI devices from/to host device drivers. | for detaching/reattaching PCI devices from/to host device drivers. | ||
XenD itself won't automatically do this". | XenD itself won't automatically do this". | ||
<references /> | |||
==== Secure Guest Migration Draft Patch ==== | |||
[[ChrisLalancette|Chris Lalancette]] | |||
followed<ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00276.html</ref> | |||
the RFC<ref>https://fedoraproject.org/wiki/FWN/Issue166#Secure_Guest_Migration_Between_Hosts</ref> | |||
of last week with a "rough first draft of the secure migration code" and sought comments on the approach before putting the final polish on it. | |||
[[DanielVeillard|Daniel Veillard]] | |||
wasn't enitrely satisfied<ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00338.html</ref> | |||
with the "costs related to the 64KB chunking imposed by the XML-RPC" and was | |||
"Trying to reopen a bit the discussion we had before on opening a | |||
separate encrypted connection". | |||
Daniel Veillard | |||
"would like to make sure we have room in the initial phase | |||
to add such a negociation where an optimal solution" on a dedicated TCP/IP | |||
connection "may be attempted, possibly falling back to a normal XML-RPC solution". | |||
[[DanielBerrange|Daniel Berrange]] | |||
pointed<ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00341.html</ref> out | |||
"This isn't XML-RPC. This is our own binary protocol using XDR encoding, | |||
which has very little metadata overhead - just a single 24 byte header | |||
per 64kb of data.", and poposed a 'MIGRATION_INCOMING' message which could | |||
cause <code>libvirted</code> to "switch the TCP channel to 'data stream' mode." | |||
[[ChrisLalancette|Chris Lalancette]] | |||
tested the migration code and found the draft secure migration caused a | |||
"slowdown of between 1.5 and 3 times". | |||
"What I'm going to do early next week is do some additional work to try to get | |||
DanB's suggestion of the STREAM_DATA RPC working. Then I'll try benchmarking | |||
(both for duration, and CPU usage)". | |||
<references /> | <references /> | ||
Revision as of 17:32, 22 March 2009
Virtualization
In this section, we cover discussion on the @et-mgmnt-tools-list, @fedora-xen-list, @libvirt-list and @ovirt-devel-list of Fedora virtualization technologies.
Contributing Writer: Dale Bewley
Enterprise Management Tools List
This section contains the discussion happening on the et-mgmt-tools list
Fedora Virtualization List
This section contains the discussion happening on the fedora-virt list.
Fedora Xen List
This section contains the discussion happening on the fedora-xen list.
Libvirt List
This section contains the discussion happening on the libvir-list.
Xen PCI Device Passthrough
A patch[1] from Daniel P. Berrange "provides initial support for PCI device passthrough in Xen, at time of boot. It does not (yet) implement device hotplug for PCI". "XenD only supports 'unmanaged' PCI devices - ie mgmt app is responsible for detaching/reattaching PCI devices from/to host device drivers. XenD itself won't automatically do this".
Secure Guest Migration Draft Patch
Chris Lalancette followed[1] the RFC[2] of last week with a "rough first draft of the secure migration code" and sought comments on the approach before putting the final polish on it.
Daniel Veillard wasn't enitrely satisfied[3] with the "costs related to the 64KB chunking imposed by the XML-RPC" and was "Trying to reopen a bit the discussion we had before on opening a separate encrypted connection". Daniel Veillard "would like to make sure we have room in the initial phase to add such a negociation where an optimal solution" on a dedicated TCP/IP connection "may be attempted, possibly falling back to a normal XML-RPC solution".
Daniel Berrange
pointed[4] out
"This isn't XML-RPC. This is our own binary protocol using XDR encoding,
which has very little metadata overhead - just a single 24 byte header
per 64kb of data.", and poposed a 'MIGRATION_INCOMING' message which could
cause libvirted to "switch the TCP channel to 'data stream' mode."
Chris Lalancette tested the migration code and found the draft secure migration caused a "slowdown of between 1.5 and 3 times". "What I'm going to do early next week is do some additional work to try to get DanB's suggestion of the STREAM_DATA RPC working. Then I'll try benchmarking (both for duration, and CPU usage)".