VMware-Forum

Guten Morgen zusammen,

wir haben nun unseren ersten VMware vSphere ESXi Host auf Dual SD Karten (Dell Server).
Aktuell bekomme ich im vCenter folgende Meldung: "Systemprotokolle auf dem Host werden in einem nicht beständigen Speicher gespeichert."

Ich habe aktuell folgenden Link gefunden: http://www.ugg.li/vmware-esx5-1-warnung ... speichert/

Nun meine Frage, ist dies in Ordnung, oder wie habt Ihr das gelöst?

Vielen Dank.

Viele Grüße

Rolf

In der Regel ein dedizierter Datastore für die Scratverzeichnisse, eines pro ESX Host.

Hallo bla!zilla,

das bedeutet, wenn ich es richtig verstanden habe, ein kleiner Storage pro ESXi Host?
Wir haben den Storage am FC, gibt es dann keine Probleme beim booten?

Vielen Dank.

Viele Grüße

Rolf

Nach Möglichkeit lege ich einen eigenen Datastore für alle ESX Hosts an. Die Hosts greifen dann gemeinsam darauf zu und jeder ESXi hat dort einen Ordner den ich dann in der Config angebe.

Alles klar verstehe, danke.
Wir hatten bisher immer lokale Platten für den ESXi Host und nun das erste mal SD Karten.

Gibt es Vor- bzw. Nachteile für so eine Konfiguration im Vergleich zu den lokalen Platten?

Viele Grüße

Rolf

1. Einfach Syslog konfigurieren
oder
2. Sobald die Datastores aus dem SAN gemountet sind Scratch konfiguieren

Gruss
Joerg

Syslog und Scratch geht beides. Ich würde auch beides konfigurieren, da im Scratchverzeichnis u.a. auch Updates vom VUM geparkt werden.

Hallo Ihr beiden,

naja bisher hatten wir das immer lokal. War ja, dank RAID1, auch nicht schlecht.
Jetzt im teuren SAN ein Volume zu definieren erfreut mich jetzt nicht ganz.

Welche Syslog Lösung nimmt Ihr für dies?

Viele Grüße

Rolf

Rolf-Walter.Wolff hat geschrieben:Hallo Ihr beiden,

naja bisher hatten wir das immer lokal. War ja, dank RAID1, auch nicht schlecht.
Jetzt im teuren SAN ein Volume zu definieren erfreut mich jetzt nicht ganz.

Aeh..... man kann davon ausgehen das euer SAN schon jede Menge Volumes definiert hat welche Richtung ESXi gehen.

Es hat keiner davon gesprochen das es DEDIZIERTE sein muessen. Nimm doch einfach eins was schon da ist.

Welche Syslog Lösung nimmt Ihr für dies?

Nen Linux Syslog mir Splunk oben drueber oder halt vCenter Log Insight wer die paar Euros ueber hat.

Fuer die welche nun wie du zum Syslog wie die Jungfrau zum Kinde kommeen hat VMware mitgedacht und liefert einen Syslogd mit dem vCenter fuer Windows aus. Ist im unteren Bereich des Installers weil ja optional und installiert sich in in 2min. Wer die VCSA hat nimmt deren Syslog. Nur hab ich da noch nicht gefunden wo er es ablegt.

Gruss
Joerg

Es geht noch einfacher, man muss nur irgendeinen Datastore definieren, was man früher oder später sowieso macht, und dann richtet ESXi beim nächsten Start die scratch-Partition (ist dann das Unterverzeichznis .locker in dem Volumen) automatisch ein.

leo hat geschrieben:Es geht noch einfacher, man muss nur irgendeinen Datastore definieren, was man früher oder später sowieso macht, und dann richtet ESXi beim nächsten Start die scratch-Partition (ist dann das Unterverzeichznis .locker in dem Volumen) automatisch ein.

Korrekt.
Manchmal ist er stoerisch wenn man dann diesen Datastore mal loeschen moechte.

Gruss
Joerg

Hi,
ich nehme hier dann meistens den Datastore auf dem der vCenter liegt und lege dort einen Ordner !Logs an. so habe ich den die beiden Managementteile zusammen.

Gruß Peter

Hallo zusammen,

vielen Dank für die Antworten und den Hinweis mit dem vCenter.

Hat der VMware Syslog Einschränkungen? hatte hier mal unter Cacti ein Syslog laufen und die FW hat dort innerhalb von Stunden den Plattenplatz beschlagnahmt.

Viele Grüße

Rolf

leo hat geschrieben:Es geht noch einfacher, man muss nur irgendeinen Datastore definieren, was man früher oder später sowieso macht, und dann richtet ESXi beim nächsten Start die scratch-Partition (ist dann das Unterverzeichznis .locker in dem Volumen) automatisch ein.

Nope, stimmt so nicht.

ESXi wählt einen potenziellen Ort in dieser Reihenfolge:

1. Ordner in /etc/vmware/locker.conf
2. FAT16 mit min. 4 GB auf einem lokalen Device (local Flag muss gesetzt sein)
3. Ein VMFS auf einem lokalen Device (local Flag muss gesetzt sein)
4. RAM-disk /tmp/scratch/

Bei Devices, die als remote erkannt werden (das können auch durchaus lokale Volumes an einem SAS Controller sein) werden NICHT automatisch für ein Scratchverzeichnis verwendet. Quelle ist ein KB von VMware mit Gültigkeit von ESXI 4.0 bis 5.5.

Es muss natürlich kein dedizierter Datastore sein. Wenn dein Storage Thin-Provisioning macht, dann kannst du den ruhig anlegen. Ob du die Daten darein legst, oder mit auf einen anderen DS, macht vom Gesamtvolumen keinen Unterschied. Eigener DS hat den Vorteil, dass der beim Zurückbauen von DS mit VMs nicht rumzickt (ein DS, der für Scratchdaten verwendet wird, kann nicht einfach abgehangen werden).

Danke Euch, hab nun einen vorhandenen DataStore genommen.
Die lokalen Platten wären uns nun fast lieber gewesen, aber nun ist es halt so.

Danke Euch allen, wieder was gelernt.

Viele Grüße

Rolf

Fuer die welche nun wie du zum Syslog wie die Jungfrau zum Kinde kommeen hat VMware mitgedacht und liefert einen Syslogd mit dem vCenter fuer Windows aus. Ist im unteren Bereich des Installers weil ja optional und installiert sich in in 2min. Wer die VCSA hat nimmt deren Syslog. Nur hab ich da noch nicht gefunden wo er es ablegt.

Gruss
Joerg

Hallo,

also Syslog haben und hatten wir schon ein paar, aber auch unterschiedliche Erfahrungen. Daher die Nachfrage.

Würde dann wohl mal den VMware Syslog testen. Wichtig ist eigentlich, dass es eine gute Oberfläche bietet und wenig Speicher verschwendet.

Viele Grüße

Rolf

Aeh... der Syslog welche mit dem vCenter kommt hat so gut wie keine GUI und das Plugin fuer den alten vSphere Client zeigt halt nur den Speicherort und Groesse der Files und sonst nix.

Anders ist Log Insight.

Wenn ihr einen zentralen Syslog Server habt dann verwende diese auch.

Gruss
Joerg

Hallo irix,

ok, dass ist dann nicht so berauschend.
Einen zentralen haben wir eigentlich keinen. Haben nur einen für die FW, und den auch nur in der "Free" Edition mit Einschränkungen.

Dann schiebe ich das Thema mal, und werde es intern antoßen.

Viele Grüße

Rolf

Rolf-Walter.Wolff hat geschrieben:Hallo irix,

ok, dass ist dann nicht so berauschend.
Einen zentralen haben wir eigentlich keinen. Haben nur einen für die FW, und den auch nur in der "Free" Edition mit Einschränkungen.

Mit Free meinst du die Splunk Community Edition? Falls ja must du deinen Hosts sagen das nicht "verbose" sondern "info" als Loglevel verwendet werden soll.

Gruss
Joerg

bla!zilla hat geschrieben:ESXi wählt einen potenziellen Ort in dieser Reihenfolge:

1. Ordner in /etc/vmware/locker.conf
2. FAT16 mit min. 4 GB auf einem lokalen Device (local Flag muss gesetzt sein)
3. Ein VMFS auf einem lokalen Device (local Flag muss gesetzt sein)
4. RAM-disk /tmp/scratch/

Es ging um den einfachen Weg, wenn man 1. und 2. nicht einrichtet, sondern direkt eine VMFS, ohne die ein ESXI keinen Sinn macht, dann hat man ein permanentes Scratch und vermeidet die Option 4 in Verbindung mit der Warnmeldung.

bla!zilla hat geschrieben:Bei Devices, die als remote erkannt werden (das können auch durchaus lokale Volumes an einem SAS Controller sein) werden NICHT automatisch für ein Scratchverzeichnis verwendet. Quelle ist ein KB von VMware mit Gültigkeit von ESXI 4.0 bis 5.5.

Bei ESXI 5.0 und 5.1 geht es mit lokalen Laufwerken, trotz widersprüchlichen Informationen in der KB.

leo hat geschrieben:Bei ESXI 5.0 und 5.1 geht es mit lokalen Laufwerken, trotz widersprüchlichen Informationen in der KB.

Da gibt es nichts widersprüchlichen. Lokales VMFS, was auch als lokal erkannt wird, funktioniert problemlos. Das wird dann auch automatisch konfiguriert.

bla!zilla hat geschrieben:

leo hat geschrieben:Bei ESXI 5.0 und 5.1 geht es mit lokalen Laufwerken, trotz widersprüchlichen Informationen in der KB.

Da gibt es nichts widersprüchlichen. Lokales VMFS, was auch als lokal erkannt wird, funktioniert problemlos. Das wird dann auch automatisch konfiguriert.

Ja, so hatten wir es bisher immer. Nun haben wir aber keine lokalen Disks mehr .

Viele Grüße

Rolf

Hi,
Wir setzen bei Kunden oft Kiwi Syslog ein, der kostet nur ein paar Euros und hat eigentlich alles was man braucht

- Web Interface
- Filter vor und hinter der DB
- läuft unter Win (was für viele Kunden wichtig ist, #schulter zucken#

Das VMware Syslog Tool ist für mich ein NoGo, da jedes Device einen eigenen Logfile anlegt. Das ist total blöd wenn man troubelshooting macht. X-File checken und immer die Uhrzeit vergleichen super nervig.

Gruß Peter

Rolf-Walter.Wolff hat geschrieben:Ja, so hatten wir es bisher immer. Nun haben wir aber keine lokalen Disks mehr .

Rolf

Die Begriffe lokal und remote sind bei VMware etwas widersprüchlich, lokale Laufwerke können remote sein (habe ich persönlich noch nicht gesehen, soll es aber laut Dokumentation geben) und über das Netzwerk eingebundenen Laufwerke können lokal sein. Also einfach mal irgendeine VMFS konfigurieren, die Wahrscheinlichkeit, dass er diese als Scratch-Partition nimmt, liegen sehr hoch.

PeterDA hat geschrieben:Hi,
Wir setzen bei Kunden oft Kiwi Syslog ein, der kostet nur ein paar Euros und hat eigentlich alles was man braucht

- Web Interface
- Filter vor und hinter der DB
- läuft unter Win (was für viele Kunden wichtig ist, #schulter zucken#

Das VMware Syslog Tool ist für mich ein NoGo, da jedes Device einen eigenen Logfile anlegt. Das ist total blöd wenn man troubelshooting macht. X-File checken und immer die Uhrzeit vergleichen super nervig.

Gruß Peter

Hallo Peter,

Kiwi nutzen wir für die Firewall Logs, allerdings im "Free" Modus.
Mal sehen, ob wir Geld dafür bekommen würden...

@leo
hat mit einem VMFS das im SAN hängt super funktioniert. Danke.

Viele Grüße

Rolf