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

headers Phil Lello | 1 Jul 2011 17:39 · /names/

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

Greetings,

----- Original Message -----
> The jails need to emulate Ubuntu 10.04 (kernel 2.6.32), however I
> believe the patches for this kernel are still experimental.
> 
> Is this true? If so, are the known issues to do with stability or
> security?

Depends.

There are two branches based on 2.6.32... the generic one and the RHEL6-based one.  Both are still marked as
"Development" here:

http://wiki.openvz.org/Download/kernel

There is also a 2.6.32-based kernel that Debian has in their repos for Debian 6.  I believe it uses the OpenVZ
2.6.32 generic patch but of course Debian's kernel isn't the stock kernel.org kernel.

I've heard of a few differences in functionality between the RHEL6-based kernel and that shipped by
Debian.  Ubuntu does not offer an OpenVZ kernel that I'm aware of.

I've been using the RHEL6-based kernel on RHEL 6.1 and it seems to work fine but it isn't a production machine
and I haven't done a whole lot of testing.  The OpenVZ Project has been updating the RHEL6-based kernel
frequently both to keep up with RHEL kernel updates as well as fix OpenVZ-related bugs that are reported.

So, what host node distro are you planning on using?  I'd recommend using the RHEL6-based OpenVZ kernel if at
all possible.  If you haven't done so already, I strongly recommend you setup a system and give it a try for
yourself... and do some testing.  If you find any bugs report them to bugzilla.openvz.org.

TYL,
--

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

Hello,
We have some servers with some more OpenVZs installed. All running
Debian lenny, squeeze and lenny bpo.
Now we have some troubles with the Hostname and FQDN of some VZ's. In
the config files of all VZs is the HOSTNAME set to the FQDN. The NAME is
set to the Hostname of the host.
In some hosts we can now see, that /etc/hostname is the FQDN, in some
not. In the VZ's where in the /etc/hostname is the hostname, $(hostname
-f) gives the FQDN... So i think some hosts have some problems with the
hostname and the real FQDN...

So what is the right usage of HOSTNAME and NAME in the VZ conf? where i
should use the FQDN and where just the hostname?

thanks!
sebastian

Greetings,

----- Original Message -----
> So what is the right usage of HOSTNAME and NAME in the VZ conf? where i
> should use the FQDN and where just the hostname?

vzctl's --name flag is just for vzctl so you can use a name rather than the ctid... just like hostnames are
generally friendlier than IP addresses.  It is really just a symlink in /etc/vz/names/ that points to the
config.  To the best of my knowledge, only vzctl allows you to use it... whereas, for example, vzmigrate
does not.

The --hostname flag is for setting the hostname of the container.  Where the value gets written into the
container is distro specific.  For example, in Red Hat / Fedora OS Templates, the value gets written to
/etc/sysconfig/network.  Other distros might expect it to be elsewhere.

The man page for vzctl is a little lean in the descriptions for --name and --hostname but I think it is clear enough.

TYL,
--

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

Hi All,

I'm running Asterisk servers on OVZ with great success.  Most of the
systems are pretty small usage, just a few phones and active channels.
 I used vzsplit to generate my resource parameters so all systems are
set equally on the hardware node.

Sometimes I'll get a container pushing the limits of these 2 resources:

othersockbuf          21.88 kb      562.56 kb      553.39 kb
1.98 mb             59
dgramrcvbuf            0.00 kb      260.06 kb      260.42 kb
260.42 kb           70

I assume this is due to active calls.

Can someone shed some light on the direct correlation between UDP
sockets and VoIP Calls?  Are the resource parameter in kb the amount
of UDP bandwidth on the network?  All VoIP/RTP traffic is UDP G.711.

I do not have any complaints about voice quality issues or anything
that would indicate the incremental counts over the soft limit are
really affecting performance of the container or the VoIP Service.

Would it be ok increase the soft limits to something like 1/4 or 1/2
the total resource of the hardware node and increase the hard limit to
MAX_ULONG?

Any suggestions or info would be appreciated.

Thanks.

JR
--

-- 
JR Richardson
Engineering for the Masses

I have a small VPS I use for testing and personal projects which is
run under openVZ by a commercial provider. About 3 weeks ago, the
provider migrated to using new Xeon "Sandy Bridge" processors.  I do a
lot of things with apache mod_perl, and at that point, most of it broke;
the apache worker exits after receiving SIGILL, "Illegal instruction".

That is not a perl error, and a very simple test case confirmed this.
So I ran apache in gdb and have a backtrace pasted here:

http://pastebin.com/16SrEzHM

This backtrace is nearly identical to one from a bug reported last year
for glibc 2.12 on AVX enabled hardware:

http://sourceware.org/bugzilla/show_bug.cgi?format=multiple&id=12113

Wikipedia claims that the 2011 Xeon "Sandy Bridge" is the only
currently available processor using these new extensions:

http://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX

Apparently glibc 2.13, gcc 4.6, and kernel 2.6.30 support AVX.  I
imagine this is generally true as I could find no reports of any 
problem besides the glibc 2.12 issue from last year.   There is a
"small reproducer" .zip attached to that report, and it does reproduce
on the VPS, which is running Fedora 14, glibc 2.13 built with gcc
4.5.1, and kernel 2.6.32-238.

So I reported this as a glibc bug, but with fedora:

https://bugzilla.redhat.com/show_bug.cgi?id=720176

Andreas Schwab points out there that according to my dump
of /proc/cpuinfo (in the report), the processor *is not* AVX enabled.
However, it definitely is a "Sandy Bridge" and the model number from
cpuinfo, "Intel(R) Xeon(R) CPU E31230", is according to Intel an AVX
processor:

http://ark.intel.com/Product.aspx?id=52271

This lead me to ask about the issue on the linux kernel devel mailing
list.   Responses there claim that this is likely due to the
virtual containerization (ie, openVZ) screwing up the cpu flags. 

Could that be due to some misconfiguration by the vendor?  Right now,
they claim no one else has reported such a problem, but have no idea
how many (if any) of their other clients are running mod_perl, and the
only other software I have noticed which triggers the problem is the
"small reproducer" (qv.) from the original glibc 2.12 bugzilla report on
sourceware.org.

Or could this be a problem intrinsic to openVZ?

Sincerely, Mark Eriksen

--

-- 
"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)
"The angel of history[...]is turned toward the past." (Walter Benjamin)

I started getting a strange stderr message from vzlist

[root <at> rc5 ~]# vzlist | head
Invalid value for DEVICES=c:196:255:rw, skipped
       CTID      NPROC STATUS    IP_ADDR         HOSTNAME
...

Thanks for any clues or information about how I can find the 
"c:196:255:rw" device.

Cheers!
Gary

Gary Wallis wrote:
> I started getting a strange stderr message from vzlist
> 
> [root <at> rc5 ~]# vzlist | head
> Invalid value for DEVICES=c:196:255:rw, skipped
>       CTID      NPROC STATUS    IP_ADDR         HOSTNAME
> ...
> 
> Thanks for any clues or information about how I can find the 
> "c:196:255:rw" device.
> 
> Cheers!
> Gary
> _______________________________________________
> Users mailing list
> Users@...
> https://openvz.org/mailman/listinfo/users
> 
> 

Found it...it is the pseudo dev

[root <at> rc5 ~]# ls -Rl /dev | grep 196 | grep 255
crw-rw----  1 root root 196, 255 Feb  1 14:55 pseudo

Main issue remains: Any ideas why this dev would have an invalid value?

5	June 2013
30	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

Migrating to OpenVZ from BSD jails

Re: Migrating to OpenVZ from BSD jails

Right use of Hostname and Name

Re: Right use of Hostname and Name

UDP socket buffer strategy for VoIP Service Containers

Problems on AVX "Sandy Bridge" hardware

vzlist stderr message Invalid value for DEVICES

Re: vzlist stderr message Invalid value for DEVICES

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