ESX / ESXi - Hilfethread

[fdsonne]

ich würde wenn dann die Pros nehmen... Die non Pros haben laut diversen Berichten schlechtere Speicherchips verbaut...

Ein Problem bei SSDs im ESXi Umfeld ist schlicht, das der massiv höhere Zugriff eben auch die Laufzeit stark verkürzen kann. Je nachdem was du mit den Teilen vorhast.
Denn der Knackpunkt der SSDs ist ja nach wie vor die Anzahl der maximal zugesicherten Schreibzugriffe pro Speicherzelle. Auch wenn die SSDs heute standardmäßig die Schreibzugriffe intelligent auf alle Zellen verteilen macht es das nur ein Stück weit besser.
Zwar haben HDDs ebenso ähnliche Betriebszeiten, die "zugesichert" werden, nur kann man dort im Grunde nicht von einer Abnutzung der Speicherzellen sprechen, wie es bei einer SSD definitiv der Fall ist.
Dazu kommen leider immernoch sehr häufig irgendwelche Firmwaremacken -> die meist bis zum Totalausfall führen können.


Je nach Belastung kommt also eine SSD deutlich schneller an ihre potentielle maximale Betreibszeit, als eine HDD. Und nach allem was man so hört im INet sind (Desktop) SSDs auch mit Nichten aktuell schon soweit, das man diese uneingeschränkt für permantente Dauerlast über Monate/Jahre hinweg einsetzen kann.

Mal ne ganz simple Rechnung dazu. Man muss mal grob über den Daumen schätzen, was an reiner Schreibarbeit pro Tag bzw. Jahr auf die SSD geschrieben wird.
Durch den Effekt der Verteilung jeglicher Schreibarbeiten gleichmäßig über alle Zellen steigt bei gleichbleibender Schreibarbeit auf die SSD bei der Verdopplung der Größe die Lebenszeit um das Doppelte.
20GB pro Tag = 7300GB pro Jahr / 500GB Platz = 14,6x mal jede Zelle beschrieben = ca. 68,5 Jahre in der Theorie bei 1000 Schreibzyklem pro Zelle (TLC Zellen der non Pro Samsung)

Messen könnte man beispielsweise mal, wie groß ein Snapshot nach exakt 24h wird, der pro VM angelegt wird. -> das ganze beispielsweise stichprobenartig über eine bestimmte Zeitspanne durchgeführt und man kann den Schreibbedarf pro Jahr rellativ genau hochrechnen.

Die Frage ist halt, ob das langt. Im ESXi Betrieb wird ja tendenziell deutlich mehr geschrieben als im simplen Desktopbetrieb. Dazu kommt der womöglich nicht zu verhindernde Effekt, das auf dem Storage selbst "geswapt" wird. Sowohl vom ESX als auch dem Gast OS.
Demgegenüber steht natürlich der höhere Speed, keine Frage. Und das du mit nem Raid 1 potentiell gegen nen SSD Ausfall selbst erstmal gewappnet bist. Zumindest wenn der Kontroller mitbekommt, das etwas mit der SSD nicht stimmt. Teilweise kommt es vor, das die Zellen zwar geschrieben werden, dort aber nur Murks drin steht -> ohne Kontrollerfehler usw. ergo Datenverlust.

 

[H_M_Murdock]

Dummerweise hast du mit allem was du schreibst Recht

In der Samsung SSD 840 Basic wird tatsächlich grundsätzlich ein weniger haltbarer Flashspeicher eingesetzt als in der Pro und natürlich hat ein ESXi mit in meinem Fall ~ 8 VMs erheblich mehr Schreiblast zu bewältigen als ein Desktopsystem.
Ich setze ja selbst seit Jahren in meinen Desktops auf SSDs (bisher 3 gehabt, davon 3 in Betrieb und eine mal wegen einem Firmware-Bug ausgefallen), meine Angst vor dem Tod selbiger ist auch mehr die vor einem Firmware-Bug als vor totgeschriebenen Flashzellen was ich natürlich nicht für unbegründet halte, aber der Betrieb als Massenspeicher für Hypervisor ist da auf jeden Fall ein Sonderfall.
Soweit ich sehen konnte kann der ESXi vor allem noch kein TRIM und ich kann mir vorstellen dass bei den vermutlich doch recht durchgehenden Zugriffen bei 8 VMs die Garbage Collection kaum vernünftig zum arbeiten kommt - je nachdem wie selbige umgesetzt ist versteht sich.

Lange Rede kurzer Sinn, ich denke bei meinen Budgetvorstellungen hol ich mir lieber Velocis, evtl. auch "nur "die 600 GB Variante.
Die Anzahl der VMs pro Platte wird da IMHO auch eher durch die Performance als die Kapazität begrenzt.

EDIT:
Ich hab mir jetzt mal 2 Stück WD6000HLHX bestellt, die hat soweit ich auf die Schnelle herausfinden konnte im Gegensatz zu den neueren Velocis keine 4k Sektoren, da ich leider nicht herausfinden konnte ob der RAID Controller in meinem Primergy TX150 S7 damit klar kommt ist mir das ganz recht.
Außerdem kann man die ganz normal in die 3,5 Zoll Wechselrahmen bauen da die Anschlüsse am IcePak an die übliche Position bei 3,5" Platten verlegt sind.
Ich bin gespannt wie sie sich performancemäßig im ESXi macht, ich erwarte mir schon wesentlich mehr davon als mit den 500 GB RE2 die ich aktuell in Betrieb hab.

 

[LaMagra-X]

Das ist ja auch richtig so... Denn der Rechner muss ja die Zeit irgendwo speichern, die du ihm sagst.
Dennoch agiert der Host in UTC. Exakt! 2h Versatz klingt für mich arg nach einem simplen Zeitzonenproblem...
Würde da ein Windows/Linux OS native auf dem Host laufen, ist das auch alles kein Problem, denn dort stellst du die Zeitzonen im OS ein und der Host agiert nur mit dem Offset.
Der ESXi kann aber so keine Zeitzonen händeln, sondern er zeigt die Zeit der Zeitzone an, in welcher sich der vSphere Client befindet -> mit dem man verbunden ist.
Das ist alles etwas schwerer zu verstehen, wenn man es nicht selbst nachstellen kann. Steht beispielsweise der Host in Amerika, du verbindest dich aber mit nem deutschen PC (und UTC + 2 Zeitzone) auf diesen, so zeigt der Host dir im ESXi Umfeld die deutsche Zeit an! -> wärend die VMs dennoch mit der korrekten USA Zeitzone laufen. Verbindet man sich nun gleichzeitig mit nem Amerikanischen Client auf den Host, zeigt dieser zur selben Zeit die amerikanische Zeit an. -> denn die Anzeige agiert pro Session. Was Minuten/Sekunden angeht, laufen alle gleich -> der Offset vorn hängt aber von der Zeitzone ab, in welcher der Client läuft.


Sauber wäre den ESXi via NTP irgendwo von beispielsweise pool.ntp.org die korrekte Zeit holen zu lassen. Und dazu zusätzlich den VMs noch die Zeiten via NTP beziehen zu lassen... Wobei man bei den VMs dann zweistufig arbeiten könnte. Sprich global einen NTP Dienst aufsetzen und diesen zentral anfragen. Dieser NTP holt die Zeit von public oder wo auch immer her (Funk, Atomuhr, whatever). Und alle VMs fragen nur diesen an.

Denn unterm Strich ist nämlich nicht das Problem die absolut korrekte Zeit auf die ms genau zu haben, sondern es ist viel wichtiger, das alle Systeme, die miteinander agieren gleich ticken... Laufen die Systeme untereinander unterschiedlich, läuft du nämlich in Probleme die teils bestenfalls unschön sind, manchmal aber auch ziemlich fatal für den Betrieb sein können.
Unschön wäre beispielsweise, wenn der Outlook Client meint, eine Mail empfangen zu haben (laut Zeitstempel), die noch gar nicht sein kann, da die Absendezeit später ist...
Fatal wäre beispielsweise durch zu hohen Versatz eine fehlschlagende Anmeldung an einem OS mit einem Domänen User. Oder irgendwelche Reportinggeschichten im DB Umfeld usw. usf.

Danke für die Infos.
Die VMs laufen ja allesamt in einer Domäne und bekommen die Zeit vom DC. Wichtig ist halt, dass der ESXi die Zeit nicht durchschleift bzw. in den VM verstellt, denn genau das ist mir nun passiert. Die BIOS-Batterie war wohl leer. Habe sie jetzt gewechselt und installiere grad ESXi 5 Update 1 neu.

VG

 

[LichtiF]

Bei uns holt sich der DC sowie die ESXi Server die Zeit von einem NTP Server aus dem Internet.

@SSD unter ESXi

Es gibt auch etliche SSD die inzwischen wohl sehr gut unter ESXi laufen sind halt nicht gerade günstig
Ich glaube gea zb hat seinen ZFS Storage unter ESXi inzwischen komplett auf SSD laufen.

 

[Steggi]

Lange Rede kurzer Sinn, ich denke bei meinen Budgetvorstellungen hol ich mir lieber Velocis, evtl. auch "nur "die 600 GB Variante.
Die Anzahl der VMs pro Platte wird da IMHO auch eher durch die Performance als die Kapazität begrenzt.

Joa, wobei das auch ein wenig von den VMs abhängt, die da drauf laufen. Aber Preismäßig fährst du damit alle Male günstiger.

Ich hab mir jetzt mal 2 Stück WD6000HLHX bestellt, die hat soweit ich auf die Schnelle herausfinden konnte im Gegensatz zu den neueren Velocis keine 4k Sektoren, da ich leider nicht herausfinden konnte ob der RAID Controller in meinem Primergy TX150 S7 damit klar kommt ist mir das ganz recht.

Welchen Controller haste denn davon?

RAID-Controller Integriertes RAID 5/6 Ctrl, SAS 6 Gb, Fujitsu , 8 ports int.
RAID-Level: 0, 1, 10, 5, 50, 6, 60, 512 MB Cache, optionale BBU (based on LSI SAS2108)
Integriertes RAID 0/1 Ctrl, SAS/SATA 6 Gb, Fujitsu , 8 ports int.
RAID-Level: 0, 1, 10, keine BBU-Unterstützung (based on LSI SAS2008)
Integriertes RAID 0/1 Ctrl, SAS/SATA 3 Gb, 8 ports int.
RAID-Level: 0, 1, 1E, keine BBU-Unterstützung (based on LSI 1068e)
Integriertes RAID 0/1 Ctrl, SAS/SATA 3 Gb, 4 ports int.
RAID-Level: 0, 1, 1E, keine BBU-Unterstützung , for internal SAS tapes (based on LSI 1064e)

Der 2008er und der 1068e unterstützen auf jeden Fall 4K, bei den anderen weiß ichs nicht

Außerdem kann man die ganz normal in die 3,5 Zoll Wechselrahmen bauen da die Anschlüsse am IcePak an die übliche Position bei 3,5" Platten verlegt sind.
Ich bin gespannt wie sie sich performancemäßig im ESXi macht, ich erwarte mir schon wesentlich mehr davon als mit den 500 GB RE2 die ich aktuell in Betrieb hab.

Joa, nen Performanceschub wirste schon merken, da die Velos um einiges mehr I/O Leistung mitbringen. Zumindest ich hab ihn deutlich gemerkt, als ich meine Toshiba Allegros in Betrieb genommen hab und einige VMs mehr von den WD RE4 rüber gewandert sind.

 

[H_M_Murdock]

Ist der RAID Ctrl SAS 6G 0/1 (D2607) SAS/SATA RAID Controller based on LSI MegaRAID SAS2008, PCIe 2.0 x8, 8 internal ports.
Dann sollte ich also auch mit 4k Platten leben können? Gut zu wissen.

Gut, kapazitätsmäßig werden die 600er erstmal reichen, zumal ich die 500er RE2 ja drin lass, die klatsch ich dann mit ISOs und ggf. 1-2 weniger performancekritischen VMs voll dann sind die auch genutzt. Die beiden kleinen 7.2k Seagate Platten (80er oder 160er - weiß ich grad gar nicht genau auf jeden Fall sacklahm und im ESXi absolut unbrauchbar) fliegen dafür raus.

Sicher gibt's SSDs die das abkönnen, da hab ich gar keine Zweifel. Aber nicht für das wenige Geld das ich im Moment für so eine Nebensächlichkeit auszugeben bereit bin.

 

[fdsonne]

Das Geld ist halt der Problempunkt
Bei Enterprise SSDs hätte ich dann auch weniger "Schmerzen" diese im ESXi Umfeld einzusetzen

 

[H_M_Murdock]

Seh ich ähnlich, wobei ich mir ne bessere Desktop SSD im Home-ESXi grundsätzlich schon vorstellen könnte. Dann reden wir aber von was teurerem als der Samsung 840 Basic und das will ich ATM nicht auf den Tisch legen.
Und rausfinden wie gut oder schlecht man dann mit ner günstigen fährt möchte ich ebenfalls nicht, bin froh dass mein ESXi im Prinzip kaum Arbeit macht da das Hobby "Serveradministration" bei mir in letzter Zeit ein wenig geruht hat und ich froh bin dass der ganze Kram trotzdem noch super läuft.
Irgendwie ist für alles auf 100% halt doch manchmal zu wenig Zeit.

 

[Steggi]

Dann sollte ich also auch mit 4k Platten leben können? Gut zu wissen.

Zumindest hat mein PERC H310, der ebenfalls nen SAS2008er Chip hat mit 4K Platten keine Probleme und der IBM M1015 der für ZFS Spielereinen gerne genutzt wird, scheint wohl auch noch keine Probleme gemacht zu haben.

Gut, kapazitätsmäßig werden die 600er erstmal reichen, zumal ich die 500er RE2 ja drin lass, die klatsch ich dann mit ISOs und ggf. 1-2 weniger performancekritischen VMs voll dann sind die auch genutzt. Die beiden kleinen 7.2k Seagate Platten (80er oder 160er - weiß ich grad gar nicht genau auf jeden Fall sacklahm und im ESXi absolut unbrauchbar) fliegen dafür raus.

Ich merks bei mir schon recht deutlich, dass mir 600 GB im RAID 10 im Moment zwar ausreichen, aber bei mindestens 20GB pro Windows Server VM (ihne irgendwelche Software) ist der Platz doch schneller weg, als man glaubt (zumindest bei mir)
Ich hab ja auch alle unkritische oder große VMDKs wie die 120GB Update Partition vom WSUS und der Gleichen auf nem 7,2K Array, denn so billig sind große SAS Platten nun doch noch nicht

Sicher gibt's SSDs die das abkönnen, da hab ich gar keine Zweifel. Aber nicht für das wenige Geld das ich im Moment für so eine Nebensächlichkeit auszugeben bereit bin.

Seh ich auch so. Im Firmenumfeld mag das vom Geld her noch durchaus ok sein auf Enterprise SSDs zu setzen (wobei zumindest bei uns noch keine SSDs in den Hosts stecken), aber im Privatumfeld ist ne große SSD im ESXi in der Regel eh etwas overkill und zu teuer im Vergleich zu normalen oder auch etwas schnelleren Platten wie den Velos.

Und rausfinden wie gut oder schlecht man dann mit ner günstigen fährt möchte ich ebenfalls nicht, bin froh dass mein ESXi im Prinzip kaum Arbeit macht da das Hobby "Serveradministration" bei mir in letzter Zeit ein wenig geruht hat und ich froh bin dass der ganze Kram trotzdem noch super läuft.
Irgendwie ist für alles auf 100% halt doch manchmal zu wenig Zeit.

Muss ich ehrlich gesagt im Moment auch nicht und seitdem der ganze NFS Spaß bei mir wieder ordentlich rennt, reicht mir auch die Performance aus SAS und SATA Arrays vollkommen aus Und wer die Platten nicht grade mit zu vielen VMs überläd, sollte auch mit normalen Platten noch recht performant fahren.

 

[LaMagra-X]

Sauber wäre den ESXi via NTP irgendwo von beispielsweise pool.ntp.org die korrekte Zeit holen zu lassen. Und dazu zusätzlich den VMs noch die Zeiten via NTP beziehen zu lassen... Wobei man bei den VMs dann zweistufig arbeiten könnte. Sprich global einen NTP Dienst aufsetzen und diesen zentral anfragen. Dieser NTP holt die Zeit von public oder wo auch immer her (Funk, Atomuhr, whatever). Und alle VMs fragen nur diesen an.

Also ich bekomm das Problem irgendwie nicht in den Griff.

Ich habe nun 3 ESXi 5.1.0 Build 1065491 am Laufen.

Zwei haben die korrekte Zeit, der dritte nicht. Ich greife ja mit demselben vSphere auf beide Hosts zu.

Warum ist beim einen (mit der falschen Zeit) die Zeit rot?

Im BIOS hat der Host auf jeden Fall nun die korrekte Zeit.


VG

 

[LichtiF]

Tja das hat nichts mit dem Client zutun die Infos kommen ja vom Host.

Mach es dir einfach und richte das Ordentlich über einen NTP Server ein.

zb. bei uns holt sich der W2k8 DC (die Win Clients bekommen ja die Uhrzeit über den DC) über einen NTP Server aus dem Internet die korrekte Uhrzeit und bei den ESXi ist dann der DC als NTP Server eingerichtet.

Somit haben alle bei uns die gleiche Uhrzeit.

 

[LaMagra-X]

Das macht Sinn.
Werde ich denke ich auch so umsetzen.

Besten Dank.

 

[fdsonne]

@LaMagra-X
eine Sache noch, der ESXi Host hat sich unter Umständen zickig, wenn er zu große Zeitsprünge via NTP angleichen muss!
Das heist, erst händisch die Werte halbwegs korrekt (maximal 5min Versatz) einstellen -> dann NTP konfigurieren und warten.

PS: auf deinen Bildern ist der NTP Client übrigens aus!

 

[LaMagra-X]

Ja, ich habe es jetzt vorerst wie folgt gelöst:

Mittels vSphere Client habe ich auf dem Server manuell die richtige Zeit (-2 Stunden) gesetzt. Im BIOS des Server ist die Zeit nun -2 Stunde, im ESX (und deswegen auch in den VMs) korrekt.

Nun installiere ich auf dem DC einen NTP Server und gebe dem ESX die IP des DCs an.

VG

 

[TCM]

Als NTP sollte man im Idealfall einen physischen Host im Netz haben. Referenz-NTP in einer VM und dann wieder an den ESXi "exportieren" ist unabhängig davon, dass man dann natürlich kein time sync für die VM anschalten sollte, eine eher schlechte Idee.

 

[koaschten]

Yup lieber dann direkt über internet auf de.pool.ntp.org synchen

 

[millenniumpilot]

Hallo Ihr,

bisher habe ich für meine beiden ESXi den Datastore jeweils lokal, auf Grund dessen, das die Platten/SSDs am ICH-Onboardkontroller hängen, sogar ohne RAID-Absicherung. Hier behelfe ich mir aber mit einem regelmäßigen Backup und zusätzlich spiegeln sich die wichtigsten VMs ihre vdmks, welche auf unterschiedlichen Platten liegen.
Jetzt habe ich die Idee, mir einen MicroServer N54L zuzulegen, um dort NappitToGo zu installieren und die lokalen Datastoreplatten und SSDs dort per iSCSI oder NFS freizugeben. Mit dem zusätzlichen Vorteil, das ich jetzt auch mal unkompliziert die VMs zw. den Hosts verschieben kann. Ich habe leider was die Performance anbetrifft, keine Erfahrung mit solch einer "SAN"-Anbindung im Vergleich zur lokalen Anbindung des Datastore.
Jetzt die Frage: wie performt soewtas und wäre der N54L in der Lage, hier zwei 1GB-NICs voll auszulasten (beim SSD-Pool)? Ich gehe im AUgenblick davon aus, das jeder ESX seine eigene dedizierte NIC im Microserver bekommt. Wenn er die aber eh nicht auslassten kann, dann ggf. halt nur eine für beide Server.

 

[H_M_Murdock]

Ich würde solche unnötigen Verschachtelungen bleiben lassen und einen unterstützten RAID Controller einsetzen.
Davon abgesehen dass ich den N54L für den ESXi für etwas zu schwachbrüstig halte.

 

[pumuckel]

ich hab nun ESXi aufgegeben .... ich nutze nun proxmox (da ich das auf den Online-Servern auch nutze)

kanns nur empfehlen

 

[Zgurgar]

Davon abgesehen dass ich den N54L für den ESXi für etwas zu schwachbrüstig halte.

Ich verstehe es so das es darum geht den N54L tatsächlich als reines NAS für einen Datastore zu benutzen.

Die Sache mit dem "verschieben" der VMs ist aber das du ein vCenter und mindestens die ESX Standard Lizenz brauchst für vMotion.

 

[LichtiF]

*hust* So wie er es installieren will ist der N54L dann reiner shared Storage wie zb eine Synology und sicher schneller als die std. NAS Kisten

Gibt genug vExperts die sowas zuhause laufen haben sobald man mehr als einen ESXi hat finde ich das auch sehr sinnvoll

---------- Post added at 11:37 ---------- Previous post was at 11:33 ----------

Ich verstehe es so das es darum geht den N54L tatsächlich als reines NAS für einen Datastore zu benutzen.

Die Sache mit dem "verschieben" der VMs ist aber das du ein vCenter und mindestens die ESX Standard Lizenz brauchst für vMotion.

Da er einen ESXi mit 64GB laufen hat wird er wohl Lizenzen haben

 

[millenniumpilot]

Hallo Ihr,

ja, es geht alleine um die Anbindung des Datastores per iSCSI oder NFS. Es soll kein ESX auf dem Microserver laufen.
Also Datastore-Platten raus aus den Host und rein in den Microserver. Durch den Einsatz von ZFS mit den bekannten zusätzlichen Vorteilen gegenüber einer Lösung eines lokalen RAID-Controllers.
Von der von Gea publizierten Lösung des Anbindens des Datastores per NFS von einer virtuellen Maschine auf dem Host bin ich wieder weg. War immer blöd das alle VMs betroffen waren, wenn ich was am OI machen bzw. basteln wollte.

 

[H_M_Murdock]

Sorry ich hab's nicht richtig gelesen, du willst den HP Server als reinen Storageserver betreiben.
Da kommt's halt stark auf das RAID Level an das du fahren willst, solang nichts mit Parität am Start ist was man sich bei Virtualisierung idr. sowieso eher verkneifen oder zumindest sehr gut überlegen sollte haut das denk ich schon hin.
Du solltest halt schnelle Platten verwenden, unter 10k RPM würd ich da nicht anfangen.

 

[TCM]

War immer blöd das alle VMs betroffen waren, wenn ich was am OI machen bzw. basteln wollte.

Und das ist anders, wenn die VMs auf externem storage liegen? Dann kannste doch auch nicht basteln, ohne dass die VMs betroffen sind.

 

[millenniumpilot]

Hallo,

das separate Storage wird dann nicht angefasst, da gibts auch nichts zu basteln. Mit "Basteln am OI" ist dann alleine die VM für die Windows-Fileshares gemeint. Ab und an musste ich z.B. die gesamte VM runterfahren, da ein Wechseln von Platten nicht erkannt wurde... und in diesem Fall waren dann auch immer die NFS-Shares für die VMs betroffen.
Denn laut Originalkonzept vom "AllInOne" liegen hier in dieser VM auch zusätzlich die Dateisysteme für den Datastore.

Edit:
in den Microserver sollen 2 Mirrorpools, einmal aus 2 SSDs und einmal für perfomancetechnisch unkritische Sachen auf 2 HDs.
Wichtig ist mir zu wissen, ob der Microserver ausreichend ist um zwei ESXi zu bedienen und ob der Umstieg von lokalen Datastore zur Anbindung über 1GB-NIC siginifikant schlechter ist.

 

[LichtiF]

Also ich werde das so auch machen mit meinem N40L sobald ich mich endlich entschieden habe (Frau überredet) mir einen neuen Server zu kaufen.

Bin nur noch am überlegen ob ich ESXi oder doch lieber Hyper-V machen werde da wir vermutlich eh alles auf Hyper-V umstellen im nächsten Jahr und ich mir das eh mal anschauen muss.

Wenn ich Hyper-V mache dann vermutlich auch im Client Windows 8 mit Hyper-V und dort die VMs ebenfalls auf den N40L legen.

 

[LaMagra-X]

Ja, denn je nach Lizenz hast du verschiedene Möglichkeiten.

In deinem Fall geht es so:
1. Remove VM from Inventory
2. Browse Datastore
3. Download der VM (Ordner)
4. Upload VM auf neuen Datastore
5. Rechte Maustaste auf vmx Datei -> Add to Invenory
6. VM starten
7. Wenn alles läuft, auf dem alten Datastore die VM löschen

Vorsicht bei der Netzwerkkonfiguration, evtl. musst du vor dem 1. Start noch überprüfen ob die Netzwerkkarte an der richtigen Portgroup hängt.

---------- Post added at 11:46 ---------- Previous post was at 11:43 ----------

@Steggi
vMotion ist doch bei der freien Lizenz nicht möglich. Er hat ja kein vCenter

Gibts keine Möglichkeit eine VM von Datastore -> Datstore zu schieben? (mit der kostenfreien ESXi Version)

Der Umweg über eine USB-Festplatte dauert leider sehr lange.

Ich hab eben eine 500GB VM aus dem Datastore über den vSphere gezogen...hat jetzt fast 5 Stunden gedauert

 

[therealJMC]

SSH auf beiden hosts anmachen und per SCP kopieren

 

[LaMagra-X]

Gute Idee, danke!

 

[therealJMC]

Da würde es sich auch anbieten, sich via SSH auf einem der ESXi's anzumelden (SSH muss natürlich auf beiden Kisten dafür rennen) und die Files direkt über SCP auf den anderen Server zu schaufeln. Damit ersparst du dir auch das Zwischenspeichern

Steggi soll ja auch nicht zu knapp kommen was den Dank angeht