Changes

Jump to: navigation, search

Reporting OpenVZ problem

895 bytes added, 11:51, 11 May 2018
no edit summary
<translate><!--T:1-->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]. 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 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 <!--T:2-->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 ==<!--T:3-->* clear Clear problem description: It is necessary not just to describe the problem, but also post real commands,you entered and their real output on console. It is useful to run commands with <code>--verbose</code> option.
* Kernel information
** kernel Kernel version, architecture and flavour (<code>uname -a</code>)** origin 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 Console tools information
** <code>vzctl --version</code>
* OpenVZ /Virtuozzo environment information** Virtuozzo version <code>cat /etc/virtuozzo-release</code>
** <code>/etc/vz/vz.conf</code> file
** <code>/etc/vz/<veid>.conf</code> file, where <code><veid></code> is an id of VE container in question.
* Various log files
** <code>/var/log/messages</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
:: 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 ==<!--T:4-->The most viable helpful tool here is <code>strace</code>. See[[stracing a program]].
== Network related problem ==<!--T:5-->
* interface/routing/filter configuration
You should run these commands in [[VEcontainer]] '''and''' on [[HN]]
<pre>
# ip a l
# cat /proc/sys/net/ipv4/ip_forwarding
</pre>
Of course, if you have public IPs you should carefully mask them. For example* see also required information in [http: 194.85.83.97 -> X.Y//forum.83openvz.97org/index.php?t=tree&goto=27545&S=37542b6163cbf0da10ebc21fdd10b471#msg_27545 post on forum]
== Kernel Oops ==<!--T:6-->"[[When {{Note|if you have an oops]]" article explains how to identify Oops and what public IP addresses, you should do when it happenscarefully mask them in a report. For example: 194. The key moment is that you should send us the '''full''' Ooops text85.83. Sometimes it can be easily obtained from <code97 ->/var/log/messages</code> file or <code>dmesg</code>, but sometimes, you see Oops on the screen and the system is completely stuckX.Y. In such situation you should produce [[Remote console setup]]83. Actually each production server should have setuped remote console97.}}
== Access to the node Kernel Oops ==<!--T:7-->In some cases, a remote access to the problem node is the fastest way "[[When you have an oops]]" article explains how to diagnose identify Oops and fix a problem, so sometimes an OpenVZ developer can request such access from what youshould do when it happens. Note The key moment is that in you should send us the '''full''' Ooops text. Sometimes it can be a root access (either directly, easily obtained from <code>/var/log/messages</code> file or via <code>sudodmesg</code>) to 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 [[hardware nodeRemote console setup]]. As a rule, each production server should have a remote console set up.
== Access to the node == <!--T:8-->In case 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 can provide an . Note that in should be root accessto the [[hardware node]] — either directly, post login information or via forum PM <code>su</code> or by e-mail, or ask for a public SSH key<code>sudo</code>.
<!--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]]
Anonymous user

Navigation menu