diff --git a/docs/OpenVZ.xml b/docs/OpenVZ.xml index c48779950..17c54fc34 100644 --- a/docs/OpenVZ.xml +++ b/docs/OpenVZ.xml @@ -18,7 +18,7 @@ - 2008 + 2009 Thomas M. Eastep @@ -42,9 +42,10 @@ Parallels (formerly SWSoft). Virtual servers take the form of - containers which are created via - templates. Templates are available for a wide - variety of distributions and architectures. + containers (the OpenVZ documentation calls these + Virtual Environments or VEs) + which are created via templates. Templates are + available for a wide variety of distributions and architectures. OpenVZ requires a patched kernel. Beginning with Lenny, Debian supplies OpenVZ kernels through the standard @@ -70,10 +71,10 @@ interface (/proc/sys/net/ipv4/conf/interface/proxy_arp). - OpenVZ creates virtual interfaces in the host with very odd - configurations. + OpenVZ creates a point-to-point virtual interface in the host with + a rather odd configuration. - Example: + Example (Single VE with IP address 206.124.146.178): gateway:~# ip addr ls dev venet0 10: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN @@ -85,8 +86,8 @@ gateway:~# The interface has no IP configuration yet it has a route to 206.124.146.178! - From within the container with IP address 206.124.146.178, we have - the following: + From within the VE with IP address 206.124.146.178, we have the + following: server:~ # ip addr ls 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN @@ -169,36 +170,57 @@ vz venet0 - #SOURCE DEST PROVIDER PRIORITY - 206.124.146.178 main 1000 + +
+ RFC 1918 Addresses in a Container + + You can assign an RFC 1918 address to a VE and use masquerade/SNAT + to provide Internet access to the container. This is just a normal + simple Shorewall configuration as shown in the Two-interface Quick Start Guide. In this + configuration the firewall's internal interface is venet0. +
- Shorewall in an OpenVZ Container + Shorewall in an OpenVZ Virtual Environment - If you have optained an OpenVZ container from a service provider, - you may find it difficult to configure any type of firewall within the - container. There are two container parameters that control iptables - behavior within the container: + If you have obtained an OpenVZ VE from a service provider, you may + find it difficult to configure any type of firewall within your VE. There + are two VE parameters that control iptables behavior within the + container: --iptables name - Restrict access to iptables modules inside a container (by - default all iptables modules that are loaded in the host system are - accessible inside a container). + Restrict access to iptables modules inside a container (The + OpenVZ claims that by default all iptables modules that are loaded + in the host system are accessible inside a container; I haven't + tried that). - You can use the following values for name: iptable_filter, - iptable_mangle, ipt_limit, ipt_multiport, ipt_tos, ipt_TOS, - ipt_REJECT, ipt_TCPMSS, ipt_tcpmss, ipt_ttl, ipt_LOG, ipt_length, - ip_conntrack, ip_conntrack_ftp, ip_conntrack_irc, ipt_conntrack, - ipt_state, ipt_helper, iptable_nat, ip_nat_ftp, ip_nat_irc, - ipt_REDIRECT, xt_mac, ipt_owner. + You can use the following values for + name: , + , , + , , + , , + , , + , , + , , + , + , , + , , + , , + , , + , . If your provider is using this option, you may be in deep - trouble using Shorewall. Look at the output of shorewall - show capabilities and weep. Then try to get your provider - to remove this restriction on your container. + trouble trying to use Shorewall in your container. Look at the + output of shorewall show capabilities and weep. + Then try to get your provider to remove this restriction on your + container.