headers
Aleksandar Ivanisevic | 1 Apr 2009 16:37
X-Face
Picon
Gravatar

Re: Auto mounting NFS mount points when a container starts

"Bailey, Darragh" <dbailey@...> writes:

> I haven't tried using rc.local yet, I don't know if that gets called,
> but it might take care of the problem.

It does. I use it to set specific MTU on the network interfaces, since
this is at least AFAIK, not possible to do via network config.

--

-- 
Gle, svaka cast tebi i tvom poslu ali kaj nas moras svaki puta dojit sa 
tvojom placom i poslom itd. Pa svaki post koji postas prije ili kasnije 
pocinje aludirati na tvoje vrhunaravne izvore prihoda i materijalnih dobara. 
Daj se sredi malo. Mislim da na ama bas nikoga ne zanima koliko ti zaradujes 
i kako trosis svoje pare. Tomislav Kralj - hr.comp.programiranje.baze
Permalink | Reply | 1 comment |
headers
Frank | 2 Apr 2009 08:42

Re: Oracle on a VE(Solved)

Hi Konstantin,
as you told me swap was the only problem you had, I focused on that. I
found the "--meminfo none" VE setting that makes VE sees memory as host
system. With this, there was no more internals error, just "not enough
memory errors" than you can fix adjusting oracle memory settings. At
last,I got it! I have oracle 11 installed and working on the VE!

The only thing I'm not sure about is if using "--meminfo none" setting on
the VE is a good idea or it can be dangerous in any way, because with this
the VE has the same memory limits as host sustem, and perhaps that can
lead to problems.

What do you think?
Regards.

Frank

> Date: Tue, 31 Mar 2009 16:29:18 +0400
> From: Konstantin Khorenko <khorenko@...>
> Subject: Re: [Users] Oracle on a VE
> To: users@...
> Message-ID: <49D20C9E.7090206@...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Frank,
>
>> So I am on the same point. I have not found any documented installation
>> of Oracle 11 on a VE, only of Oracle 10.
>> Do you know any?
> We tried to install Oracle 11 inside a Container once using the guide for
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bailey, Darragh | 2 Apr 2009 14:23
Picon
Favicon

RE: Re: Auto mounting NFS mount points when a container starts [SOLVED]


> -----Original Message-----
> From: users-bounces@... 
> [mailto:users-bounces@...] On Behalf Of Aleksandar Ivanisevic
> Sent: 01 April 2009 15:38
> To: users@...
> Subject: [Users] Re: Auto mounting NFS mount points when a 
> container starts
> 
> "Bailey, Darragh" <dbailey@...> writes:
> 
> > I haven't tried using rc.local yet, I don't know if that 
> gets called,
> > but it might take care of the problem.
> 
> It does. I use it to set specific MTU on the network interfaces, since
> this is at least AFAIK, not possible to do via network config.

Found the correct solution, enable the "netfs" and "portmap" services. This appears to correct automount
the nfs filesystems as required. By default they are disabled in the templates.

--
Regards,
Darragh Bailey

Systems Software Engineer
Hewlett Packard Galway Ltd.

Postal Address:    Hewlett Packard Galway Limited, Ballybrit Business Park, Galway
Registered Office: Hewlett Packard Galway Limited, 63-74 Sir John Rogerson's Quay Dublin 2
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marco d'Itri | 7 Apr 2009 13:27
Picon
Favicon

entering a VE

Can somebody explain the exact roles of setluid() and of the
VZCTL_ENV_CREATE ioctl or point me to documentation?

I am trying to write a replacement of "vzctl enter", but my ultimate
goal is to write a PAM module which can be used by cron/ssh/etc running
in the HN to switch to the VE context. The code will be GPL'ed.
(If anybody believes that this cannot work then it is the right time to
say it...)

I also do not understand well the issues related to open file
descriptors: why does vzctl use pipes between the two processes for
stdin/out/err?
Will anything change if stdin/out/err are connected to sockets instead
of ttys?

--

-- 
ciao,
Marco
Permalink | Reply | 0 comments |
headers
Edward Hibbert | 9 Apr 2009 12:41
Favicon

Trouble getting the 4G (a.k.a. hugemem) patch to work.

Apologies if this is a dumb FAQ. 
 
I'm trying to get a kernel with what's known in the RedHat world as hugemem, i.e. 4G user space.  I've downloaded a -ent version of the 2.6.18 kernel, and also tried building one myself, but neither of these seems to allow me to exceed 3G. 
 
The source code does seem to have 4G macros in it, and I find it hard to believe that the patch simply doesn't work - so I'm more inclined to think I'm doing something stupid. 
 
Any suggestions?  Yes, yes, I know we should move to 64-bit, but that's not an option right now.
 
Regards,
 
Edward.
_______________________________________________
Users mailing list
Users@...
https://openvz.org/mailman/listinfo/users
Permalink | Reply | 0 comments |
headers
Edward Hibbert | 9 Apr 2009 14:30
Favicon

RE: Trouble getting the 4G (a.k.a. hugemem) patch to work.

One other bit of info; I'm fairly sure that the 4G patch is built in to the kernel, because I can see this during the boot sequence:
 
mapped 4G/4G trampoline to fff6d000.
So that leaves me baffled as to why I can't get a process above 3G.

From: Edward Hibbert
Sent: 09 April 2009 11:41
To: 'users-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org'
Subject: Trouble getting the 4G (a.k.a. hugemem) patch to work.

Apologies if this is a dumb FAQ. 
 
I'm trying to get a kernel with what's known in the RedHat world as hugemem, i.e. 4G user space.  I've downloaded a -ent version of the 2.6.18 kernel, and also tried building one myself, but neither of these seems to allow me to exceed 3G. 
 
The source code does seem to have 4G macros in it, and I find it hard to believe that the patch simply doesn't work - so I'm more inclined to think I'm doing something stupid. 
 
Any suggestions?  Yes, yes, I know we should move to 64-bit, but that's not an option right now.
 
Regards,
 
Edward.
_______________________________________________
Users mailing list
Users@...
https://openvz.org/mailman/listinfo/users
Permalink | Reply | 668 comments |
headers
Kirill Korotaev | 9 Apr 2009 15:07
Favicon

Re: RE: Trouble getting the 4G (a.k.a. hugemem) patch to work.

default OpenVZ kernel is built with 3GB / 4GB split, not 4/4. for
compatibility with some old java versions.
So user space is limited to 3GB as usually.

On 4/9/09 4:30 PM, "Edward Hibbert" <Edward.Hibbert@...> wrote:

> One other bit of info; I'm fairly sure that the 4G patch is built in to the
> kernel, because I can see this during the boot sequence:
>  
> mapped 4G/4G trampoline to fff6d000.
> So that leaves me baffled as to why I can't get a process above 3G.
> 
> 
> From: Edward Hibbert
> Sent: 09 April 2009 11:41
> To: 'users@...'
> Subject: Trouble getting the 4G (a.k.a. hugemem) patch to work.
> 
> Apologies if this is a dumb FAQ.
>  
> I'm trying to get a kernel with what's known in the RedHat world as hugemem,
> i.e. 4G user space.  I've downloaded a -ent version of the 2.6.18 kernel, and
> also tried building one myself, but neither of these seems to allow me to
> exceed 3G.  
>  
> The source code does seem to have 4G macros in it, and I find it hard to
> believe that the patch simply doesn't work - so I'm more inclined to think I'm
> doing something stupid.
>  
> Any suggestions?  Yes, yes, I know we should move to 64-bit, but that's not an
> option right now.
>  
> Regards,
>  
> Edward.
Permalink | Reply | 1 comment |
headers
Bailey, Darragh | 9 Apr 2009 14:55
Picon
Favicon

RE: Trouble getting the 4G (a.k.a. hugemem) patch to work.


I'm guessing that you are using the 32bit version since 64bit version doesn't require a hugemem version to
address about 4GB.

You should try using the PAE version, see the following post
http://www.mail-archive.com/rhelv5-list-H+wXaHxf7aLQT0dZR+AlfA <at> public.gmane.org/msg04272.html

It explains that if you use the standard 32bit hugemem version that much of the memory area reserved for the
kernel is used up for addressing the memory above 4GB. Where as the PAE kernel is for systems that support
PAE, which has 36bits for addressing memory and will avoid any weird memory mapping issues all the way up to
64GB. Still though if you need a system with more than 16GB, you're better off using 64bit.

--
Regards,
Darragh Bailey

Systems Software Engineer
Hewlett Packard Galway Ltd.

Postal Address:    Hewlett Packard Galway Limited, Ballybrit Business Park, Galway 
Registered Office: Hewlett Packard Galway Limited, 63-74 Sir John Rogerson's Quay Dublin 2
Registered Number: 361933

_______________________________________________
The contents of this message and any attachments to it are confidential and may be legally privileged. If
you have received this message in error you should delete it from your system immediately and advise the sender.
To any recipient of this message within HP, unless otherwise stated you should consider this message and
attachments as "HP CONFIDENTIAL".

> -----Original Message-----
> From: users-bounces@... 
> [mailto:users-bounces@...] On Behalf Of Edward Hibbert
> Sent: 09 April 2009 13:30
> To: users@...
> Subject: [Users] RE: Trouble getting the 4G (a.k.a. hugemem) 
> patch to work.
> 
> One other bit of info; I'm fairly sure that the 4G patch is 
> built in to the kernel, because I can see this during the 
> boot sequence:
>  
> mapped 4G/4G trampoline to fff6d000.
> 
> So that leaves me baffled as to why I can't get a process above 3G.
> 
> ________________________________
> 
> From: Edward Hibbert 
> Sent: 09 April 2009 11:41
> To: 'users@...'
> Subject: Trouble getting the 4G (a.k.a. hugemem) patch to work.
> 
> 
> Apologies if this is a dumb FAQ.  
>  
> I'm trying to get a kernel with what's known in the RedHat 
> world as hugemem, i.e. 4G user space.  I've downloaded a -ent 
> version of the 2.6.18 kernel, and also tried building one 
> myself, but neither of these seems to allow me to exceed 3G.  
>  
> The source code does seem to have 4G macros in it, and I find 
> it hard to believe that the patch simply doesn't work - so 
> I'm more inclined to think I'm doing something stupid.  
>  
> Any suggestions?  Yes, yes, I know we should move to 64-bit, 
> but that's not an option right now.
>  
> Regards,
>  
> Edward.
>
Permalink | Reply | 668 comments |
headers
Edward Hibbert | 9 Apr 2009 15:12
Favicon

RE: RE: Trouble getting the 4G (a.k.a. hugemem) patch to work.

Thanks for your reply.

I thought the -ent version was built with 4/4?

If not, can I enable it?  How?

Kirill Korotaev wrote:
> default OpenVZ kernel is built with 3GB / 4GB split, not 4/4. for
> compatibility with some old java versions. So user space is limited
> to 3GB as usually. 
> 
> On 4/9/09 4:30 PM, "Edward Hibbert" <Edward.Hibbert@...>
> wrote: 
> 
>> One other bit of info; I'm fairly sure that the 4G patch is built in
>> to the kernel, because I can see this during the boot sequence:
>> 
>> mapped 4G/4G trampoline to fff6d000.
>> So that leaves me baffled as to why I can't get a process above 3G.
>> 
>> 
>> From: Edward Hibbert
>> Sent: 09 April 2009 11:41
>> To: 'users@...'
>> Subject: Trouble getting the 4G (a.k.a. hugemem) patch to work.
>> 
>> Apologies if this is a dumb FAQ.
>> 
>> I'm trying to get a kernel with what's known in the RedHat world as
>> hugemem, i.e. 4G user space.  I've downloaded a -ent version of the
>> 2.6.18 kernel, and also tried building one myself, but neither of
>> these seems to allow me to exceed 3G.
>> 
>> The source code does seem to have 4G macros in it, and I find it hard
>> to believe that the patch simply doesn't work - so I'm more inclined
>> to think I'm doing something stupid.
>> 
>> Any suggestions?  Yes, yes, I know we should move to 64-bit, but
>> that's not an option right now.
>> 
>> Regards,
>> 
>> Edward.
> 
> 
> _______________________________________________
> Users mailing list
> Users@...
> https://openvz.org/mailman/listinfo/users
Permalink | Reply | 0 comments |
headers
Edward Hibbert | 9 Apr 2009 15:43
Favicon

RE: Trouble getting the 4G (a.k.a. hugemem) patch to work.

Yes, I'm on 32 bit.  I'm trying to get a single process with a larger address space.  PAE gives you up to 3GB in a
single process, but I'm after the extra memory space that the 4G/4G patch gives you.

Bailey, Darragh wrote:
> I'm guessing that you are using the 32bit version since 64bit version
> doesn't require a hugemem version to address about 4GB. 
> 
> You should try using the PAE version, see the following post
>
http://www.mail-archive.com/rhelv5-list-H+wXaHxf7aLQT0dZR+AlfA <at> public.gmane.org/msg04272.html 
> 
> It explains that if you use the standard 32bit hugemem version that
> much of the memory area reserved for the kernel is used up for
> addressing the memory above 4GB. Where as the PAE kernel is for
> systems that support PAE, which has 36bits for addressing memory and
> will avoid any weird memory mapping issues all the way up to 64GB.
> Still though if you need a system with more than 16GB, you're better
> off using 64bit.      
> 
>
Permalink | Reply | 0 comments |

Gmane