Re: [owl-users] Network unreachable from inside Owl CT

Ihsan,

Thank you for bringing this topic up in here.  We were going to announce
the pre-created templates of the Owl userland along with other updates
that we were making, but you were quicker than us. :-)

On Sat, Dec 12, 2009 at 07:19:10PM +0700, Ihsan Sabri wrote:
> FYI, there is /etc/vz/dists/owl.conf (owned by centos package
> vzctl-3.0.23-1) on HN contains:

This is the correct distro config file for use with our pre-created
templates.  However, is this file being used on your system?  To have it
actually used with Owl-current-20091129-x86_64.tar.gz, which you
mentioned was the template you used, you need to either create a symlink
named Owl-current-20091129-x86_64.conf under /etc/vz/dists pointing to
owl.conf or set DEF_OSTEMPLATE to owl.conf.  This is mentioned in:

http://openwall.info/wiki/Owl/usage-examples/OpenVZ/getting-started

Oh, you could also rename Owl-current-20091129-x86_64.tar.gz to
owl.tar.gz (or create a link of that name and use it to refer to the
template), but that's arguably more confusing.

> The question now is why Container using OpenVZ official pre-created
> templates didn't need this manual routing table manipulation?

This could be for several reasons.  Maybe the filenames of some of those
pre-created templates "matched" suitable distro config filenames.  Maybe
the default distro config was a better match for them than it was for Owl.

If owl.conf was in fact being used with Owl-current-20091129-x86_64.tar.gz
from the very beginning in your case, yet you experienced the problem,
then this could be something for us to look into.  We had tested the
templates on Owl and did not run into the problem.  OK, we did run into
a similar problem with some test templates (unreleased), but we included
a workaround for that into the templates that we made available
(GATEWAYDEV=venet0 in /etc/sysconfig/network), so it should not be the
problem anymore.  On the other hand, if you first created/started the
container with a config file other than owl.conf, then fixed it to use
owl.conf, then maybe your first bootup of the container (with a wrong
config) removed this workaround... so this could be something for you to
check and let us know.

Thanks again,

Alexander

P.S. Perhaps the next step for you is to replace the host system with Owl.
You should be able to continue running both Owl and non-Owl containers.