From Fedora Project Wiki

Revision as of 19:22, 30 March 2010 by Poelstra (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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 13
  • Last updated: 2010-03-22
  • Percentage of completion: 100%

TODO

  • Make NetworkManager use netcf (outside the scope of this feature, might as well scrap it)

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. Its 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. Launch virt-manager, connect to libvirt
  2. Edit->Host Details->Interfaces->New Interface
  3. Choose 'Bridge', choose an interface to 'Bridge', select Finish
  4. Reference this bridge in the new VM wizard for new guests, verify working network connectivity
There is a known issue with this: virt-manager does not copy over the original device's IP configuration

for the new bridge. This is a big defficiency. It is fixed upstream, but is a pretty substancial backport. It would probably

be better to just rebase.

Remote bridge enumeration

  1. Launch virt-manager, connect to a remote libvirt instance with a configured bridge
  2. Launch the 'New VM' wizard, proceed as normal to the last screen. Make sure virt-manager lists the remote bridge device as an install option

User Experience

See the previous section. This could be greatly improved, i.e. don't require a deliberate bridge creation step, but simply allow a user to choose an unbridged interface at VM install time and bridge/share on the fly.

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