|
|
| (218 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. |
| === Fedora Xen List ===
| | 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. |
| This section contains the discussion happening on the
| |
| [http://www.redhat.com/mailman/listinfo/fedora-xen fedora-xen list].
| |
|
| |
|
| ==== ====
| |
| <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 /> |
libvirt