VMware-Forum

Hallo liebe community,

da ich neu in der Windows Welt bin, was Virtualisierungen angeht,
kann ich mit der Fehlermeldung leider nichts anfangen.
Alle iSCSI LUNs sind online.
Laut log ist die E/A Latenz von 20 000 auf 800 000 Mikrosekunden gestiegen.

Verison 5.0.0. VMWare vCenter Server

Danke schonmal für eure Hilfe!

Vielleicht hilft ja bereits ein Blick in Failed write command to write-quiesced partition in VMware ESX 4.x and ESXi 4.x/5.0/5.1/5.5, und die Auswertung der dort erwaehnten Logdateien.

Oder ein Update/Upgrade, wenn's kein Storage-Problem sein sollte...

Muss ich bei einem Update alle VM's herunterfahren? (Denke schon ...)
Bzw. ist das Update von einer Lizenz abhängig?
Wie führe ich das Update aus?

Muss ich bei einem Update alle VM's herunterfahren?

Selbstverstaendlich. D.h., BEIM Update nicht unbedingt, aber auf jeden Fall um das Update zu "aktivieren".

Bzw. ist das Update von einer Lizenz abhängig?

Innerhalb der Major Version nicht (4.x, 5.x, 6.x, ...)

Wie führe ich das Update aus?

http://pubs.vmware.com/vsphere-50/topic ... 7B29F.html

Aber wie schon erwaehnt:
ZUERST moegliche Ursachen im Storage abklaeren. Wenn "auf einmal" diese Meldungen zu "latency deteriorated" erscheinen, hat das ganz selten was mit der ESXi-Version zu tun, die schon ueber Jahre unveraendert & problemlos im Einsatz ist.

Danke für die ausführliche Antwort.

Kann zu geringer Speicherplatz diese Meldung zu Folge haben?
Sonst hat sich auf dem Storage nichts geändert - LUNs sind weiterhin online.
Die Meldung taucht mittlerweile schon jede fünf bis zehn Minuten auf.

Auch hier:
Das haengt vom Storage ab.

Der ESXi an sich hat damit eher keine Probleme.

Was ist es denn ueberhaupt fuer Storage?
Auch wenn "nichts geaendert" wurde: Hat mal jemand die entsprechenden Logs vom Storage untersucht?

Handelt sich hier um ein NetApp Storage.
Ich finde hier im syslog, audit log und im health monitor keinerlei Fehler.
Der LUN check sagt auch: No problems found - Bei keinem einzigen LUN.

Wenn ich direkt im vCenter die Ereignisse der LUNs begutachte, steht sehr oft als Fehlerbeschreibung "Wegen Konnektivitätsprobleme kann nicht mehr auf das Volume ('NAME') zugegriffen werden. Es wird versucht, eine Wiederherstellung durchzuführen."
Heute von 04.00 Uhr in der Früh. Das war auch die Zeit wo ich die erste Meldung per Mail erhalten habe.

Dann muss man, denke ich, tiefer gehen in der Analyse.

Z.B. die Antwortzeiten aus Sicht des Storage untersuchen (Veraenderungen?), oder laufende Tasks, die unnatuerlicherweise noch aktiv sind, Snapshot-Operationen, usw.usf.

Ist die NetApp per FC angeschlossen -> Fabric (inkl. Switches) untersuchen/testen
Ist die NetApp per iSCSI/NFS angeschlossen -> Netzwerk-Switches untersuchen/testen

Edit:
Na, das ist doch schon ein Hinweis...

Ist per iSCSI angeschlossen.
Netzwerk Switches, etc. sind davon in keiner Weise betroffen - Habe ich schon überprüft, weil wir diese auch
in unserem monitoring haben.
Snapshot Operation -> Ja, mit Veeam, das ist aber schon Jahre im Einsatz, und hat noch keinen derartigen Fehler
verursacht.

Ja, ist schon ein Hinweis - Leider erklärt es die laufenden Meldungen nicht.

Tja, das kann man jetzt so und so sehen...

Haengen denn mehrere Hosts an der NetApp? Oder nur einer?
Nur ESXi? oder noch andere physische Systeme?

Hat nur einer der Hosts Probleme, oder alle/mehrere?

Sorry, aber viel mehr ist meiner Glaskugel nicht zu entnehmen.

Es hängen mehrere VMs an der NetApp, aber nur ESX physisch.

Naja. Probleme ist relativ - Es gibt meiner Meinung nach keine Probleme,
nur das diese komischen Fehler in den Ereignissen des HV stehen.

Dann ist ja eigentlich alles gut, und Du brauchst nur noch eine kleine Batch-Datei schreiben, die die Fehlermeldungen aus den Logs loescht...

Aber im Ernst:
Konnektivitaetsprobleme wuerde ich jetzt nicht unbedingt als "keine Probleme" ansehen. Und wenn die erste Begutachtung noch nix erbringt, "weil das Monitoring sich noch nicht gemeldet hat", dann muss eben gruendlicher geschaut werden.

Wenns nur so einfach wäre

Ja, leider gehen mir die Ideen aus, wo ich noch nachschauen könnte ...

'write-quiesced' läßt ja irgendwie Zusammenhang mit Snapshots vermuten. Kann es sein daß auf der Netapp vergessen wurde automatische Snapshots abzuschalten ?

Falls 7-mode (OUI 0a9800 riecht nach FAS20xx?):

snap list
snap sched

Und was mir gerade noch auffaellt (solange die Frage danach, ob, falls mehrere Hosts auf die Netapp zugreifen, alle Hosts dieselben Probleme zeigen, noch nicht beantwortet ist):

Es hängen mehrere VMs an der NetApp, aber nur ESX physisch.

Soll das heissen, dass neben den vmkernel-Verbindungen ueber die iSCSI-vSwitches (oder zumindest Portgroups) auch noch VM-Networks da drauf liegen?

mbreidenbach hat geschrieben:'write-quiesced' läßt ja irgendwie Zusammenhang mit Snapshots vermuten. Kann es sein daß auf der Netapp vergessen wurde automatische Snapshots abzuschalten ?

Falls 7-mode (OUI 0a9800 riecht nach FAS20xx?):

snap list
snap sched

Hi,
danke für deine Antwort. Ich poste hier die Ergebnisse der beiden Kommandos:

snap list:

Volume vol0
working...

%/used %/total date name
---------- ---------- ------------ --------
2% ( 2%) 0% ( 0%) Feb 14 08:00 hourly.0
5% ( 3%) 0% ( 0%) Feb 14 00:00 nightly.0
7% ( 3%) 1% ( 0%) Feb 13 20:00 hourly.1
10% ( 3%) 1% ( 0%) Feb 13 16:01 hourly.2
12% ( 3%) 1% ( 0%) Feb 13 12:01 hourly.3
14% ( 3%) 1% ( 0%) Feb 13 08:00 hourly.4
17% ( 3%) 1% ( 0%) Feb 13 00:00 nightly.1
18% ( 3%) 1% ( 0%) Feb 12 20:00 hourly.5

Volume vol_vmware
working...

No snapshots exist.

Volume vol_exchange_sql
working...

%/used %/total date name
---------- ---------- ------------ --------
28% (28%) 16% (16%) ZENSIERT 20 21:56 {1f0223ba-d775-XXXXX90d2-b97427efbe7a} (busy,LUNs)
30% ( 4%) 18% ( 2%) ZENSIERT 13 21:53 {6a0bdc84-0279-XXXX9e3-4e818e343988} (busy,LUNs)

Volume vol_ZENSIERTuser
working...

%/used %/total date name
---------- ---------- ------------ --------
0% ( 0%) 0% ( 0%) Feb 14 08:00 hourly.0
0% ( 0%) 0% ( 0%) Feb 14 00:00 nightly.0
0% ( 0%) 0% ( 0%) Feb 13 20:01 hourly.1
0% ( 0%) 0% ( 0%) Feb 13 16:01 hourly.2
0% ( 0%) 0% ( 0%) Feb 13 12:01 hourly.3
0% ( 0%) 0% ( 0%) Feb 13 08:00 hourly.4
0% ( 0%) 0% ( 0%) Feb 13 00:00 nightly.1
0% ( 0%) 0% ( 0%) Feb 12 20:01 hourly.5

Volume vol_VMFS_LUN04
working...

No snapshots exist.

Volume vol_vmfs_lun05
working...

No snapshots exist.

Volume vol_vmfs_lun06
working...

No snapshots exist.

-----------------------------------------------------------------------------------

snap sched:

Volume vol0: 0 2 6@8,12,16,20
Volume vol_vmware: 0 2 6@8,12,16,20
Volume vol_exchange_sql: 0 0 0
Volume vol_ZENSIERTuser: 0 2 6@8,12,16,20
Volume vol_VMFS_LUN04: 0 2 6@8,12,16,20
Volume vol_vmfs_lun05: 0 2 6@8,12,16,20
Volume vol_vmfs_lun06: 0 2 6@8,12,16,20


LG