From Fedora Project Wiki

< FWN‎ | Beats

 
(217 intermediate revisions by 3 users not shown)
Line 2: Line 2:
  
 
{{Anchor|Virtualization}}
 
{{Anchor|Virtualization}}
 +
  
 
== 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 of Fedora virtualization technologies on the
 +
@fedora-virt list.
  
 
Contributing Writer: [[User:Dale | Dale Bewley]]
 
Contributing Writer: [[User:Dale | Dale Bewley]]
 
=== Enterprise Management Tools List ===
 
This section contains the discussion happening on the
 
[http://www.redhat.com/mailman/listinfo/et-mgmt-tools et-mgmt-tools list]
 
 
==== 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>
 
 
Jonathan Pregler<ref>http://www.redhat.com/archives/et-mgmt-tools/2009-March/msg00075.html</ref>
 
and
 
Nick Haunold asked about a lack of HP and Dell RAID drivers in <code>virt-p2v</code>. No answer was found, but
 
Jonathan Pregler is now working<ref>http://www.redhat.com/archives/et-mgmt-tools/2009-March/msg00085.html</ref> on creating a SUSE live CD with <code>virt-p2v</code> and the RAID drivers embedded.
 
 
<references />
 
 
==== NetWare Support added to virtinst ====
 
[[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.
 
 
<references />
 
  
 
=== Fedora Virtualization List ===
 
=== Fedora Virtualization List ===
Line 33: Line 14:
 
[http://www.redhat.com/mailman/listinfo/fedora-virt fedora-virt list].
 
[http://www.redhat.com/mailman/listinfo/fedora-virt fedora-virt list].
  
==== ====
+
==== Virt Status Report ====
<references />
+
[[JustinForbes|Justin Forbes]]
 +
posted<ref>http://www.redhat.com/archives/fedora-virt/2009-December/msg00056.html</ref> a Fedora virtualization status report.
 +
Justin pointed out F13 bugs<ref>http://fedoraproject.org/wiki/Virtualization_bugs</ref> now include Important and Pony classifications in addition to Blocker and Target.
  
=== Fedora Xen List ===
 
This section contains the discussion happening on the
 
[http://www.redhat.com/mailman/listinfo/fedora-xen fedora-xen list].
 
 
==== 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."
 
 
Regarding to the Users’ Manual
 
for Xen v3.3 from xensource the configuration files should still be in
 
/etc/xen/ like they are on RHEL5. However, on F8 they are somewhere in
 
/var/lib/xen and have a new format (not XML?)."
 
 
[[MarkusArmbruster|Markus Armbruster]]<ref>http://www.redhat.com/archives/fedora-xen/2009-March/msg00053.html</ref>
 
"Xen uses *two* native configuration file formats: S-expressions and a
 
Python-like syntax.  The .sxp files you found below /var/lib/xend/ use
 
the former syntax, the guest configuration in /etc/xen the latter."
 
 
and
 
[[DanielBerrange|Daniel P. Berrange]]<ref>http://www.redhat.com/archives/fedora-xen/2009-March/msg00054.html</ref>
 
explained Xen uses two different configuration formats.
 
* "'<code>xend</code>' use <code>/var/lib/xend</code> for storing master config files in SXPR<ref>http://en.wikipedia.org/wiki/S-expression</ref> format."
 
* '<code>xm</code>' abuses python as a config file format in <code>/etc/xen</code>.
 
XenD itself has
 
no knowledge of these files, 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"
 
 
Fedora 7 and 8 were based on Xen 3.1
 
F9 3.2, F10 3.3.
 
 
<references />
 
<references />
  
=== Libvirt List ===
+
==== RHEL and Fedora Virtualization Feature Parity ====
This section contains the discussion happening on the
+
Robert Day wondered how the virtualization features<ref>http://www.redhat.com/virtualization/rhev/</ref> of Red Hat Enterprise Linux 5.4
[http://www.redhat.com/mailman/listinfo/libvir-list libvir-list].
+
compared to Fedora 12.
  
==== Xen PCI Device Passthrough ====
+
[[DanielBerrange|Daniel Berrange]]
A patch<ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00270.html</ref> from
+
explained<ref>http://www.redhat.com/archives/fedora-virt/2009-December/msg00040.html</ref>
[[DanielBerrange| Daniel P. Berrange]]
+
"The KVM based virtualization in RHEL-5.4 is not nearly so far behind
"provides initial support for PCI device passthrough in
+
Fedora as you might think. The {{package|libvirt}} mgmt stack in RHEL-5.4 was
Xen, at time of boot. It does not (yet) implement device hotplug
+
rebased to be near parity with [[Releases/11|Fedora 11]], and KVM in RHEL-5.4 is
for PCI".
+
also pretty close to that using what's best described as a hybrid of
"XenD only supports 'unmanaged' PCI devices - ie mgmt app is responsible
+
kvm-83 and kvm-84."
for detaching/reattaching PCI devices from/to host device drivers.
 
XenD itself won't automatically do this".
 
  
 
<references />
 
<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 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."
 
 
[[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 />
  
==== 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>.
 
[[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>
 
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]]
 
agreed
 
<ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00345.html</ref>
 
"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."
 
 
 
 
<references />
 
<references />

Latest revision as of 18:09, 18 December 2009



Virtualization

In this section, we cover discussion of Fedora virtualization technologies on the @fedora-virt list.

Contributing Writer: Dale Bewley

Fedora Virtualization List

This section contains the discussion happening on the fedora-virt list.

Virt Status Report

Justin Forbes posted[1] a Fedora virtualization status report. Justin pointed out F13 bugs[2] now include Important and Pony classifications in addition to Blocker and Target.

RHEL and Fedora Virtualization Feature Parity

Robert Day wondered how the virtualization features[1] of Red Hat Enterprise Linux 5.4 compared to Fedora 12.

Daniel Berrange explained[2] "The KVM based virtualization in RHEL-5.4 is not nearly so far behind Fedora as you might think. The Package-x-generic-16.pnglibvirt mgmt stack in RHEL-5.4 was rebased to be near parity with Fedora 11, and KVM in RHEL-5.4 is also pretty close to that using what's best described as a hybrid of kvm-83 and kvm-84."