VMware Converter 4.3.0-292238 EXTREM(!) langsam

[sudo]

Moin!
Ich habe ein Problem mit dem VMware Converter 4.3.0.
Ein Kunde hat von uns übergangsweise einen freeESXi bekommen, da es drei Maschinen gibt die mittelfristig abgeschaltet werden sollen, aber im Moment in der Infrastruktur noch benötigt werden. Allerdings muss nun die P-Hardware an den alten Betreuer zurück gegeben werden.
Wieeee auch immer, ich wollte jedenfalls diese drei Maschinen auf einen freeESXi schieben.

Mit zwei von drei Maschinen hat das auch problemlos geklappt (trotz 64-bit Systemen). Aber bei der letzten Maschine scheint es zu scheitern.

Ich nutze den "local-Mode" mit HotClone.

Es geht um einen Server 2003 Standard x86 ohne Hyper-V. Viel ist dort nicht installiert.

Ich habe den Convert letzten Dienstag angestoßen. Als ich am Freitag in's WE gegangen bin, hat er verbleibende 12 Tage geschätzt (6% Fortschritt bis dato).
Heute morgen ist er immerhin schon bei 36%, aber schätzt immernoch 6 Tage.

Das ist doch nicht normal, oder?

Der Server hat im Moment zwei 200GB Partitionen, ich wollte nur die erste Übernehmen (10GB used) und sie auf 15GB verkleinern.

Ich habe nun schon viel gegoogled und herausbekommen, dass es möglicherweise an dem Resizing liegt. Ist dem so?

Ich finde, es kann nicht sein, dass er zwei Wochen für 10GB Daten braucht. Die anderen beiden Server hatten auch jeweils 10GB used und haben etwa 6 Stunden gebraucht. Und selbst das fand ich schon viel.

Bin über jeden Tipp dankbar. Im Moment bastel ich mir gerade die ColdClone-CD. Großes Lob schonmal dafür. Auch wenn ich sie bei diesem Kunden nicht nutzen kann, da der Server laufen muss.

Der ESXi hat komplett supportete Hardware von Intel. Bei Bedarf poste ich auch die Hardware-Bezeichnungen.

Viele Grüße aus Hamburg und schönen Dank schonmal

[continuum]

Hi

also das dauert viel zu lange und diesen Vorgang würde ich abbrechen.
Falls vorhanden versuch mal eine USB-platte als Ziel zu nehmen.

Dann defragmentier die Original Maschine vorher und lass mal sdelete durchlaufen.

Das klingt nach extrem langsamen Netzwerk.
Falls es dann imer noch nicht schneller geht lass das resizing mal - dass kann man dann immer noch in einem 2ten Schritt.

Basteln einer Coldclone CD ? - sprichst du von MOA ?
Falls ja und es dabei Probleme gibt - ruf an.
Dafür gibt es telefon-support

[sudo]

Hi

also das dauert viel zu lange und diesen Vorgang würde ich abbrechen.
Falls vorhanden versuch mal eine USB-platte als Ziel zu nehmen.

Dann defragmentier die Original Maschine vorher und lass mal sdelete durchlaufen.

Das klingt nach extrem langsamen Netzwerk.
Falls es dann imer noch nicht schneller geht lass das resizing mal - dass kann man dann immer noch in einem 2ten Schritt.

Basteln einer Coldclone CD ? - sprichst du von MOA ?
Falls ja und es dabei Probleme gibt - ruf an.
Dafür gibt es telefon-support

Moin Namensvetter!

Danke dir für die hilfreichen Tipps.
Defrag und sdelete starte ich gleich an (natürlich nicht beides gleichzeitig ).
Am "langsamen Netzwerk" wirds auf L1-Basis auf jeden Fall nicht liegen. Der ESXi und die zu konvertierende Maschine sind beide nebeneinander im Rack und jeweils mit 0,5m Patchkabel mit dem Cisco-Switch verbunden.

Danach mach ich einen Convert ohne resizing. Kann von mir aus auch so bleiben, das interne Raid im ESXi ist groß genug.

Gruß
Uli (mit einem "l")

PS: Ja - es geht um MOA. Klasse Sache! Werd' gleich mal testweise eine kleine Maschine hier in der Firma auf unseren ESX schieben.

[continuum]

Kann sein dass der pebuilder link im Moment nicht funktioniert ...
wenn der build nicht klappt musst du den zur Not von Hand runterladen und ins selbe Verzeichnis wie die setup.exe packen

[sudo]

Kann sein dass der pebuilder link im Moment nicht funktioniert ...
wenn der build nicht klappt musst du den zur Not von Hand runterladen und ins selbe Verzeichnis wie die setup.exe packen

Wenn ich fragen hab, meld' ich mich wieder. Im moment ist er fleißig am saugen.

[continuum]

wie gesagt - keine Scheu
ich bin bei dem Thema recht missionarisch veranlagt und plauder gerne aus dem Naehkaestchen

[sudo]

Moin nochmal!

Da ich es gestern nicht mehr geschafft habe, an dem langsamen Convert weiter zu arbeiten, habe ich mich gerade erst daran gemacht.

Der Server ist im Moment lebenswichtig (er "routet" interne telefongespräche zwischen zwei Gebäuden des Kunden, wo zu wenig Leitungen liegen) und darum möchte ich ihn so wenig wie möglich anfassen, weil ich kein Backup von der Installation habe (vorheriger EDV-Betreuer hielt Vollbackups für nicht so wichtig und wir haben die Betreuung erst neu übernommen).
Darum bin ich etwas vorsichtig, was Defrag und sdelete angeht.
Ein Kollege hat aber vorhin am Server eine USB Festplatte angeschlossen und ich werde jetzt erstmal darauf einen Convert anstarten (schauen, obs schneller geht).

Wenn das nichts helfen sollte, muss ich wohl in den sauren Apfel beißen und den Defrag ausführen (gerade weil ein SQL Server läuft, bin ich etwas vorsichtig mit Defrag).

Gibt es sonst noch Möglichkeiten, woran es liegen könnte?

Gruß!


EDIT: Es scheitert aber anscheinend schon daran, den alten Convert-Job abzubrechen. Das dauert schon eine halbe Stunde, aber es tut sich nichts. Einen neune anlegen, bringt auch nichts.

[echt_weg]

als alternative könntest du auch versuchen mit drivesnapshot (http://www.drivesnapshot.de) die partitionen online zu imagen und dann in eine vm restoren.

das klappt häufig recht gut

[sudo]

Moin!

[hier habe ich Murks erzählt]

Vielen Dank für Eure Hilfe. Ein klasse Forum!

[irix]

Einen DC konvertiert man nur mittels Coldclone oder garnicht. Aber nicht im lfd. Betrieb.

Gruss
Joerg

[continuum]

... und schon gar nicht wenn das Erstellen der vmdk 6 Tage gedauert hat

Da kann ja nichts consistentes bei raus kommen.

WEenn dann allenfalls mit Converter 5 - der sznchronisiert ganz am Ende noch einmal durch ...

Wie Irix schon sagt ...
am besten faehrst du den Server mal runter - steckst die USB-platte an - bootest die CD ...
dann bist du mit der Sache in 2 ,3 Stunden durch

[sudo]

Einen DC konvertiert man nur mittels Coldclone oder garnicht. Aber nicht im lfd. Betrieb.

Gruss
Joerg

Nene. Den DC convertier ich auch nicht, keine Angst. der bleibt physisch. Da wollte ich nur die USB-Platte mit den fertigen .vmdk's von dem ANDEREN convertierten Server anschließen.

Aber ich habe mich getäuscht. Der Upload von einer Datei (beliebige Datei, 10GB Exchange-Backup-File) vom DC aus ist genauso langsam.
Also liegt es wohl am ESXi. Wobei das eigentlich auch nicht sein kann, weil der Convert der anderen beiden Maschinen vorher einwandfrei geklappt hat.

Ich bin verwirrt :/

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

Ich poste hier nun mal meine Erkenntnisse für die Nachwelt und wen es interessiert:

--> Der ESXi war schuld. Ich hatte ihn vorher an einem NETGEAR FS105-Switch (5 Port Fast Ethernet) und habe die ersten beiden Maschinen convertiert.
Danach habe ich ihn im laufenden Betrieb an den Cisco-Gigabit-Switch im Rack gehängt. Die Netzwerkkarte hat sich allerdings nicht von 100Mbit Vollduplex auf Gigabit umgestellt.
IMHO sollte das zwar eigentlich kein Problem sein, außer dass es ggf. langsamer ist, aber das bewirkte, dass die Übertragungsrate auf ca. 15kbit/s(!) einbrach. Daraus resultierten die Veranschlagung von 14 Tagen des Converters, bzw. die 12 Tage Veranschlagung des Copy Vorgangs über das Netzwerk.
Ich habe die Netzwerkkarte über den vSphere Client wieder neu auf "Autom. aushandeln" gestellt und siehe da: Auf einmal läufts alles. Für die 50GB hat er jetzt etwa 2 Stunden gebraucht. Nicht schnell, aber immerhin besser als 12 Tage

Vielen Dank für Eure Hilfe