ESXi Problem. Kein Upload einer Datei > 300GB

[RaumKraehe]

Moin Moin

Ich habe ein echt komisches Problem mit meinem ESXi 4.1 Server.

Vor 2 Tagen ist einer unserer VMware Server ausgefallen. An sich kein Problem, dachte ich. Die Backups sind alle vorhanden und ich habe noch weitere VMware Server auf die ich das Backup einfach schieben kann und gut ist.

Die VM hat eine größe von 344 GB.

Tja, leider ist nichts gut. Ich habe einen extrem komischen Fehler.

Immer wenn ich versuche das Backup zurückzuspielen bekomme ich am Ende der 344 GB großen Datei die Fehlermeldung:

Failed: Transfer Error (The upload failed (Unable to write data to the transport connection: An established connection was aborted by the software in your host machine.))

Das spuckt zumindest meine Backuplösung aus. (VMExplorer)

Kleinere VMs, ich konnte bis 128 GB testen klappen ohne Probleme. Nur diese eine will in keinem Fall.

Komisch ist auch das selbst wenn ich versuche die Daten über Vsphere direkt hochzuladen der ganze Vorgang am Ende auch abbricht, mit fast der gleichen Fehlermeldung.

Connection closed by Host. blabal

Als Workaround habe ich dann das ganze per SSH (SCP) probiert. Auch hier bin ich nicht in der Lage die 344 GB zu übertragen. Abbruch ganz am Ende.
Es ist echt dumm das man im Durchschnitt 3 Stunden warten muss bis man weiß das es wieder nicht geklappt hat.

Meine Vermutung war das der HDD Platz nicht reicht. Aber auf dem Server sind gute 850 GB frei. Das kann es eigentlich nicht sein.

Tja, nun bin ich extrem ratlos. Hat jemand eine Idee oder das Problem schon einmal gehabt? Gibt es eine Freeware die mir einen Zugriff auf das VMFS und die schreiben kann?

Danke schon mal.

[Sascha1971]

Arbeitest du mit Luns (San) oder nur mit lokalen Festplatten ?
Und wie hast du die Formatiert ?

Hast du evtl die Möglichkeit die Datei auf einer externe Platte (USB) zu speichern. Würde die dann auf der Platte einbinden und dann auf die lokale Platte verschieben. Wird zwar ewig dauern, aber das könnte evtl klappen.

[RaumKraehe]

Es sind lokale Festplatten die direkt durch ESXi mit VMFS formatiert wurden.

Meine Idee die ich nun habe sieht wie folgt aus:

Da die VM die ich zurückspielen muss zum Glück nicht in einem RAID Verbund war überlege ich gerade diese (HDD) einfach an einen anderen Server zu hängen und dann schlicht die VM in dem neuen Server zu registrieren.
Ich hab den Datastore auf dem bestehenden Server schon umbenannt und haffe das ESXi eine zusätzliches Festplatte einfach so erkennt oder das es zumindest nicht so ein Problem sein sollte diese einzubinden.

Leider habe ich sowas unter ESXi noch nie gemacht.

Aber eine Vermutung zu meinen eigentlichen Problem hast du nicht? :(

Ich habe nun zumindest ein paar Optimierungen durchgeführt und die Geschwindigkeit deutlich gesteigert. Also das Übertragen des Backups. Mal sehen ob es was bringt.

[Sascha1971]

Da ich das kostenlose Backup Recovery benutze, geht das bei mir was leichter.

Den anderen Server als Festplatte hinzu zu fügen ist leicht.
Oben auf den reiter Kofiguration gehen dann links auf Speicher.
Dann oben die blaue Schrift "Speicher hinzufügen".

Wenn der andere Rechner nur eine Netzwerkkarte besitzt und kein FC Adapte oder ähnliches musst du jetzt "Netzwerkdateisystem (NFS)" anklicken.

Dann will er von dir IP Adresse oder Macadresse haben + Welchen Ordner du frei gegeben hast.

Das sollte es danns chon gewesen sein.

Wenn das System läuft kannst du es ja dann per Migieren wieder auf die lokale Platte verschieben.

[RaumKraehe]

Der andere Server funktioniert ja nicht. Da haben wir uns wohl falsch verstanden.

Ich habe nun die komplette Platte an einen anderen Server hängen können und die VM läuft nun erstmal wieder. Das gibt mir zumindest Zeit zu analysieren warum sich das Backup nicht zurückspielen ließ.

Komischer Weise zeigen die Logs des Servers, auf dem das Zurückspielen nicht geklappt hat rein gar nichts an. :(

Alle anderen Backups die ich mit VMExplorer mache funktionieren super. Die eine VM ist allerdings die größte von allen und da konnte ich das, mangels Speicherplatz, nie mal just for fun testen.

[Hellspawn]

was ist den die blockgröße des vmfs? die beschränkt nämlich die max. größe von vmdks.

[RaumKraehe]

Oh, kein Plan. Wie bekomme ich das raus?

Also könnte es sein das die Blockgröße des defekten Servers nicht mit der des Servers, auf den ich versuche das Backup einzuspielen, übereinstimmt und deshalb das ganze bei knapp 300 GB abbricht?

[Hellspawn]

wenns die blocksize wäre, wäre die beschränkung auf 256gb... aber ich hab bei google das gefunden:
http://serverfault.com/questions/504775/trilead-vm-explorer-failed-transfer-error
das kannst du ja mal probieren.

[RaumKraehe]

Ich danke dir. Ja das habe ich auch gefunden. :)

Außer das es meinen Upload enorm beschleunigt hat, hat es keinen Effekt auf das Problem.

Ich kann leider nicht genau sagen wann er abbricht. Ich sitze ja nicht 3 Stunden davor und schaue wie die Bytes gezählt werden. ;) Auf jeden Fall im hinten drittel.

Aber das Blockgrößenproblem klingt für mich schon mal sehr interessant. Das werde ich in jedem Fall mal weiter verfolgen. Fakt ist die VM-Umgebung auf dem defekten Server wurde nicht von mir eingerichtet. Und ich hatte damals definiert das die max. Größe der VM 600 GB sein soll. Alle anderen Server sind aber von mir eingerichtet und ich musste learning by doing praktizieren. Also am Anfang ohne Plan. Auch spricht es dafür das eben alle anderen VMs keine Probleme machen, außer der einen die Größer als 256 GB ist.

Den letzten Wert den ich heute gesehen hatte war irgend was um die 280.000.000 kb die kopiert wurden. Das ergibt ca. 267 GB.

[Hellspawn]

ist es eine vmdk oder hast du sys und data getrennt?
btw, du kannst mit dem vcenter client ja auch direkt auf den esxi gehen und dort über die übersicht einfach mit rechtsclick auf den datastore-->durchsuchen(oder so :D) uploaden. ausserdem könntest du ssh aufmachen und den transfer über winscp probieren.(über konfigurieren->sicherheitsprofil) aso das hast du schon probiert.
morgen in der arbeit kann ich dir screenshots machen.
/edit: über rechtsclick->eigenschaften auf den datastore solltest du auch den blocksize des vmfs sehen)

[RaumKraehe]

Vielen Vielen Vielen Dank.

Storage des alten Servers = 2 MB Blockgröße
Storage des neuen Servers = 1 MB Blockgröße

Nun kann ich beruhigt in den Urlaub fahren.

Danke noch mal für die Anregungen.

[Hellspawn]

kewl freut mich, schönen urlaub noch :)

[Lokadamus]

Storage des alten Servers = 2 MB Blockgröße
Storage des neuen Servers = 1 MB Blockgröße:| Wie alt ist dein neuer Server?

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003565
The maximum virtual disk (VMDK) size is 2 TB minus 512 B for ESXi 5.0 and 5.1. In ESXi 5.5, the size is increased to 62TB.

Kann man auch einmal durchgucken:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012384

ESXi 4.1 ist schon ein bischen älter und solche Probs sollten mit der 5er Version weg sein.

[Hellspawn]

wennst schon obergscheit sein willst, dann klär ihn doch bitte auch über die nachteile der 5.5er auf... ich könnt jedes mal kotzen wenn ich in den webclient muss um die hardware der vm's zu ändern.
ausserdem hat 5.x die heartbleed sicherheitslücke(openssl 1.0.1) und 4.1 nicht(0.9.8). :D
lass ihn doch einfach, er wird seinen upgradecyclus haben, so wie wir. niemand in der it(erfahrene) updaten aus jux heraus. es muss schon was bringen, oder notwendig sein.

[RaumKraehe]

:| Wie alt ist dein neuer Server?

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003565
The maximum virtual disk (VMDK) size is 2 TB minus 512 B for ESXi 5.0 and 5.1. In ESXi 5.5, the size is increased to 62TB.

Kann man auch einmal durchgucken:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012384

ESXi 4.1 ist schon ein bischen älter und solche Probs sollten mit der 5er Version weg sein.

Wir fahren 4.1 und das eigentlich auch ohne weitere Probleme. Eine Umstellung auf 5.1 oder 5.5 ist irgend wann im laufe das Jahres geplant. Zumindest mal testweise. Aber dafür muss ich meinem GF erstmal einen Test-Server aus dem Kreuz leiern. Ziel ist es die gesammte Unternehmens IT als VMs abzubilden. Da kommen dann aber auch noch andere Probleme auf mich zu.

Aber das hat Zeit und muss nicht von heute auf morgen passieren.

Unsere IT ist nicht wirklich komplex von daher kann ich mit den Nachteilen von 4.1 sehr gut leben. Das Problem mit dem Upload der großen VM ist ja nicht die Version 4.1 an sich, sondern meine Unwissenheit gewesen. Ich habe mir das alles alleine reingezogen ohne am Anfang zu wissen was ich da eigentlich mache. ;)

[Lokadamus]

lass ihn doch einfach, er wird seinen upgradecyclus haben, so wie wir. niemand in der it(erfahrene) updaten aus jux heraus. es muss schon was bringen, oder notwendig sein.Wenn du dich mit Debian stable beschäftigen musst, dann ist jedes Update prima. ;)
Es ist immer ein sinnvolles Update.

Wenn eine andere Linux- Distri wichtig wird, wird es immer interessant. Aber da bin ich purer Egoist. Die Probs, die ich mit FreeBSD habe ... äää ... da läuft irgendwas unter Linux nicht. Achja, Paket Schießmichtot muss noch angepasst werden, wo war noch mal das Prob? ;)

Ja, ich kann ein Arschloch sein.