From Fedora Project Wiki

< FWN‎ | Beats

(→‎Libvirt List: Configuring Host Interfaces RFC)
(→‎oVirt Devel List: i'm really slacking this week :()
Line 78: Line 78:


[4] http://www.redhat.com/archives/libvir-list/2009-January/msg00414.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].

Revision as of 09:50, 19 January 2009

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.

Contributing Writer: Dale Bewley



Libvirt List

This section contains the discussion happening on the libvir-list.

sVirt 0.30 Released

James Morris announced[1] "the release of v0.30 of sVirt[2], a project to add security labeling support to Linux-based virtualization.

[1] http://www.redhat.com/archives/libvir-list/2009-January/msg00158.html

[2] http://selinuxproject.org/page/SVirt

sVirt Qemu Hurdles

Daniel J Walsh began to work on the svirt lock down of the qemu process, and saw[1] a problem with "the Package-x-generic-16.pngqemu binaries are being used to both setup the guest image environment and then to run the guest image."

"The problem with this is the act of installing an image or setting up 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

Fine Grained Access Controls

Konrad Eriksson desired[1] is "an addition[2] to Package-x-generic-16.pnglibvirt 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."

Daniel P. Berrange pointed[3] out how this relates to sVirt. "At this stage sVirt 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

David Lutterkort composed[1] and RFC beginning "For certain applications, we want Package-x-generic-16.pnglibvirt to be able to configure host network interfaces in a variety of ways; currently, we are most interested in teaching libvirt 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. John Levon argued[2] "We should be considering why libvirt 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."

Daniel P. Berrange countered[3] "The existance of many different [implementations] is exactly the reason for libvirt to have this capability. Libvirt 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. Libvirt is providing this capability across virtualization technology." Also saying[4] "Network interface APIs are the core missing piece of libvirt 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