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
Virt-p2v and RAID Controller Drivers
Based on Fedora 10, "virt-p2v
is an experimental live CD for migrating physical machines to virtual machine guests." [1]
Jonathan Pregler[2]
and
Nick Haunold asked about a lack of HP and Dell RAID drivers in virt-p2v
. No answer was found, but
Jonathan Pregler is now working[3] on creating a SUSE live CD with virt-p2v
and the RAID drivers embedded.
NetWare Support added to virtinst
John Levon
patched[1]
to support NetWare PV installs.
python-virtinst
Fedora Xen List
This section contains the discussion happening on the fedora-xen list.
Which Xen Configuration Files
Urs Golla was confused[1] "about the configuration files for XEN user domains in Fedora."
Daniel P. Berrange[2] explained that parts of Xen uses different configuration formats.
xend
stores master config files in SXPR[3] format in/var/lib/xend
.xm
stores python-like config files in/etc/xen
"XenD itself has
no knowledge of these files," (in /etc/xen
) "so it can't manage them. They should not
be used in Xen >= 3.0.4 If you have existing files in /etc/xen
, then you
can load them into XenD by doing 'xm new configname
', at which point
both Xend and libvirt
will be able to manage them. For Xen < 3.0.4
libvirt
has some limited support for reading /etc/xen files directly"
Using
and the libvirt
virsh
command, the above
configuration files are essentially obviated. Instead
an intermediate XML configuration[4]
can be modified and applied back to xend
.
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 P. 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)".
More Flexible x86 Emulator Choice
Daniel P. Berrange
explained[1]
the current
restricts
"what emulator binary we allow for QEMU guests on x86 arches".
"This patch makes QEMU driver more flexible" ... "when setting up
its capabilities information."
"This should finally remove the confusion where a user in libvirt
selectrs 'i686' and then wonders why we've disallowed choice of 'kvm'.
It also fixes 'virsh version' when only qemu-kvm is installed."
virt-manager
The path to each emulator binary is hardcoded in libvirt
.
Daniel Veillard
found[2] this approach "worrying".
The merge[3]
of
and qemu
will make the reliance on a pathname to determine a binary's capabilities even less tenable.
kvm
Daniel P. Berrange agreed [4] "this approach we're currently using has pretty much reached the end of its practicality. In particular it is impossible to solve the problem of figuring out whether a plain 'qemu' binary supports kvm natively. To adress that, we'd actually need to run the binary and probe its output. This would require pretty much re-writing this entire capabilities setup logic from scratch. Similarly coping with varying path locations is another problem we can't easily solve with this current code."