Article ID: 1015, created on Oct 6, 2008, last review on Jun 17, 2016

  • Applies to:
  • Operations Automation 5.4
  • Virtuozzo 6.0
  • Virtuozzo containers for Linux
  • Virtuozzo hypervisor


Here are the most common causes of a container not starting.

  1. The container starts but shuts down after a few minutes.

    You probably do not have a valid license installed; it might be expired or the number of containers is exceeded. Please check the output of the vzlicview command. The status of the license should be ACTIVE and the ct_total value in brackets should be not greater than ct_total. More information about licenses can be found in the article How do I check/install a Parallels Virtuozzo Containers license?

  2. The container cannot be started because it is locked.

    Please follow the instructions from this article.

  3. The container starts but displays the error /bin/bash: no such file or something similar.

    The owner of the container could have removed some important package, such as bash or glibc. For containers based on standard templates, you can use the deprecated option of the vzctl command, vzctl recover CTID, to recover the private area of the container.

    Also, the standard OS template the container is based on may be absent from the Hardware Node; you may check it using vzpkgls CTID and vzpkgls and install the missing OS template if it is needed.

    For containers based on EZ templates, such an error can appear after migrating the container from another node or after restoring the container from a backup. The pre-migration steps and reparative post-migration steps are described in the article Prepare containers for migration.

    The container may also be compromised (see below).

  4. The container starts but Segmentation fault occurs very soon after its starting.

    The container may be compromised; please check the article How do I determine that my container is hacked/compromised?

  5. The container failed to start with a message like this:

    ERROR: Can't write to file /etc/sysconfig/network-scripts/ifcfg-venet0
    vzquota : (warning) block_hard_limit [50100] < block_current_usage [60279]
    vzquota : (warning) block_hard_limit [50100] < block_current_usage [60279]

    This error message means that the container exceeded its disk space quota and cannot be started because it is impossible to change system files during container startup. You can check the usage and limits for the container using the following command:

    # vzquota show CTID

    Solution - Increase diskspace (and probably inodes) allocated to the container using the vzctl utility:

    # vzctl set CTID --diskspace BARRIER:LIMIT --save
    # vzctl set CTID --diskinodes BARRIER:LIMIT --save

    If increasing blocks and inodes limits does not help, try to re-init the quota for this container with the following:

    # vzctl quotainit CTID

    Then start the container.

  6. The container failed to start with a message like this:

    Running the command: /etc/sysconfig/vz-scripts/vz-net_add
    Run the script /etc/sysconfig/vz-scripts/dists/scripts//
    /bin/cp: writing `/etc/sysconfig/network.5': Disk quota exceeded
     ERROR: Can't copy file /etc/sysconfig/network

    Check that the second-level quota for the user root was not manually set inside the container:

    # vzctl mount CTID
    # vzquota stat CTID -t

    Check quotas for users, for example:

    User/group objects:
    ID           type  resource       usage   softlimit   hardlimit    grace status
    0            user 1k-blocks    11464476      358400      358400     none loaded
    0            user    inodes      716143           0           0          loaded

    Here the quota for "root" has been exceeded, and the number of used disk blocks exceeds the soft and hard limits, causing the startup issue.

    You can reset this quota for the root user (UID 0) using the following command:

    # vzquota setlimit2 CTID -u 0 0 0 0 0

    Alternatively, the limit can be reset for any other user or group with the following commands, supplying the proper UID or GID:

    # vzquota setlimit2 CTID -u UID 0 0 0 0
    # vzquota setlimit2 CTID -g GID 0 0 0 0
  7. The container failed to start with the following:

    # vzctl start CTID
    Owner check failed on the server pcs.hostname.tld; Container is registered for Pcs.hostname.tld

    Either the container is registered on another node or someone changed the hostname of the node.

    • If the issue is related only to one container, you can manually edit /vz/private/CTID/.owner to Pcs.hostname.tld (pcs.hostname.tld and Pcs.hostname.tld are different; the hostname is case-sensitive).
    • If the issue is related to all containers and they are not listed in the output of the vzlist -a command, then the fastest and the proper way is to change the hostname of the node back using the hostname command:

      # hostname Pcs.hostname.tld

    After that, the containers should appear on the node and you will be able to start them. Please note that this is a temporary change and that you should modify the hostname in /etc/sysconfig/network in order for the changes to stick after a reboot.

Search Words

container does not start

cant start container

vps won't start

containers crashing

disk quota exceeded

Container is unmounted Failed to start the Container

container startup issues

network is not working in ubutunu

Owner check failed on the server

container startup

migration no migration

d02f9caf3e11b191a38179103495106f 2897d76d56d2010f4e3a28f864d69223 a26b38f94253cdfbf1028d72cf3a498b e8e50b42231236b82df27684e7ec0beb 0dd5b9380c7d4884d77587f3eb0fa8ef c62e8726973f80975db0531f1ed5c6a2 5356b422f65bdad1c3e9edca5d74a1ae caea8340e2d186a540518d08602aa065 ac82ce33439a9c1feec4ff4f2f638899 2554725ed606193dd9bbce21365bed4e 614fd0b754f34d5efe9627f2057b8642

Email subscription for changes to this article
Save as PDF