Difference between revisions of "Reporting OpenVZ problem"
(→Some program fails to run: rewording) |
(assorted fixes) |
||
| Line 1: | Line 1: | ||
| − | To support OpenVZ users we maintain [http://forum.openvz.org/index.php?t=thread&frm_id=2 | + | To support OpenVZ users we maintain [http://forum.openvz.org/index.php?t=thread&frm_id=2 Support forum] and [http://openvz.org/mailman/listinfo/users Users mailing list]. If you analyze an activity at the forum, then you'll find out that the substantial portion of all the messages are requests to users to provide an additional information about their environments. Because of this, the time between the report of a problem and its solution is sometimes much longer than it could be. |
| − | + | This article described which information a user should report when reporting OpenVZ-related problem. We hope that it will make our support service more effective. | |
== You should always report == | == You should always report == | ||
| Line 21: | Line 21: | ||
** <code>/var/log/vzctl.log</code> | ** <code>/var/log/vzctl.log</code> | ||
** Other | ** Other | ||
| − | If other programs are involved in your problem, try to run they with increased verbosity and attach appropriate log files, if exist. | + | 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 == | == A program fails to run == | ||
| − | The most | + | The most helpful tool here is <code>strace</code>. See [[stracing a program]]. |
== Network related problem == | == Network related problem == | ||
| Line 36: | Line 36: | ||
# cat /proc/sys/net/ipv4/ip_forwarding | # cat /proc/sys/net/ipv4/ip_forwarding | ||
</pre> | </pre> | ||
| − | + | ||
| + | {{Note|if you have public IP addresses, you should carefully mask them in a report. For example: 194.85.83.97 -> X.Y.83.97.}} | ||
== Kernel Oops == | == 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> | + | "[[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> output. In other cases, you can only see an Oops message on the monitor, and the system is completely stuck. In such a situation you should implement [[Remote console setup]]. As a rule, each production server should have a remote console set up. |
== Access to the node == | == Access to the node == | ||
Revision as of 13:54, 26 February 2007
To support OpenVZ users we maintain Support forum and Users mailing list. If you analyze an activity at the forum, then you'll find out that the substantial portion of all the messages are requests to users to provide an additional information about their environments. Because of this, the time between the report of a problem and its solution is sometimes much longer than it could be.
This article described which information a user should report when reporting OpenVZ-related problem. We hope that it will make our support service more effective.
Contents
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 --verbose option.
- Kernel information
- kernel version, architecture and flavour (
uname -a) - origin of your binary kernel (RPM from openvz.org, other repository, compiled from sources, ...)
- .config file (if you compiled the kernel)
- kernel version, architecture and flavour (
- Linux distribution used on HN
- vzctl information
vzctl --version
- OpenVZ environment information
/etc/vz/vz.conffile/etc/vz/<veid>.conffile, where<veid>is an id of VE in question.
- Various log files
/var/log/messages/var/log/vzctl.log- 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 helpful tool here is strace. See stracing a program.
- interface/routing/filter configuration
You should run these commands in VE and on HN
# ip a l # ip r l # iptables -L # iptables -t nat -L # cat /proc/sys/net/ipv4/ip_forwarding
|
Note: if you have public IP addresses, you should carefully mask them in 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 /var/log/messages file or dmesg output. In other cases, you can only see an Oops message on the monitor, and the system is completely stuck. In such a situation you should implement Remote console setup. As a rule, each production server should have a remote console set up.
Access to the node
In some cases, a remote access to the problem node is the fastest way to diagnose and fix a problem, so sometimes an OpenVZ developer can request such access from you. Note that in should be a root access (either directly, or via sudo) to the hardware node.
In case you can provide an access, post login information via forum PM or by e-mail, or ask for a public SSH key.
|
Warning: Do not post any login details to public forums, mailing lists etc. |
