OpenVZ Virtuozzo Containers Wiki - User contributions [en]

C++ Code Style Guide

2021-01-28T09:45:17Z

Dim: /* Taboos */

We have legacy and new code. fixes of the legacy, which are small patches actually, adhere to the enclosing style.
For new code, see below.

== Naming Conventions ==

# Names should be readable, better to do not use abbreviations
# [https://en.wikipedia.org/wiki/CamelCase CamelCase] for names. Class, namespace, enum names should start with uppercase (for example, Audit). Other names should start with lowercase (Audit->getValue())
# Typedefs should have "_t" or "_type" suffix (myFavoriteType_t)
# Member value should have "m_" prefix (m_store)
# Static member variable should have "s_" prefix (s_count)
# Global object should have "g_" prefix. Global static variable is global still -> "g_" prefix
# No value type hints in a variable name or return type hints in a function name
# Local variables names should be short
# Class and namespaces names should consist of 1 or 2 words (Audit, AuditValue, but not AuditValueForTransition)
# Function name should start with a verb, because any function implies an action (getValue())
# Accesser name should start with "get", mutator name should start with "set" (getValue()/setValue())

== Formatting Conventions ==

# It is highly desirable to follow the restrictions:
## line length is below 80 symbols,
## function body (outer) is below 50 lines
# '{' is on the same line with "if", "for", "while"
# Single-line nested block - without braces
# There should be a C++-style comment ("// comment") at:
## closing '}' for a namespace should have a comment about the namespace
## #else, #endif, #elif - a comment about a condition of the very first #ifdef
# One operation (ended by ';') per line
# Preferred order of a class labeled sections inside the class declaration:
## public
## protected
## private
# Preferred order inside a section:
## typedefs
## constructors
## destructor
## member functions
## static functions
## member variables
## static variables
# Empty line after every section inside a class declaration
# No empty line after the last section inside a class declaration
# No indent inside namespace
# Header files:
## No "using namespace ..." inside header files
## if a header file is a part of public API:
### use 'extern "C"' construct
### comments for doxygen MUST be

== Taboos ==

# We do not use RTTI (no dynamic_cast<>)
# We do not use exceptions
# We do not use conversion operators (int())
# We do not use assembler inlines
# We do not use "friends"
# We do not use "public" or "protected" member variables
# We do not use standalone functions (not bound to some class)

== Other Rules ==

# A function, which results only in a success or failure, should use 'boolean' return type. In a case of "success", it should return "true".
# A function, which results in a custom error, should return PRL_RESULT return type.
## For a successful result, use PRL_ERR_SUCCESS
## A check of successful result of this value should be performed by PRL_SUCCEEDED() or PRL_FAILED() macros.
# It is highly desirable to avoid function definitions with more than 3 arguments. Allowed exceptions - external callbacks, interfaces, legacy functions.
# Use references to objects rather than pointers, even for smart pointers.
# Group related classes to a single namespace
# We do not welcome a polymorphic inheritance
# If possible, avoid manual memory management (use of "new" and "delete" operators)
# If possible, avoid low-level thread management API ("pthread_xxx"), better to use boost or QT wrappers over it.
# Use anonymous namespace for symbols, which should be defined and used only inside a local compilation unit.
# If possible, avoid use of complex boolean conditions. '==' is better than '!=', '<' is better than '>='
# We do not welcome a function with a boolean argument, which changes the function's behaviour

Virtuozzo 7 Technical Preview - Containers

2015-07-27T13:59:34Z

Dim: /* Download */

[[Virtuozzo]] is a Linux distribution based on opensource OpenVZ components.

This is an early technology preview of Virtuozzo 7. We have made some good progress, but this is just the beginning. Much more still needs to be done. In the preview we replaced the containers engine and made our tools work with the new kernel technologies. We consider this beta a major milestone on the road to the official Virtuozzo 7 release and want to share the progress with the community.

== Key Changes ==
* Virtuozzo 7 is based on RHEL7 and [[Download/kernel/rhel7-testing|Kernel 3.10+]]
* Containers are using kernel features cgroups and namespaces that limit, account for, and isolate resource usage as isolated namespaces of a collection of processes. The beancounters interface remains in place for backward compatibility. At the same time it acts as a proxy for actual cgroups and namespaces implementation.
* UUID instead of VEID for container identification. You can use UUID or name to identify a container. By default vzctl will treat the former VEID parameter as name.
* [[VCMMD|VCMM 4th generation of memory manager]]. We switched to memcg. By balancing and configuring memcg limits we will get the exact overcommit, shadow gangs, swap, page cache overuse Virtuozzo parameters. This will be done by a userspace daemon.

== Not Implemented ==
* KVM-based virtual machines
* Instance migration based on the [http://criu.org/Main_Page CRIU project]
* Migration from OpenVZ and Virtuozzo 6

== Deprecated ==
* VZFS
* [[UBC|User bean counters]]
* Delayed /vz mounting

== Known Issues ==
* Cannot boot Virtuozzo 7 Beta 1 with EFI. (#PSBM-34786)
* Autopartitioning for standard partitions in the Virtuozzo 7 Beta 1 installer does not work.For details, see [https://bugzilla.redhat.com/show_bug.cgi?id=1172441 RHEL bug #1172441]. (#PSBM-34787)
* Installation may stop due to a Red Hat Enterprise Linux 7 bug. In this case, restart installation. For details, see [https://bugzilla.redhat.com/show_bug.cgi?id=1167948 RHEL bug #1167948]. (#PSBM-34797)
* netconsole cannot be used along with bridged containers. (#PSBM-34959)
* Container console does not work in Openstack
* Simfs is not working

== Download ==
* [http://download.openvz.org/virtuozzo/releases/7.0-beta1/x86_64/iso/ Installation ISO images]

== Feedback ==
* [[Mailing lists]]

Userspace patches

2015-06-16T13:21:42Z

Dim:

{{Virtuozzo}}

We are waiting for contributions to userspace utilities from OpenVZ community.

This document describes how to contribute your patches to the OpenVZ userspace.

== Source code ==

OpenVZ source code is available from GIT repository at

https://src.openvz.org/projects/OVZ

To clone, use

git clone https://src.openvz.org/scm/ovz/<project>.git

For example:

git clone https://src.openvz.org/scm/ovz/prlctl.git

== Preparing patches ==

For new code please follow:
* C++ language - [[C++ Code Style Guide]]
* C language - [https://www.kernel.org/doc/Documentation/CodingStyle Linux kernel code style]
* Python language - [https://www.python.org/dev/peps/pep-0008/ Python code style]

For existing code patches, please follow a style which is used for code around.

== Send pull request ==

For contributions, please register at [https://src.openvz.org our Stash site] and follow [https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow "forking" workflow].

== See also ==

* [[Contribute]]
* [[C++ Code Style Guide]]
* [[Static code analysis]]
* [[Wishlist]]
* [[QA|OpenVZ Testing]]

[[Category: Contributions]]
[[Category:Virtuozzo]]

Userspace patches

2015-06-16T13:21:13Z

Dim:

{{Virtuozzo}}
{{Stub}}

We are waiting for contributions to userspace utilities from OpenVZ community.

This document describes how to contribute your patches to the OpenVZ userspace.

== Source code ==

OpenVZ source code is available from GIT repository at

https://src.openvz.org/projects/OVZ

To clone, use

git clone https://src.openvz.org/scm/ovz/<project>.git

For example:

git clone https://src.openvz.org/scm/ovz/prlctl.git

== Preparing patches ==

For new code please follow:
* C++ language - [[C++ Code Style Guide]]
* C language - [https://www.kernel.org/doc/Documentation/CodingStyle Linux kernel code style]
* Python language - [https://www.python.org/dev/peps/pep-0008/ Python code style]

For existing code patches, please follow a style which is used for code around.

== Send pull request ==

For contributions, please register at [https://src.openvz.org our Stash site] and follow [https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow "forking" workflow].

== See also ==

* [[Contribute]]
* [[C++ Code Style Guide]]
* [[Static code analysis]]
* [[Wishlist]]
* [[QA|OpenVZ Testing]]

[[Category: Contributions]]
[[Category:Virtuozzo]]

C++ Code Style Guide

2015-06-16T09:29:39Z

Dim:

== Naming Conventions ==

# Names should be readable, better to do not use abbreviations
# [https://en.wikipedia.org/wiki/CamelCase CamelCase] for names. Class, namespace, enum names should start with uppercase (for example, Audit). Other names should start with lowercase (Audit->getValue())
# Typedefs should have "_t" or "_type" suffix (myFavoriteType_t)
# Member value should have "m_" prefix (m_store)
# Static member variable should have "s_" prefix (s_count)
# Global object should have "g_" prefix. Global static variable is global still -> "g_" prefix
# No value type hints in a variable name or return type hints in a function name
# Local variables names should be short
# Class and namespaces names should consist of 1 or 2 words (Audit, AuditValue, but not AuditValueForTransition)
# Function name should start with a verb, because any function implies an action (getValue())
# Accesser name should start with "get", mutator name should start with "set" (getValue()/setValue())

== Formatting Conventions ==

# It is highly desirable to follow the restrictions:
## line length is below 80 symbols,
## function body (outer) is below 50 lines
# '{' is on the same line with "if", "for", "while"
# Single-line nested block - without braces
# There should be a C++-style comment ("// comment") at:
## closing '}' for a namespace should have a comment about the namespace
## #else, #endif, #elif - a comment about a condition of the very first #ifdef
# One operation (ended by ';') per line
# Preferred order of a class labeled sections inside the class declaration:
## public
## protected
## private
# Preferred order inside a section:
## typedefs
## constructors
## destructor
## member functions
## static functions
## member variables
## static variables
# Empty line after every section inside a class declaration
# No empty line after the last section inside a class declaration
# No indent inside namespace
# Header files:
## No "using namespace ..." inside header files
## if a header file is a part of public API:
### use 'extern "C"' construct
### comments for doxygen MUST be

== Taboos ==

# We do not use RTTI (no dynamic_cast<>)
# We do not use exceptions
# We do not use syntax allowed by C++11 standard
# We do not use conversion operators (int())
# We do not use assembler inlines
# We do not use "friends"
# We do not use "public" or "protected" member variables
# We do not use standalone functions (not bound to some class)

== Other Rules ==

# A function, which results only in a success or failure, should use 'boolean' return type. In a case of "success", it should return "true".
# A function, which results in a custom error, should return PRL_RESULT return type.
## For a successful result, use PRL_ERR_SUCCESS
## A check of successful result of this value should be performed by PRL_SUCCEEDED() or PRL_FAILED() macros.
# It is highly desirable to avoid function definitions with more than 3 arguments. Allowed exceptions - external callbacks, interfaces, legacy functions.
# Use references to objects rather than pointers, even for smart pointers.
# Group related classes to a single namespace
# We do not welcome a polymorphic inheritance
# If possible, avoid manual memory management (use of "new" and "delete" operators)
# If possible, avoid low-level thread management API ("pthread_xxx"), better to use boost or QT wrappers over it.
# Use anonymous namespace for symbols, which should be defined and used only inside a local compilation unit.
# If possible, avoid use of complex boolean conditions. '==' is better than '!=', '<' is better than '>='
# We do not welcome a function with a boolean argument, which changes the function's behaviour

C++ Code Style Guide

2015-06-16T09:26:04Z

Dim:

== Naming Conventions ==

# Names should be readable, better to do not use abbreviations
# [https://en.wikipedia.org/wiki/CamelCase CamelCase] for names. Class, namespace, enum names should start with uppercase (for example, Audit). Other names should start with lowercase (Audit->getValue())
# Typedefs should have "_t" or "_type" suffix (myFavoriteType_t)
# Member value should have "m_" prefix (m_store)
# Static member variable should have "s_" prefix (s_count)
# Global object should have "g_" prefix. Global static variable is global still -> "g_" prefix
# No value type hints in a variable name or return type hints in a function name
# Local variables names should be short
# Class and namespaces names should consist of 1 or 2 words (Audit, AuditValue, but not AuditValueForTransition)
# Function name should start with a verb, because any function implies an action (getValue())
# Accesser name should start with "get", mutator name should start with "set" (getValue()/setValue())

== Formatting Conventions ==

# It is highly desirable to follow the restrictions:
## line length is below 80 symbols,
## function body (outer) is below 50 lines
# '{' is on the same line with "if", "for", "while"
# Single-line nested block - without braces
# There should be a C++-style comment ("// comment") at:
## closing '}' for a namespace should have a comment about the namespace
## #else, #endif, #elif - a comment about a condition of the very first #ifdef
# One operation (ended by ';') per line
# Preferred order of a class labeled sections inside the class declaration:
## public
## protected
## private
# Preferred order inside a section:
## typedefs
## constructors
## destructor
## member functions
## static functions
## member variables
## static variables
# Empty line after every section inside a class declaration
# No empty line after the last section inside a class declaration
# No indent inside namespace
# Header files:
## No "using namespace ..." inside header files
## if a header file is a part of public API:
### use 'extern "C"' construct
### comments for doxygen MUST be

== Taboos ==

# We do not use RTTI (no dynamic_cast<>)
# We do not use exceptions
# We do not use syntax allowed by C++11 standard
# We do not use conversion operators (int())
# We do not use polymorphic inheritance
# We do not use assembler inlines
# We do not use "friends"
# We do not use "public" or "protected" member variables
# We do not use standalone functions (not bound to some class)

== Other Rules ==

# A function, which results only in a success or failure, should use 'boolean' return type. In a case of "success", it should return "true".
# A function, which results in a custom error, should return PRL_RESULT return type.
## For a successful result, use PRL_ERR_SUCCESS
## A check of successful result of this value should be performed by PRL_SUCCEEDED() or PRL_FAILED() macros.
# It is highly desirable to avoid function definitions with more than 3 arguments. Allowed exceptions - external callbacks, interfaces, legacy functions.
# Use references to objects rather than pointers, even for smart pointers.
# Group related classes to a single namespace
# If possible, avoid manual memory management (use of "new" and "delete" operators)
# If possible, avoid low-level thread management API ("pthread_xxx"), better to use boost or QT wrappers over it.
# Use anonymous namespace for symbols, which should be defined and used only inside a local compilation unit.
# If possible, avoid use of complex boolean conditions. '==' is better than '!=', '<' is better than '>='
# We do not welcome a function with a boolean argument, which changes the function's behaviour

C++ Code Style Guide

2015-06-15T18:10:32Z

Dim: Created page with " == Naming Conventions == # Names should be readable, better to do not use abbreviations # "Camel" case for names (for example, AuditValue) # Class, namespace, enum names sho..."

== Naming Conventions ==

# Names should be readable, better to do not use abbreviations
# "Camel" case for names (for example, AuditValue)
# Class, namespace, enum names should start with uppercase (for example, Audit). Other names should start with lowercase (Audit->getValue())
# Typedefs should have "_t" or "_type" suffix (myFavoriteType_t)
# Member value should have "m_" prefix (m_store)
# Static member variable should have "s_" prefix (s_count)
# Global object should have "g_" prefix. Global static variable is global still -> "g_" prefix
# No value type hints in a variable name or return type hints in a function name
# Local variables names should be short
# Class and namespaces names should consist of 1 or 2 words (Audit, AuditValue, but not AuditValueForTransition)
# Function name should start with a verb, because any function implies an action (getValue())
# Accesser name should start with "get", mutator name should start with "set" (getValue()/setValue())

== Formatting Conventions ==

# It is highly desirable to follow the restrictions:
## line length is below 80 symbols,
## function body (outer) is below 50 lines
# '{' is on the same line with "if", "for", "while"
# Single-line nested block - without braces
# There should be a C++-style comment ("// comment") at:
## closing '}' for a namespace should have a comment about the namespace
## #else, #endif, #elif - a comment about a condition of the very first #ifdef
# One operation (ended by ';') per line
# Preferred order of a class labeled sections inside the class declaration:
## public
## protected
## private
# Preferred order inside a section:
## typedefs
## constructors
## destructor
## member functions
## static functions
## member variables
## static variables
# Empty line after every section inside a class declaration
# No empty line after the last section inside a class declaration
# No indent inside namespace
# Header files:
## No "using namespace ..." inside header files
## if a header file is a part of public API:
### use 'extern "C"' construct
### comments for doxygen MUST be

== Taboos ==

# We do not use RTTI (no dynamic_cast<>)
# We do not use exceptions
# We do not use syntax allowed by C++11 standard
# We do not use conversion operators (int())
# We do not use polymorphic inheritance
# We do not use assembler inlines
# We do not use "friends"
# We do not use "public" or "protected" member variables
# We do not use standalone functions (not bound to some class)

== Other Rules ==

# A function, which results only in a success or failure, should use 'boolean' return type. In a case of "success", it should return "true".
# A function, which results in a custom error, should return PRL_RESULT return type.
## For a successful result, use PRL_ERR_SUCCESS
## A check of successful result of this value should be performed by PRL_SUCCEEDED() or PRL_FAILED() macros.
# It is highly desirable to avoid function definitions with more than 3 arguments. Allowed exceptions - external callbacks, interfaces, legacy functions.
# Use references to objects rather than pointers, even for smart pointers.
# Group related classes to a single namespace
# If possible, avoid manual memory management (use of "new" and "delete" operators)
# If possible, avoid low-level thread management API ("pthread_xxx"), better to use boost or QT wrappers over it.
# Use anonymous namespace for symbols, which should be defined and used only inside a local compilation unit.
# If possible, avoid use of complex boolean conditions. '==' is better than '!=', '<' is better than '>='
# We do not welcome a function with a boolean argument, which changes the function's behaviour

Userspace patches

2015-06-03T17:46:08Z

Dim:

{{Stub}}

We are waiting for contributions to userspace utilities from OpenVZ community.

For contributions, please register at [https://src.openvz.org our Stash site] and follow [https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow "forking" workflow].

[[Category: Contributions]]

Containers/Network virtualization

2006-11-10T10:51:50Z

Dim:

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.

== Usages ==
Current known usages are:
* Virtual Environments - complete OS environment, with it's own users, groups, filesystems and devices;
* Application Containers - partly isolated environment with application inside.

== Approaches ==
=== Virtualization on the 2nd level (OpenVZ) ===
'''Requirements''':

The main requirement is that containers should have close to standalone servers networking capabilities. In details:
# containers should have own loopback;
# containers should have ability to setup their own level 3 addresses;
# containers should have ability to sniff their traffic;
# containers should have ability to setup their own routes;
# containers should have ability to receive multicast/broadcast packets;
# containers should have their own netfilters;
# containers should have at least one level 2 device;

'''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;
# Keep sockets isolated by namespace;
# have the loopback isolated;
# have the performance near to native as possible;
# have broadcast and multicast working.

'''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
# guest has a subset of IPs assigned for 'binding'
# source ip (of guest packets) is within the assigned set
# 'local' guest traffic is isolated from other guests
# no measurable overhead on packet routing
# normal routing not impaired (same behaviour as without)
# Guest-Guest and Guest-Host traffic via Loopback

'''Current implementation''':

Network Context with 'assigned' set of IPs, which are used for 'collision' checks at bind
time, 'source' checks at send time and 'destination' checks at receive time. The first
assigned IPs is handled special as it is used for routing decisions outside the IP set.
Loopback traffic isolation is done via IP 'remapping'.

== Virtualization table ==
This is a summary table in order to show which core networking objects are virtualized/isolated in above approaches or not.

{| class="wikitable"
! width="20%" | Virtualization approach
! width="10%" | network devices
! Width="10%" | routing tables
! Width="10%" | network sockets
! Width="10%" | loopback
! Width="10%" | netfilters
|-
| 2d level virtualization || v || v/i || v || v || v
|-
| 3d level virtualization || - || i || i || i || -
|-
| sockets isolation || - || - || i || - || -
|}

Legend:
* 'v' - virtualized
* 'i' - isolated
* '-' - neither virtualized nor isolated

[[Category:Containers]]

Containers/Network virtualization

2006-11-10T10:51:15Z

Dim:

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.

== Usages ==
Current known usages are:
* Virtual Environments - complete OS environment, with it's own users, groups, filesystems and devices;
* Application Containers - partly isolated environment with application inside.

== Approaches ==
=== Virtualization on the 2nd level (OpenVZ) ===
'''Requirements''':

The main requirement is that containers should have close to standalone servers networking capabilities. In details:
# containers should have own loopback;
# containers should have ability to setup their own level 3 addresses;
# containers should have ability to sniff their traffic;
# containers should have ability to setup their own routes;
# containers should have ability to receive multicast/broadcast packets;
# containers should have their own netfilters;
# containers should have at least one level 2 device;

'''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;
# Keep sockets isolated by namespace;
# have the loopback isolated;
# have the performance near to native as possible;
# have broadcast and multicast working.

'''Current implementation''':

For input packets context switching is inherited from the routing entry, for output - inherited from the socket one.

=== Socket isolation (Linux-VServer) ===
'''Requirements''':
# all interfaces and IPs are visible on the host
# routing and iptables is configured on the host
# guest has a subset of IPs assigned for 'binding'
# source ip (of guest packets) is within the assigned set
# 'local' guest traffic is isolated from other guests
# no measurable overhead on packet routing
# normal routing not impaired (same behaviour as without)
# Guest-Guest and Guest-Host traffic via Loopback

'''Current implementation''':

Network Context with 'assigned' set of IPs, which are used for 'collision' checks at bind
time, 'source' checks at send time and 'destination' checks at receive time. The first
assigned IPs is handled special as it is used for routing decisions outside the IP set.
Loopback traffic isolation is done via IP 'remapping'.

== Virtualization table ==
This is a summary table in order to show which core networking objects are virtualized/isolated in above approaches or not.

{| class="wikitable"
! width="20%" | Virtualization approach
! width="10%" | network devices
! Width="10%" | routing tables
! Width="10%" | network sockets
! Width="10%" | loopback
! Width="10%" | netfilters
|-
| 2d level virtualization || v || v/i || v || v || v
|-
| 3d level virtualization || - || i || i || i || -
|-
| sockets isolation || - || - || i || - || -
|}

Legend:
* 'v' - virtualized
* 'i' - isolated
* '-' - neither virtualized nor isolated

[[Category:Containers]]

Containers/Network virtualization

2006-11-08T11:28:37Z

Dim: /* Approaches */

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.

== Usages ==
Current known usages are:
* Virtual Environments - complete OS environment, with it's own users, groups, filesystems and devices;
* Application Containers - partly isolated environment with application inside.

== Approaches ==
=== Virtualization on the 2nd level (OpenVZ) ===
'''Requirements''':

The main requirement is that containers should have close to standalone servers networking capabilities. In details:
# containers should have own loopback;
# containers should have ability to setup their own level 3 addresses;
# containers should have ability to sniff their traffic;
# containers should have ability to setup their own routes;
# containers should have ability to receive multicast/broadcast packets;
# containers should have their own netfilters;
# containers should have at least one level 2 device;

'''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;
# Keep sockets isolated by namespace;
# have the loopback isolated;
# have the performance near to native as possible;
# have broadcast and multicast working.

'''Current implementation''':

For input packets context switching is inherited from the routing entry, for output - inherited from the socket one.

=== Socket virtualization (Linux-VServer) ===
'''Requirements''':
# implementation overhead for established tcp connections should be zero;
# FIXME

'''Current implementation''':

There is no context switching for packets at all, checks are performed between process and socket contexts.

== Virtualization table ==
This is a summary table in order to show which core networking objects are virtualized/isolated in above approaches or not.

{| class="wikitable"
! width="20%" | Virtualization approach
! width="13%" | network devices
! Width="13%" | routing tables
! Width="13%" | network sockets
! Width="13%" | netfilters
|-
| 2d level virtualization || v || v/i || v || v
|-
| 3d level virtualization || - || i || i || -
|-
| bind filtering || - || - || i || -
|}

Legend:
* 'v' - virtualized
* 'i' - isolated
* '-' - neither virtualized nor isolated

[[Category:Containers]]

ToDo

2006-11-07T15:57:29Z

Dim: /* Kernel */

==Kernel==

* NFS issues
* Loopback device (/dev/lo*) support
* vzquota over other than ext2/ext3 filesystems
* Incorporate Zaptel/Asterisk modules [http://forum.openvz.org/index.php?t=msg&th=170&start=0& forum]?
* patch profiling to support VE's differentiation. [http://forum.openvz.org/index.php?t=tree&th=1455&mid=8098&&rev=&reveal=]

==Templates==

* template metadata creation HOWTO
* template metadata rpms build system, like we have for tools
* tool for auto creation rpm/deb packages from precreated templates tarballs for easy installation with yum/apt help
* page for precreated templates submission to contribs
* page with list of all available templates, like http://www.vmware.com/vmtn/appliances/
* templates metadata should include some high-level package manager (yum for FC5, what else?)
* add 'extras' repo to FC5 template metadata

==VE package management==

* x86_64, ia64, ppc64 external package management (vzrpm, vzpkgenv?)
* support for application templates
* apt-based external package management
* adoption for common build system

==Tools==

vzctl:
* add IPv6 configuration support
* Debian-specific initscript
* complete redesign
* [http://bugzilla.openvz.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=OpenVZ&component=vzctl&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= List of opened vzctl bugs in Bugzilla]

==Testing suite==
* should include base vzctl operation, published, easy to install and run on the node.

Containers/Network virtualization

2006-11-02T12:36:26Z

Dim:

Containers/Network virtualization

2006-11-01T17:17:17Z

Dim:

Containers

2006-11-01T16:31:07Z

Dim:

== Topics ==
* [[Containers/Networking]]
* [[Containers/Network_virtualization]]
* [[Containers/Pidcache]]
* [[Containers/Pidspace]]
* [[Containers/UBC discussion]]
* [[Containers/Guarantees for resources]]

== Patches ==
Cedric Le Goater ([[User:Legoater]]) maintains mainstream kernels with the patches from [http://lists.osdl.org/mailman/listinfo/containers containers@ mailing list]:
* http://www.sr71.net/patches/2.6.18/2.6.18-rc7-mm1-lxc1/

== External links ==
* [http://lists.osdl.org/mailman/listinfo/containers "Containers" mailing list]

Containers/Network virtualization

2006-11-01T16:30:12Z

Dim: Network virtualization moved to Containers/Network virtualization: right place

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

== Usages ==
Current known usages are:
* Virtual Environments - complete OS environment, with it's own users, groups, filesystems and devices;
* Application Containers - partly isolated environment with application inside.

== Approaches ==
* '''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.
* '''virtualization on the 3d level (IBM)''';
: For input packets context switching is performed in routing code, for output - inherited from socket one.
* '''socket virtualization (Linux-VServer)'''.
: There is no context switching for packets at all, checks are performed between process and socket contexts.

== Virtualization table ==
This is a summary table in order to show which core networking objects are virtualized/isolated in above approaches or not.

{| border="1" cellpadding="3" cellspacing="0"
! width="20%" | Virtualization approach
! width="13%" | network devices
! Width="13%" | routing tables
! Width="13%" | network sockets
! Width="13%" | netfilters
|-
| 2d level virtualization || v || v/i || v || v
|-
| 3d level virtualization || - || i || i || -
|-
| bind filtering || - || - || i || -
|}

Legend:
* 'v' - virtualized
* 'i' - isolated
* '-' - nor virtualized, nor isolated

Network virtualization

2006-11-01T16:30:12Z

Dim: Network virtualization moved to Containers/Network virtualization: right place

#REDIRECT [[Containers/Network virtualization]]

Containers/Network virtualization

2006-11-01T15:37:53Z

Dim:

Containers/Network virtualization

2006-11-01T15:34:53Z

Dim:

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

== Usages ==
Current known usages are:
* Virtual Environments - complete OS environment, with it's own users, groups, filesystems and devices;
* Application Containers - partly isolated environment with application inside.

== Approaches ==
* 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.
* virtualization on the 3d level (IBM);
: For input packets context switching is performed in routing code, for output - inherited from socket one.
* socket virtualization (Linux-VServer).
: There is no context switching for packets at all, checks are performed between process and socket contexts.

== Virtualization table ==
This is a summary table in order to show which core networking objects are virtualized/isolated in above approaches or not.

{| border="1" cellpadding="3" cellspacing="0"
! width="20%" | Virtualization approach
! width="13%" | network devices
! Width="13%" | routing tables
! Width="13%" | network sockets
! Width="13%" | netfilters
|-
| 2d level virtualization || v || v/i || v || v
|-
| 3d level virtualization || - || i || i || -
|-
| bind filtering || - || - || i || -
|}

Legend:
* 'v' - virtualized
* 'i' - isolated
* '-' - nor virtualized, nor isolated

Containers/Network virtualization

2006-11-01T15:32:59Z

Dim:

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

== Usages ==
Current known usages are:
* Virtual Environments - complete OS environment, with it's own users, groups, filesystems and devices;
* Application Containers - partly isolated environment with application inside.

== Approaches ==
* 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.
* virtualization on the 3d level (IBM);
: For input packets context switching is performed in routing code, for output - inherited from socket one.
* socket virtualization (Linux-VServer).
: There is no context switching for packets at all, checks are perfromed between process and socket contexts.

== Virtualization table ==
This is a summary table in order to show which core networking objects are virtualized/isolated in above approaches or not.

{| border="1" cellpadding="3" cellspacing="0"
! width="20%" | Virtualization approach
! width="13%" | network devices
! Width="13%" | routing tables
! Width="13%" | network sockets
! Width="13%" | netfilters
|-
| 2d level virtualization || v || v/i || v || v
|-
| 3d level virtualization || - || i || i || -
|-
| bind filtering || - || - || i || -
|}

Legend:
* 'v' - virtualized
* 'i' - isolated
* '-' - nor virtualized, nor isolated

Containers/Network virtualization

2006-11-01T15:24:54Z

Dim:

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

== Usages ==
Current known usages are:
* Virtual Environments - complete OS environment, with it's own users, groups, filesystems and devices;
* Application Containers - partly isolated environment with application inside.

== Approaches ==
* 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.
* virtualization on the 3d level (IBM);
: For input packets context switching is performed in routing code, for output - inherited from socket one.
* socket virtualization (Linux-VServer).
: There is no context switching for packets at all, checks are perfromed between process and socket contexts.

== Virtualization table ==
This is a summary table in order to show which core networking objects are virtualized/isolated in above approaches or not.

{| border="1" cellpadding="3" cellspacing="0"
! width="20%" | Virtualization approach
! width="13%" | devices
! Width="13%" | routing tables
! Width="13%" | routing cache
! Width="13%" | sockets
|-
| 2d level virtualization || v || v || i || v
|-
| 3d level virtualization || - || i || - || i
|-
| bind filtering || - || - || - || i
|}

Legend:
* 'v' - virtualized
* 'i' - isolated
* '-' - nor virtualized, nor isolated

Printing in VE with Debian stable

2006-10-20T07:52:42Z

Dim:

Here are the steps to set up a print server (CUPS) on a VE using Debian.

* Create the VE and do your initial setup.
* apt-get cupsys cupsys-bsd foomatic-db cupsomatic-ppd (etc)
* Return to the HN and do the following:
: <code>vzctl set <veid> --devnodes lp0:rw</code>
* If you configured parport, etc, as modules, you'll have to do the following:
: <code>cat << _EOF_ >> /etc/modules
: <code>parport</code>
: <code>parport_pc</code>
: <code>lp</code>
: <code>_EOF_</code>
* Return to the VE and configure your printer in CUPS.

[[Category: HOWTO]]
[[Category: Debian]]

Category:HOWTO

2006-10-20T07:40:46Z

Dim: Previous change is moved to separate article

This category is for various HOWTOs on all the possible topics.

ToDo

2006-10-10T13:29:20Z

Dim:

==Kernel==

* NFS issues
* Loopback device (/dev/lo*) support
* vzquota over other than ext2/ext3 filesystems

==Templates==

* template metadata creation HOWTO
* template metadata rpms build system, like we have for tools
* tool for auto creation rpm/deb packages from precreated templates tarballs for easy installation with yum/apt help
* page for precreated templates submission to contribs
* page with list of all available templates, like [http://www.vmware.com/vmtn/appliances/
* templates metadata should include some high-level package manager (yum for FC5, what else?)
* add 'extras' repo to FC5 template metadata

==VE package management==

* x86_64, ia64, ppc64 external package management (vzrpm, vzpkgenv?)
* support for application templates
* apt-based external package management
* adoption for common build system

==Tools==

vzctl:
* add IPv6 configuration support
* Debian-specific initscript
* complete redesign
* [http://bugzilla.openvz.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=OpenVZ&component=vzctl&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= List of opened vzctl bugs in Bugzilla]

==Testing suite==
* should include base vzctl operation, published, easy to install and run on the node.

ToDo

2006-10-10T12:59:32Z

Dim:

==Kernel==

* NFS issues
* vzquota over other than ext2/ext3 filesystems

==Templates==

* template metadata creation HOWTO
* template metadata rpms build system, like we have for tools
* tool for auto creation rpm/deb packages from precreated templates tarballs for easy installation with yum/apt help.
* page for precreated templates submission to contribs.
* page with list of all available templates, like http://www.vmware.com/vmtn/appliances/
* templates metadata should include "smart" package manager (yum to fc5, what else?)
* add extra repo to fc5 template metadata

==VPS package management==

* x86_64, ia64, ppc64 external package management (vzrpm, vzpkgenv?)
* apt-based external package management
* adoption for common build system

==Tools==

vzctl:
* add IPv6 configuration support
* complete redesign.

ToDo

2006-10-10T12:57:12Z

Dim:

Monitoring openvz resources using nagios and snmp

2006-10-09T08:25:50Z

Dim:

== snmpd configuration ==
Debian Etch example:
<pre>
apt-get install snmpd
</pre>

edit '''/etc/default/snmpd''' : remove ''-u snmp'' and replace ''127.0.0.1'' with your ip, Full'''/etc/default/snmpd''' example:
<pre>
export MIBDIRS=/usr/share/snmp/mibs
SNMPDRUN=yes
SNMPDOPTS='-Lsd -Lf /dev/null -I -smux -p /var/run/snmpd.pid 207.46.250.119'
TRAPDRUN=no
TRAPDOPTS='-Lsd -p /var/run/snmptrapd.pid'
</pre>

Create user(my_username) and add new mib:
<pre>
/etc/init.d/snmpd stop
echo rouser my_username priv > /etc/snmp/snmpd.conf
echo "extend .1.3.6.1.4.1.2021.51 beancounters /bin/cat /proc/user_beancounters" >> /etc/snmp/snmpd.conf
echo createUser my_username MD5 my_password DES >> /var/lib/snmp/snmpd.conf
/etc/init.d/snmpd start
</pre>

Testing snmp:
<pre>
snmpwalk -v 3 -u my_usrname -l authPriv -a MD5 -A my_password -x DES -X my_password 207.46.250.119
</pre>

Warning: the minimum pass phrase length is 8 characters.

== nagios configuration ==
=== example nagios configuration ===
add to configuration:
<pre>
define command {
command_name check_snmp_openvz_on_port
# command_line /usr/local/bin/check_snmp_openvz.sh $HOSTADDRESS$ PORT USER PASSWORD
command_line /usr/local/bin/check_snmp_openvz.sh $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$
}
</pre>

<pre>
define host {
host_name openvz-server
alias Serwer Openvz
address 207.46.250.119
use generic-host
contact_groups admins
}
</pre>

<pre>
define service{
use generic-service
host_name openvz-server
service_description Virtual Machines Limits
check_command check_snmp_openvz_on_port!161!my_username!my_password
max_check_attempts 1
}

</pre>

=== nagios plugin ===
It is shell script:
<pre>
# cat /usr/local/bin/check_snmp_openvz.sh
#!/bin/bash
HOST=$1
PORT=$2
USER=$3
PASS=$4
export FILE=/tmp/$HOST.beancounters
RET=0

DATA=`snmpwalk -v 3 -u $USER -l authPriv -a MD5 -A $PASS -x DES -X $PASS $HOST:$PORT .1.3.6.1.4.1.2021.51.4 \
| perl -ne '/"(.*)"/ ; print "$1\n" ;'`

if [ "$?" != "0" ]; then
echo "Unknown snmp error"
exit 1
fi

if [ -f $FILE ]; then
echo "$DATA" | perl -n -e'
use Data::Dumper;
my $file=$ENV{"FILE"};
my $ret=0 ;
my $vid ;
my $resource ;
my $held ;
my $maxheld ;
my $barrier ;
my $limit ;
my $failcnt ;
my %beancounters ;
my %beancounters_old ;
while(<STDIN>){
my %vmachine;
if ( /\D*(\d+):.*/ ){ $vid=$1; $beancounters{$vid}=\%vmachine ; }
if ( /^[\W\d]+([a-z]+)\s+(\d+)\s+(\d+)\s+(\d+)\s+(\d+)\s+(\d+).*/ ) {
$resource=$1 ;
$held=$2 ;
$maxheld=$3 ;
$barrier=$4 ;
$limit=$5 ;
$failcnt=$6 ;
${beancounters{$vid}}{$resource}=[$held , $maxheld , $barrier , $limit ,$failcnt ];
if ( ($held > $barrier) && ($barrier != 0) ) {
print "WARNING: Limits on $vid: $resource held->$held , barrier->$barrier ( limit->$limit ) \n" ;
$ret=1;
}
}
}

# read and parse old data
open(MYINPUTFILE, "<$file");
while(<MYINPUTFILE>){
my %vmachine;
if ( /\D*(\d+):.*/ ){ $vid=$1; $beancounters_old{$vid}=\%vmachine ; }
if ( /^[\W\d]+([a-z]+)\s+(\d+)\s+(\d+)\s+(\d+)\s+(\d+)\s+(\d+).*/ ) {
$resource=$1 ;
$held=$2 ;
$maxheld=$3 ;
$barrier=$4 ;
$limit=$5 ;
$failcnt=$6 ;
${beancounters_old{$vid}}{$resource}=[$held , $maxheld , $barrier , $limit ,$failcnt ];
}
}

foreach my $vmachine_id (keys %beancounters) {
foreach my $resource (keys %{$beancounters{$vmachine_id}} ) {
if ( defined($beancounters{$vmachine_id}{$resource}[4]) && defined($beancounters_old{$vmachine_id}{$resource}[4]) ){
my $failcnt=$beancounters{$vmachine_id}{$resource}[4];
my $failcnt_old=$beancounters_old{$vmachine_id}{$resource}[4];
my $held=$beancounters{$vmachine_id}{$resource}[0];
my $maxheld=$beancounters{$vmachine_id}{$resource}[1];
my $barrier=$beancounters{$vmachine_id}{$resource}[2];
my $limit=$beancounters{$vmachine_id}{$resource}[3];
if ( $failcnt_old < $failcnt ){
print "CRITICAL: Incrased failcnt $vmachine_id: $resource from $failcnt_old to $failcnt (held->$held , maxheld->$maxheld , barrier->$barrier , limit->$limit ) \n" ;
$ret=2;
}
}
}

}

if ($ret == 0 ) { print "Ok. \n" ; }
# print Dumper(%beancounters_old) ;
exit($ret);
'

RET=$?
fi

echo "$DATA" > $FILE

exit $RET
</pre>

[[Category: HOWTO]]

Using NAT for container with private IPs

2006-07-18T06:58:28Z

Dim:

== How to provide access for VE to Internet ==

To enable the [[VE]]s, which have only internal IP addresses, to access the Internet, SNAT (Source Network Address Translation, also known as IP masquerading) should be configured on the [[Hardware Node]]. This is ensured by the standard Linux <tt>iptables</tt> utility. To perform a simple SNAT setup, execute the following command on the [[Hardware Node]]:
<pre>
# iptables -t nat -A POSTROUTING -s src_net -o eth0 -j SNAT --to ip_address
</pre>

where <tt>src_net</tt> is a range of IP addresses of VEs to be translated by SNAT, and <tt>ip_address</tt> is the external IP address of your [[Hardware Node]]. Multiple rules are allowed, for example, in case you wish to specify several ranges of IP addresses. If you are using a number of physical network interfaces on the [[Hardware Node|Node]], you may need to specify a different interface for outgoing connections, e.g. <tt>-o eth2</tt>.

{{Note|If you are using stable (currently 2.6.8-based) kernel, then to enable SNAT for the VEs on your local network you need to explicitly enable connection tracking in [[VE0]].}}
Make sure that the following string is present in the <tt>/etc/modprobe.conf</tt> file:
<pre>
options ip_conntrack ip_conntrack_enable_ve0=1
</pre>

In case it is not, add this string to the file by means of any text editor (for example, vi). This setting is not needed for kernels more recent than 2.6.8, since connection tracking for [[VE0]] is enabled by default in those kernels.

To make all IP addresses to be translated by SNAT (not only the ones of [[VE]]s with private addresses), you should type the following string:
<pre>
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to ip_address
</pre>

== How to provide access from Internet to a VE ==

In addition, to make some services in VE with private IP address be accessible from the Internet, DNAT (Destination Network Address Translation) should be configured on the [[Hardware Node]]. To perform a simple DNAT setup, execute the following command on the [[Hardware Node]]:
<pre>
# iptables -t nat -A PREROUTING -p tcp -d ip_address --port port_num \
-i eth0 -j DNAT --to-destination ve_address:dst_port_num
</pre>

where <tt>ve_address</tt> is an IP address of the VE, <tt>dst_port_num</tt> is a tcp port which requires service use, <tt>ip_address</tt> is the external (public) IP address of your [[Hardware Node]], and <tt>port_num</tt> is a tcp port of [[Hardware Node]], which will be used for Internet connections to private VE service. Note that this setup makes the service which is using <tt>port_num</tt> on the [[Hardware Node]] be unaccessible from the Internet. Also note that SNAT translation is required too.

For example, if you need a web server in a VE to be accessible from outside and, at the same time, keep a web server on the [[Hardware Node]] be accessible, use the following config:
<pre>
# iptables -t nat -A PREROUTING -p tcp -d ip_address --dport 8080 \
-i eth0 -j DNAT --to-destination ve_address:80
# iptables -t nat -A POSTROUTING -s ve_address -o eth0 -j SNAT --to ip_address
</pre>

After applying this, you'll see VE' web server at <nowiki>http://ip_address:8080/</nowiki>.

The <tt>iptables</tt> utility allows to set up more complex rules for Network Address Translation, involving various protocols and ports. If you wish to get more information on this, consult the numerous Internet sites (e.g. [http://www.netfilter.org netfilter.org]) and tutorials devoted to this issue.

== External Links ==
* [http://www.netfilter.org netfilter.org]

[[Category: HOWTO]]
[[Category: Networking]]

Asterisk in container with Debian stable

2006-07-17T08:08:40Z

Dim:

Below is an example of how to install Asterisk into OpenVZ VE based on debian stable aka. "sarge":

<pre>
$ apt-get install asterisk

$ nano /etc/defaults/asterisk
</pre>

change:
<pre>
RUNASTERISK=no -> yes
AST_REALTIME=yes -> no (for realtime, you need

$ /etc/init.d/asterisk start
</pre>
modify the config files for asterisk, and done!

if you need capi or/and zaptel/zaphfc:

* for capi: you need the /dev files on you hw-node and vps:
<pre>
crw-rw---- 1 root dialout 68, 0 Jan 3 2006 /dev/capi20
crw-rw---- 1 root dialout 68, 1 Jan 3 2006 /dev/capi20.00
crw-rw---- 1 root dialout 68, 2 Jan 3 2006 /dev/capi20.01
crw-rw---- 1 root dialout 68, 3 Jan 3 2006 /dev/capi20.02
[...]
</pre>
/* if the files doesn' exist use mknod for creating it*/

and in your vps config add for directly access:
<pre>
DEVICES="c:68:0:rw, c:68:1:rw, c:68:2:rw"
</pre>
* for zaptel/zaphfc:
<pre>
crw-rw---- 1 root dialout 196, 0 Jan 4 2006 ctl
crw-rw---- 1 root dialout 196, 1 Jan 4 2006 1
crw-rw---- 1 root dialout 196, 2 Jan 4 2006 2
crw-rw---- 1 root dialout 196, 3 Jan 4 2006 3
crw-rw---- 1 root dialout 196, 4 Jan 4 2006 4
[...]
crw-rw---- 1 root dialout 196, 253 Jan 4 2006 timer
crw-rw---- 1 root dialout 196, 255 Jan 4 2006 pseudo
crw-rw---- 1 root dialout 196, 254 Jan 4 2006 channel
</pre>
/* if the files doesn' exist use mknod for creating it*/

and in your vps config
<pre>
DEVICES="c:196:0:rw, c:196:2:rw, c:196:1:rw, c:196:253:rw,c:196:254:rw,c:196:255:rw"
</pre>

if need both (capi and zaphfc)
<pre>
DEVICES="c:68:0:rw, c:68:1:rw, c:68:2:rw c:196:0:rw, c:196:2:rw, c:196:1:rw, c:196:253:rw,c:196:254:rw,c:196:255:rw"
</pre>

[[category:HOWTO]]

Virtual network device

2006-07-05T10:29:13Z

Dim: /* Example */

Vitual network device (<code>venet</code>) is the default network device for a [[VE]]. This network device looks like a peer-to-peer connection between [[VE]] and the [[VE0|host system]]. It does packet switching based on IP header. This is a default network device for VE (an alternative is [[veth]] device).

Venet device is created automatically on [[VE]] start. Vzctl scripts set up an appropriate IP address and other settings on venet inside a VE.

= Virtual network device usage =

== Adding IP address to a VE ==
<pre>
vzctl set <VEID> --ipadd <IP1>[,<IP2>,...] [--save]
</pre>

{{Note|This option is incremental, so IP addresses are added to already existing ones.}}

=== Example ===
<pre>
vzctl set 101 --ipadd 10.0.0.1 --save
</pre>
After executing this command IP address 10.0.0.1 will be added to VE 101 and IP configuration will be saved to a VE configuration file.

== Removing IP address from a VE ==
<pre>
vzctl set <VEID> --ipdel <IP1>[,<IP2>,...] [--save]
vzctl set <VEID> --ipdel all [--save]
</pre>

=== Example ===
<pre>
vzctl set 101 --ipdel 10.0.0.1
</pre>
After executing this command IP address 10.0.0.1 will be removed from VE 101, but IP configuration will not be changed in VE config file. And after VE reboot IP address 10.0.0.1 will be assigned to this VE again.

== See also ==
* [[Virtual ethernet device]]
* [[Differences between venet and veth]]

[[Category: Networking]]
[[Category: HOWTO]]

Using NAT for container with private IPs

2006-06-02T07:53:02Z

Dim:

== How to provide access for VPS to Internet ==

To enable the VPSs, which have only internal IP addresses, to access the Internet, SNAT (Source Network Address Translation, also known as IP masquerading) should be configured on the Hardware Node. This is ensured by the standard Linux iptables utility. To perform a simple SNAT setup, execute the following command on the Hardware Node:
<pre>
# iptables -t nat -A POSTROUTING -s src_net -o eth0 -j SNAT --to ip_address
</pre>

where src_net is a range of IP addresses of VPSs to be translated by SNAT, and ip_address is the external IP address of your Hardware Node. Multiple rules are allowed, for example, in case you wish to specify several ranges of IP addresses. If you are using a number of physical network interfaces on the Node, you may need to specify a different interface for outgoing connections, e.g. -o eth2.

Note: If you are using stable (2.6.8-based) kernel, then to enable SNAT for the VPSs on your local network you should also make sure that the following string is present in the /etc/modules.conf file:
<pre>
options ip_conntrack ip_conntrack_enable_ve0=1
</pre>

In case it is not, add this string to the file by means of any text editor (for example, vi). This setting is not needed for kernels more recent than 2.6.8, since connection tracking for VE0 is enabled by default in those kernels.

To make all IP addresses to be translated by SNAT (not only the ones of VPSs with private addresses), you should type the following string:
<pre>
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to ip_address
</pre>

== How to provide access from Internet to VPS ==

In addition, to make some services in VPS with internal IP address be accessible from the Internet, DNAT (Destination Network Address Translation) should be configured on the Hardware Node. To perform a simple DNAT setup, execute the following command on the Hardware Node:
<pre>
# iptables -t nat -A PREROUTING -p tcp -d ip_address --port port_num -i eth0 -j DNAT --to-destination vps_address:dst_port_num
</pre>

where vps_address is an IP address of VPS, dst_port_num is a tcp port, which required service use, ip_address is the external IP address of your Hardware Node, and port_num is a tcp port of Hardware Node, which will be used for Internet connections to private VPS service. Note that this setup makes the service, which use port_num on the Hardware Node, be unaccessible from the Internet. Also note that SNAT translation is required too.

For example, if you need a web server in a VPS to be accessible from outside, and, at the same time, keep a web server on the Hardware Node be accessible, use the following config:
<pre>
# iptables -t nat -A PREROUTING -p tcp -d ip_address -p 8080 -i eth0 -j DNAT --to-destination vps_address:80
# iptables -t nat -A POSTROUTING -s vps_address -o eth0 -j SNAT --to ip_address
</pre>

After applying this, you'll see VPS' web server at http://ip_address:8080/

The iptables utility allows to set up more complex rules for Network Address Translation, involving various protocols and ports. If you wish to get more information on this, consult the numerous Internet sites (e.g. [http://www.netfilter.org www.netfilter.org]) and tutorials devoted to this issue.

[[Category: HOWTO]]
[[Category: Networking]]

Using NAT for container with private IPs

2006-06-02T07:51:39Z

Dim: MASQUERADE moved to Using NAT for VPS with private IPs

== Using NAT for providing access to/from VPS with private IPs ==

== VPS to Internet ==

To enable the VPSs, which have only internal IP addresses, to access the Internet, SNAT (Source Network Address Translation, also known as IP masquerading) should be configured on the Hardware Node. This is ensured by the standard Linux iptables utility. To perform a simple SNAT setup, execute the following command on the Hardware Node:
<pre>
# iptables -t nat -A POSTROUTING -s src_net -o eth0 -j SNAT --to ip_address
</pre>

where src_net is a range of IP addresses of VPSs to be translated by SNAT, and ip_address is the external IP address of your Hardware Node. Multiple rules are allowed, for example, in case you wish to specify several ranges of IP addresses. If you are using a number of physical network interfaces on the Node, you may need to specify a different interface for outgoing connections, e.g. -o eth2.

Note: If you are using stable (2.6.8-based) kernel, then to enable SNAT for the VPSs on your local network you should also make sure that the following string is present in the /etc/modules.conf file:
<pre>
options ip_conntrack ip_conntrack_enable_ve0=1
</pre>

In case it is not, add this string to the file by means of any text editor (for example, vi). This setting is not needed for kernels more recent than 2.6.8, since connection tracking for VE0 is enabled by default in those kernels.

To make all IP addresses to be translated by SNAT (not only the ones of VPSs with private addresses), you should type the following string:
<pre>
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to ip_address
</pre>

== Internet to VPS ==

In addition, to make some services in VPS with internal IP address be accessible from the Internet, DNAT (Destination Network Address Translation) should be configured on the Hardware Node. To perform a simple DNAT setup, execute the following command on the Hardware Node:
<pre>
# iptables -t nat -A PREROUTING -p tcp -d ip_address --port port_num -i eth0 -j DNAT --to-destination vps_address:dst_port_num
</pre>

where vps_address is an IP address of VPS, dst_port_num is a tcp port, which required service use, ip_address is the external IP address of your Hardware Node, and port_num is a tcp port of Hardware Node, which will be used for Internet connections to private VPS service. Note that this setup makes the service, which use port_num on the Hardware Node, be unaccessible from the Internet. Also note that SNAT translation is required too.

For example, if you need a web server in a VPS to be accessible from outside, and, at the same time, keep a web server on the Hardware Node be accessible, use the following config:
<pre>
# iptables -t nat -A PREROUTING -p tcp -d ip_address -p 8080 -i eth0 -j DNAT --to-destination vps_address:80
# iptables -t nat -A POSTROUTING -s vps_address -o eth0 -j SNAT --to ip_address
</pre>

After applying this, you'll see VPS' web server at http://ip_address:8080/

The iptables utility allows to set up more complex rules for Network Address Translation, involving various protocols and ports. If you wish to get more information on this, consult the numerous Internet sites (e.g. [http://www.netfilter.org www.netfilter.org]) and tutorials devoted to this issue.

[[Category: HOWTO]]
[[Category: Networking]]

MASQUERADE

2006-06-02T07:51:39Z

Dim: MASQUERADE moved to Using NAT for VPS with private IPs

#REDIRECT [[Using NAT for VPS with private IPs]]

Using NAT for container with private IPs

2006-06-02T07:49:08Z

Dim:

Using NAT for container with private IPs

2006-06-02T07:48:34Z

Dim:

== Using NAT for providing access to/from VPS with private IPs ==

== VPS to Internet ==

To enable the VPSs, which have only internal IP addresses, to access the Internet, SNAT (Source Network Address Translation, also known as IP masquerading) should be configured on the Hardware Node. This is ensured by the standard Linux iptables utility. To perform a simple SNAT setup, execute the following command on the Hardware Node:
<pre>
# iptables -t nat -A POSTROUTING -s src_net -o eth0 -j SNAT --to ip_address
</pre>

where src_net is a range of IP addresses of VPSs to be translated by SNAT, and ip_address is the external IP address of your Hardware Node. Multiple rules are allowed, for example, in case you wish to specify several ranges of IP addresses. If you are using a number of physical network interfaces on the Node, you may need to specify a different interface for outgoing connections, e.g. -o eth2.

Note: If you are using stable (2.6.8-based) kernel, then to enable SNAT for the VPSs on your local network you should also make sure that the following string is present in the /etc/modules.conf file:
<pre>
options ip_conntrack ip_conntrack_enable_ve0=1
</pre>

In case it is not, add this string to the file by means of any text editor (for example, vi). This setting is not needed for kernels more recent than 2.6.8, since connection tracking for VE0 is enabled by default in those kernels.

To make all IP addresses to be translated by SNAT (not only the ones of VPSs with private addresses), you should type the following string:
<pre>
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to ip_address
</pre>

== Internet to VPS ==

In addition, to make some services in VPS with internal IP address be accessible from the Internet, DNAT (Destination Network Address Translation) should be configured on the Hardware Node. To perform a simple DNAT setup, execute the following command on the Hardware Node:

# iptables -t nat -A PREROUTING -p tcp -d ip_address --port port_num -i eth0 -j DNAT --to-destination vps_address:dst_port_num

where vps_address is an IP address of VPS, dst_port_num is a tcp port, which required service use, ip_address is the external IP address of your Hardware Node, and port_num is a tcp port of Hardware Node, which will be used for Internet connections to private VPS service. Note that this setup makes the service, which use port_num on the Hardware Node, be unaccessible from the Internet. Also note that SNAT translation is required too.

For example, if you need a web server in a VPS to be accessible from outside, and, at the same time, keep a web server on the Hardware Node be accessible, use the following config:
<pre>
# iptables -t nat -A PREROUTING -p tcp -d ip_address -p 8080 -i eth0 -j DNAT --to-destination vps_address:80
# iptables -t nat -A POSTROUTING -s vps_address -o eth0 -j SNAT --to ip_address
</pre>

After applying this, you'll see VPS' web server at http://ip_address:8080/

The iptables utility allows to set up more complex rules for Network Address Translation, involving various protocols and ports. If you wish to get more information on this, consult the numerous Internet sites (e.g. [http://www.netfilter.org www.netfilter.org]) and tutorials devoted to this issue.

[[Category: HOWTO]]
[[Category: Networking]]

FAQ

2006-05-30T15:47:22Z

Dim: