Well if you don't need it then just try and remove the NAT module
using "modprobe -r iptable_nat". And see if that makes any difference.
Can't remove it, get the message
"module is in use".. not sure by what.
Do you have any rules in the NAT table? E.g. check "iptables -t nat -L". Then
remove those rules and try removing the module again. I doubt that the NAT module is the
core of your problem though.
Yes it turns out we did. This server is an LVS "real server" back
end and Horm's transparent proxy is in use. that's
what the NAT is being used for.
CONFIG_XEN_SKBUFF is on in my config.
There is no MAX_SKBUFF_ORDER parameter anywhere in my source tree,
much less the config file.
MAX_SKBUFF_ORDER is not a configuration option. It is part of the Dom0/DomU
kernel code.
I have grepped the whole kernel code from the kernel which I'm
running, which is unmodified from the redhat SRPMS as delivered with
version 5, update 3. 2.6.18-128.1.6.el5xen. I don't find
the string MAX_SKBUFF_ORDER anywhere in there. Which source file should
it be in?
Your posted kernel config is from your Dom0? You said before that you are
running a 64-bit Dom0. You need to check the CONFIG_XEN_SKBUFF option in the
Dom0 config. I am in general wondering if you might have issues with your
DomU/Dom0 configuration. How did you install those kernels? Did you install
them using the distro? Did you compile them yourself? I assume you also run a
64-bit hypervisor?
Yes running 64-bit dom0 and hypervisor. the kernel config
is actually the same for both dom0 and domU as in redhattish xen
you actually run the same kernel-xen in both. Only difference is
that it is 64-bit for the dom0 and 32-bit for the domU.
If it is easy for you to recompile DomU/Dom0 kernels then you could try and
recompile with CONFIG_XEN_SKBUFF, CONFIG_HAVE_ARCH_ALLOC_SKB and
CONFIG_HAVE_ARCH_DEV_ALLOC_SKB disabled, and see if it makes any difference.
We think we see how to get rid of the NAT so we will try to do
that first, and then will recompile the kernel as mentioned above
if necessary. Government sites like ours don't like running
custom kernels.. in fact we just completed a process to
get back in sync with the distro after running a custom xen kernel
for 1.5 years, which is how we noticed this problem, although
it was going on with our custom kernel too and we just never noticed
it at the time.
Steve Timm
--
------------------------------------------------------------------
Steven C. Timm, Ph.D (630) 840-8525
timm@xxxxxxxx http://home.fnal.gov/~timm/
Fermilab Computing Division, Scientific Computing Facilities,
Grid Facilities Department, FermiGrid Services Group, Assistant Group Leader.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
| 
Home