6,534
edits
Changes
assorted fixes
To support OpenVZ users we maintain [http://forum.openvz.org/index.php?t=thread&frm_id=2& Support forum] and [mailtohttp:users@//openvz.org /mailman/listinfo/users Users mailing list]. If you analyze an activity at the forum, then you'll find out, that the very big part substantial portion of all the messages there are requests to users to provide an additional information about their environments. Because of it this, the time between the report of a problem and its solution is sometimes much more longer, than it could be.
== You should always report ==
** <code>/var/log/vzctl.log</code>
** Other
If other programs are involved in your problem, try to run they with increased verbosity and attach appropriate log files, if they exist.
== A program fails to run ==
The most viable helpful tool here is <code>strace</code>. See[[stracing a program]].
== Network related problem ==
# cat /proc/sys/net/ipv4/ip_forwarding
</pre>
== Kernel Oops ==
"[[When you have an oops]]" article explains how to identify Oops and what you should do when it happens. The key moment is that you should send us the '''full''' Ooops text. Sometimes it can be easily obtained from <code>/var/log/messages</code> file or <code>dmesg</code>, but sometimesoutput. In other cases, you can only see an Oops message on the screen monitor, and the system is completely stuck. In such a situation you should produce implement [[Remote console setup]]. Actually As a rule, each production server should have setuped a remote consoleset up.
== Access to the node ==