Changes

Jump to: navigation, search

Reporting OpenVZ problem

56 bytes added, 13:54, 26 February 2007
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.
The aim of this This article is to clue up users, what described which information they a user should report when they encounter reporting OpenVZ -related problem. We hope that it will make our support service more effective.
== 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>
Of course, {{Note|if you have public IPs IP addresses, you should carefully mask themin a report. For example: 194.85.83.97 -> X.Y.83.97.}}
== 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 ==

Navigation menu