Parallels Virtuozzo Containers 4.6 for Linux

Troubleshooting 350

Aug 25 08:27:46 boar

Aug 25 08:27:46 boar [<f0c713c3>] scsi_io_completion+0x149/0x2f3 [scsi_mod]

Aug 25 08:27:46 boar [<f0c333b9>] sd_rw_intr+0x1f1/0x21b [sd_mod]

Aug 25 08:27:46 boar [<f0c6d3b9>] scsi_finish_command+0x73/0x77 [scsi_mod]

Aug 25 08:27:46 boar [<024cbfa2>] blk_done_softirq+0x4d/0x58

Aug 25 08:27:46 boar [<02426452>] __do_softirq+0x84/0x109

Aug 25 08:27:46 boar [<0242650d>] do_softirq+0x36/0x3a

Aug 25 08:27:46 boar [<024050b7>] do_IRQ+0xad/0xb6

Aug 25 08:27:46 boar [<024023fa>] default_idle+0x0/0x59

Aug 25 08:27:46 boar [<0240242b>] default_idle+0x31/0x59

Aug 25 08:27:46 boar [<024024b1>] cpu_idle+0x5e/0x74

Aug 25 08:27:46 boar =======================

Aug 25 08:27:46 boar Code: 5d c3 55 57 89 c7 56 89 ce 53 bb 01 00 00 00 83 ec

0c 8b 68 3c 83 7f 20 00 8b 45 00 8b 00 89 44 24 04 8b 45 04 89 04 24 8b 40 04

<8b> 40 28 89 44 24 08 0f 85 86 00 00 00 f6 47 10 01 75 0a 85 c9

Aug 25 08:27:46 boar EIP: [<f0ce6507>] clone_endio+0x29/0xc6 [dm_mod]

SS:ESP0068:0b483e38

Aug 25 08:27:46 boar Kernel panic - not syncing: Fatal exception in interrupt

All you need is to put the oops into a file and then send this file as part of your problem report to the Parallels support team.

Finding Kernel Function That Caused D Process State

If there are too many processes in the D state and you can't find out what is happening, issue the following command:

# objdump -Dr /boot/vmlinux-`uname -r` >/tmp/kernel.dump

and then get the process list:

# ps axfwln

F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND

100 0 20418 20417 17 0 2588 684 - R ? 0:00 ps axfwln

100 0 1 0 8 0 1388 524 145186 S ? 0:00 init

040 0 8670 1 9 0 1448 960 145186 S ? 0:00 syslogd -m 0

040 0 8713 1 10 0 1616 1140 11ea02 S ? 0:00 crond

Look for a number under the

WCHAN column for the process in question. Then, open

/tmp/kernel.dump

in an editor, find that number in the first column and then scroll backward to the first function name, which can look like this:

"c011e910 <sys_nanosleep>:"

Then you can tell if the process “lives” or is blocked into the found function.

Problems With Container

Management

This section includes recommendations on how to settle some problems with your Containers.

Troubleshooting 351

Failure to Create a Container

An attempt to create a new Container fails. There is a message on the system console: Cached package set XXX version YYY not found.

Solution 1

The necessary OS template might be absent from the server. Copy the template to the server, install it, cache it, and try to create a Container once again.

Solution 2

The Container private area might not be pre-cached. In this case the vzpkgcache utility shall be used. Issue the command:

vzpkgcache

The utility looks for the OS templates installed on the server and caches those that are not cached. After this, try to create a Container once again.

Troubleshooting 352

Failure to Start a Container

An attempt to start a Container fails.

Solution 1

If there is a message on the system console: parameters missing, and the list of missed parameters follows the message, set these parameters using the vzctl set --save command (see

Configuring Container (p. 44) for instructions). Try to start the Container once

again.

Solution 2

If there is a message on the system console: IP address is already used, issue the cat /proc/vz/veinfo

command. The information about the Container numeric identifier,

Container class, number of Container’s processes and Container IP address shall be displayed for each running Container. This shall also demonstrate that your Container is up, i.e. it must be running without any IP address assigned. Set its IP address using the command:

vzctl set CT_ID --ipadd IP_addr --save

where CT_ID represents the Container numeric identifier and IP_addr represents an actual IP address.

Solution 3

Poor UBC parameters might prevent the Container from starting. Try to validate the Container configuration (see

Validating Container Configuration (p. 169)). See what configuration

parameters have caused the error and set appropriate values using the vzctl set --save command.

Solution 4

The Container might have used all its disk quota (either disk space or disk inodes). Check the

Container disk quota (see the

Managing Disk Quotas section) and increase the quota parameters if needed (see

Setting Up Per-Container Disk Quota Parameters (p. 123)).

Solution 5

Run the vzfsutil utility to make sure that the VZFS symlinks inside the Container work correctly. For example:

vzfsutil --call –t /vz/template /vz/private/<CT_ID>

The complete reference on the vzfsutil utility is provided in the Parallels Virtuozzo

Containers 4.6 Reference Guide.

Solution 6

The Container administrator might have inadvertently modified, replaced, or deleted any file that is part of an application or OS template, which has brought about the Container malfunction. In this case, restore the file(s) with the vzctl recover command (see the

Recovering Container section for details).

Solution 7

Troubleshooting 353

Restore the latest operable copy of the Container by means of the vzarestore utility (see the

Backing Up and Restoring Container section for details).

Failure to Access Container From Network

Solution 1

The IP address assigned to this Container might be already in use in your network. Make sure it is not. The problem Container address can be checked by issuing the following command:

# grep IP_ADDRESS /etc/vz/conf/<CT_ID>.conf

IP_ADDRESS="10.0.186.101"

The IP addresses of other Containers, which are running, can be checked by running

cat /proc/vz/veinfo

Solution 2

Make sure the routing to the Container is properly configured. Containers can use the default router for your network, or you may configure the server as rooter for its Containers.

Failure to Log In to Container

The Container starts successfully, but you cannot log in.

Solution 1

You are trying to connect via SSH, but access is denied. Probably you have not set the password of the root user yet or there is no such user. In this case, use the vzctl set -userpasswd

command. For example, for Container 101 you might issue the following command:

# vzctl set 101 --userpasswd root:secret

Solution 2

Check forwarding settings by issuing the following command:

# cat /proc/sys/ipv4/conf/venet0/forwarding

If it is 0 then change it to 1 by issuing the following command:

# echo 1 > /proc/sys/ipv4/conf/venet0/forwarding

Troubleshooting 354

Failure to Back Up Container in Parallels Management Console

An attempt to back up a Container with a large amount of disk space (e.g. 6 Gb) by means of

Parallels Management Console finishes with the following error message: The request was timed out

. However, the backup process continues running and the Container backup is successfully created on the Backup Node after a while, which can be checked by exploring the

/vz/backup

directory on this Node, where all Container backups are stored by default.

Solution

The problem is caused by the fact that the timeout limit set by Parallels Agent for the Container backup process in Management Console has been reached. This limit is equal to 3600 seconds by default. You can increase the maximal backup timeout value by performing the following operations:

1 In Management Console, right-click on the Hardware Node name and select

Tasks >

Manage Parallels Agent Configuration on the context menu.

2 In the left part of the displayed window, choose

backm > configuration > timeouts.

3 Double-click the backup parameter in the right part of the

Parallels Agent Configuration window and specify the needed time (in seconds) in the

Parameter value field.

4 Click

OK.

Failure to Display List of Container Backups

You created a number of Container backups on the Backup Node and now wish to view them.

However, the process of displaying your Container backups takes a very long time or even goes into infinity.

Solution

By default, the timeout limit for the Container backup search process is set to a very high value -

3600 seconds, which makes the search process to run for 60 minutes before showing a list of available backups on the Backup Node. To reduce the time needed to display your Container backup list, you should decrease the backup search value. You can do it in the following way:

1 In Parallels Management Console, right-click on the Hardware Node name and select

Tasks

>

Manage Parallels Agent Configuration on the context menu.

2 In the left part of the displayed window, choose

backm > configuration > timeouts.

3 Double-click the search parameter in the right part of the

Parallels Agent Configuration window and specify the desired time (in seconds) in the

Parameter value field.

Note: You are recommended to set the value of the search parameter to 300 seconds.

4 Click

OK.