Zufällige und unkontrollierte Neustarts

SomerHimson

Active Member
Mar 29, 2017
28
1
43
Germany
Hallo zusammen! :)

Ich beschäftige mich erst seit rund 10 Wochen mit Proxmox, bin ein (angehender) "Konvertit" von (gaaanz altem) VMware.

Habe mir extra einen nagelneuen I7-7700 mit 32 GB RAM, 2x4 TB WD Gold und 256 GB SSD beschafft (ZFS RAID 1 über die vollen WDs; sind auch ein paar eth's drin).

Die installierte Version ist diese hier:
Linux version 4.4.35-1-pve (root@elsa) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Fri Dec 9 11:09:55 CET 2016

Die Kiste macht leider völlig unkontrollierte Neustarts, manchmal jeden Tag, manchmal länger. Jetzt im Moment läuft sie 7 Tage.

Habe mit ein Heartbeat geschrieben, der im Minutentakt eine Logdatei füllt. Diese Einrichtung verriet mir, der unkontrollierte Neustart läßt lediglich ein HB aussetzen, während ein kontrollierter drei fehlen läßt. Ich habe daher die Vermutung, die Karre fährt gar nicht wirklich sauber runter, sondern drückt quasi den Reset-Knopf.
Ich habe mir letzte Woche ein Skript geschrieben, das bei allen Runlevelstarts einen Eintrag mit dem Aufruf und dem aktuellen Runlevel macht. Ich hoffe so einen Beweis zu finden, ob der Server wirklich neustartet oder einfach den "Reset-Knopf drückt". Seitdem läuft die Maschine, da habe ich also noch keine weiteren Erkenntnisse.

In den üblichen (von Debian kommend) Logdateien steht nie etwas, das irgendwie auf ein Runterfahren hindeutet. Man sieht immer nur, die Kiste startet und dann kommen ganz normal die einzelnen Dienste, als wäre ein ganz normaler Start durchgeführt worden.

Interessanter Weise laufen die Instanzen danach auch wieder recht sauber. Lediglich eine Sophos UTM hat einmal sich komisch aufgehängt und eine Windows 8.1 Pro-Instanz hängt gelegentlich beim Booten (letzteres aber auch bei Instanzstart von Hand).

Das Thema Stromschwankungen kann man recht gut ausschließen, denn der Server hängt an einer 1500 VA APC-USV (noch ohne Datenkommunikation) und im BIOS ist das Einschalten nach Spannungsrückkehr ausgeschaltet.
Den RAM habe ich 28 Stunden mit memcheck durch intensive Prüfung gequält, das war nicht auffällig.
Ehrlich gesagt kann ich mir schwer vorstellen, die Hardware hat was, die Kiste ist ganz neu und vom guten Händler maßgeschneidert.

Meine Frage an die Experten ist nun, was muß passieren, damit Proxmox einfach neustartet.
Was bzw. wo kann ich mir noch nachschauen um Hnweise zu bekommen?

Bitte um jeden Hinweis, Tip und Rat dankbar. Im Moment steht der dicker Rechner hier nur rum und frißt Strom. Solange der nicht sauber läuft kann ich seinen 14 Jahre alten Vorgänger nicht in Rente schicken. :-(
 

Attachments

  • Proxmox.jpg
    Proxmox.jpg
    112.6 KB · Views: 29
Hi,

bitte unbedingt updatenden. Der 4.4.35 hat Probleme mit zfs.
 
Wow, das nenne ich prompte Antwort...

Danke für den Tip, werde ich gerne umsetzen. Muß ich jetzt nur schnell rausfinden, wie das geht, mit apt-get update dann upgrade wollte er eben nur einen handvoll Samba-Zeug nachziehen.

Er meckert das hier an:

W: Failed to fetch https://enterprise.proxmox.com/debian/dists/jessie/pve-enterprise/binary-amd64/Packages HttpError401

E: Some index files failed to download. They have been ignored, or old ones used instead.
TASK ERROR: command 'apt-get update' failed: exit code 100
 
Danke, ich schaue mir das mal in Ruhe durch.

Wäre ja prima, wenn das das Problem lösen würde, ich bin nämlich echt absolut am Ende mit meinem (wenn auch spärlichen) Latein.
 
  • Like
Reactions: PargeLenis
Ich weiß zwar nicht, was ich heute anders als gestern Abend gemacht habe, aber jetzt hat das Upgrade funktioniert:

Linux version 4.4.49-1-pve (root@nora) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP PVE 4.4.49-86 (Thu, 30 Mar 2017 08:39:20 +0200)

Werde jetzt die Kiste mal beobachten. Vielleicht hat das ja schon mein Problem gelöst. :)
 
Leider ist die Kiste eben gerade wieder neugestartet. :-(
Mein Runlevel-Protokoll meint, es wurde nicht das System runtergefahren, sondern nur gestartet.

Wo kann ich noch nach dem Grund suchen? Gibt es vielleicht eine spezielle Sicherheitsfunktion von Proxmox, die die Kiste neustartet um ein Einfrieren zu verhindern?
 
Leider ist die Kiste eben gerade wieder neugestartet. :-(
Mein Runlevel-Protokoll meint, es wurde nicht das System runtergefahren, sondern nur gestartet.

Wo kann ich noch nach dem Grund suchen? Gibt es vielleicht eine spezielle Sicherheitsfunktion von Proxmox, die die Kiste neustartet um ein Einfrieren zu verhindern?
Hi,
nö das klingt eher nach einem Problem mit der Hardware...
Ist Dein Bios aktuell?
Vielleicht hat das PSU oder RAM ein Problem?

Wenn im Log nix steht, kann man kernel-dump einschalten - am sichersten ist es dies seriell auf ein andren Rechner zu übertragen, um dort die Ausgabe mitzubekommen. Denn wenn der Kernel meint, es reicht ihm ist "er" häufig nicht in der Lage noch was auf's Plattensystem zu loggen.

Udo
 
Hallo Udo,

in den letzten Monaten haben wir das damals verbaute Netzteil als "irgendwie" defekt eingrenzen können. Nach einem Austausch gab es Wochenlang keinen Neustart, unter genau gleicher Belastung wie zuvor. Dann gab es innerhalb einer Woche zwei ungeplante Neustarts, so ich mir nicht sicher war, ob ich da nicht vielleicht was "verfummelt" hatte. Dann wieder wochenlang Ruhe und ein neues Netzteil verbaut (hatte nur eines zum Testen drin) und auch damit war das System einige Wochen einwandfrei. Dann habe ich angefangen die Kiste mehr zu nutzen und habe gemerkt, das die Zugriffe auf die Platten recht langsam sind, zumindest phasenweise. CPU-Last war immer unter 20 %, daran kann es nicht gelegen haben. Dann in den letzten zwei Wochen jetzt, hat das System viermal alleine neugestartet, ohne Fehler in den Logs (zumindest so weit ich sehen kann). dreimal davon war, als ich sehr hohe Plattenlast hatte (2x 4 TB WD Gold als ZFS). Gefühlt verhält sich das System, als wenn es "stolpert" bei Dampf auf den Platten, bis es "hinfällt". Die Datentransfers sind teilweise in Schüben bzw. er macht "Gedenksekunden".

Was mich von Anfang an wundert ist, ich kann nichts in den Verzeichnissen /rpool/ROOT/pve-1 und /rpool/data sehen. Als würden da gar keine Dateien drin liegen. Da ich keine Erfahrung mit ZFS habe (ist mein erstes System damit) dachte ich bisher, das ist vielleicht doch normal. Könnte aber auch auch ein Problem mit dem FS oder dem Mounten hinweisen.

Hat jemand einen Tip, was ich noch anschauen oder/oder probieren könnte?

Da ich seit zwei Wochen den alten Server abgeschaltet habe (ging ja alles gut mit dem neuen bis dahin), sind die Neustarts und Problemchen jetzt von "nervig" auf "kritisch" gestiegen... :-(

Gruß,
Christian

PS.:
root@Proxmox-01:/etc/default# mount | grep rpool
rpool/ROOT/pve-1 on / type zfs (rw,relatime,xattr,noacl)
rpool on /rpool type zfs (rw,noatime,xattr,noacl)
rpool/ROOT on /rpool/ROOT type zfs (rw,noatime,xattr,noacl)
rpool/data on /rpool/data type zfs (rw,noatime,xattr,noacl)
 
Hi,
hat der Server ein lom? Wo ggf Health-Werte geloggt werden?
Dein Eingangs-Post klingt allerdings eher nicht danach, aber da kann ich mich täuschen.

Hat Dein Bios Einstellungen, um den server zu restarten, wenn er nicht healthy ist (sollte nicht eingeschaltet sein)?

Hast Du dir die SMART-Werte der Platten (SSD) mal angesehen?
Was ist das für eine SSD und wie benutzt du sie (wegen IO in Schüben).

Wie sieht dein ZFS-Pool aus?
Code:
zpool status
Udo
 
Hallo Udo,

bei "lom" stehe ich auf dem Schlauch. Ich habe (leider) keinen richtigen Profi-Server mehr hier laufen (frißt mir zu viel Strom).

Meine Hardware ist das hier:
- Intel Core i7-7700
- Gigabyte GA-Q170M-D3H (-> u.a. Intel® Q170 Express Chipset, Intel® GbE LAN chip)
- 2x 16GB Kingston HyperX Fury DDR4 PC2400
- Intel I350-T2 (2x 1Gbit/s) (-> Intel(R) PRO/1000 Network Connection)
- HP NC364T D90972 Quad Port (-> Intel(R) PRO/1000 Network Connection)
- 400W BeQuiet 80+ gold
- 2x 4TB WD Gold 7,2k
- 256GB Samsung PM961
- DVD-Brenner

Wenn Du mir einen Tip geben kannst, wonach ich bei diesen "Healthy"-Dingen im BIOS suchen kann, schaue ich da natürlich gleich nach.

Die SSD nutze ich zur Zeit nur als schnelle Partition für einige Instanzen, das ZFS- nutzt die gar nicht.

*******************************
root@Proxmox-01:~# zpool status
pool: rpool
state: ONLINE
scan: scrub repaired 0 in 29h10m with 0 errors on Mon Oct 9 05:34:15 2017
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda2 ONLINE 0 0 0
sdb2 ONLINE 0 0 0

errors: No known data errors
*********************************

Was mir im /var/log/deamon.log noch auffällt ist die Flut von Meldungen wie diese hier:

*********************************
Oct 29 12:10:29 Proxmox-01 rrdcached[3277]: queue_thread_main: rrd_update_r (/var/lib/rrdcached/db/pve2-vm/100) failed with status -1. (/var/lib/rrdcached/db/pve2-vm/100: illegal attempt to update using time 1509275139 when last update time is 3216423524 (minimum one second step))
Oct 29 12:10:29 Proxmox-01 rrdcached[3277]: queue_thread_main: rrd_update_r (/var/lib/rrdcached/db/pve2-vm/105) failed with status -1. (/var/lib/rrdcached/db/pve2-vm/105: illegal attempt to update using time 1509275139 when last update time is 2872078261 (minimum one second step))
**********************************

Davon gibt es massig, da kommen alle 5 Minuten so eine Art Schübe, von unterschiedlichesten Dateien.
Jetzt läuft die Maschine übrings wieder seit zwei Tagen rund. Rechenlast liegt im Mittel bei 25 % und Temperaturen sind alle weit im grünen Bereich (SMART und sensors werden im halbstunden-Takt protokolliert).

Danke, das Du Dir für mich Zeit nimmst.
 
Hallo Udo,

bei "lom" stehe ich auf dem Schlauch. Ich habe (leider) keinen richtigen Profi-Server mehr hier laufen (frißt mir zu viel Strom).
Hi,
lom (light outs management) oder idrac (bei dell-server) kann recht hilfreich bei der Fehlersuche sein
Meine Hardware ist das hier:
- Intel Core i7-7700
- Gigabyte GA-Q170M-D3H (-> u.a. Intel® Q170 Express Chipset, Intel® GbE LAN chip)
Welche Bios-Version hast Du am Start?
Siehe hier: https://www.gigabyte.com/Motherboard/GA-Q170M-D3H-rev-10#support-dl
demnach behebt z.B. F21 was passen würde:
F21 : Improve system stability

Wie sieht es mit anderen Bios-Einstellungen aus (Performance, Spannungen für Ram+CPU, Overclocking, Turbo - keine Ahnung wie Gigabyte dies inzwischen alles so nennt).
Ich würde, falls das Bios nicht up-to-date ist, dieses Updaten, danach Factory-Defaults setzten und konservative Einstellungen wählen.

Udo
 
Hallo Udo,

das Bios ist auf F21, und F22 kann man nur unter Windows brennen. Da ich nur Proxmox auf der Kiste hab', weiß ich noch nicht, wie ich das jetzt aktualisiert bekomme. Wenn ich eine praktiable Lösung gefunden habe, werde ich natürlich auf F22 nachziehen. Einstellungen hab' ich nicht groß angepasst, da meine aktive Bios-Tuning-Zeit schon länger her ist und die meisten Parameter dort für mich bömische Dörfer.

Kann ich noch irgendwas im Proxmox nachschauen oder ausprobieren?
 
Oh, kann das sein, das Du im Server lebst? ;-)
Nachdem dort auf der Gigabyte-Seite von Windows stand und ich nicht mein Bios riskieren wollte, hab' ich lieder keine Experimente versucht. Aber wie gesagt, meine "heiße" Hardware-Zeit ist rum.
Ich werd's die Tage mal probieren, zur Zeit wird der Server stark genutzt (so er denn nicht neustartet ;-) ).
Ich geb' dann Bescheid, wenn ich das Board geflasht hab'.
 
Hallo Udo,
es hat etwas gedauert, und ich habe viel rumprobiert. Das neuste BIOS kriege ich mangels Windows auf der Maschine nicht drauf (das mit FreeDOS schnall ich nicht oder es funktioniert echt nicht), aber ich habe mich arrangiert gehabt.

Jetzt habe ich eine zweite Maschine mit nagelneuen Teilen gebaut (I5-7500, Asus Z170-P, 2x4 GB Samsung, 2x2TB WD Red, usw.) und auch Proxmox 5.1 rel. 3 darauf gepackt. Also es ist praktisch alles anders als beim großen, aber trotzdem hat der eben mitten in der Installation meiner zweiten Instanz (Sophos UTM) einfach neugestartet.
Ich kapiers gar nicht mehr, habe nichts vom großen Übertragen, so absolut gar nichts, und trotzdem passiert das gleiche.

Ich habe dabei übrings gemerkt, die große Kiste hat scheinbar immer noch PVE 4.4, trotz ständiger Updates und Dist-Upgrades:
Kernelversion: Linux 4.4.98-2-pve #1 SMP PVE 4.4.98-101 (Mon, 18 Dec 2017 13:36:02 +0100)
PVE Manager Version: pve-manager/4.4-20/2650b7b5

Die neue Schachtel:
Kernelversion: Linux 4.13.13-2-pve #1 SMP PVE 4.13.13-32 (Thu, 21 Dec 2017 09:02:14 +0100)
PVE Manager Version: pve-manager/5.1-41/0b958203

Was kann ich noch tun?
Ist da im BIOS vielleicht eine Stolperfalle?
"VT-d" mag Proxmox gar nicht, da friert er direkt bei Starten ein, das hab' ich schon gelernt.

PS.: Mir fällt eben eine komische Sache ein: Auf der großen Maschine hat in den letzten 6 Wochen die UTM die NIC zur internen DMZ (keine Hardwarekarte, rein intern) verloren. Aber nur die UTM, die anderen Instanzen in der DMZ nicht.
Kann es vielleicht was mit der UTM zu tun haben? Ich meine, die SCSI-Emulation akzeptiert sie auch nicht, daher hab' ich VirtIO für die Platte genommen.

PS.-2: Vorgestern morgen ist der große Server wieder neugestartet. Komisch war dieses Mal, das die UTM einen Neustart wegen Up2date meldete (sonst hieß es immer "unknown"). Das brachte mich zu der Idee, das vielleicht ein bestimmter Reboot-Befehl einer Instanz die reale CPU neustartet. Ich benutze als CPU-Einstellung keine Emulation sondern "host", Kann das damit was zu tun haben?
 
Last edited:
Hallo Udo,
es hat etwas gedauert, und ich habe viel rumprobiert. Das neuste BIOS kriege ich mangels Windows auf der Maschine nicht drauf (das mit FreeDOS schnall ich nicht oder es funktioniert echt nicht), aber ich habe mich arrangiert gehabt.

Jetzt habe ich eine zweite Maschine mit nagelneuen Teilen gebaut (I5-7500, Asus Z170-P, 2x4 GB Samsung, 2x2TB WD Red, usw.) und auch Proxmox 5.1 rel. 3 darauf gepackt. Also es ist praktisch alles anders als beim großen, aber trotzdem hat der eben mitten in der Installation meiner zweiten Instanz (Sophos UTM) einfach neugestartet.
Ich kapiers gar nicht mehr, habe nichts vom großen Übertragen, so absolut gar nichts, und trotzdem passiert das gleiche.
Hi,
kannst Du mal die Configs der laufenden VMs posten?
Code:
vms=`qm list | grep running | awk '{print $1}'`
for i in $vms; do echo "VM $i:"; qm config $i; echo ""; done
Ich habe dabei übrings gemerkt, die große Kiste hat scheinbar immer noch PVE 4.4, trotz ständiger Updates und Dist-Upgrades:
Kernelversion: Linux 4.4.98-2-pve #1 SMP PVE 4.4.98-101 (Mon, 18 Dec 2017 13:36:02 +0100)
PVE Manager Version: pve-manager/4.4-20/2650b7b5
ah ha - das klingt nach falschen repo!
Nimm mal bitte das pve-no-subscription ( https://pve.proxmox.com/wiki/Package_Repositories ) und mache ein
Code:
apt update
apt dist-upgrade

reboot
Die neue Schachtel:
Kernelversion: Linux 4.13.13-2-pve #1 SMP PVE 4.13.13-32 (Thu, 21 Dec 2017 09:02:14 +0100)
PVE Manager Version: pve-manager/5.1-41/0b958203
Hast Du hier das richte Repo drin?
...
Ich benutze als CPU-Einstellung keine Emulation sondern "host", Kann das damit was zu tun haben?
Fast alle VMs lasse ich unter dem standard kvm64 laufen... wenn Du verschlüsselung innerhalb der VM nutzt kann sich aes oder ähnliches natürlich sehr lohnen, was Du durch die host-cpu bekommst.

Udo
 
Guten Morgen Udo,

hier die Ausgabe der VM-Konfigs:

***************************************************************************************
VM 100:
bootdisk: scsi0
cores: 1
cpu: host
ide2: none,media=cdrom
memory: 1024
name: 03-Angie
net0: e1000=E6:F2:C9:D8:16:CC,bridge=vmbr0
net1: e1000=6E:7A:5B:BB:82:F4,bridge=vmbr12
numa: 0
onboot: 1
ostype: l26
parent: Vor_LDAP_2
scsi0: local-zfs:vm-100-disk-1,size=32G
scsi1: SSD:100/vm-100-disk-1.qcow2,size=1G
scsihw: virtio-scsi-pci
smbios1: uuid=b0b799b8-5db3-4919-8c5f-64833c93fc02
sockets: 1
startup: order=3,up=90,down=45

VM 102:
bootdisk: ide0
cores: 4
cpu: host
ide0: local-zfs:vm-102-disk-1,size=80G
ide1: local-zfs:vm-102-disk-3,size=768G
ide2: none,media=cdrom
memory: 4096
name: 04-Jane
net0: e1000=0A:C5:D7:A4:8C:14,bridge=vmbr1
numa: 0
onboot: 1
ostype: win8
parent: System_laeuft
scsihw: virtio-scsi-pci
smbios1: uuid=4004f8fd-08c0-4c4e-9d90-4af9f91ff8af
sockets: 1
startup: order=4,up=15,down=60

VM 103:
boot: cdn
bootdisk: virtio0
cores: 2
cpu: host
ide2: none,media=cdrom
memory: 3072
name: 02-Lagertha
net0: e1000=62:C9:AD:FC:9D:F5,bridge=vmbr0
net1: e1000=D2:5D:02:AE:BC:D8,bridge=vmbr11
net2: e1000=32:7D:9E:94:38:24,bridge=vmbr12
net3: e1000=EE:E4:52:CA:DA:8B,bridge=vmbr1
net4: e1000=9E:F4:10:CF:64:1F,bridge=vmbr5
net5: e1000=26:22:9B:EB:D0:01,bridge=vmbr2
numa: 0
onboot: 1
ostype: l26
parent: PasswdProblem
scsihw: virtio-scsi-pci
smbios1: uuid=176b73b7-17a9-4845-a2b1-1b757306df45
sockets: 1
startup: order=2,up=60,down=60
virtio0: local-zfs:vm-103-disk-1,size=100G

VM 105:
bootdisk: scsi0
cores: 2
cpu: host
ide2: none,media=cdrom
memory: 8192
name: 05-Maura
net0: virtio=2E:F5:F7:85:FD:EC,bridge=vmbr0
numa: 0
onboot: 1
ostype: l26
parent: Vor_LDAP
scsi0: local-zfs:vm-105-disk-1,size=10G
scsi1: local-zfs:vm-105-disk-2,size=200G
scsi2: local-zfs:vm-105-disk-3,size=2560G
scsihw: virtio-scsi-pci
smbios1: uuid=f933583d-b8d5-47fa-9564-59b98547b96e
sockets: 1
startup: order=5,up=30,down=30

VM 106:
bootdisk: scsi0
cores: 1
cpu: host
ide2: ISO-Images:iso/ipfire-2.19.x86_64-full-core109.iso,media=cdrom
memory: 512
name: 01-Katja
net0: e1000=46:F8:9C:72:A3:18,bridge=vmbr11
net1: virtio=96:5A:C9:51:55:79,bridge=vmbr4
numa: 0
onboot: 1
ostype: l26
scsi0: local-zfs:vm-106-disk-1,size=6G
scsihw: virtio-scsi-pci
smbios1: uuid=691548e7-4140-410d-a1d2-346bc4aea2aa
sockets: 1
startup: order=1,up=60,down=60

VM 108:
boot: cdn
bootdisk: ide0
cores: 1
cpu: host
ide0: local-zfs:vm-108-disk-1,size=4G
ide2: none,media=cdrom
memory: 128
name: 05-Amidala
net0: rtl8139=96:A2:37:C5:F9:3C,bridge=vmbr0
numa: 0
onboot: 1
ostype: l26
scsihw: virtio-scsi-pci
smbios1: uuid=35f7cded-7261-4a66-8e14-ab4d96887d46
sockets: 1
startup: order=5,up=30,down=30

VM 109:
bootdisk: scsi0
cores: 1
cpu: host
ide2: none,media=cdrom
memory: 128
name: 02-Carmen
net0: e1000=D2:08:AE:0D:0B:0E,bridge=vmbr11
net1: e1000=1E:BD:CF:C1:AA:7D,bridge=vmbr2
numa: 0
onboot: 1
ostype: l26
scsi0: local-zfs:vm-109-disk-1,size=5G
scsihw: virtio-scsi-pci
smbios1: uuid=d85a5046-1ce7-4109-b439-af159f62981a
sockets: 1
startup: order=2,up=30,down=30

VM 111:
bootdisk: ide0
cores: 1
cpu: host
ide0: local-zfs:vm-111-disk-1,size=10G
ide1: none,media=cdrom
memory: 384
name: 07-Inken
net0: rtl8139=4A:F0:8B:79:4F:02,bridge=vmbr0
net1: rtl8139=E2:E5:58:A8:2D:BB,bridge=vmbr6
numa: 0
onboot: 1
ostype: wxp
parent: Frisch_aufgesetzt
scsihw: lsi
smbios1: uuid=1d19b6a6-2b32-4931-ae8e-2c2fe977d78b
sockets: 1
startup: order=7,up=15,down=15

VM 112:
bootdisk: ide0
cores: 2
cpu: host
ide0: local-zfs:vm-112-disk-1,size=40G
ide2: ISO-Images:iso/Win10_1607_German_x64.iso,media=cdrom,size=4185302K
memory: 2048
name: 06-Diana
net0: e1000=12:8A:4E:25:44:26,bridge=vmbr0
numa: 0
onboot: 1
ostype: win10
parent: Vor_GigabyteFlash
scsihw: virtio-scsi-pci
smbios1: uuid=d93bac75-c1ef-46e2-ad23-89c1b10bde89
sockets: 1
startup: order=6,up=15,down=15

VM 113:
bootdisk: ide0
cores: 1
cpu: host
ide0: SSD:113/vm-113-disk-1.qcow2,size=4G
ide1: SSD:113/vm-113-disk-2.qcow2,size=2G
ide2: none,media=cdrom
memory: 384
name: 06-Lucy
net0: rtl8139=46:EA:89:78:6B:E2,bridge=vmbr0
numa: 0
onboot: 1
ostype: wxp
scsihw: lsi
smbios1: uuid=0ca1db05-a805-4f10-b6a9-912e6b29f74a
sockets: 1
startup: order=6,up=15,down=15
***************************************************************************************

Die Repos sind von Jessie, da habe ich nix geändert. Dachte das würde mit den dist-upgrades automatisch gemacht.
Passe ich gleich mal an und versuche mein Glück. Ich fahre mal sicherheitshalber die VMs runter und hoffe danach kann ich sie normal starten. Hab da einiges im Netz gelsen von Problemen beim Upgrade von 4.4 auf 5.x...

Mit den CPUs, da hab' ich "host" genommen, weil ich keine Live-Migration machen werde, habe hier nur einen Server stehen, der Strom ist mir zu teuer. Habe es "nur zum Spielen" und da müßen sich die Kosten gegenüber der "Regierung" rechtfertigen lassen.

Der neue Server hat mich inzwischen auf folgende Theorie gebracht:
Wenn der RAM zu voll wird, scheinen die plötzlichen Neustarts aufzutreten. Ich habe da ja noch praktisch grüne Wiese den mal über Nacht mit drei Instanzen laufen lassen, war einwandfrei. Vorhin habe ich zum Test meiner Theorie eine weitere Instanz gestartet und keine 15 Minuten später kam ein Neustart. Wie immer ohne jede Einträge und Vorwarnung, zumindest nicht dort, wo ich schaue.
Die neue Maschine hat aus Kostengründen nur 8 GB, dachte das reicht für den Kleinkram meiner Eltern. Mittlerweile weiß ich, das war zu wenig, wegen des ZFS, neuer RAM ist heute morgen auch schon gekommen. Trotzdem, über Nacht liefen VM's mit 6,5 GB RAM was mit den 8 GB und KSM sharing von rund 800 MB recht knapp war. Aber es ging scheinbar. Die vierte Instanz hat 1 GB und das ist natürlich zu viel, war ja auch Absicht. Ich würde jetzt von Proxmox bei einer RAMüberlastung erwarten, das es einzelnen VM's ausschaltet oder zumindest ein paar Fehlermeldungen irgendwo hinschreibt, bevor es neustartet, aber trotzdem scheint es mit dem zu vollen RAM zu tun zu haben.
Auf dem großen Server haben alle VM's zusammen 19,5 GB RAM mit 7,2 GB KSM sharing, wenn ich mich nicht verrechnet habe, sollte bei 32 GB eigentlich reichen. Aber, wenn ich jetzt heftig den Cache beanspruche, durch Schreiben und Lesen auf der Platte, dann steigt der RAM-Bedarf und könnte vielleicht zu einem ähnlichen Effekt wie beim kleinen Server führen.

upload_2018-1-11_11-16-16.png

Was hälst Du von der Theorie?
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!