Ich habe eine seltsame Situation mit meiner gehosteten Engine in oVirt.
Wir haben einen oVirt-Cluster eingerichtet, der Gluster als Speicher für die Engine-ISOs und alle Informationen verwendet. Vor etwa einer Woche sind zwei der drei Server ausgefallen. Wir haben die Maschinen etwa dreimal neu gestartet und die Gluster-Hosts haben sich als verbunden gemeldet und keine Split-Brain-Fehler gemeldet.
Der gehostete Engine-Prozess versuchte, die gehostete Engine auf einem der Hosts hochzufahren, aber sie ging in den Zustand EngineUnexpectedlyDown über. Und er zog 1600 von der Punktzahl des Servers ab und versuchte dann, sie auf der nächsten Maschine hochzufahren, bis alle bei etwa 800 Punkten landeten. Er versuchte dann nur, auf einer Maschine zu booten, blieb dann aber einfach mit der Meldung „VM konnte nicht erreicht werden“ stehen.
Wir haben herausgefunden, dass die gehostete Engine tatsächlich bootet, da wir uns mit einem VNC-Client mit ihr verbinden können. Aber sie scheint sich in einer Art gesperrtem Zustand zu befinden. Wenn Sie sich bei der gehosteten Engine anmelden, können selbst als Root keine Dateien geändert werden und die VM ist auf keine andere Weise zugänglich.
Gibt es eine Möglichkeit zu sehen, ob die VM gesperrt/schreibgeschützt ist? Und gibt es eine Möglichkeit, diese Sperre zu entfernen?
Antwort1
Angenommen, Sie haben Replik 3 verwendet. Wenn 2 Hosts ausfallen, wird das Dateisystem schreibgeschützt. Dies könnte bis zu einem gewissen Grad erklären, was Sie derzeit sehen. In den meisten Fällen sollten wir damit rechnen, dass die VM einfriert, da QEMU nicht in den Speicher schreiben kann. Ich benötige jedoch weitere Informationen dazu, daher werden hier Protokolldateien von den Hosts benötigt.
Lassen Sie uns zunächst dafür sorgen, dass der Status aus dem Speicher gelesen werden kann. Dies erreichen Sie, indem Sie von einem der Hosts aus Folgendes ausführen:
hosted-engine --vm-status
Vorausgesetzt, es funktioniert, versuchen Sie, den Host in die globale Wartung zu verschieben:
hosted-engine --set-maintenance --mode=global
Wenn dies nicht funktioniert, bedeutet dies, dass beim Zugriff auf die Metadatendatei im Speicher Probleme vorliegen und diese möglicherweise schreibgeschützt ist.
Wenn dies funktioniert, befindet sich die VM im Wartungsmodus. So können Sie den Status der Dateien innerhalb der VM prüfen und die VM bei Bedarf auf demselben Host neu starten.