Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Wiki / Linuxvirtualization

Linuxvirtualization

Linux (Network) Virtualization Efforts

Linux (Network) Virtualization Efforts

Summaries

From Mike's March 10, 2008 progress report:

Anyway, as of a year or so ago, the Linux virtual network landscape was a mess. From my limited reading of archived mail concerning Linux network virtualization, there seem to be three main players:

Herbert Poetzl, representing vservers, believes that layer 3 isolation (like they have in vservers) is sufficient and causes the minimal overhead. Not opposed to layer 3 virtualization if there is no significant additional overhead.

Andrey Savochkin, representing openvz, believes that layer 2 virtualization (like they have in openvz) is important because layer 3 is too restrictive.

Eric Biederman, xmission? Favors layer 2 virt, but more concerned with the kernel framework. Wants a framework that is not invasive to those not using it; i.e., wants to maximize changes of it being accepted in the main line code.

A long discussion that took place over a year ago:

http://lkml.org/lkml/2006/6/9/349

Network namespaces were integrated in 2.6.24, and I am assuming that it is the Biederman work. I have not found much recent activity otherwise.

So where does this leave us? Going forward with a local node Linux vnode implementation would involve one of:

  • sticking with the plab-derived kernel and hacking vservers to do what we want, or
  • switch to an OpenVZ system, or
  • build our own on top of a 2.6.24+ kernel

The bigger issue is what do we do for protoGENI nodes? Choices are:

  • one of the above, or
  • wait for the VINI folks to come out with a kernel that works

From David Johnson's 17 Sep 2007 progress report:

I looked into levels of network virtualization/isolation in linux, and concluded that we're not likely to get anymore than isolation in the planetlab kernel (unless they're already doing some hacking to virtualize the stack -- we need to ask). The "openVZ" project (supported by a russian company, SWSoft, that makes Virtuozzo for linux) provides a huge patch for the linux kernel that virtualizes many parts of the kernel, including the network stack and namespaces. However, the knock on that patch is that it can really add lots of kernel overhead, including in the network stack. The vserver/openvz people once talked about merging their patchsets, but concluded that the differences are too large. The vserver people had looked at virtualizing more of the network stack back in 2005

From David Johnson's 01 Oct 2007 progress report:

There is a decent size effort that has been underway since last year to virtualize many namespaces in the kernel, including the network stack (the prime contributors seem to be IBM developers and a guy with an xmission email addr, plus the !OpenVZ people). I went over the mailing lists to get a good idea of the current state of this project and its goals and roadmap. I was mostly concerned about net virt, not the rest of the containerization/namespace issues also present on this list.

The current patchset provides network virtualization from "layer 2" up; however, there was some debate about doing this only at layer 3 and higher to minimize performance hits. However, for now anyway, the layer 2 stuff seems to have won, which is good news for planetlab and for us.

This is the place where the princeton people seem to be working. I saw some mail from Sapan Bhatia (who had the vini poster at nsdi) on this list in June (although I haven't seen any patches from him yet). I think they are probably going to leverage this effort eventually, so we should try it out (which I will do). I need to see how complete it is. I have seen claims that "planetlab has integrated net namespaces with vserver and things are cool" on the list, but not sent from the plab people. I'm on the vserver devel list and I don't see stuff there. I haven't seen relevant cvs commits from them in the vserver stuff or linux kernel srcs they maintain in their own cvs, but perhaps these commits don't get sent via mail, or elsewhere.

I should mention that this effort does emphasize pushing its patches upstream into the mainline kernel, so this is a good reason to hitch ourselves to this effort. However, one of the key guardians of the linux network stack doesn't see the final point to virtualizing all parts of the network namespace... so the complete bits might not make it. However, he is merging lots upstream at the moment.