|
|
| (185 intermediate revisions by 24 users not shown) |
| Line 1: |
Line 1: |
| <pre>#!html
| | {{header|docs}} |
| ==Virtualization==</pre>
| |
|
| |
|
| Virtualization in Fedora {{Template:DocsDict/BeatsVer}}
| | {{Docs_beat_closed}} |
| includes major changes, and new features, that continue to support the Xen and KVM platforms.
| |
|
| |
| === Kernel Integration Improvements ===
| |
|
| |
|
| The Xen kernel is now based on the paravirt ops implementation from the upstream kernel. Previously, the Xen kernel was created by forward-porting Xen bits from the 2.6.18 kernel into the current Fedora kernel. This task was arduous and labor intensive, and resulted in the Xen kernel being several releases behind the bare-metal kernel. The inclusion of paravirt ops now makes this process unnecessary. Once paravirt ops is merged upstream, Xen will no longer require a separate kernel.
| | [[Category:Docs Project]] |
| | | [[Category:Draft documentation]] |
| However, the Xen kernel now lacks Dom0 support. An existing Xen host/Dom0 must continue to run Fedora 8. Xen Dom0 support will be added back in Fedora 10.
| | [[Category:Documentation beats]] |
| | |
| Fully virtualized Linux guests now have 3 possible installation methods:
| |
| | |
| * PXE boot from the network.
| |
| * Local CDROM drive / ISO image.
| |
| * Network install from a FTP/HTTP/NFS hosted distribution tree.
| |
| | |
| The latter allows for fully automated installation through the use of kickstart files. This provides parity between Xen HVM and KVM guests in terms of installation methods.
| |
| | |
| For more information refer to:
| |
| | |
| http://fedoraproject.org/wiki/Features/XenFullvirtKernelBoot
| |
| | |
| === Improved Storage Management ===
| |
| Previously/ Fedora introduced the ability to manage existing guest domains remotely using <code>libvirt</code>. It was not possible to create new guests due to the lack of storage management capabilities. In Fedora {{Template:DocsDict,BeatsVer}}
| |
| , new storage management can create and delete storage volumes from a remote host using <code>libvirt</code>.
| |
|
| |
| === PolicyKit Integration ===
| |
| Previously, the <code>virt-manager</code> application ran as <code>root</code> when managing a local hypervisor, and used <code>consolehelper</code> to authenticate from a desktop session. Running GTK applications as root is bad practice. PolicyKit integration now permits running <code>virt-manager</code> as a regular user.
| |
| | |
| === Improved Remote Authentication ===
| |
| Previously/ Fedora introduced support for secure remote management using TLS/SSL, and x509 certificates. Fedora {{Template:DocsDict,BeatsVer}}
| |
| improves remote management capabilities by adding support for authentication by password database, Kerberos domain controller, or system authentication using PAM. This feature applies to all tools using <code>libvirt</code>.
| |
|
| |
| === Other Improvements ===
| |
| Fedora also includes the following virtualization improvements:
| |
| * a new P2V tool, shipping as a Live CD, for converting a bare-metal install to a virtual guest
| |
| * a new tool, <code>xenner</code>, for running Xen-paravirtual kernels on top of KVM
| |
| * storage and network paravirtual-drivers for KVM guests
| |
| * full support for monitoring network and block statistics of QEMU and KVM in <code>libvirt</code> and <code>virt-top</code>, bringing parity with statistics monitoring, previously only available to Xen guests
| |
