Article ID: 1015, created on Mar 26, 2009, last review on Dec 5, 2014

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

Lösung

Nachfolgend finden Sie die meisten Ursachen dafür, dass ein Container nicht startet.

  1. Der Container startet, aber fährt nach wenigen Minuten wieder herunter.

    Bei Ihnen ist möglicherweise keine gültige Lizenz installiert, die Lizenz ist abgelaufen oder die Anzahl an Containern ist überschritten. Überprüfen Sie die Ausgabe des Befehls vzlicview. Der Status der Lizenz muss ACTIVE sein und der Wert für ct_total in Klammern darf den Wert von ct_total nicht überschreiten. Weitere Informationen zu Lizenzen finden Sie im Artikel Wie überprüfe/installiere ich eine Lizenz für Parallels Virtuozzo Containers?

  2. Der Container kann nicht gestartet werden, da er gesperrt ist.

    Gehen Sie bitte nach der Anleitung in diesem Artikel vor.

  3. Der Container startet, zeigt aber den Fehler /bin/bash: no such file oder einen ähnlichen Fehler an.

    Der Besitzer des Containers hat möglicherweise einige wichtige Pakete entfernt, wie z. B. bash oder glibc. Bei Containern, die auf Standard-Templates basieren, können Sie die veraltete Option vzctl recover CTID des vzctl-Befehls verwenden, um den privaten Bereich des Containers wiederherzustellen.

    Möglicherweise fehlt auch das Standard-OS-Template für den Container auf dem Hardware Node. Sie können dies mittels vzpkgls CTID und vzpkgls überprüfen und das fehlende OS-Template gegebenenfalls installieren.

    Bei Containern, die auf EZ-Templates basieren, kann ein derartiger Fehler auftreten, nachdem der Container von einem anderen Node migriert wurde oder anhand eines Backups wiederhergestellt wurde. Die Schritte vor der Migration sowie Schritte zur Reparatur nach der Migration finden Sie im Artikel Vorbereiten von Containern für die Migration.

    Es kann auch sein, dass der Container kompromittiert wurde (siehe unten).

  4. Der Container startet, aber kurz nach dem Starten tritt ein Segmentierungsfehler auf.

    Der Container kann kompromittiert worden sein. Lesen Sie hierzu den Artikel Wie stelle ich fest, ob mein Container gehackt/kompromittiert wurde?

  5. Der Start des Containers ist fehlgeschlagen und es wird in etwa folgende Meldung angezeigt:

    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]
    

    Diese Fehlermeldung weist darauf hin, dass der Container sein Speicherplatzkontingent überschritten hat und nicht gestartet werden kann, weil während des Container-Starts keine Systemdateien geändert werden können. Sie können den Verbrauch und die Grenzen für den Container über folgenden Befehl überprüfen:

    # vzquota show CTID
    

    Lösung - Erhöhen Sie den dem Container zugeteilten diskspace (und möglicherweise auch inodes) mit dem Dienstprogramm vzctl:

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

    Wenn die Erhöhung der Grenzen für blocks und inodes nicht hilft, versuchen Sie, das Kontingent für diesen Container neu zu initialisieren:

    # vzctl quotainit CTID
    

    Starten Sie den Container anschließend.

  6. Der Start des Containers ist fehlgeschlagen und es wird in etwa folgende Meldung angezeigt:

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

    Überprüfen Sie, ob das Kontingent zweiter Ebene für den Benutzer root manuell innerhalb des Containers festgelegt wurde:

    # vzctl mount CTID
    # vzquota stat CTID -t
    

    Überprüfen Sie die Kontingente für die Benutzer, z. B.:

    ...
    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
    ...
    

    Im Beispiel wurde das Kontingent für "root" überschritten und die Anzahl an Datenträgerblöcken überschreitet das Soft- und das Hardlimit. Dies verursacht das Startproblem.

    Sie können das Kontingent für den Benutzer root (UID 0) über folgenden Befehl zurücksetzen:

    # vzquota setlimit2 CTID -u 0 0 0 0 0
    

    Alternativ kann die Grenze für jeden beliebigen anderen Benutzer oder jede andere Gruppe mit folgenden Befehlen unter Angabe der entsprechenden UID oder GID zurückgesetzt werden:

    # vzquota setlimit2 CTID -u UID 0 0 0 0
    # vzquota setlimit2 CTID -g GID 0 0 0 0
    
  7. Der Start des Containers ist mit folgendem Fehler fehlgeschlagen:

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

    Entweder ist der Container auf einem anderen Node registriert oder jemand hat den Hostnamen des Nodes geändert.

    • Wenn das Problem nur auf einen Container bezogen ist, können Sie /vz/private/CTID/.owner manuell zu Pcs.hostname.tld ändern (pcs.hostname.tld ist nicht dasselbe wie Pcs.hostname.tld; beim Hostnamen wird Groß- und Kleinschreibung beachtet).
    • Wenn das Problem mit allen Containern in Zusammenhang steht und diese nicht in der Ausgabe des Befehls vzlist -a aufgelistet sind, dann ist die schnellste und passendste Methode, den Hostnamen des Nodes mithilfe des hostname-Befehls wieder in den ursprünglichen umzuändern:

      # hostname Pcs.hostname.tld
      

    Danach sollten die Container auf dem Node erscheinen und Sie in der Lage sein, sie zu starten. Bitte beachten Sie, dass es sich dabei um eine temporäre Änderung handelt und Sie den hostname in /etc/sysconfig/network modifizieren sollten, damit die Änderungen nach einem Neustart bestehen bleiben.

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

Email subscription for changes to this article
Save as PDF