Containers/Network virtualization - Revision history

71.202.99.189: /* Requirements */

2010-01-14T16:47:12Z

‎Requirements

Kir: formatting (use ==== headers not bold for subsections)

2006-11-10T10:55:32Z

formatting (use ==== headers not bold for subsections)

Dim at 10:51, 10 November 2006

2006-11-10T10:51:50Z

Dim at 10:51, 10 November 2006

2006-11-10T10:51:15Z

Bertl: added Linux-VServer

2006-11-08T17:13:36Z

added Linux-VServer

Dim: /* Approaches */

2006-11-08T11:28:37Z

‎Approaches

Dim at 12:36, 2 November 2006

2006-11-02T12:36:26Z

Dim at 17:17, 1 November 2006

2006-11-01T17:17:17Z

Kir: fixed cat.

2006-11-01T16:48:23Z

fixed cat.

Kir: added to Containers cat.

2006-11-01T16:40:14Z

added to Containers cat.

@@ Line 30: / Line 30: @@
 ==== Requirements ====
-# One can ran servers in several containers listening on *:port without conflict and __without__ forcing the bind to use the IP address assigned to the container;
+# One can run servers in several containers listening on *:port without conflict and __without__ forcing the bind to use the IP address assigned to the container;
 # The source address will be filled with the container IP address;
 # Keep sockets isolated by namespace;

@@ Line 7: / Line 7: @@
 == Approaches ==
 === Virtualization on the 2nd level (OpenVZ) ===
-'''Requirements''':
 The main requirement is that containers should have close to standalone servers networking capabilities. In details:
@@ Line 20: / Line 22: @@
-'''Current implementation''':
+==== Current implementation ====
 For input packets context switching is performed in netif_receive_skb(), inherited from the device  context. For output, context is inherited from the socket one.
 === Virtualization on the 3d level (IBM) ===
-'''Requirements''':
 # One can ran servers in several containers listening on *:port without conflict and __without__ forcing the bind to use the IP address assigned to the container;
 # The source address will be filled with the container IP address;
@@ Line 33: / Line 37: @@
 # have broadcast and multicast working.
-'''Current implementation''':
+==== Current implementation ====
 For input packets context switching is inherited from the routing entry, for output - inherited from the socket one.
 === Sockets isolation (Linux-VServer) ===
-'''Requirements''':
 # all interfaces and IPs are visible on the host
 # routing and iptables is configured on the host
@@ Line 48: / Line 54: @@
 # Guest-Guest and Guest-Host traffic via Loopback
-'''Current implementation''':
+==== Current implementation ====
 Network Context with 'assigned' set of IPs, which are used for 'collision' checks at bind
@@ Line 57: / Line 63: @@
 == Virtualization table ==
-This is a summary table in order to show which core networking objects are virtualized/isolated in above approaches or not.
+This is a summary table in order to show which core networking objects are virtualized/isolated in the above approaches and which are not.
 {| class="wikitable"

@@ Line 37: / Line 37: @@
 For input packets context switching is inherited from the routing entry, for output - inherited from the socket one.
-=== Socket isolation (Linux-VServer) ===
+=== Sockets isolation (Linux-VServer) ===
 '''Requirements''':
 # all interfaces and IPs are visible on the host

@@ Line 37: / Line 37: @@
 For input packets context switching is inherited from the routing entry, for output - inherited from the socket one.
-=== Socket virtualization ===
+=== Socket isolation (Linux-VServer) ===
 '''Requirements''':
 # all interfaces and IPs are visible on the host
 # routing and iptables is configured on the host
@@ Line 80: / Line 71: @@
 | 3d level virtualization || - || i || i || i || -
 |-
-| bind filtering || - || - || i || - || -
+| sockets isolation || - || - || i || - || -
 |}
@@ Line 88: / Line 77: @@
 * 'v' - virtualized
 * 'i' - isolated
 * '-' - neither virtualized nor isolated
 [[Category:Containers]]

@@ Line 37: / Line 37: @@
 For input packets context switching is inherited from the routing entry, for output - inherited from the socket one.
-=== Socket virtualization (Linux-VServer) ===
+=== Socket virtualization ===
 '''Requirements''':
 # implementation overhead for established tcp connections should be zero;
@@ Line 45: / Line 45: @@
 There is no context switching for packets at all, checks are performed between process and socket contexts.
 == Virtualization table ==
@@ Line 51: / Line 70: @@
 {| class="wikitable"
 ! width="20%" | Virtualization approach
-! width="13%" | network devices
+! width="10%" | network devices
-! Width="13%" | routing tables
+! Width="10%" | routing tables
-! Width="13%" | network sockets
+! Width="10%" | network sockets
-! Width="13%" | netfilters
+! Width="10%" | loopback
 |-
-| 2d level virtualization || v || v/i || v || v
+| 3d level virtualization || - || i || i || i || -
 |-
-| 3d level virtualization || - || i || i || -
+| bind filtering || - || - || i || - || -
 |-
-| bind filtering || - || - || i || -
+| network isolation || i/m || i || i || i/m || -
 |}
@@ Line 66: / Line 88: @@
 * 'v' - virtualized
 * 'i' - isolated
 * '-' - neither virtualized nor isolated
 [[Category:Containers]]

@@ Line 7: / Line 7: @@
 == Approaches ==
-* '''virtualization on the 2nd level (OpenVZ)''';
+=== Virtualization on the 2nd level (OpenVZ) ===
-: For input packets context switching is performed in device xmit code, requires virtual device for performing. For output, context is inherited from socket one.
+'''Requirements''':
-* '''virtualization on the 3d level (IBM)''';
-: For input packets context switching is performed in routing code, for output - inherited from socket one.
+The main requirement is that containers should have close to standalone servers networking capabilities. In details:
-* '''socket virtualization (Linux-VServer)'''.
+# containers should have own loopback;
-: There is no context switching for packets at all, checks are performed between process and socket contexts.
+# containers should have ability to setup their own level 3 addresses;
 == Virtualization table ==

← Older revision		Revision as of 12:36, 2 November 2006
Line 35:		Line 35:
	* 'i' - isolated		* 'i' - isolated
	* '-' - neither virtualized nor isolated		* '-' - neither virtualized nor isolated
		+
		+	[[Category:Containers]]

← Older revision		Revision as of 17:17, 1 November 2006
Line 1:		Line 1:
−	~~[[Category:Containers]]~~	+	There are a number of approaches to the network virtualization, caused by different requirements for different usages. This page is made in order to summarize them and create solution suitable for all.
−
−	There are a number of approaches to the network virtualization, caused by different requirements for different usages. This page is made in order to summarize them and create solution ~~possibly~~ suitable for all.

	== Usages ==		== Usages ==

← Older revision		Revision as of 16:48, 1 November 2006
Line 1:		Line 1:
−	{{Category:Containers}}	+	[[Category:Containers]]

	There are a number of approaches to the network virtualization, caused by different requirements for different usages. This page is made in order to summarize them and create solution possibly suitable for all.		There are a number of approaches to the network virtualization, caused by different requirements for different usages. This page is made in order to summarize them and create solution possibly suitable for all.

← Older revision		Revision as of 16:40, 1 November 2006
Line 1:		Line 1:
		+	{{Category:Containers}}
		+
	There are a number of approaches to the network virtualization, caused by different requirements for different usages. This page is made in order to summarize them and create solution possibly suitable for all.		There are a number of approaches to the network virtualization, caused by different requirements for different usages. This page is made in order to summarize them and create solution possibly suitable for all.