172
edits
Changes
Initial edition of article
To support OpenVZ users we maintain [http://forum.openvz.org/index.php?t=thread&frm_id=2& Support forum] and [mailto:users@openvz.org Users mailing list]. If you analyze an activity at the forum, then you'll find out, that the very big part of all messages there are requests to users to provide an additional information about their environments. Because of it the time between the report of a problem and its solution is sometimes much more longer, than it could be.
The aim of this article is to clue up users, what information they should report when they encounter OpenVZ related problem. We hope that it will make our support service more effective.
== You should always report ==
* clear problem description
It is necessary not just to describe the problem, but also post real commands,
and real output on console. It is useful to run commands with <code>--verbose</code> option.
* Kernel information
** kernel version, architecture and flavour (<code>uname -a</code>)
** origin of your binary kernel (RPM from openvz.org, other repository, compiled from sources, ...)
** .config file (if you compiled the kernel)
* Linux distribution used on [[HN]]
* vzctl information
** <code>vzctl --version</code>
* OpenVZ environment information
** <code>/etc/vz/vz.conf</code> file
** <code>/etc/vz/<veid>.conf</code> file, where <code><veid></code> is an id of VE in question.
* Various log files
** <code>/var/log/messages</code>
** <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 exist.
== Some program fails to run ==
* Strace of the program
You can read about it at [[Stracing_a_program]] article
== Network related problem ==
* interface/routing/filter configuration
You should run these commands in [[VE]] '''and''' on [[HN]]
<pre>
# ip a l
# ip r l
# iptables -L
# iptables -t nat -L
# cat /proc/sys/net/ipv4/ip_forwarding
</pre>
Of course, if you have public IPs you should carefully mask them. 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 sometimes, you see Oops on the screen and the system is completely stuck. In such situation you should produce [[Remote console setup]]. Actually each production server should have setuped remote console.
== Access to the node ==
Probably, one of the most quick ways to find the root of the problem is to give us an access to the node. Note, that it should be a root access (or via <code>sudo su<code>) to [[HN]]. You can post login via PM or by e-mail.
The aim of this article is to clue up users, what information they should report when they encounter OpenVZ related problem. We hope that it will make our support service more effective.
== You should always report ==
* clear problem description
It is necessary not just to describe the problem, but also post real commands,
and real output on console. It is useful to run commands with <code>--verbose</code> option.
* Kernel information
** kernel version, architecture and flavour (<code>uname -a</code>)
** origin of your binary kernel (RPM from openvz.org, other repository, compiled from sources, ...)
** .config file (if you compiled the kernel)
* Linux distribution used on [[HN]]
* vzctl information
** <code>vzctl --version</code>
* OpenVZ environment information
** <code>/etc/vz/vz.conf</code> file
** <code>/etc/vz/<veid>.conf</code> file, where <code><veid></code> is an id of VE in question.
* Various log files
** <code>/var/log/messages</code>
** <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 exist.
== Some program fails to run ==
* Strace of the program
You can read about it at [[Stracing_a_program]] article
== Network related problem ==
* interface/routing/filter configuration
You should run these commands in [[VE]] '''and''' on [[HN]]
<pre>
# ip a l
# ip r l
# iptables -L
# iptables -t nat -L
# cat /proc/sys/net/ipv4/ip_forwarding
</pre>
Of course, if you have public IPs you should carefully mask them. 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 sometimes, you see Oops on the screen and the system is completely stuck. In such situation you should produce [[Remote console setup]]. Actually each production server should have setuped remote console.
== Access to the node ==
Probably, one of the most quick ways to find the root of the problem is to give us an access to the node. Note, that it should be a root access (or via <code>sudo su<code>) to [[HN]]. You can post login via PM or by e-mail.
