VM werden sporadisch nicht automatisch gestartet - Failed to start VM "VM-Name" automatically.

    Moin zusammen,

    ich hab da auch mal eine Kleinigkeit, eventuell hat ja jemand Ideen...


    Ich betreibe 3 VM die ständig laufen, einmal wöchentlich wird das NAS per Zeitplan neu gestartet und die VM sollten anschließend wieder automatisch starten. Das klappt meistens auch, alle paar Wochen allerdings nicht.

    Betroffen sind mehr oder weniger abwechselnd alle VM, bei allen handelt es sich um Debian 10/11 Maschinen. Es ist bislang immer nur eine VM, die nicht startet, die anderen haben dann kein Problem. Die nicht gestartete VM ist dann suspended und kann manuell problemlos gestartet werden.

    Nachdem das NAS hochgefahren ist, bekomme ich dann die Meldung

    Code
    Error (...) [Virtualization Station] Failed to start VM "VM-Name" automatically. An exception has occurred..

    oder

    Code
    Error (...)	[Virtualization Station] Failed to start VM "VM-Name" automatically. Failed to carry out operation..

    Das passiert entsprechend auch mal nach manuellen Reboots. Ein offensichtlicher Zusammenhang, den ich mir trotzdem nicht erklären kann:


    Kurz bevor das Problem das erste Mal aufgetreten ist habe ich die SSDs, welche die VS sowie die VM hosten, nach deren Austausch (mehr Kapa) von statischem Volume auf Speicherpool umgebaut und dazu die VM zunächst exportiert, die VS de- und reinstalliert und anschließend die VM wieder importiert.

    Was mir jetzt wo ich mir die Problematik das erste Mal anschaue auch auffällt: Die CPU der VM waren eigentlich auf "Passthrough" gestellt, beim Import scheinen alle auf "AMD Opteron 63xx" umgestellt worden zu sein.

    Das werde ich jetzt schonmal korrigieren, habt ihr sonst noch Ideen, woher das Problem kommen kann?


    QTS 4.5.3

    VS 3.6.16 (Problem besteht seit 3.6.10, welche unglücklicherweise unmittelbar vor der SSD-Umstellung rauskam)


    Cheers!

    Zwei Ideen, die helfen könnten:


    1)

    Wie ist der Hauptspeicherausbau? Eine VM scheint viel Speicher im Stück belegen zu wollen. Womöglich ist der Speicher beim Boot nicht vorhanden, später aber schon. Seit ich meinem NAS mehr Hauptspeicher gegönnt habe, werden die VMs beim Systemstart zuverlässiger gestartet.


    2)

    In den Release-Notes zu 3.6.16 schreibt Qnap

    Mod: Zitat ohne Quellenangabe ... korrigiert! :handbuch::arrow: Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

    Zitat von Release Notes: Virtualization Station 3.6.16

    To avoid bootstorm-related issues, we have added a startup delay feature to the "Retain Previous Status" auto start policy in the Settings page of VMs.

    Beim Booten scheinen gewisse Probleme häufiger aufzutreten.


    Hast du die "Start-Verzögerung" bei "vorherigen Status bewahren" schon ausprobiert?

    Zitat von Anthracite

    Wie ist der Hauptspeicherausbau?

    Das NAS (TVS-473) hat 16GB RAM, den VM ist jeweils 1GB zugewiesen, Memory Sharing ist aktiv.

    Das sollte doch eigentlich passen, weiß aber auch nicht, wie die Auslastung beim Systemstart tatsächlich aussieht, da das Monitoring in einer der VM läuft und beim Reboot nicht verfügbar ist :S

    Zitat von Anthracite

    Hast du die "Start-Verzögerung" bei "vorherigen Status bewahren" schon ausprobiert?

    Gerade mal geschaut: Die sind alle per Default auf 60s gestellt.

    Dabei steht auch der Hinweis "Online VMs will be suspended before the NAS shuts down or reboots. However, a VM that uses SATA controllers will be shut down by sending an ACPI signal.". Die VM haben allerdings alle nur eine VirtIO HDD.


    Die Zeit werde ich dann mal hochschrauben, erstmal will ich aber beobachten ob die Anpassung der CPU etwas bewirkt.

    Schalte mal das Memory sharing aus. Das kostet nach meiner Erfahrung viel Leistung und bringt nicht viel.


    Ram wird die Kiste genug haben um 3 GB für die VMs abzweigen zu können.

    Beim Boot sind eher IOs und CPU das Limit, da ja nach QTS alle Apps starten. Sind hier dann einige mit DBs dabei, gibts entsprechende Wartezeiten.

    Starten dann noch 3 VMs gleichzeitig wieder, fällt die letzte je nach Last in einen Timeout.


    Also mal 30 Sekunden versetzt starten lassen sollte dann reichen.

    Werde ich auch mal testen bzw. ohnehin umsetzen. Will jetzt nur mal sehen ob die Anpassung der CPU schon was bringt, vorher gab es das Problem ja nicht.

    Eine VM ist nicht der Rede wert, die anderen beiden hosten jeweils LibreNMS (viel Datenbank) und den Unifi Controller (hier dürfte auch etwas Datenbank drinstecken).

    Ich habe zwei Debian- und eine Fedora-VM, die in Minimalkonfiguration eigentlich nach einem Neustart mit 180s Verzögerung in den alten Zustand gehen sollen. Meist machen das zwei davon, ganz selten hängt sich eine davon auf. Die eine (immer die gleiche) macht das aber nur ganz selten. Sie ist praktisch immer im Suspend-Modus und ich muss dann jedes mal erst Abschalten erzwingen und sie dann neu starten. Da hat auch ein erhöhen der Start-Verzögerung nichts geholfen. Auch das deaktivieren des Memory-Sharings hat bei mir nichts geholfen.


    Nicht ganz passend, aber doch in die Richtung habe ich bei allen diesen Linux-VMs folgendes "Problem": Es wird der NTP-Server bei einem Neustart des kompletten NAS nicht rechtzeitig gefunden. Da muss ich dann jedesmal für alle diese drei VMs nochmal nach Neustart manuell den NTP-Dienst neu starten. Hab's mal per Cronjob versucht, da habe ich aber auch noch einen Knoten drin.

    Für das NTP Problem könnte der Start mit einer Systemunit evtl. eine Lösung sein.

    Da kann man Bedingungen eintragen, z.B. erst NTP starten wenn die IP/Host xyz (z.B. der NTP Host) erreicht werden kann.


    Gruss

    Da muss ich mal wieder in meinem Gedächtnis wühlen - vor langer Zeit hatte ich mal sowas gemeint, verstanden zu haben....

    Zitat von tiermutter

    Die CPU der VM waren eigentlich auf "Passthrough" gestellt, beim Import scheinen alle auf "AMD Opteron 63xx" umgestellt worden zu sein.

    Das werde ich jetzt schonmal korrigieren

    Mittlerweile hat das NAS mindestens 5 geplante und einen ungeplanten Neustart durch und das Problem ist nicht wieder aufgetreten.

    Es scheint also durch die Anpassung der CPU behoben zu sein, ich werde den Start der VMs aber dennoch verzögern.

    Kann auch bestätigen, dass ohne Start-Delay (oder zu niedrigem Wert dessen) VMs direkt nach Start der VS random nicht starten wollen. Mit 180 Sek ist man da auf jeden Fall auf der sicheren Seite. Ich vermute es liegt mal wieder an der etwas unüberlegten Startreihenfolge der Apps in QTS. Wenn da zB.: ne VM starten will, aber der Netzwerk-Service (vSwitches) noch nicht up ist, wirds krachen.


    tiermutter: Als Idee noch für dich. Den Unifi Controller gibts auch als Docker-Image. Der ist deutlich Ressourcen schonender als die VM und kann dasselbe.

    Habe die VM mittlerweile auch verzögert... das Docker Image kenne ich, da ich ja aber ohnehin die VS für die anderen VM brauche wollte ich es mir dann auch gleich sparen zusätzlich die CS zu installieren. Denke das könnte dann eine Nullnummer werden wenn die CS auch noch laufen muss :S

    Ja da hast du recht. Nur wegen dem einen Container lohnt die Installation der CS nun auch nicht :)

    Außerdem müsste ich dann schon wieder was Neues lernen... hatte mir die CS mal angeschaut (glaube sogar mit dem Unifi Container) und bin ad hoc nicht zurecht gekommen... da bringe ich mir dann lieber irgendwas Anderes bei :S

    Das stimmt, die Docker-Thematik ist mächtig. Bedarf aber einer gewissen Einarbeitung und hat ne steile Lernkurve. Hat mich auch ein paar Monate gekostet, bis ich das Ding anständig bedienen konnte. :D

    Aber aus Effizienzgründen ist das schon ein sehr feines Tool. Hab hier 20 Container am laufen die in Summe kein 4GB RAM schlucken. Diese Packungsdichte bekommst du mit VMs bei weitem nicht hin, weil Jede VM nun mal den kompletten RAM den du als Max eingestellt hast komplett allokiert/blockiert.


    Bei mir läuft beides. CS u. VS. Ich schau immer, ob ich mein Service in nem Container vernünftig ins Laufen bekommen und verwende VS als Fallback, wenns nicht oder nicht ordentlich funktioniert in nem Container. Auch das gibts natürlich.

    Ja das stimmt schon. Aber solange die Hardware noch mitmacht mache ich mir da noch keine Gedanken... Für die 24/7 gehen 3 von 16GB drauf, schlimmstenfalls sind noch zwei Slots frei um den RAM zu erweitern... Hauptsache nichts Neues lernen :D