|
|
| (297 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| | [[Category:Virtualization]] <!-- do not copy into FWN issue --> |
| | |
| {{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: [[DaleBewley | Dale Bewley]]
| |
| | |
| | |
| | |
|
| |
|
| | Contributing Writer: [[User:Dale | Dale Bewley]] |
|
| |
|
| === Libvirt List === | | === Fedora Virtualization 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/fedora-virt fedora-virt list]. |
|
| |
|
| ==== sVirt 0.30 Released ==== | | ==== Virt Status Report ==== |
| [[JamesMorris|James Morris]] announced[1] "the release of v0.30 of <code>sVirt</code>[2], a project to add security labeling support to Linux-based virtualization. | | [[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. |
|
| |
|
| [1] http://www.redhat.com/archives/libvir-list/2009-January/msg00158.html
| | <references /> |
|
| |
|
| [2] http://selinuxproject.org/page/SVirt
| | ==== RHEL and Fedora Virtualization Feature Parity ==== |
| | Robert Day wondered how the virtualization features<ref>http://www.redhat.com/virtualization/rhev/</ref> of Red Hat Enterprise Linux 5.4 |
| | compared to Fedora 12. |
|
| |
|
| ==== sVirt Qemu Hurdles ====
| | [[DanielBerrange|Daniel Berrange]] |
| [[DanielWalsh|Daniel J Walsh]] began to work on the svirt lock down of the <code>qemu</code> process, and | | explained<ref>http://www.redhat.com/archives/fedora-virt/2009-December/msg00040.html</ref> |
| saw[1] a problem with "the {{package|qemu}} binaries are being used to both setup the guest image
| | "The KVM based virtualization in RHEL-5.4 is not nearly so far behind |
| environment and then to run the guest image."
| | Fedora as you might think. The {{package|libvirt}} mgmt stack in RHEL-5.4 was |
| | rebased to be near parity with [[Releases/11|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." |
|
| |
|
| "The problem with this is the act of installing an image or setting up
| | <references /> |
| the environment an image runs within requires much more privileges then
| |
| actually running the image."
| |
|
| |
|
| "SELinux runs best when one processes forks/execs another process this
| |
| allows us to run the two processes under different labels. Each process
| |
| with the privileges required to run."
| |
|
| |
|
| [1] http://www.redhat.com/archives/libvir-list/2009-January/msg00198.html
| | ==== ==== |
| | <references /> |
|
| |
|
| ==== Fine Grained Access Controls ==== | | ==== ==== |
| [[KonradEriksson|Konrad Eriksson]] desired[1] is "an addition[2] to {{package|libvirt}} that enables access control on individual actions and data that can be accessed through the library API. This could take the form of an AC-module that, based on the identity of the caller, checks each call and grants/denies access to carry out the action (could also take parameters in account) and optionally filter the return data. The AC-module could then interface different backend AC solutions (SELinux, RBAC, ...) or alternatively implement an internal scheme."
| | <references /> |
| | |
| [[DanielBerrange|Daniel P. Berrange]] pointed[3] out how this relates
| |
| to <code>sVirt</code>. "At this stage <code>sVirt</code> is primarily about protecting guests from each other, and protecting the host from guests. Konrad's suggestions are about protecting guests/hosts from administrators, by providing more fine grained control over what libvirt APIs an admin can invoke & on what objects. Both bits of work are required & are complementary to each other."
| |
| | |
| [1] http://www.redhat.com/archives/libvir-list/2009-January/msg00282.html
| |
| | |
| [2] http://wiki.libvirt.org/page/TodoFineGrainedSecurity
| |
| | |
| [3] http://www.redhat.com/archives/libvir-list/2009-January/msg00362.html
| |
| | |
| ==== Configuring Host Interfaces RFC ==== | |
| [[DavidLutterkort|David Lutterkort]] composed[1] and RFC beginning
| |
| "For certain applications, we want {{package|libvirt}} to be able to configure host
| |
| network interfaces in a variety of ways; currently, we are most
| |
| interested in teaching <code>libvirt</code> how to set up ordinary ethernet
| |
| interfaces, bridges, bonding and vlan's.
| |
| Below is a high-level proposal of how that could be done. Please comment
| |
| copiously ;)"
| |
| | |
| Adding this type of support struck some as a complex open-ended prospect.
| |
| [[JohnLevon|John Levon]] argued[2] "We should be considering why <code>libvirt</code> is /well-placed/ to configure the
| |
| host. I think it should be pretty clear that it's actually not: the
| |
| problems around distro differences alone is a good indication. The
| |
| proposed API is anaemic enough to not be of much use. This is way beyond carving out the physical system into virtual chunks
| |
| and it's a big step towards lib*virt* becoming libmanagement."
| |
| | |
| [[DanielBerrange|Daniel P. Berrange]] countered[3]
| |
| "The existance of many different [implementations] is exactly the reason for <code>libvirt</code>
| |
| to have this capability. <code>Libvirt</code> is providing a consistent mgmt API
| |
| for management of guests and host networking interfaces is as much a
| |
| part of this as the storage management. <code>Libvirt</code> is providing this
| |
| capability across virtualization technology." Also saying[4] "Network interface APIs are the core missing piece of <code>libvirt</code> API functionality IMHO."
| |
| | |
| [1] http://www.redhat.com/archives/libvir-list/2009-January/msg00350.html
| |
| | |
| [2] http://www.redhat.com/archives/libvir-list/2009-January/msg00398.html
| |
| | |
| [3] http://www.redhat.com/archives/libvir-list/2009-January/msg00403.html
| |
| | |
| [4] http://www.redhat.com/archives/libvir-list/2009-January/msg00414.html
| |
| | |
| === oVirt Devel List ===
| |
| This section contains the discussion happening on the
| |
| [http://www.redhat.com/mailman/listinfo/ovirt-devel ovirt-devel list].
| |
libvirt