From Fedora Project Wiki

< FWN‎ | Beats

(→‎Fedora Xen List: none this week)
(→‎Libvirt List: Configuring Host Interfaces RFC)
Line 47: Line 47:


[3] http://www.redhat.com/archives/libvir-list/2009-January/msg00362.html
[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 ===
=== oVirt Devel List ===
This section contains the discussion happening on the
This section contains the discussion happening on the
[http://www.redhat.com/mailman/listinfo/ovirt-devel ovirt-devel list].
[http://www.redhat.com/mailman/listinfo/ovirt-devel ovirt-devel list].

Revision as of 09:32, 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

oVirt Devel List

This section contains the discussion happening on the ovirt-devel list.