|
|
(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 /> |