From Fedora Project Wiki

< FWN‎ | Beats

m (removed CR/LF characters. added blank lines beneath each head/subhead)
Line 4: Line 4:
  
 
== Virtualization ==
 
== 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.  
 
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.  
  
Line 9: Line 10:
  
 
=== Enterprise Management Tools List ===
 
=== Enterprise Management Tools List ===
 +
 
This section contains the discussion happening on the
 
This section contains the discussion happening on the
 
[http://www.redhat.com/mailman/listinfo/et-mgmt-tools et-mgmt-tools list]
 
[http://www.redhat.com/mailman/listinfo/et-mgmt-tools et-mgmt-tools list]
  
 
==== Virt-p2v and RAID Controller Drivers ====
 
==== Virt-p2v and RAID Controller Drivers ====
 +
 
Based on Fedora 10, "<code>virt-p2v</code> is an experimental live CD for migrating physical machines to virtual machine guests." <ref>http://et.redhat.com/~rjones/virt-p2v/</ref>
 
Based on Fedora 10, "<code>virt-p2v</code> is an experimental live CD for migrating physical machines to virtual machine guests." <ref>http://et.redhat.com/~rjones/virt-p2v/</ref>
  
Line 23: Line 26:
  
 
==== NetWare Support added to virtinst ====
 
==== NetWare Support added to virtinst ====
[[JohnLevon|John Levon]]
+
 
patched<ref>http://www.redhat.com/archives/et-mgmt-tools/2009-March/msg00065.html</ref>
+
[[JohnLevon|John Levon]] patched<ref>http://www.redhat.com/archives/et-mgmt-tools/2009-March/msg00065.html</ref>
 
{{package|python-virtinst}} to support NetWare PV installs.
 
{{package|python-virtinst}} to support NetWare PV installs.
  
 
<references />
 
<references />
  
 +
=== Fedora Xen List ===
  
 
=== Fedora Xen List ===
 
 
This section contains the discussion happening on the
 
This section contains the discussion happening on the
 
[http://www.redhat.com/mailman/listinfo/fedora-xen fedora-xen list].
 
[http://www.redhat.com/mailman/listinfo/fedora-xen fedora-xen list].
  
 
==== Which Xen Configuration Files ====
 
==== Which Xen Configuration Files ====
Urs Golla was
+
 
confused<ref>http://www.redhat.com/archives/fedora-xen/2009-March/msg00043.html</ref> "about the configuration files for XEN user domains in Fedora."
+
Urs Golla was confused<ref>http://www.redhat.com/archives/fedora-xen/2009-March/msg00043.html</ref> "about the configuration files for XEN user domains in Fedora."
  
 
[[DanielBerrange|Daniel P. Berrange]]<ref>http://www.redhat.com/archives/fedora-xen/2009-March/msg00054.html</ref>
 
[[DanielBerrange|Daniel P. Berrange]]<ref>http://www.redhat.com/archives/fedora-xen/2009-March/msg00054.html</ref>
Line 43: Line 45:
 
* <code>xend</code> stores master config files in SXPR<ref>http://en.wikipedia.org/wiki/S-expression</ref> format in <code>/var/lib/xend</code>.
 
* <code>xend</code> stores master config files in SXPR<ref>http://en.wikipedia.org/wiki/S-expression</ref> format in <code>/var/lib/xend</code>.
 
* <code>xm</code> stores python-like config files  in <code>/etc/xen</code>
 
* <code>xm</code> stores python-like config files  in <code>/etc/xen</code>
"XenD itself has
+
"XenD itself has no knowledge of these files," (in <code>/etc/xen</code>) "so it can't manage them. They should not be used in Xen >= 3.0.4 If you have existing files in <code>/etc/xen</code>, then you can load them into XenD by doing '<code>xm new configname</code>', at which point both Xend and <code>libvirt</code> will be able to manage them. For Xen < 3.0.4 <code>libvirt</code> has some limited support for reading /etc/xen files directly"
no knowledge of these files," (in <code>/etc/xen</code>) "so it can't manage them. They should not
 
be used in Xen >= 3.0.4 If you have existing files in <code>/etc/xen</code>, then you
 
can load them into XenD by doing '<code>xm new configname</code>', at which point
 
both Xend and <code>libvirt</code> will be able to manage them. For Xen < 3.0.4
 
<code>libvirt</code> has some limited support for reading /etc/xen files directly"
 
  
Using {{package|libvirt}} and the <code>virsh</code> command, the above
+
Using {{package|libvirt}} and the <code>virsh</code> command, the above configuration files are essentially obviated. Instead an intermediate XML configuration<ref>http://libvirt.org/formatdomain.html</ref> can be modified and applied back to <code>xend</code>.
configuration files are essentially obviated. Instead
 
an intermediate XML configuration<ref>http://libvirt.org/formatdomain.html</ref>
 
can be modified and applied back to <code>xend</code>.
 
  
 
<references />
 
<references />
  
 
=== Libvirt List ===
 
=== Libvirt List ===
 +
 
This section contains the discussion happening on the
 
This section contains the discussion happening on the
 
[http://www.redhat.com/mailman/listinfo/libvir-list libvir-list].
 
[http://www.redhat.com/mailman/listinfo/libvir-list libvir-list].
  
 
==== Xen PCI Device Passthrough ====
 
==== Xen PCI Device Passthrough ====
A patch<ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00270.html</ref> from
+
 
[[DanielBerrange| Daniel P. Berrange]]
+
A patch<ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00270.html</ref> from [[DanielBerrange| Daniel P. Berrange]]
"provides initial support for PCI device passthrough in
+
"provides initial support for PCI device passthrough in Xen, at time of boot. It does not (yet) implement device hotplug for PCI".
Xen, at time of boot. It does not (yet) implement device hotplug
+
"XenD only supports 'unmanaged' PCI devices - ie mgmt app is responsible for detaching/reattaching PCI devices from/to  host device drivers.
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".
 
XenD itself won't automatically do this".
  
Line 74: Line 66:
  
 
==== Secure Guest Migration Draft Patch ====
 
==== 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]]
+
[[ChrisLalancette|Chris Lalancette]] followed<ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00276.html</ref>
wasn't enitrely satisfied<ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00338.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.
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 P. Berrange]]
+
[[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
pointed<ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00341.html</ref> out
+
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".
"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]]
+
[[DanielBerrange|Daniel P. 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."
tested the migration code and found the draft secure migration caused a
+
 
"slowdown of between 1.5 and 3 times".
+
[[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)".
"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 />
  
 
==== More Flexible x86 Emulator Choice ====
 
==== More Flexible x86 Emulator Choice ====
[[DanielBerrange|Daniel P. Berrange]]
 
explained<ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00281.html</ref>
 
the current {{package|libvirt}} 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 {{package|virt-manager}}
 
selectrs 'i686' and then wonders why we've disallowed choice of 'kvm'.
 
It also fixes 'virsh version' when only qemu-kvm is installed."
 
  
The path to each emulator binary is hardcoded in <code>libvirt</code>.
+
[[DanielBerrange|Daniel P. Berrange]] explained<ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00281.html</ref>
[[DanielVeillard|Daniel Veillard]]
+
the current {{package|libvirt}} 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 {{package|virt-manager}}
found<ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00339.html</ref> this approach "worrying".
+
selectrs 'i686' and then wonders why we've disallowed choice of 'kvm'. It also fixes 'virsh version' when only qemu-kvm is installed."
The merge<ref>http://fedoraproject.org/wiki/Features/KVM_and_QEMU_merge</ref>
+
 
of {{package|qemu}} and {{package|kvm}}
+
The path to each emulator binary is hardcoded in <code>libvirt</code>. [[DanielVeillard|Daniel Veillard]] found<ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00339.html</ref> this approach "worrying". The merge<ref>http://fedoraproject.org/wiki/Features/KVM_and_QEMU_merge</ref>
will make the reliance on a pathname to determine a binary's capabilities even less tenable.
+
of {{package|qemu}} and {{package|kvm}} will make the reliance on a pathname to determine a binary's capabilities even less tenable.
  
[[DanielBerrange|Daniel P. Berrange]]
+
[[DanielBerrange|Daniel P. Berrange]] agreed <ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00345.html</ref>
agreed
+
"this approach we're currently using has pretty much reached the end of its practicality. In particular it is impossible to solve
<ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00345.html</ref>
+
the problem of figuring out whether a plain 'qemu' binary supports kvm natively. To adress that, we'd actually need to run the binary
"this approach we're currently using has pretty much reached
+
and probe its output. This would require pretty much re-writing this entire capabilities setup logic from scratch. Similarly coping with
the end of its practicality. In particular it is impossible to solve
+
varying path locations is another problem we can't easily solve with this current code."
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."
 
  
 
<references />
 
<references />

Revision as of 15:51, 23 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

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] Package-x-generic-16.pngpython-virtinst to support NetWare PV installs.

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 Package-x-generic-16.pnglibvirt and the 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 Package-x-generic-16.pnglibvirt 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 Package-x-generic-16.pngvirt-manager selectrs 'i686' and then wonders why we've disallowed choice of 'kvm'. It also fixes 'virsh version' when only qemu-kvm is installed."

The path to each emulator binary is hardcoded in libvirt. Daniel Veillard found[2] this approach "worrying". The merge[3] of Package-x-generic-16.pngqemu and Package-x-generic-16.pngkvm will make the reliance on a pathname to determine a binary's capabilities even less tenable.

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."