Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Wiki / Lowellintegrationplans

Lowellintegrationplans

Integration with UMass-Lowell PEN

Integration with UMass-Lowell PEN

Overview

The are two main tactics this integration could take:

  • Independently implement component manager for PEN, federate with ProtoGENI at the 'narrow waist' level

OR

  • Integrate support for creating slivers and virtual links on a PEN into the Emulab client side software, and have the PEN managed with an Emulab installation acting as its component manager

Notes

At this point, because we are already exploring slicing components with OpenVZ, the second option above seems to look better.

- Bridging issue in OpenVZ -

As you know, OpenVZ Virtual Environment (VEs) rely on bridging between VE's virtual NICs with host's NICs. With our network processor based NICs, we can eliminate the need of such bridging.

Here is how it works:

1. With a network processor based NIC (we use Netronome NFE-i8000) and its drivers, we can instantiate a configurable number (up to 256) of "virtual" NICs on the root context (host). These virtual NICs appear as if they are regular NICs such as eth0...

2. From the VEs, we can *directly* access a NIC on the root context (host). We can do ifconfig, for example, to set up IP address. The benefit is that, we do NOT need to do bridging. However, once we do that, the NIC on the host will be invisible or not accessable to other VEs.

3. Using a conventional NIC, such direct access from VE will be limited by the number of physical NICs on the host (root context.) In contrast, with network processor based card providing a *flexible* number of "virtual" NICs on host, we can access them directly from a number of VEs, each of which has possibly a different number of virtual NICs inside.

Tasks

  • Integrate OpenVZ setup into Emulab client-side Utah/Georgia Tech/Lowell
  • Add support for creating PEN interfaces into libvirt Lowell/Georgia Tech

Timeline

TBD