Failed to map guest I/O buffer

[mwiederkehr 373]

Hallo zusammen

 

Ein Hyper-V-Cluster mit vier Hosts (Windows Server 2019) gibt es immer wieder Probleme durch extrem hohe Storage-Latenzen. Diese gehen zeitweise auf mehrere Sekunden hoch, so dass sich die Benutzer über mangelnde Performance auf den Terminalserver beschweren.

 

Auf dem Host sind dann in kurzem Abstand mehrere dieser Meldungen zu finden:

Event-ID: 8

Source: Hyper-V-StorageVSP

Text: Failed to map guest I/O buffer for write access with status 0xC0000044. Device name = C:\ClusterStorage\VolumeX\VM\Disk.vhdx

 

In der VM sind zur gleichen Zeit Meldungen über wiederholte oder verzögerte Schreibzugriffe zu finden.

 

Ich habe einige Meldungen zu dem Problem gefunden, aber leider keine Lösung. Am nähesten kommt diese Beschreibung: https://forums.veeam.com/microsoft-hyper-v-f25/windows-server-2019-hyper-v-vm-i-o-performance-problem-t62112.html

 

Veeam ist im Einsatz, aber die Probleme treten nicht auf, wenn Backups laufen. Die VHDX liegen auf einem MSA2052 und einem OceanStor Dorado. Die machen fast nichts (unter 1000 IOPS), alles SSD. Die Probleme treten zufällig verteilt bei einzelnen VMs auf. Nicht bei mehreren gleichzeitig und auch nicht zu Zeiten hoher Last. Das Problem tritt täglich ein bis zwei Mal für wenige Minuten auf. Ansonsten ist die Performance super. Und auch wenn eine VM das Problem gerade hat, sind andere VMs auf der gleichen LUN nicht betroffen.

 

Die Hosts sind HPE ProLiant DL360 Gen10. Ich habe alle Windows Updates sowie das aktuelle ProLiant Support Pack installiert.

 

Der im Thread beschriebene Workaround (Verschieben der VMs alle paar Tage) scheint zu funktionieren. Es deutet alles auf einen Fehler in Windows hin. Die bisher verfügbaren (Private) Patches scheinen nicht zu helfen.

 

So weit, so klar. Was mich aber stutzig macht: wieso sehe ich das Problem nur auf einem Cluster? ProLiant, WS2019 und Veeam ist ja keine exotische Konfiguration...

 

Habt ihr das bei euren Clustern auch schon beobachtet?

[Nobbyaushb 1.471]

vor einer Stunde schrieb mwiederkehr:

 

Hallo zusammen

Habt ihr das bei euren Clustern auch schon beobachtet?

Ja, und nur bei denen, die unter Server 2019 laufen.

Welches Build fahrt ihr?

Auf den anderen beiden Hyper-V Clustern unter Server 2016 tritt das Problem bei nahezu identischer Hardware nicht auf.

Alle Cluster sind reine Intel Hardware (Wortmann) mit Intel 10G und/oder Mellanox X3 25G

[mwiederkehr 373]

Erstmal vielen Dank für Deine Antwort! Ich bin -so fies das tönt- sehr froh, dass ihr das Problem auch habt. So weiss ich zumindest, dass es wohl kein Konfigurationsfehler ist.

 

vor 12 Stunden schrieb Nobbyaushb:

Welches Build fahrt ihr?

Das "Normale", also 1809, Build 17763.

 

Habt ihr einen besseren Workaround als die VMs regelmässig zu verschieben? Habt ihr eine Case-Nr. bei Microsoft? Werde auch ein Ticket aufmachen, vielleicht hilft das den Entwicklern ja bei der Fehlersuche.

[testperson 1.677]

Hi,

 

falls noch nicht gemacht / vielleicht hilft es bei der Suche. Das Error Lockup Tool (The Microsoft Error Lookup Tool - Win32 apps | Microsoft Docs) meldet zu "0xC0000044":

 

Err_6.4.5.exe 0xC0000044
# for hex 0xc0000044 / decimal -1073741756
  ISCSI_ERR_FAILED_TO_RECOVER_SESSION_AFTER_ASYNCLOGOUT          iscsilog.h
# After receiving an async logout from the target, attempt to
# relogin the session failed.  Error status is given in the
# dump data.
  STATUS_QUOTA_EXCEEDED                                          ntstatus.h
# Insufficient quota exists to complete the operation
# as an HRESULT: Severity: FAILURE (1), FACILITY_NULL (0x0), Code 0x44
# for hex 0x44 / decimal 68
  ERROR_TOO_MANY_NAMES                                           winerror.h
# The name limit for the local computer network adapter card
# was exceeded.
# 3 matches found for "0xC0000044"

 

HTH

Jan

[mwiederkehr 373]

Nach langer Zeit kann ich hier eine Rückmeldung geben, dass das Problem wohl gelöst ist. Die Meldung (und die zugehörigen Suchresultate) haben mich auf eine falsche Fährte geführt. Als dann plötzlich bei einem Host das Clusternetzwerk auf rot war, kam ich dem tatsächlichen Problem auf die Spur. Das Problem ist, dass die NICs nach einem Reboot nach einigen Minuten Last Paketverlust zeigen. Und zwar nur die vom Clusternetzwerk, welche in einem vSwitch mit SET sind. Die nicht geteamten iSCSI-Ports laufen fehlerfrei.

 

Firmware und Treiber sind aktuell und das Problem ist auf mehreren Servern nachvollziehbar vorhanden. Leider wissen weder Microsoft von HPE aktuell weiter, deshalb haben wir jetzt andere Adapter eingebaut. Seither gab es keine Probleme mehr mit der Performance und auch der Fehler ist nicht mehr aufgetaucht im Event Log.

 

Die nicht funktionierenden Adapter waren "HPE Ethernet 10Gb 2-port 530FLR-SFP+". Funktionieren tun die "HPE Ethernet 10/25Gb 2-port 640FLR-SFP28".

 

Vielleicht hilft das ja mal jemanden. Vielen Dank euch für die Hilfe!