From Fedora Project Wiki
(fesco voted not to accept this feature on 2009-02-27 and suggested reconsideration for F12)
m (target f12)
Line 9: Line 9:
== Current status ==
== Current status ==


* Targeted release: [[Releases/11|Fedora 11]]
* Targeted release: [[Releases/12|Fedora 12]]
* Last updated: 2009-02-13
* Last updated: 2009-02-13
* Percentage of completion: 20%
* Percentage of completion: 20%
Line 108: Line 108:


[[Category:Virtualization|Shared Network Interface]]
[[Category:Virtualization|Shared Network Interface]]
[[Category:F11 Virt Features|Shared Network Interface]]
[[Category:F12 Virt Features|Shared Network Interface]]


[[Category:FeaturePageIncomplete]]
[[Category:FeaturePageIncomplete]]

Revision as of 10:27, 19 March 2009

Summary

Enable guest virtual machines to share a physical network interface (NIC) with other guests and the host operating system. This allows guests to independently appear on the same network as the host machine.

Owner

Current status

  • Targeted release: Fedora 12
  • Last updated: 2009-02-13
  • Percentage of completion: 20%

TODO

  • netcf library
  • Implement the libvirt API
  • Make NetworkManager use netcf
  • UI in virt-manager for configuring a shared interface.

Completed

Detailed Description

Background

Guest virtual machines usually need access to the network.

In Fedora we currently provide network access via a libvirt Virtual Network which is designed to always be available. This acts like a home broadband router, in that it NATs the traffic over any connected network interface.

A virtual network is the most suitable network access method to use for guests by default. It works well for laptop users because as you e.g. switch between wireless networks, the virtual network continues to be usable. It also allows inter-guest and guest-host communication even when the host machine is not connected to any network.

However, virtual networks also have a major disadvantage. Because traffic is NATed, the guest is not accessible to external hosts without configuring DNAT rules to forward connections to a specific host port onto the guest.

An alternate approach is to create a bridge, add a physical network device to the bridge and configure the bridge statically or using dhcp. At this point, the bridge appears to the host just like the physical interface.

Once the bridge has been configured, guest machines which are added to the bridge share the physical device and are effectively connected to the same physical network as the host machine. Thus, guest machines can be configured like any physical machine on the network and are directly accessible from other machines on the network.

Implementation

A new library - netcf - will be implemented for network interface configuration. It's API will resemble libvirt's in that interface configuration will be represented in XML. The library will have a separate backend for each network configuration regime (e.g. Fedora/RHEL vs. Debian).

NetworkManager will use netcf to read and write system network interface configuration. It will also gain support for create a bridge, updating iptables, adding the physical interface and configuring the bridge.

Next, an API and XML format will be added to libvirt for configuring host network interfaces. This will support not only the bridging configuration described here, but also other common network interface configurations. To begin with, the XML format used will be identical to the format used by netcf.

The libvirt implementation must be capable of working with either NetworkManager or standard initscripts, depending on how the machine is configured.

A very welcome side-effect of this new API in libvirt is that it will be possible to configure network interfaces remotely. This builds upon existing remote virtualization management features like secure remote management, secure remote console access, remote guest installation and remote storage management.

Finally, a UI will be added to virt-manager to allow users to configure given physical network interfaces as shared. A UI already exists to user shared interfaces for guest network connectivity.

Benefit to Fedora

This shared network interface configuration is a very common configuration in virtualization.

Xen supported this with a hacky /etc/xen/scripts/network-bridge which was universally despised.

The current recommended way to set this up in Fedora involves disabling NetworkManager, manually editing network initscript configuration and adding iptables rules. This is not ideal, and the new method will be far superior.

Scope

As described above, a new library is being developed and changes are also required in at least NetworkManager, libvirt and virt-manager.

How To Test

  1. Run virt-manager and click on "New" to begin installing a guest
  2. On the "Connect to host network" screen, choose a shared physical interface from the list
  3. Click on "Finish" to being installing the guest
  4. Observe (e.g. using brctl) that a bridge has been configured
  5. Verify that the guest has successfully connected to the network
This is pure fantasy. We would at least need to warn the user that choosing an unbridged interface would mean disconnecting and reconnecting from the network

User Experience

See the previous section.

Dependencies

None, outside of the implementation efforts detailed above.

Contingency Plan

If the NetworkManager implementation is not ready, we may still provide the libvirt initscripts backend. In order to use this, people would have to disable NetworkManager. That is still an improvement on the current situation, though.

If the libvirt side is not ready, but the NetworkManager bits are then at least we can stop telling people to disable NetworkManager. There probably wouldn't be any virt-manager UI, though.

Documentation

Release Notes

Fedora 11 adds the ability to configure shared network interfaces for improved virtual machine connectivity. This enables virtual machines to be bridged directly to same the physical network as the host machine.

Comments and Discussion