I've heard that there are issues with running iptables commands from a
32-bit guest on a 64-bit host, but I've also seen at least one patch[1]
submitted to help resolve this issue.

I'm running 2.6.22-ovz005 and vzctl from git.  Is this still an issue in
this version?  Obviously I can setup iptables on the host, but it would
be nice to allow the guest to control their own firewall rules.

Regards,
Cliff 


[1] http://forum.openvz.org/index.php?t=msg&goto=1687&

AFAIK, yes, issues are still there. Situation should be better in 2.6.24
(can be found in git). If you have time to check/test it, we would be very thankful.

Kirill


Cliff Wells wrote:
> I've heard that there are issues with running iptables commands from a
> 32-bit guest on a 64-bit host, but I've also seen at least one patch[1]
> submitted to help resolve this issue.
> 
> I'm running 2.6.22-ovz005 and vzctl from git.  Is this still an issue in
> this version?  Obviously I can setup iptables on the host, but it would
> be nice to allow the guest to control their own firewall rules.
> 
> Regards,
> Cliff 
> 
> 
> [1] http://forum.openvz.org/index.php?t=msg&goto=1687&
> 
>

On Wed, 2007-12-19 at 12:17 +0300, Kirill Korotaev wrote:
> AFAIK, yes, issues are still there. Situation should be better in 2.6.24
> (can be found in git). If you have time to check/test it, we would be very thankful.

We are both in luck =)  The server isn't in production yet but has about
10 VE's setup.  I'll give 2.6.24 a try and report back.

Thanks,
Cliff

> 
> Cliff Wells wrote:
> > I've heard that there are issues with running iptables commands from a
> > 32-bit guest on a 64-bit host, but I've also seen at least one patch[1]
> > submitted to help resolve this issue.
> > 
> > I'm running 2.6.22-ovz005 and vzctl from git.  Is this still an issue in
> > this version?  Obviously I can setup iptables on the host, but it would
> > be nice to allow the guest to control their own firewall rules.
> > 
> > Regards,
> > Cliff 
> > 
> > 
> > [1] http://forum.openvz.org/index.php?t=msg&goto=1687&
> > 
> >

Cliff, moreover, we drop support of 2.6.22 and want to develop 2.6.24 up to
really stable (for Ubuntu release).
So will do the best to handle your bug reports ASAP.

Thanks,
Kirill


Cliff Wells wrote:
> On Wed, 2007-12-19 at 12:17 +0300, Kirill Korotaev wrote:
> 
>>AFAIK, yes, issues are still there. Situation should be better in 2.6.24
>>(can be found in git). If you have time to check/test it, we would be very thankful.
> 
> 
> We are both in luck =)  The server isn't in production yet but has about
> 10 VE's setup.  I'll give 2.6.24 a try and report back.
> 
> Thanks,
> Cliff
> 
> 
>>Cliff Wells wrote:
>>
>>>I've heard that there are issues with running iptables commands from a
>>>32-bit guest on a 64-bit host, but I've also seen at least one patch[1]
>>>submitted to help resolve this issue.
>>>
>>>I'm running 2.6.22-ovz005 and vzctl from git.  Is this still an issue in
>>>this version?  Obviously I can setup iptables on the host, but it would
>>>be nice to allow the guest to control their own firewall rules.
>>>
>>>Regards,
>>>Cliff 
>>>
>>>
>>>[1] http://forum.openvz.org/index.php?t=msg&goto=1687&
>>>
>>>

On Wed, 2007-12-19 at 20:46 +0300, Kirill Korotaev wrote:
> Cliff, moreover, we drop support of 2.6.22 and want to develop 2.6.24 up to
> really stable (for Ubuntu release).

So does this mean 2.6.24 is slated as the replacement for 2.6.18?

> So will do the best to handle your bug reports ASAP.

Sounds like a plan.  I'll upgrade my kernel later today.  


Regards,
Cliff

Cliff Wells wrote:
> On Wed, 2007-12-19 at 20:46 +0300, Kirill Korotaev wrote:
> 
>>Cliff, moreover, we drop support of 2.6.22 and want to develop 2.6.24 up to
>>really stable (for Ubuntu release).
> 
> 
> So does this mean 2.6.24 is slated as the replacement for 2.6.18?

no. 2.6.18 will live very very long, as long as RHEL5 will live.
(at least 4-5 years AFAIR)

The same way 2.6.9-RHEL4 is also alive and supported and is not going to die yet.

2.6.24 is developed for Ubuntu Long Term Support Server
and won't have new OVZ features compared to 2.6.18.
i.e. we are currently very much commited to 2.6.18-RHEL5
and will add features there (even to stable branch) as long as needed.

>>So will do the best to handle your bug reports ASAP.
> 
> Sounds like a plan.  I'll upgrade my kernel later today.  

make sure you take it from git branch 2.6.24-openvz in that repo.

Thanks,
Kirill

Zitat von Kirill Korotaev <dev@sw.ru>:

> Cliff Wells wrote:
>> On Wed, 2007-12-19 at 20:46 +0300, Kirill Korotaev wrote:
>>
>>> Cliff, moreover, we drop support of 2.6.22 and want to develop 2.6.24 up to
>>> really stable (for Ubuntu release).
>>
>>
>> So does this mean 2.6.24 is slated as the replacement for 2.6.18?
>
> no. 2.6.18 will live very very long, as long as RHEL5 will live.
> (at least 4-5 years AFAIR)
>
> The same way 2.6.9-RHEL4 is also alive and supported and is not   
> going to die yet.
>
> 2.6.24 is developed for Ubuntu Long Term Support Server
> and won't have new OVZ features compared to 2.6.18.
> i.e. we are currently very much commited to 2.6.18-RHEL5
> and will add features there (even to stable branch) as long as needed.

Does this mean that the 32-bit iptables problems on 64-bit hosts will  
be fixed in 2.6.18 OpenVZ kernel?

Would be nice as we plan to move all hosts to 64-bit but have 32-bit  
guests at least for a while.

Regards

Andreas

>>2.6.24 is developed for Ubuntu Long Term Support Server
>>and won't have new OVZ features compared to 2.6.18.
>>i.e. we are currently very much commited to 2.6.18-RHEL5
>>and will add features there (even to stable branch) as long as needed.
> 
> 
> Does this mean that the 32-bit iptables problems on 64-bit hosts will  
> be fixed in 2.6.18 OpenVZ kernel?

MUST be fixed (the only known big problem is ipt_ULOG).
There was a number of compats added in latests kernels to fix 32/64 issues.
What exact problems do you refer to? Can you point to them or to bug you have in mind?

> Would be nice as we plan to move all hosts to 64-bit but have 32-bit  
> guests at least for a while.

That's common usage scenario and we do our best to support it as good as possible.

Thanks,
Kirill

On Thu, 2007-12-20 at 16:47 +0100, Listaccount wrote:

> Would be nice as we plan to move all hosts to 64-bit but have 32-bit  
> guests at least for a while.

Out of curiosity, why would you run 64-bit guests?  It seems to me that
in a memory-constrained environment such as a VE (assuming you're
allocating less than 4GB of RAM to it) 64-bit would be wasteful.

Personally I think the 64-bit host/32-bit guest setup is the best of
both worlds.

Of course, I'm assuming you're using ovz to slice up a host (i.e. for
shared hosting) versus using it in a more specialized application (in
which case 64-bit guests might make sense). 

Regards,
Cliff

On Wed, 2007-12-19 at 10:10 -0800, Cliff Wells wrote:
> On Wed, 2007-12-19 at 20:46 +0300, Kirill Korotaev wrote:
> > Cliff, moreover, we drop support of 2.6.22 and want to develop 2.6.24 up to
> > really stable (for Ubuntu release).
> 
> So does this mean 2.6.24 is slated as the replacement for 2.6.18?
> 
> > So will do the best to handle your bug reports ASAP.
> 
> Sounds like a plan.  I'll upgrade my kernel later today.  

Unfortunately this didn't happen.  After a week my server suddenly took
a dive.  I suspect I've either got bad RAM or a CPU stepping mismatch is
biting me.  I should be able to get back to it by tomorrow.

Regards,
Cliff

Cliff Wells wrote:
> On Thu, 2007-12-20 at 16:47 +0100, Listaccount wrote:
> 
> 
>>Would be nice as we plan to move all hosts to 64-bit but have 32-bit  
>>guests at least for a while.
> 
> 
> Out of curiosity, why would you run 64-bit guests?  It seems to me that
> in a memory-constrained environment such as a VE (assuming you're
> allocating less than 4GB of RAM to it) 64-bit would be wasteful.

Hmm... Good question :@)
Maybe people tend to think 64bit is always better :@)

Really there are some 64bit operations which are faster
(maybe SSL and similar CPU-intensive operations),
so may have sense using 64bit environments. Or for big databases
and other applications requiring huge address space.
But not always, you are right.

> Personally I think the 64-bit host/32-bit guest setup is the best of
> both worlds.

maybe. I have no real data about memory usage nor CPU usage differences.

> Of course, I'm assuming you're using ovz to slice up a host (i.e. for
> shared hosting) versus using it in a more specialized application (in
> which case 64-bit guests might make sense). 

Thanks,
Kirill

Zitat von Kirill Korotaev <dev@sw.ru>:

>>> 2.6.24 is developed for Ubuntu Long Term Support Server
>>> and won't have new OVZ features compared to 2.6.18.
>>> i.e. we are currently very much commited to 2.6.18-RHEL5
>>> and will add features there (even to stable branch) as long as needed.
>>
>>
>> Does this mean that the 32-bit iptables problems on 64-bit hosts will
>> be fixed in 2.6.18 OpenVZ kernel?
>
> MUST be fixed (the only known big problem is ipt_ULOG).
> There was a number of compats added in latests kernels to fix 32/64 issues.
> What exact problems do you refer to? Can you point to them or to bug  
>  you have in mind?

Not something special. As of now we use 32-bit / 32-bit for our OpenVZ  
solely but as said plan to move the HW nodes to 64-bit soon and many  
32-bit guests use iptables.

Thanxs

Andreas

Zitat von Kirill Korotaev <dev@sw.ru>:

> Cliff Wells wrote:
>> On Thu, 2007-12-20 at 16:47 +0100, Listaccount wrote:
>>
>>
>>> Would be nice as we plan to move all hosts to 64-bit but have 32-bit
>>> guests at least for a while.
>>
>>
>> Out of curiosity, why would you run 64-bit guests?  It seems to me that
>> in a memory-constrained environment such as a VE (assuming you're
>> allocating less than 4GB of RAM to it) 64-bit would be wasteful.
>
> Hmm... Good question :@)
> Maybe people tend to think 64bit is always better :@)

Its more of "the application inquestion should be tested on 64-bit".  
We are a software company and use OpenVZ to provide a lot of  
"testmachines" on a low number of HW-nodes.

As we will provide 64-bit Unix versions of our application we need to  
test it on 64-bit.

Regards

Andreas

On Wed, 2007-12-19 at 07:51 -0800, Cliff Wells wrote:
> On Wed, 2007-12-19 at 12:17 +0300, Kirill Korotaev wrote:
> > AFAIK, yes, issues are still there. Situation should be better in 2.6.24
> > (can be found in git). If you have time to check/test it, we would be very thankful.
> 
> We are both in luck =)  The server isn't in production yet but has about
> 10 VE's setup.  I'll give 2.6.24 a try and report back.

So having gotten my server back up, I'm looking to test out 2.6.24, but
I'm a bit confused: I pulled the git tree using:

git clone git://git.openvz.org/pub/linux-2.6.24-openvz linux-2.6.24-openvz 

but when I run "make menuconfig", there doesn't appear to be any OpenVZ
related configuration available.  It looks pretty much like a vanilla
kernel.

What am I missing?

Regards,
Cliff

On Fri, 2007-12-21 at 18:44 -0800, Cliff Wells wrote:
> So having gotten my server back up, I'm looking to test out 2.6.24, but
> I'm a bit confused: I pulled the git tree using:
> 
> git clone git://git.openvz.org/pub/linux-2.6.24-openvz linux-2.6.24-openvz 
> 
> but when I run "make menuconfig", there doesn't appear to be any OpenVZ
> related configuration available.  It looks pretty much like a vanilla
> kernel.

Anyone?  I'm desperate to be a crash test dummy, but I look silly just
sitting here with my helmet on.

Cliff

> On Fri, 2007-12-21 at 18:44 -0800, Cliff Wells wrote:
> > So having gotten my server back up, I'm looking to test out 2.6.24,
> > but
> > I'm a bit confused: I pulled the git tree using:
> > 
> > git clone git://git.openvz.org/pub/linux-2.6.24-openvz
> > linux-2.6.24-openvz 
> > 
> > but when I run "make menuconfig", there doesn't appear to be any
> > OpenVZ
> > related configuration available.  It looks pretty much like a vanilla
> > kernel.

> Anyone?  I'm desperate to be a crash test dummy, but I look silly just
> sitting here with my helmet on.

2.6.24 tree has two branches for now: mainstream soon-to-be-released
2.6.24 kernel and 2.6.24-openvz branch forked from it.

However, you've already downloaded all needed data ;-)
After clone do:

	cd linux-2.6.24-openvz
	git checkout -b 2.6.24-openvz origin/2.6.24-openvz