Difference between revisions of "Reporting OpenVZ problem"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
(→‎Access to the node: reworked)
 
(15 intermediate revisions by 4 users not shown)
Line 1: Line 1:
−
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.
+
<translate>
 +
<!--T:1-->
 +
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]. For reporting bugs use [https://bugs.openvz.org/ OpenVZ bugtracker]. 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.
  
−
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.
+
<!--T:2-->
 +
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 == <!--T:3-->
−
* clear problem description
+
* Clear problem description
−
It is necessary not just to describe the problem, but also post real commands,
+
: It is necessary not just to describe the problem, but also post real commands you entered and their real output. It is useful to run commands with <code>--verbose</code> option.
−
and real output on console. It is useful to run commands with <code>--verbose</code> option.
 
 
* Kernel information
 
* Kernel information
−
** kernel version, architecture and flavour (<code>uname -a</code>)
+
** Kernel version, architecture and flavour (<code>uname -a</code>)
−
** origin of your binary kernel (RPM from openvz.org, other repository, compiled from sources, ...)
+
** Origin of your binary kernel (RPM from openvz.org, other repository, compiled from sources, ...)
 
** .config file (if you compiled the kernel)
 
** .config file (if you compiled the kernel)
 
* Linux distribution used on [[HN]]
 
* Linux distribution used on [[HN]]
−
* vzctl information
+
* Console tools information
 
** <code>vzctl --version</code>
 
** <code>vzctl --version</code>
−
* OpenVZ environment information
+
* OpenVZ/Virtuozzo environment information
 +
** Virtuozzo version <code>cat /etc/virtuozzo-release</code>
 
** <code>/etc/vz/vz.conf</code> file
 
** <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.
+
** <code>/etc/vz/<veid>.conf</code> file, where <code><veid></code> is an id of container in question.
 
* Various log files
 
* Various log files
 
** <code>/var/log/messages</code>
 
** <code>/var/log/messages</code>
 
** <code>/var/log/vzctl.log</code>
 
** <code>/var/log/vzctl.log</code>
 +
** Virtuozzo allows to gather all useful logs into single report. Execute <code>prlsrvctl problem-report --send</code> and <code>prlctl problem-report [CTUID|VMUID] --send</code> and specify problem report ID number in bug.
 
** 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.
  
−
== Some program fails to run ==
+
== A program fails to run == <!--T:4-->
−
* Strace of the program
+
The most helpful tool here is <code>strace</code>. See [[stracing a program]].
−
You can read about it at [[Stracing_a_program]] article
 
  
−
== Network related problem ==
+
== Network related problem == <!--T:5-->
 
* interface/routing/filter configuration
 
* interface/routing/filter configuration
−
You should run these commands in [[VE]] '''and''' on [[HN]]
+
You should run these commands in [[container]] '''and''' on [[HN]]
 
<pre>
 
<pre>
 
# ip a l
 
# ip a l
Line 37: Line 40:
 
# cat /proc/sys/net/ipv4/ip_forwarding
 
# cat /proc/sys/net/ipv4/ip_forwarding
 
</pre>
 
</pre>
−
Of course, if you have public IPs you  should carefully mask them. For example: 194.85.83.97 -> X.Y.83.97.
+
* see also required information in [http://forum.openvz.org/index.php?t=tree&goto=27545&S=37542b6163cbf0da10ebc21fdd10b471#msg_27545 post on forum]
  
−
== Kernel Oops ==
+
<!--T:6-->
−
"[[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.
+
{{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.}}
  
−
== Access to the node ==
+
== Kernel Oops == <!--T:7-->
−
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 <code>sudo</code>) to the [[hardware node]].
+
"[[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.
  
−
In case you can provide an access, post login information via forum PM or by e-mail, or ask for a public SSH key.
+
== Access to the node == <!--T:8-->
 +
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 root access to the [[hardware node]] — either directly, or via <code>su</code> or <code>sudo</code>.
  
−
{{Warning|Do not post any login details to public forums, mailing lists etc.}}
+
<!--T:9-->
 +
In case you can provide access, post login information via forum PM or e-mail, or ask for a public SSH key.
 +
 
 +
<!--T:10-->
 +
{{Warning|Do not post any sensitive information (like login details) to public forums, mailing lists etc.}}
 +
 
 +
== External resources == <!--T:11-->
 +
 
 +
<!--T:12-->
 +
* [https://bugs.openvz.org/ OpenVZ bugtracker]
 +
</translate>
 +
 
 +
[[Category: QA]]

Latest revision as of 11:51, 11 May 2018

<translate> To support OpenVZ users we maintain Support forum and Users mailing list. For reporting bugs use OpenVZ bugtracker. 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[edit]

  • Clear problem description
It is necessary not just to describe the problem, but also post real commands you entered and their real output. 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)
  • Linux distribution used on HN
  • Console tools information
    • vzctl --version
  • OpenVZ/Virtuozzo environment information
    • Virtuozzo version cat /etc/virtuozzo-release
    • /etc/vz/vz.conf file
    • /etc/vz/<veid>.conf file, where <veid> is an id of container in question.
  • Various log files
    • /var/log/messages
    • /var/log/vzctl.log
    • Virtuozzo allows to gather all useful logs into single report. Execute prlsrvctl problem-report --send and prlctl problem-report [CTUID|VMUID] --send and specify problem report ID number in bug.
    • 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[edit]

The most helpful tool here is strace. See stracing a program.

Network related problem[edit]

  • interface/routing/filter configuration

You should run these commands in container and on HN 

# ip a l
# ip r l
# iptables -L
# iptables -t nat -L
# cat /proc/sys/net/ipv4/ip_forwarding
Yellowpin.svg 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[edit]

"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[edit]

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 root access to the hardware node — either directly, or via su or sudo.

In case you can provide access, post login information via forum PM or e-mail, or ask for a public SSH key.

Warning.svg Warning: Do not post any sensitive information (like login details) to public forums, mailing lists etc.

External resources[edit]

</translate>

Retrieved from "https://wiki.openvz.org/index.php?title=Reporting_OpenVZ_problem&oldid=22933"