OpenVZ is an Operating System-level server virtualization solution, built on Linux. OpenVZ creates isolated, secure virtual environments

headers Mike Chen | 1 May 2010 07:58 · /proc/

Hi everyone.

I found some threads in OpenVZ's forum about MASQUERADE in iptables
that said it's not yet supported. Can someone conform this?

Thx.

 Mike> Hi everyone. I found some threads in OpenVZ's forum about
 Mike> MASQUERADE in iptables that said it's not yet supported. Can
 Mike> someone conform this?

It works but you can use the SNAT target instead which is the preferred
way to map addresses because is creates less overhead.

The MASQUERADE target is mostly only used with dynamically assigned IP
connections i.e. when we do not know the actual IP address upfront (read
DHCP). If you have a static IP address, then you should use the SNAT
target which works perfectly fine with OpenVZ.

_______________________________________________
Users mailing list
Users@...
https://openvz.org/mailman/listinfo/users

I'm attempting to configure multiple tagged vlans over a bridged interface to allow my containers to
obtain dhcp leases from different networks.  The host OS is centos. Is there any documentation regarding
the steps involved in this type of setup?  I haven't been able to find anything that precisely matches this config.

It seems to work with a single vlan, but as soon as I attempt to add a second eth0.<VLAN> interface, it stops working.

I figured someone must be doing this.  If I leave out the vlans, everything works fine using the default
vlan...guests can dhcp lease their network addresses, etc.

I'm using the latest openvz utils and kernel from the openvz yum repo.  The base OS is CentOS 5.2 x86_64.

"Red Hat" style ifcfg- config files would be great.

Thanks for your help.

-jeremy

Greetings,

Late this afternoon the CentOS project announced the release of CentOS 5.5.  I built i386 and x86_64 OS
Templates for CentOS 5.5 and have uploaded them to the contrib site.  Anyone interested can find them here:

http://download.openvz.org/template/precreated/contrib/

They are currently named:

centos-5-i386-default-5.5-20100514.tar.gz and centos-5-x86_64-default-5.5-20100514.tar.gz

But their names will change over time as I update them about once a month.

Enjoy,
--

-- 
Scott Dowdle
704 Church Street
Belgrade, MT 59714
(406)388-0827 [home]
(406)994-3931 [work]

_______________________________________________
Users mailing list
Users@...
https://openvz.org/mailman/listinfo/users

http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.5

On 05/15/2010 10:08 AM, SD :: Ventas wrote:
> Sorry if i ask this, but do you have the changelog?? to see wich is the
> difference between 5.4 and 5.5 ???
>
> thank you.
>
> Ing. Alejandro M.
> -----------------------
> Hospedaje Web y Servidores Dedicados
> http://www.dedicados.com.mx
> -----------------------
> ventas@...
> -----------------------
>
>
> El 14/05/2010 09:08 p.m., Scott Dowdle escribió:
>> Greetings,
>>
>> Late this afternoon the CentOS project announced the release of CentOS 5.5.  I built i386 and x86_64 OS
Templates for CentOS 5.5 and have uploaded them to the contrib site.  Anyone interested can find them here:
>>
>> http://download.openvz.org/template/precreated/contrib/
>>
>> They are currently named:
>>
>> centos-5-i386-default-5.5-20100514.tar.gz and centos-5-x86_64-default-5.5-20100514.tar.gz
>>
>> But their names will change over time as I update them about once a month.
>>
>> Enjoy,
>>
>
>
> _______________________________________________
> Users mailing list
> Users@...
> https://openvz.org/mailman/listinfo/users

G'day.

We are currently looking into doing more monitoring and management of our VEs
from the hardware node, and as part of that we would like to have access to a
reasonably reliable mapping of VE id to VE init process PID on the host node.

(This would be, basically, the equivalent of /var/run/foo.pid, where foo was
 the VEID, and the PID was the host-node PID of the init process.)

This mapping would make it easier for our tools to first verify that the init
process was correct[1], then to walk the process tree or otherwise inspect the
children running in that container.

Sadly, to my eye it doesn't look possible to capture this without a private
patch to the vzctl tool[2], since none of the current hooks have access to the
information, and the init process forks away to a new PGIG, SID, etc, quite
deliberately (and sensibly.)

So ... is there any sensibly way I could implement this without needing a
private patch, other than to scan the process table after starting the
container and rebuilding that mapping?

        Daniel

Footnotes: 
[1]  Check /proc/$pid/status for matching envID, and VPid of 1, to verify that
     the init process matches our mapping.  If not, raise a warning because
     something unexpected has happened.

[2]  ...and the assumption that only vzctl starts containers, which is an
     assumption I can live with: this all is supposed to improve our
     monitoring capabilities, not prevent a hostile root-capable user on the
     hardware node from doing something dubious.

--

-- 
✣ Daniel Pittman            ✉ daniel@...            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

Hi Daniel,

a simple solution can be, take a look to /proc of running contaier from
ct0.

 <path-to-ct-root>/proc/1/stat

e.g.

$ awk '{ print $1 }' /var/lib/vz/root/20123/proc/1/stat
28858
^_real pid at ct0

Hope this helps.

Bye,
 Thorsten

On Sun, 16 May 2010 19:43:58 +1000, Daniel Pittman <daniel@...>
wrote:
> G'day.
> 
> We are currently looking into doing more monitoring and management of
our
> VEs
> from the hardware node, and as part of that we would like to have access
> to a
> reasonably reliable mapping of VE id to VE init process PID on the host
> node.
> 
> (This would be, basically, the equivalent of /var/run/foo.pid, where foo
> was
>  the VEID, and the PID was the host-node PID of the init process.)
> 
>(...)

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31

23	May 2013
23	April 2013
24	March 2013
22	February 2013
36	January 2013
23	December 2012
42	November 2012
29	October 2012
72	September 2012
29	August 2012
49	July 2012
41	June 2012
56	May 2012
64	April 2012
113	March 2012
31	February 2012
46	January 2012
39	December 2011
83	November 2011
55	October 2011
40	September 2011
66	August 2011
8	July 2011
33	June 2011
75	May 2011
30	April 2011
33	March 2011
17	February 2011
21	January 2011
37	December 2010
41	November 2010
11	October 2010
52	September 2010
46	August 2010
122	July 2010
76	June 2010
48	May 2010
88	April 2010
67	March 2010
61	February 2010
86	January 2010
53	December 2009
57	November 2009
22	October 2009
45	September 2009
47	August 2009
42	July 2009
50	June 2009
28	May 2009
25	April 2009
58	March 2009
53	February 2009
130	January 2009
92	December 2008
94	November 2008
35	October 2008
93	September 2008
95	August 2008
65	July 2008
70	June 2008
107	May 2008
41	April 2008
68	March 2008
81	February 2008
104	January 2008
208	December 2007
85	November 2007
80	October 2007
92	September 2007
62	August 2007
51	July 2007
54	June 2007
98	May 2007
95	April 2007
147	March 2007
56	February 2007
55	January 2007
77	December 2006
50	November 2006
47	October 2006
23	September 2006
43	August 2006
15	July 2006
39	June 2006
62	May 2006
19	April 2006
66	February 2006
36	January 2006
3	December 2005
8	November 2005
18	September 2005
1	January 2004

Will I be able to use MASQUERADE in iptables?

Re: Will I be able to use MASQUERADE in iptables?

回复： [Users] Re: Will I be able to use MASQUERADE in iptables?

Problem Process in D state

tagged vlan and bridges

CentOS 5.5 released, contributed OS Templates available

Re: CentOS 5.5 released, contributed OS Templates available

Re: CentOS 5.5 released, contributed OS Templates available

Capturing the PID of every VE during startup / shutdown.

Re: Capturing the PID of every VE during startup / shutdown.