OpenVZ Container starten nicht mehr

Spinx · Sep 22, 2012

Hallo,

Ich habe auf meinem Root Server 2 weitere VE angelegt. Alle Befehle liefen Problemlos durch. Die Logs sind sauber, auch ein vzlist -a sagt mir das diese angelegt wurden und gestartet sind.

Aus unbekannten Gründen kann ich aber per Putty oder WinSCP nicht drauf zugreifen. Woran könnte dies liegen?

mr_brain · Sep 23, 2012

Bridge oder Route nicht verfügbar?

Spinx · Sep 23, 2012

Ganz Merkwürdig. Das Verzeichnis /var/lib/vz/private/CIED war sofort vorhanden.

/var/lib/vz/root/CIED erst fast 30 Minuten später. Ich vermute mal das es daran lag. Nun stelle ich mir die Frage wieso dies so lange dauert.

Deleted member 11691 · Sep 23, 2012

Vermutlich weil die Quota neu eingelesen werden muss und das nunmal dauert. Ist hier öfters passiert, wenn das Hostsystem nen Kernel Oops hatte.

Firewire2002 · Sep 23, 2012

Spinx said:
auch ein vzlist -a sagt mir das diese angelegt wurden und gestartet sind

Spinx said:
/var/lib/vz/root/CIED erst fast 30 Minuten später

Gib uns die Ausgaben der Befehle und überlass die Schlussfolgerungen uns. Das bisher geschriebene passt sehr deutlich nicht zusammen.

Spinx · Sep 23, 2012

Bitteschön.

Anlegen der VE, Befehl + Ausgabe:

root@1:~# vzctl create 104 --ostemplate debian-6.0-amd64-minimal
Creating container private area (debian-6.0-amd64-minimal)
Performing postcreate actions
Container private area was created
root@1:~# vzctl set 104 --onboot yes --save
Saved parameters for CT 104
root@1:~# vzctl set 104 --hostname 4.domain.de --save
Saved parameters for CT 104
root@1:~# vzctl set 104 --ipadd xx.xx.xx.134 --save
Saved parameters for CT 104
root@1:~# vzctl set 104 --nameserver 8.8.8.8 --nameserver 8.8.4.4 --save
Saved parameters for CT 104
root@1:~# vzctl start 104
Starting container ...
Container is mounted
Adding IP address(es): xx.xx.xx.134
Setting CPU units: 1000
Set hostname: 4.domain.de
File resolv.conf was modified
Container start in progress...
root@1:~# vzctl set 104 --userpasswd root:xxx
root@1:~# vzctl set 104 --applyconfig m --save
UB limits were set successfully
Setting CPU limit: 50
Setting CPU units: 1000
Setting CPUs: 4
Saved parameters for CT 104

Die Logs

2012-09-23T08:17:21+0200 vzctl : CT 104 : Creating container private area (debian-6.0-amd64-minimal)
2012-09-22T08:17:27+0200 vzctl : CT 104 : Performing postcreate actions
2012-09-22T08:17:27+0200 vzctl : CT 104 : Container private area was created
2012-09-22T08:17:39+0200 vzctl : CT 104 : Saved parameters for CT 104
2012-09-22T08:17:39+0200 vzctl : CT 104 : Saved parameters for CT 104
2012-09-22T08:17:39+0200 vzctl : CT 104 : Saved parameters for CT 104
2012-09-22T08:17:40+0200 vzctl : CT 104 : Saved parameters for CT 104
2012-09-22T08:18:01+0200 vzctl : CT 104 : Starting container ...
2012-09-22T08:18:01+0200 vzctl : CT 104 : Container is mounted
2012-09-22T08:18:01+0200 vzctl : CT 104 : Adding IP address(es): xx.xx.xx.134
2012-09-22T08:18:02+0200 vzctl : CT 104 : Setting CPU units: 1000
2012-09-22T08:18:02+0200 vzctl : CT 104 : Set hostname: 4.domain.de
2012-09-22T08:18:03+0200 vzctl : CT 104 : File resolv.conf was modified
2012-09-22T08:18:03+0200 vzctl : CT 104 : Container start in progress...
2012-09-22T08:18:11+0200 vzctl : CT 104 : UB limits were set successfully
2012-09-22T08:18:11+0200 vzctl : CT 104 : Setting CPU limit: 50
2012-09-22T08:18:11+0200 vzctl : CT 104 : Setting CPU units: 1000
2012-09-22T08:18:11+0200 vzctl : CT 104 : Setting CPUs: 4
2012-09-22T08:18:11+0200 vzctl : CT 104 : Saved parameters for CT 104

root@1:~# vzlist -a
CTID NPROC STATUS IP_ADDR HOSTNAME
102 92 running xx.xx.xx.133 domain.de
104 6 running xx.xx.xx.134 4.domain.de
root@1:~#

Die VM mit der CTID 102 war übrigens erst nach Guten 8 Stunden verfügbar.

Firewire2002 · Sep 23, 2012

Wenn er beim Start sagt "Container is mounted" ist definitiv auch der Inhalt von /var/lib/vz/root/<VEID> da.
Und wenn er den Status running hat, muss /var/lib/vz/root/ vorhanden sein, denn dann läuft mindestens der init Prozess der VE schon und der kann nur laufen, wenn /var/lib/vz/root/<VEID> vorhanden/gemountet ist.

Wenn da schon Prozesse laufen und das siehst du ja mindestens im vzlist. Dann ist die VE auch verfügbar. Wenn dein SSHd ewig braucht zum Starten, ist das ein Problem des Dienstes und nicht der VE.
Lässt sich aber eben so mit einem "vzps -E <VEID> faux" oder einem normalen "ps faux" prüfen.

Schau dir doch einfach mal an, was er macht, während er die VE startet.

Spinx · Sep 23, 2012

Huch Verzeiht mein Fehler. Ich war auf einem anderen Homeserver

War wohl doch Gestern ein bischen zu spät und ein Bier zuviel.

Ich fange mal neu an

Auf meinem Homeserver habe ich OpenVZ installiert. Da ich viel Experimentiere und den VServer mehrmals am Tag neuinstalliere habe ich mir eine kleines Script in PHP geschrieben das eine bash file erstellt.

Code:

// Datei Ã–ffnen
$datei = fopen("openvz.sh","w");
			
// Alle Daten sammeln
$data = '#!/bin/bash'."\n";
$data .= '/usr/sbin/vzctl create ' . $adr['vsid'] . ' --ostemplate ubuntu-11.10-x86_64'."\n";
$data .= '/usr/sbin/vzctl set ' . $adr['vsid'] . ' --onboot yes --save'."\n";
$data .= '/usr/sbin/vzctl set ' . $adr['vsid'] . ' --hostname '.$adr['hostname'].' --save'."\n";
$data .= '/usr/sbin/vzctl set ' . $adr['vsid'] . ' --ipadd '.$adr['ip'].' --save'."\n";
$data .= '/usr/sbin/vzctl set ' . $adr['vsid'] . ' --nameserver 8.8.8.8 --nameserver 8.8.4.4 --save'."\n";
$data .= '/usr/sbin/vzctl start ' . $adr['vsid'] . "\n";
$data .= '/usr/sbin/vzctl set ' . $adr['vsid'] . ' --userpasswd root:'.$adr['rootpw']."\n";
$data .= '/usr/sbin/vzctl set ' . $adr['vsid'] . ' --applyconfig '.$adr['veimages'].' --save';
			
// Alles in die Datei schreiben
fwrite($datei, $data);
			
// Datei schlieÃŸen
fclose($datei);
			
// Openvz.sh aufrufen
exec('./openvz.sh');

Laut Logs ist alles sauber

Creating container private area (ubuntu-11.10-x86_64)
Performing postcreate actions
Container private area was created
Saved parameters for CT 100
Saved parameters for CT 100
Saved parameters for CT 100
Saved parameters for CT 100
Starting container ...
Container is mounted
Adding IP address(es): 192.168.178.23
Setting CPU units: 1000
Set hostname: h1.homeserver.de
File resolv.conf was modified
Container start in progress...
UB limits were set successfully
Setting CPU limit: 50
Setting CPU units: 1000
Setting CPUs: 4
Saved parameters for CT 100

Gestartet ist die VE auch, hier die Augabe einer Debian VE

CTID NPROC STATUS IP_ADDR HOSTNAME
100 7 running 192.168.178.23 h1.homeserver.de

Ein vzps -E 100 faux sagt

VEID USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
100 0 31367 0.0 0.0 8352 804 ? S 15:38 0:00 init [2]
100 0 31608 0.0 0.0 119692 1484 ? S 15:38 0:00 /usr/sbin/rsyslogd -c4
100 0 31634 0.0 0.0 20900 848 ? S 15:38 0:00 /usr/sbin/cron
100 0 31640 0.0 0.0 49168 1120 ? S 15:38 0:00 /usr/sbin/sshd

Und hier einer Ubuntu/Suse VE

vzlist -a
CTID NPROC STATUS IP_ADDR HOSTNAME
100 1 running 192.168.178.23 h1.homeserver.de

vzps -E 100 faux
VEID USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
100 0 2801 0.0 0.0 15452 1632 ? S 16:22 0:00 init

Soweit funktioniert dies auch, aber leider nicht immer. In 80% der Falle läuft es durch. Die Restlichen 20% wird die VE zwar angelegt aber ich erhalte kein Zugriff per putty. Dieses Prüblem tritt selten bei Debian 6 auf, Probleme macht dies bei Ubuntu 12 und Suche 12, die Images habe ich mir dort besorgt http://wiki.openvz.org/Download/template/precreated

Ich konnte jetzt keinen Fehler feststellen, deshalb wende ich mich an euch. Wo könnte das Problem liegen?

Firewire2002 · Sep 23, 2012

Spinx said:
Wo könnte das Problem liegen?

Die Ursache zu erraten ist nicht zielführend. Gib uns von einer VE, bei der das Problem aktuell besteht, die Ausgabe von "vzps -E <VEID> faux".

Ist die VE pingbar?
Kommst du per "vzctl enter <VEID>" hinein?

Dein Scriptchen da ist im übrigen recht Sinnfrei. Wenn da noch mehr drum herum steht, kannst du vzctl auch direkt per exec() ausführen. Oder du lässt das Perl(?) Gefrickel da weg und übergibst dem Bash Script direkt die richtigen Parameter.
Ausserdem ist die applyconfig Zeile an einer ungünstigen Position. Wenn ihm beim Starten schon die Ressourcen ausgehen, nützt es dir auch nichts, die nach dem Starten zu setzen. Ersatz applyconfig, dann die VE starten. Sinnvollerer Weise würdest du das aber direkt beim vzctl create übergeben. Eben so wie IP Adresse und Hostname.

Spinx · Sep 23, 2012

Ich hatte Oben meinen Beitrag nochmal kommentiert mit den nötigen Infos. Poste es aber nochmal Gerne.

Die Daten einer VE wo ich keinen Zugriff bekomme. weder per Putty noch per vzctl enter CTIE

vzlist -a
CTID NPROC STATUS IP_ADDR HOSTNAME
100 1 running 192.168.178.23 h1.homeserver.de

vzps -E 100 faux
VEID USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
100 0 2801 0.0 0.0 15452 1632 ? S 16:22 0:00 init

Dein Scriptchen da ist im übrigen recht Sinnfrei. Wenn da noch mehr drum herum steht, kannst du vzctl auch direkt per exec() ausführen.

Nein, es steht sonst nix mehr drum herum bis auf die SQL Abfrage im Header.

Perl(?) Gefrickel

PHP

Firewire2002 · Sep 23, 2012

Wenn "vzctl enter" nicht funktioniert, gibt es eine Fehlermeldung aus.
Und die wäre?

Spinx · Sep 23, 2012

Die Meldung lautet

enter into CT 100 failed
Unable to open pty: No such file or directory

Firewire2002 · Sep 23, 2012

Und diese Meldung verfütterst du nun an Google und nutzt eine der Tausend Lösungen.

Edit:
Welche Distribution hast du auf dem Hostsystem und welche Versionen der Distributionen hast du in den VEs?

Spinx · Sep 23, 2012

Ich habe auf dem Hostsystem Debian 6 46bit

Auf diesem habe ich folgende images zur Verfügung

centos-6-x86_64
debian-6.0-amd64-minimal
suse-12.1-x86_64
ubuntu-12.04-x86_64
ubuntu-11.10-x86_64

Bei allen klappt das anlegen einer VE relativ Gut. Lediglich Suse 12.1 und ubuntu 12.04 machen diese Probleme

Firewire2002 · Sep 23, 2012

Die Info hättest du auch mal zu Beginn bringen können. Hätte vieles erspart.
Kernel und VZ Tools auf dem Hostsystem sind zu alt. Kannst du vergessen.

Spinx · Sep 23, 2012

Sry, dachte das habe ich erwähnt.

Ein aptitude update bringt mir keinen neuen Pakete.
Ein erneutes Aufsetzen bringt vermutlich auch nix da er die alten Pakete wieder nutzt.

Nun habe ich 2 Möglichkeiten. Entweder mit Ubuntu 11 und suse 11.4 zufrieden geben oder schauen das ich den kernel und vz tools auf den neustenstand bringe wobei mit den vztools habe ich vorhin versucht. So wie ich nun gelesen habe muss ich folgendes Paket laden http://download.openvz.org/utils/vzctl/3.0.30.1/vzctl-3.0.30.1-1.x86_64.tar.gz entpacken und die Ordner Struktur behalten. Leider lassen sich die Files nicht überschreiben -.-

Firewire2002 · Sep 23, 2012

Solang du nicht wie Proxmox den RHEL Kernel nach Debian portierst, kannst du das eh vergessen.
Debian ist für ein OpenVZ Hostsystem die ungünstigste Distribution.

Nimm für das Hostsystem CentOS, Scientific Linux oder irgendwas anderes RHEL6 kompatibles und nutze die offiziellen OpenVZ RPMs/Repos. Dann funktioniert das auch dauerhaft und ohne gefrickel.

Spinx · Sep 23, 2012

Ok, also alles neuinstallieren und Centos Installieren? Das ist das kleinste Problem

Mr.Check · Sep 24, 2012

Yo, besser ist das. Danach sollte es ganz anders laufen ;-)

Spinx · Sep 24, 2012

Gut, dann schauen wir mal welche Unterschiede zu Debian bestehen und ob ich irgendwo ein howto mit den ersten schritten für centos finde

OpenVZ Container starten nicht mehr

New Member

Registered User

New Member

Deleted member 11691

Guest

Registered User

New Member

Registered User

New Member

Registered User

New Member

Registered User

New Member

Registered User

New Member

Registered User

New Member

Registered User

New Member

New Member

New Member

We value your privacy