terra CLOUD EVault Backup CIFS mount Fehler 32: mount error (12): Cannot allocate memory

terra CLOUD EVault Backup CIFS mount Fehler 32: mount error (12): Cannot allocate Memory

 

Fehlerbild

Im Rahmen der Nutzung von einer in unseren Kundenumgebungen öfter zum Einsatz kommenden terra CLOUD EVault Backup Appliance, dem sogenannten vSphere Agent 7.x, für die VM basierende Datensicherung ganzer VMware vSphere Umgebungen mit nur einer Computer Lizenz des terra CLOUD Backup, standen wir vor der bisher noch nicht durchlebten Herausforderung der Einlieferung einer Initialsicherung in das terra CLOUD Rechenzentrum der Wortmann AG. Die terra EVault CLOUD Backup Appliance steuerte in unserem Fall ein VMware vSphere Essentials Bundle einer renommierten Rechtsanwaltskanzlei via dem auf dieser Umgebung vorhandenen VMware vCenter an. Die Installation der terra CLOUD EVault Backup Appliance war wie üblich schnell auf Basis des aktuellen Handbuchs erledigt, es gab jedoch die Hürde zu nehmen, dass die Einlieferung eines initialen Backups auf Datenträger zum terra CLOUD Rechenzentrum der Wortmann AG nur im Rahmen einer USB Festplatte möglich ist, die man durch den Mount einer CIFS-Freigabe in die terra CLOUD Backup Appliance einbinden muss.

Um die Initialdatensicherung auf die USB Festplatte zu bekommen, gibt es sicherlich mehrere Wege, die nach Rom führen, wir wollten die Sicherung jedoch nicht via eines weiteren Kopiervorgangs auf die USB Festplatte aufbringen, sondern direkt auf diese schreiben. Da die VMware Server der Kanzlei sich in einem separaten Netzwerk Segment befanden, entschieden wir uns eine simple aktuelle Workstation mit USB 3.0 Anschlüssen und einem bereits auf dieser befindlichen Windows 10 Prof. Lizenz direkt an den Server Switch anzuschließen, um die Datenpakete der Intialsicherung nicht durch die Netzwerksegmente und vor allem auch nicht durch die Firewall des Unternehmens zu schicken.

Die in diesem Fall 2 USB Festplatten wurden an den beiden USB 3.0 Schnittstellen der Workstation angeschlossen und als “hd1” und “hd2” für Jeder bzw. Everyone freigegeben. Folgend haben wir den nötigen Mount der CIFS-Freigabe auf der Konsole der terra CLOUD EVault Backup Appliance ausgeführt (direkt über den Konsolen Zugriff des VMware vSphere Client sowie auch via PuTTY) – leider ohne Erfolg.

Nötiger Befehl: mount add //Win10Workstation/hd1

gefolgt von Eingabe des Benutzernamens und Passworts (Gastzugang auf die Freigabe wurde nicht getestet).

Fehlermeldung: 32: mount error (12): Cannot allocate Memory

Unsere Recherche zu dem Fehler führte uns zu einigen verschiedenen Lösungsansätzen und Ursachen. Für unsere Umgebung ist fest zu machen, dass die Ursache im Zusammenspiel zwischen der terra CLOUD EVault Backup Appliance unter Linux und dem Windows 10 Prof. Betriebssystem auf der anderen Seite zu Suchen ist. Fakt ist, dass man den Mount einer CIFS-Freigabe auf der Appliance Seite ohne Änderungen erfolgreich ausführen konnte, wenn man eine Freigabe herangezogen hat, die sich auf einem Windows Server befand (getestet wurde der Mount von \\Servername\NETLOGON eines Windows Server 2008 R2 sowie eines Windows Server 2012 R2). Auf der anderen Seite konnte man die Freigabe auf der Windows 10 Prof. Workstation von einem beliebigen anderen Endpunkt mit Windows Betriebssystem erfolgreich ansprechen und mounten (getestet wurde von Windows 7 Prof. sowie von Windows Server 2012 aus).

Ergänzend sei aufgeführt, das man im Ereignis Protokoll der Windows 10 Prof. Workstation bei jeden Fehlversuch den Eintrag

Protokollname: System
Quelle:        srv
Ereignis-ID:   2011
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Beschreibung:
Der Konfigurationsparameter “irpstacksize” des Servers ist zu klein, um ein lokales Gerät zu verwenden. Vergrößern Sie den Wert dieses Parameters.

sowie in den meisten Fällen bis zu 3x hinter einander auch den Eintrag

Protokollname: System
Quelle:        Server
Ereignis-ID:   2504
Aufgabenkategorie:Keine
Ebene:         Warnung
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Beschreibung:
Der Server konnte zu der Transportschicht \Device\NetBT_Tcpip_{D8D7F2D3-D0AA-436B-BFC6-94FDA9D8A4E1} keine Verbindung herstellen.

finden konnte, der dann glücklicher Weise mehr oder minder Selbsterklärend ist.

 

Lösung

Wegbekommen tut man die Fehlermeldung über Anpassung der Eigenschaften des Server Dienst vom Windows 10 Prof. Betriebssystem.

Empfehlenswert – auch wenn nicht unbedingt nötig – ist aus unserer Sicht die Übernahme des REG_DWORD “Size” aus der Welt der Windows Server Betriebssysteme, das dort mit dem Wert 3 in der Registry zu finden ist. Unter Windows 10 Prof. kann man diesen Parameter am einfachsten hinzufügen, wenn man sich eine administrative Kommando Zeile öffnet und dort den Befehl

reg add HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v Size /t REG_DWORD /d 3 /f

ausführt.

Wirklich relevant ist hingegen die Erstellung und Erhöhung des Parameters IRPStackSize, wie man bereits aus der Meldung im Ereignisprotokoll schlussfolgern kann. Etwas unschön ist hierbei, dass sich die einschlägigen Microsoft Knowledgebase Artikel zu diesem Theme immer nur über bereits veraltete Betriebssysteme auslassen und somit keine schlagkräftigen Aussagen zu finde sind ohne selber zu testen. Microsoft empfiehlt in den Knowledgebase Artikeln die Erstellung des Parameters und diesen ausgehen von dem dezimal Wert 12 jeweils um 3 Zähler zu erhöhen, bis der Mount am Linux System erfolgreich ausgeführt werden kann. Wir haben diesen Vorgang bis zum Wert 21 ohne Erfolg getestet und uns dann entschlossen gleich auf den Dezimal Wert 50 zu springen, der der Standard bei einem ebenfalls veralteten Windows Server 2000 Betriebssystem wäre. Die Werte aktuellerer Serverbetriebssysteme empfinden wir als interessant, diese ließen sich aber ohne weiteren Aufwand nicht ermitteln.

Wie bereits den Size Parameter können Sie den IRPStackSize Parameter über folgenden Befehl aus der administrativen Kommandozeile heraus direkt erstellen

reg add HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v IRPStackSize /t REG_DWORD /d 50 /f

Folgend funktionierte bei uns der Mount beider CIFS-Freigaben fehlerfrei. Auch die folgende Initialsicherung der Umgebung via der terra CLOUD EVault Backup Appliance erzielte ähnliche Ergebnisse wie die, die wir sonst vom Vorreiter Veeam oder seinem Marktbegleiter Nakivo kennen. Es wurden 10 Windows Server VMs mit einem Gesamtvolumen von 2,56TB und einer Datenbelegung von 1,844TB in einem komprimierten und verschlüsselten Sicherungssatz mit einer Größe von insgesamt 1,05TB gesichert.

 

Posted in Allgemein, VMware vSphere, Wortmann Rechenzentrum - TERRA Cloud
Tags: , , , ,

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.