Du musst unter Konfiguration des ESXi die 2Tb Platte als Datastore einrichten, und kannst sie dann dem Server2008 unter Eigenschaften zuteilen. Dann kannst du sie normal nutzen.
ESX / ESXi - Hilfethread
- Ersteller XTaZY
- Erstellt am
Du musst unter Konfiguration des ESXi die 2Tb Platte als Datastore einrichten, und kannst sie dann dem Server2008 unter Eigenschaften zuteilen. Dann kannst du sie normal nutzen.
therealJMC
Enthusiast
- Mitglied seit
- 14.01.2010
- Beiträge
- 3.730
Hmm, dabei gibts aber was zu bedenken:
- Dabei wird der inhalt der 2TB Platte gelöscht
- Man muss eine virtuelle Platte auf dem Datastore der 2TB Platte erstellen, man kann nicht direkt die platte zuweisen
Auch wenn ich mich wiederhole
gerade für sowas eignet sich das hier: Creating RDMs on SATA drives
- Dabei wird der inhalt der 2TB Platte gelöscht
- Man muss eine virtuelle Platte auf dem Datastore der 2TB Platte erstellen, man kann nicht direkt die platte zuweisen
Auch wenn ich mich wiederhole
gerade für sowas eignet sich das hier: Creating RDMs on SATA drives
daniel16420
Neuling
Mal ne Frage:
ich habe einen hp proliant dl380 g6 mit esxi 4.0.0 und möchte auf esx 5 (habe eine lizenz gekauft) updaten mit der installations cd.
- wenn ich update, starten meine vms dann wieder ganz normal, oder soll ich sie wegsichern, esx5 installieren und wieder zurückspielen?
ich habe einen hp proliant dl380 g6 mit esxi 4.0.0 und möchte auf esx 5 (habe eine lizenz gekauft) updaten mit der installations cd.
- wenn ich update, starten meine vms dann wieder ganz normal, oder soll ich sie wegsichern, esx5 installieren und wieder zurückspielen?
Hi,
ich hab da auch mal ne Frage.
Will mir die Tage den ESXi 5 installieren.
Es werden zum start zwei virtuelle Maschinen erstellt. Eine als reiner Fileserver und einer als Webserver/ Teamspeak usw...
Nun frage ich mich, ob es überhaupt möglich ist mein externes Storagesystem an den Fileserver durchzuschleifen? Das Storagesystem ist von Sharkoon, 5-Bay in RAID 5 Konfig. Es besitzt einen USB 3 und einen E-Sata Anschluss. Kann ich dies einer VM zuweisen? Ohne das ich natürlich meine Daten darauf verliere?
Das Board unterstützt VT-D
Generelle Konfig des Servers:
Intel Core i3 2100T
Intel DQ67EP
8GB RAM
4 einzelnde Platten für die virtuellen Disks. Kein RAID.
ESXi wird auf einen USB Stick installiert
Gruß
Alex
ich hab da auch mal ne Frage.
Will mir die Tage den ESXi 5 installieren.
Es werden zum start zwei virtuelle Maschinen erstellt. Eine als reiner Fileserver und einer als Webserver/ Teamspeak usw...
Nun frage ich mich, ob es überhaupt möglich ist mein externes Storagesystem an den Fileserver durchzuschleifen? Das Storagesystem ist von Sharkoon, 5-Bay in RAID 5 Konfig. Es besitzt einen USB 3 und einen E-Sata Anschluss. Kann ich dies einer VM zuweisen? Ohne das ich natürlich meine Daten darauf verliere?
Das Board unterstützt VT-D
Generelle Konfig des Servers:
Intel Core i3 2100T
Intel DQ67EP
8GB RAM
4 einzelnde Platten für die virtuellen Disks. Kein RAID.
ESXi wird auf einen USB Stick installiert
Gruß
Alex
Steggi
Enthusiast
- Mitglied seit
- 31.12.2010
- Beiträge
- 3.483
Du kannst das ganze via E-SATA und RDM durchreichen, oder das Gerät direkt über USB an die VM hängen. Den E-SATA Controller wirst du nicht durchreichen können (wobei ich noch nicht mal weiß, ob der nicht auch an die internen Ports gekoppelt ist) denn auch wenn dein Board VT-D kann, deine CPU kanns nicht 
Intel® Virtualization Technology (VT-x)
Yes
Intel® Virtualization Technology for Directed I/O (VT-d)
No
Intel® Virtualization Technology (VT-x)
Yes
Intel® Virtualization Technology for Directed I/O (VT-d)
No
So, ich schon wieder..... 
Nach dem ich den Kampf mit der Installationsroutine gewonnen habe( Musste leider 5 CDs verschwenden^^ ) und ich nun auch endlich meine Netzwerkkarte zum laufen gebracht habe ist mein ESXi 5 fertig.
Habe jetzt meine erste VM mit Server 2003R2 installiert. Hat alles wunderbar funktioniert. Nur wie bekomme ich jetzt mein Storage durch geschliffen, wenn VT-D nicht zur Verfügung steht? Geht es dann überhaupt?
Schließe ich das Storage über E-Sata an. So wird unter Datenspeicher das System richtig erkannt. Aber wenn ich daraus ein VM Storage erstellen würde, wären ja alle Daten weg. Richtig?
Klemme ich es über USB an, bekomme ich zwar ne Meldung, dass was angeschlossen wurden ist, kann damit aber nichts machen, oder finde zu mindestens nichts.
Weise ich einer VM einen USB Controller zu, kann ich die Geräte von meinen PC über die Konsole durchschleifen. Aber das ist ja nicht mein Ziel.
Kann mir da einer Helfen oder gibt es nur die Lösung, einen CPU mit VT-D zu kaufen, um den E-SATA Port direkt durch zu geben?
Gruß
Alex
Nach dem ich den Kampf mit der Installationsroutine gewonnen habe( Musste leider 5 CDs verschwenden^^ ) und ich nun auch endlich meine Netzwerkkarte zum laufen gebracht habe ist mein ESXi 5 fertig.
Habe jetzt meine erste VM mit Server 2003R2 installiert. Hat alles wunderbar funktioniert. Nur wie bekomme ich jetzt mein Storage durch geschliffen, wenn VT-D nicht zur Verfügung steht? Geht es dann überhaupt?
Schließe ich das Storage über E-Sata an. So wird unter Datenspeicher das System richtig erkannt. Aber wenn ich daraus ein VM Storage erstellen würde, wären ja alle Daten weg. Richtig?
Klemme ich es über USB an, bekomme ich zwar ne Meldung, dass was angeschlossen wurden ist, kann damit aber nichts machen, oder finde zu mindestens nichts.
Weise ich einer VM einen USB Controller zu, kann ich die Geräte von meinen PC über die Konsole durchschleifen. Aber das ist ja nicht mein Ziel.
Kann mir da einer Helfen oder gibt es nur die Lösung, einen CPU mit VT-D zu kaufen, um den E-SATA Port direkt durch zu geben?
Gruß
Alex
therealJMC
Enthusiast
- Mitglied seit
- 14.01.2010
- Beiträge
- 3.730
Ich überlege momentan ob wir in nächster Zeit mal ein Upgrad von ESX4.1 auf ESXi5.0 einplanen sollten. Vorteil ist bei 4 Hosts kann ich sie nacheinander Updaten und die VMs verschieben...Nachteil ist ich fürchte mich irgendwie davor den ESX anzufassen
Was genau würdest du backupen?
Von den ESX an sich habe ich ein Hostprofile, könnte also jederzeit wieder zurück auf 4.1. Die VMFS-Datastore liegen auf der SAN, evtl. würde ich da vorher einen Snapshot anlegen damit. Die VMs werden ja erst angefasst wenn die Hardwareversion geupgradet wird.
Wenn ich mir die Anleitung her anschaue geht das ja echt ziemlich unproblematisch.
vSphere 5 - Migrating from ESX 4.1 to ESXi 5.0 - YouTube
Von den ESX an sich habe ich ein Hostprofile, könnte also jederzeit wieder zurück auf 4.1. Die VMFS-Datastore liegen auf der SAN, evtl. würde ich da vorher einen Snapshot anlegen damit. Die VMs werden ja erst angefasst wenn die Hardwareversion geupgradet wird.
Wenn ich mir die Anleitung her anschaue geht das ja echt ziemlich unproblematisch.
vSphere 5 - Migrating from ESX 4.1 to ESXi 5.0 - YouTube
Hi,
wir haben extra Software um die virtuellen Maschinen von VM Ware zu backupen. Haben von alle Maschinen ein Backup gezogen um sicher zu gehen. Aber wie gesagt, ging sehr unproblematisch.
Habe jetzt bei meinen Privaten ESXi 5 ein RDM eingerichtet. War nicht ganz so easy hat aber funktioniert. Keine Daten verloren und mein Storage ist jetzt durchgeschliffen. Super
Aber wo ich hier gerade schon bin^^
Gibt es ne Möglichkeit eine einzelne virtuelle Platte zwei Maschinen zuzuweisen. Sinn: So könnte man auf einer virtuellen Platte Tools speichern, die man bei mehreren Maschinen braucht. Hat da schon jemand was probiert?
Gruß
Alex
wir haben extra Software um die virtuellen Maschinen von VM Ware zu backupen. Haben von alle Maschinen ein Backup gezogen um sicher zu gehen. Aber wie gesagt, ging sehr unproblematisch.
Habe jetzt bei meinen Privaten ESXi 5 ein RDM eingerichtet. War nicht ganz so easy hat aber funktioniert. Keine Daten verloren und mein Storage ist jetzt durchgeschliffen. Super
Aber wo ich hier gerade schon bin^^
Gibt es ne Möglichkeit eine einzelne virtuelle Platte zwei Maschinen zuzuweisen. Sinn: So könnte man auf einer virtuellen Platte Tools speichern, die man bei mehreren Maschinen braucht. Hat da schon jemand was probiert?
Gruß
Alex
Nein, funktioniert nicht, da sperrt sich der ESX-Host. Dafür gibt's normalerweise ein zentrales Netzlaufwerk, was idealerweise beim Administrator bzw. Domänen-Admins im Login-Script/wieauchimmer bei der Anmeldung verbunden wird.
Zum Upgrade: die virtuellen Maschinen braucht man nicht zu sichern, wenn die auf einer zentralen Storage liegen und man die Hosts einen nach dem anderen aktualisiert. Ein Host sollte/muss sowieso von der Kapazität "übrig" sein, damit die virtuellen Maschinen weiterlaufen, wenn ein Host ausfallen sollte. Vor dem Upgrade der Hosts die virtuellen Maschinen von dem auf andere Hosts verlagern, schon kann man die Hosts einen nach dem anderen und im Anschluss die VMWare-Tools aktualisieren.
Dafür gibt's normalerweise ein zentrales Netzlaufwerk, was idealerweise beim Administrator bzw. Domänen-Admins im Login-Script/wieauchimmer bei der Anmeldung verbunden wird.Zum Upgrade: die virtuellen Maschinen braucht man nicht zu sichern, wenn die auf einer zentralen Storage liegen und man die Hosts einen nach dem anderen aktualisiert. Ein Host sollte/muss sowieso von der Kapazität "übrig" sein, damit die virtuellen Maschinen weiterlaufen, wenn ein Host ausfallen sollte. Vor dem Upgrade der Hosts die virtuellen Maschinen von dem auf andere Hosts verlagern, schon kann man die Hosts einen nach dem anderen und im Anschluss die VMWare-Tools aktualisieren.
Hi,
wir haben extra Software um die virtuellen Maschinen von VM Ware zu backupen. Haben von alle Maschinen ein Backup gezogen um sicher zu gehen. Aber wie gesagt, ging sehr unproblematisch.
Habe jetzt bei meinen Privaten ESXi 5 ein RDM eingerichtet. War nicht ganz so easy hat aber funktioniert. Keine Daten verloren und mein Storage ist jetzt durchgeschliffen. Super
Aber wo ich hier gerade schon bin^^
Gibt es ne Möglichkeit eine einzelne virtuelle Platte zwei Maschinen zuzuweisen. Sinn: So könnte man auf einer virtuellen Platte Tools speichern, die man bei mehreren Maschinen braucht. Hat da schon jemand was probiert?
Gruß
Alex
Storage auf ESXi Datenspeicher per RDM ist nicht optimal.
Eine saubere Lösung eines ESXi-Servers mit virtualisiertem NAS/SAN könnte so aussehen:
- ESXi auf einer onboard SATA Platte installieren
- auf dieser SATA Platte ein lokales datastore anlegen
- ein virtuelles SAN OS darauf anlegen (egal was, ich bevorzuge ZFS für Storage)
- einen zweiten Disk Controller einbauen, alle Datenplatten da anschließen und diesen
per vt-d und pass-through an das SAN OS durchreichen. Das SAN OS hat dann direkten Zugriff,
hat alle Reparaturmöglichkeiten und praktisch die gleiche Performance wie auf echter Hardware
Das NAS/SAN kann jetzt Datenserver spielen.
Unter anderem kann es auch shared storage (iSCSI oder NFS) für ESXi bereitstellen.
Jede VM kann darauf zugreifen z.B. ISO's mounten etc.
Warum sollte ESXi shared SAN Storage nutzen:
- Weil es schneller ist (ein gutes SAN ist schneller als ESXi im Storagebereich)
- Weil move/copy/clone/backup einfach ein Kopieren eines Ordners auf dem SAN darstellt
und der ESXi Filebrowser elend langsam ist
- Weil ein gutes SAN z.B. ZFS beliebig viele Snaps ohne anfänglichen Platzverbrauch und Delay kann
- weil der Zugriff auf das SAN und die Snapshots einfach und schnell per Windows SMB und
vorherige Version erfolgt
- weil die Datensicherheit erheblich besser ist (z.B. ZFS dank Prüfsummen und online-scrubbing
gegen silent errors)
- weil ein SAN-Pool wachsen kann
- weil es blockbasiertes Replizieren gibt (inkrementelles Backup auf Basis von Snaps und geänderter Datenblocks)
..
Wenn das SAN virtualisiert wird, ergibt sich neben den geringeren Kosten (nur ein Server) auch der Vorteil,
dass weniger Hardware (im Vergleich zu der ganzen SAN-Verkabelung) auch weniger Probleme bereitet.
Da der Datenverkehr zwischen ESXi und SAN intern über den ESXi Switch läuft, ist es kein Problem damit in
Software (per VMCI und/oder ESXi vmxnet3 Treiber) über den ESXi Software-Switch bis zu 10 Gb zu erreichen-
ohne teure SAN-Verkabelung. Ist zwar nicht für ganz große Installationen geeignet, da ist ein separates redundantes SAN besser. Ich mach damit aber schon mittelgroße Sachen wobei ich mehrere redundante Systeme habe und jeder ESXi-Server sein eigenes lokales SAN nutzt. (Ich denke da immer an einen ganz großen Webprovider (die älteren errinnern sich vielleicht); denen ist vor vielen Jahren das zentrale SAN abgeraucht und Hunderttausende von Websites waren eine Woche offline, manche waren ganz weg - deshalb ist mein Weg sowenig gemeinsam genutzte Sachen wie möglich und soviel wie nötig)
Ich habe dazu auch ein kleines howto erstellt (englisch, auf Basis freier/kostenloser Software)
http://www.napp-it.org/doc/downloads/all-in-one.pdf
Zuletzt bearbeitet:
Das es nicht optimal ist weiß ich auch. Für den privaten Haushalt aber ausreichend.
ABER das was du schreibst ist in meinen Fall nicht umsetzbar!
Erstens unterstützt meine CPU kein VT-D. Okay hier ist zwar schon ein 2400er geplant, die Umsetzung wird aber dauern.
Zweitens habe ich ein ITX Board und somit nur ein PCIe x16 Slot frei. Dieser wird aber am Wochenende genutzt um eine weitere NIC zu Verfügung zu stellen.
Drittens will ich das Storage auch mal abnehmen können und an einen normalen PC verwenden. Dies geht mit deiner Methode nicht.
Gruß
Alex
P.S. Was die Leistung angeht ist ein RDM sehr schnell.
ABER das was du schreibst ist in meinen Fall nicht umsetzbar!
Erstens unterstützt meine CPU kein VT-D. Okay hier ist zwar schon ein 2400er geplant, die Umsetzung wird aber dauern.
Zweitens habe ich ein ITX Board und somit nur ein PCIe x16 Slot frei. Dieser wird aber am Wochenende genutzt um eine weitere NIC zu Verfügung zu stellen.
Drittens will ich das Storage auch mal abnehmen können und an einen normalen PC verwenden. Dies geht mit deiner Methode nicht.
Gruß
Alex
P.S. Was die Leistung angeht ist ein RDM sehr schnell.
daniel16420
Neuling
Zu dem Thema: Ich wusste es mal, aber habs wieder vergessen. Wie wird dieser Lock auf den vmdks aufgehoben wenn ein ESX ausfällt? Läuft das z.B. automatisch über HA ab sobald die anderen Hosts merken, dass der Ausgefallene nicht mehr antwortet?Nein, funktioniert nicht, da sperrt sich der ESX-Host.
Bei uns läuft eine 3/4-Konfiguration, also könnte ich eigentlich im laufenden Betrieb einen ESX in den Maintanance Modus versetzen und dann upgraden. Denke aber ich verlege das ganze aufs Wochenende; ich erinnere mich noch daran wie ich unseren ExchangeSX per vMotion verschoben habe und 15m später ist mir aufgefallen, dass Outlook keine Verbindung mehr zum Exchange hat...
10Gb wären schon nett
Neja so viel sauberer ist das nun auch nicht
Der Vorteil an der Geschichte ist, man kann das ganze direkt als Fileserver missbrauchen... Ansonsten bleibt als riesiger Nachteil der Single Point of Failure an der Stelle, wo eben die SAN VM abgelegt ist.
Hier kann man sich nur äußerst schwer schützen...
Das Problem ist und bleibt der mangelnde Software Raid Support von VMware für die ESXi Server... Den Host selbst kann man bequem auf nem USB Stick fallen lassen. Das SAN OS muss aber irgendwie auf nen Datastore. Der ohne Software Raid Support eben ne Single HDD/SDD, oder ein FlashMedium wie auch immer geartet sein muss. Raucht das Teil weg, steht die ganze Kiste.
Will man hier Sicherheiten haben, brauch es nem supported Raidcontroller und mindestens zwei HDDs zu. Kauft man aber das Teil, und kann man auf ne Fileserverfunktion selbst verzichten, so kommt man eher sogar vorteilhafter, den Raidcontroller gleich auch als Datastorepool zu nutzen.
Als Beispiel. So ein HP Smart Array P410 mit 256MB Cache + BBU kostet im Einkauf keine 200€ inkl. MwSt.
Er bringt Raid 0/1/10/5 Support und ich glaube sogar Raid 6. Wird voll vom ESXi unterstützt und bietet 8 Ports... Mit der Möglichkeit über ne Extenderkarte weitere HDDs zu betreiben.
Deutlich günstiger gehts in Sachen Hardware Raid fast nicht. Und man spart sich die Bastellösung mit dem SAN OS
Das Teil ist zwar nicht HighEnd, aber durchaus ordentlich...Ich persönlich sehe den Vorteil von so nem Storage OS in ner VM mit durchgereichtem Controller nur dort, wo wirklich noch 100% Fileserverspeed gebraucht wird. Hat man dazu aber ne diskrete Kiste oder aber man begnügt sich mit den keine Ahnung 90 oder 80% Speed ner Fileserver VM mit vmdk Platten, so sehe ich an der Stelle echt keine Vorteile mehr.
Womögliche Probleme in Sachen Durchreichen von Controllern mal ganz außen Vorgelassen
PS: das mit den 10Gbit ist nur die halbe Wahrheit
Dafür benötigt man nämlich die Enterprise oder Enterprise Plus Version. Soweit mir bekannt kann die Standard Edition sowie die Essentiel Version(en) das nicht. Und die Advanced (wo es beim 4er schon nicht ging) fällt ja weg.
Mit nem ESXi und kostenloser Version wirds mit 10GBit in Sachen VM NIC auch nix. Bleibt der Flaschenhals zumindest bei der virtuellen Netzwerkkarte des Storage OS bzw. der Storage VM.
Was meinst du damit genau?
Der Host selbst merkt, wenn jemand die Füße in der vmdk drin hat. Ist dies der Fall, geht kein weiterer Zugriff, sobald die "Füße" raus sind, hast du sofort Zugriff. Sprich fliegt dir ein Host um die Ohren sagen wir, ist sofort ab dem Zeitpunkt die vmdk quasi frei für jeden anderen.
Aber für was braucht man sowas!?
Da kommst du wohl eher besser, wenn du dir ein shared ISO baust, was du dann von Zeit zu Zeit mit den Tools updatest, die du benötigst. Das kannst du dann entweder direkt lokal auf die Hosts schieben und vom Datastore mounten, oder halt über den vSphere Client aus mounten über jegliche Storages, wo der Client halt Zugriff hat.
Bei uns läuft eine 3/4-Konfiguration, also könnte ich eigentlich im laufenden Betrieb einen ESX in den Maintanance Modus versetzen und dann upgraden. Denke aber ich verlege das ganze aufs Wochenende; ich erinnere mich noch daran wie ich unseren ExchangeSX per vMotion verschoben habe und 15m später ist mir aufgefallen, dass Outlook keine Verbindung mehr zum Exchange hat...
10Gb wären schon nett
Zuerst den vCenter Server in der neuen Version installieren. Ganz wichtig!
Am besten kein Update machen, sondern einfach ne zweite Maschine fertig vorbereiten, dort sauber den vCenter Server Dienst drauf bringen und die Zusatztools, was man sonst noch so braucht, wie den Update Manager.
PS: Zum Update Manager noch meinen Tip. Der 5er vCenter bringt nen SQL 2008 (ich glaub R2) in der 64Bit Version mit. Der Update Manager verlangt aber nen 32Bit DSN und meckert sonst rum.
VMware KB: Installing ESXi/ESX 4.1 and vCenter Server 4.1 best practices
Hier steht dazu alles wichtige unter dem Abschnitt Update Manager...
Ansonsten, läuft das vCenter sauber, kann man erstmal die Lizenzen einspielen... Da man ja über die Softwaresubscription bei VMware den Spaß life auf der Internetseite Updaten kann, bekommt man für alle seine Hosts, dann die 5er Keys. Diese werden zusammen mit den alten 4er Keys im neuen 5er vCenter eingespielt (im Lizenzmenü)
Am besten baut man dann die Cluster Konfiguration erstmal "trocken" im vCenter selbst auf, sind ja noch keine Hosts drin. Danach erfolgt das Anlegen von Distributed Switches, sofern in use. (wichtig zu wissen ist, der 5er ESXi kann nun nur noch Distributed Switches, wenn man auf die Enterprise Plus Version hat, austricksen wie beim 4er ist nicht mehr)
Steht das soweit, kann es ans migrieren gehen.
Schritt 1 ist. Im alten vCenter 4 einfach alles was mit HA zu tun hat, deaktivieren (sprich DRS, FT usw.)
Schritt 2, die Hosts aus dem vCenter (inkl. laufender VMs und ohne irgendwas an den Hosts selbst zu verändern) ausklinken (rechtsklick auf den Host und Verbindung trennen oder so heist das)
Schritt 3, die Hosts im neuen vCenter einklinken (an der Stelle verlangt er die Zuweisung der 4er Lizenzen, wie oben erwähnt) und direkt dem Cluster sauber zuweisen. (und auch gleich vMotion aktivieren)
Danach läuft erstmal alles wie gehabt weiter... Diese Schritte selbst gehen gänzlich ohne Boots oder ähnliches der Hosts und VMs. Sozusagen im Lifebetrieb.
Als nächstes fängt man nun an, die Hosts selbst in den Wartungsmodus zu schicken und nach und nach diese mit dem 5er ESXi neu zu installieren (am besten nicht updaten, was teils auch gehen würde)
Im Nachgang daran, wird der Update Manager angeschmissen und der Host gepatcht, den man gerade installiert hat. Sowie alles in Sachen vSwitche und Netzwerkzuordnung vorgenommen.
Hat man hier den ersten durch, kann man bei ner Enterprise Plus Lizenz/alternativ die 60 Tage Testphase in Form der Testlizenz für die Hosts dann erstmal einen Host sauber einrichten und ein Hostprofil anlegen. (was die Arbeit mit weiteren Hosts ungemein erleichtert)
Anmerkung dabei, die Arbeit mit den Hostprofilen gestaltet sich in meinen Augen etwas schwer, es gibt nun keine dedizierten Servicekonsole Ports (wie beim 4er ESX) mehr, sondern nur noch ESXi üblich vmKernel Ports. Das Problem ist aber, die Reihenfolge, wie man diese Ports anlegt, ist mehr oder weniger wichtig. Hier sollte man beim Arbeiten mit Hostprofilen diese entweder händisch selbst anlegen (und das was das Hostprofil erzeugt vorher löschen) oder aber ganz auf das Hostprofil verzichten. Bei mir hat es nämlich durch das Hostprofil die Reihenfolge umgebogen, was den Effekt hatte, das die Servicekonsole trotz richtig gesetzen Haken für eben diese nicht dort auf der IP erreichbar war, wie sie sollte... (man sperrt sich schön selbst aus
)Beherzigt man das alles, werden dann im Nachgang alle Hosts so durchgenommen.
Schlussendlich hat man ohne Mucken ne laufende 5er Umgebung.
PS: die Datastores können im Nachgang (wenn alle Hosts, die Zugriff haben dann 5er Hosts sind) auf VMFS5 upgedated werden, das geht ebenso life ohne Unterbruch.
Die VMs selbst können ebenso von Version 4 oder 7 auf Version 8 gebracht werden, was ebenso life geht.
Im aller letzten Schritt sollten dann noch die VMware Tools auf allen VMs auf die neue Version gebracht werden. Das erfordert aber nen Neustart der VM selbst und erzeugt somit einen Unterbruch (sollte also nicht im scharfen Betrieb getätigt werden
)Neja so viel sauberer ist das nun auch nicht
Der Vorteil an der Geschichte ist, man kann das ganze direkt als Fileserver missbrauchen... Ansonsten bleibt als riesiger Nachteil der Single Point of Failure an der Stelle, wo eben die SAN VM abgelegt ist.
Hier kann man sich nur äußerst schwer schützen...
All-In-One: Alles in einem Rechner, entweder er läuft oder eben nicht
Man braucht halt immer ein redundantes System - mit oder ohne SAN - mit SAN braucht man neben einem zweiten ESXi auch ein zweites SAN. Bei mir hat aber jedes ESXi System sein eigenes virtualisiertes SAN das auch den anderen ESXi Rechnern zur Verfügung steht. Also sehr redundant.
Raid-1 für den ESXi + lokales datastore für die Storage VM macht schon Sinn - entweder mit einem
unterstützten Raidcontroller oder einem treiberlosen Raid-1 Modul für Sata.
Kauft man aber das Teil, und kann man auf ne Fileserverfunktion selbst verzichten, so kommt man eher sogar vorteilhafter, den Raidcontroller gleich auch als Datastorepool zu nutzen.
Als Beispiel. So ein HP Smart Array P410 mit 256MB Cache + BBU kostet im Einkauf keine 200€ inkl. MwSt.
Er bringt Raid 0/1/10/5 Support und ich glaube sogar Raid 6. Wird voll vom ESXi unterstützt und bietet 8 Ports... Mit der Möglichkeit über ne Extenderkarte weitere HDDs zu betreiben.
Deutlich günstiger gehts in Sachen Hardware Raid fast nicht. Und man spart sich die Bastellösung mit dem SAN OS
Lokaler ESXi Raid-Speicher ist halt im Vergeich zu einem ZFS SAN ein gewaltiger Unterschied, da:
Write-Whole Problem, keine Prüfsummen, kein selbstreparierendes Dateisystem, kein Online Scrubbing gegen stille Datenfehler, keine snap- und blockbasierte Replikation, kein Hybridspeicher, keine unbegrenzte Anzahl von Snapshots ohne Zeitverlust, keine Möglichkeit mal ganz schnell von Windows aus eine VM zu klonen zu sichern oder zu verschieben, kein direkter oder nur sehr langsamer Zugriff mit dem ESXi Browser oder extra Backupsoftware.. (Ich habe viel Laborbetrieb mit Gratis ESXi - kein automatisches Vmotion, wär aber mit SAN auch kein Thema, geht aber ganz gut auch so und spart ein paar Tausender)
Ich persönlich sehe den Vorteil von so nem Storage OS in ner VM mit durchgereichtem Controller nur dort, wo wirklich noch 100% Fileserverspeed gebraucht wird. Hat man dazu aber ne diskrete Kiste oder aber man begnügt sich mit den keine Ahnung 90 oder 80% Speed ner Fileserver VM mit vmdk Platten, so sehe ich an der Stelle echt keine Vorteile mehr.
Womögliche Probleme in Sachen Durchreichen von Controllern mal ganz außen Vorgelassen
Virtualisierung ist eigentlich bei ESXi perfekt gelöst. Ohne Shared Storage, egal ob externes SAN oder in
virtualisierter Form macht es aber nicht halb soviel her.
Hardware zum Durchreichen muss gezielt gekauft werden. Dann geht es aber problemlos (z.B. LSI HBA und Boards mit Intel Server-Chipsatz)
PS: das mit den 10Gbit ist nur die halbe Wahrheit
Dafür benötigt man nämlich die Enterprise oder Enterprise Plus Version. Soweit mir bekannt kann die Standard Edition sowie die Essentiel Version(en) das nicht. Und die Advanced (wo es beim 4er schon nicht ging) fällt ja weg.
Mit nem ESXi und kostenloser Version wirds mit 10GBit in Sachen VM NIC auch nix. Bleibt der Flaschenhals zumindest bei der virtuellen Netzwerkkarte des Storage OS bzw. der Storage VM.
Wäre mir jetzt neu, dass die kleinen Versionen inkl freie Version den virtuellen Switch begrenzen. VMCI und vmxnet3 gehen auch. Meines Wissens kann man lediglich nichts zuteilen oder beschränken.
Compare VMware vSphere Editions for Cloud Computing, Server and Data Center Virtualization
Zuletzt bearbeitet:
Die SAN redundanz bringt dir aber dann auch nur mit Lizenzen was... mit der kostenfreien Version erkaufst du dir damit nicht wirklich was. Oder unterhalten sich die SAN VMs untereinander und spiegeln untereinander? Aber selbst wenn, dann würde arg auf die Performance drücken wenn das via LAN und womöglich noch mit 1GBit gehen würde...
Das Problem bleibt bei der Root Platte der Storage VM. Selbst wenn man mit nem intelligenten System die weiteren VMs auf dem System so auslegt, das man Plattenausfälle kompensieren kann, weil eben redundanzen in Form von verteilen Platten in dieser Storage VM bestehen, kann es immernoch die Storage VM reißen, wenn deren Root Platte abschmiert. Da hilft dann nur besagte Raid 1 Module... Wobei das auch Bastellösung ohne Ende ist
Also mich begleiten VMware Produkte nun schon seit knappen 10 Jahren... Und ich kann dir sagen, das ich nicht einen einzigen Fehler hatte, der auf die von dir genannten Sachen zurück geht. ZFS schön und gut. Im Fileserverbetrieb für reine Userdaten sicher ordentlich von Vorteil zumindest in einigen Bereichen wie den Snapshots usw.
Aber als Basis für die Datastores der VMs sehe ich das nicht unbedingt als unbedingt von nöten.
Und auch die Backupgeschichten bzw. die Filezugriffe sind nicht so langsam wie du es beschreibst, da gibts freilich auch Software die das gut macht. Im aller dümmsten Fall nutzt man einfach was ala WinSCP oder Filezilla um die Files wegzubekommen, wenn der VMware Browser zu lahm ist
Das ist durchaus richtig, ich sehe nur eben den Nachteil darin, das virtualisierte shared Storage bringt den Fehlerpunkt auf eben seine Root Partition. Und schafft es somit beim Ableben der einen HDD, das komplette System lahm zu legen, was an diesem shared Storage hängt. Und eben genau die HDDs sind leider immernoch das quasi Anfälligste in so einem System. Neben den NTs... mit einem Abstand gefolgt vom RAM. Board/CPUs sowie irgendwelche Controllerkarten gehen laut meinen Erfahrungen in den aller seltensten Fällen kaputt...
Aber der eigentliche Vorteil in den mittleren bis großen Umgebungen ist genau der, das das Storage eben extern ist und somit auch Wartungsarbeiten an den Hosts oder am dann womöglich auch redundanten Storage durchführbar sind ohne Unterbruch. Das klappt mit nem virtualisierten Storage nicht. Und das durchreichen des Controllers macht die VM selbst noch unflexibel.
Also ich hab auf Arbeit ein paar 4.0, 4.1 und 5.0er Systeme am tuckern... Nahezu alle vollständig mit vmnet3 Adaptern in den VMs. Und diese Adapter geben als Verbindungsglied zwischen (Storage) VM und eben dem Host selbst nur 1GBit/s an Speed, sofern die Lizenz nicht passt.
Zuletzt bearbeitet:
Die SAN redundanz bringt dir aber dann auch nur mit Lizenzen was... mit der kostenfreien Version erkaufst du dir damit nicht wirklich was. Oder unterhalten sich die SAN VMs untereinander und spiegeln untereinander? Aber selbst wenn, dann würde arg auf die Performance drücken wenn das via LAN und womöglich noch mit 1GBit gehen würde...
Das Problem bleibt bei der Root Platte der Storage VM. Selbst wenn man mit nem intelligenten System die weiteren VMs auf dem System so auslegt, das man Plattenausfälle kompensieren kann, weil eben redundanzen in Form von verteilen Platten in dieser Storage VM bestehen, kann es immernoch die Storage VM reißen, wenn deren Root Platte abschmiert. Da hilft dann nur besagte Raid 1 Module... Wobei das auch Bastellösung ohne Ende ist
Ich habe zwar 10 Gb, ist aber hier komplett egal - ZFS Replikation arbeitet inkrementell. Das bedeutet, nur geänderte Datenblocks werden z.B. alle 10 Min übertragen, da würde auch 100 Mb ausreichen.
Ansosten ist eine Raid-1 Systemplatte kein Problem. Eine Bastellösung ist das dann auch nicht, nur weil es kein Vermögen kostet sondern lediglich etwas für den Zweck ausreichendes.
Also mich begleiten VMware Produkte nun schon seit knappen 10 Jahren... Und ich kann dir sagen, das ich nicht einen einzigen Fehler hatte, der auf die von dir genannten Sachen zurück geht. ZFS schön und gut. Im Fileserverbetrieb für reine Userdaten sicher ordentlich von Vorteil zumindest in einigen Bereichen wie den Snapshots usw.
Aber als Basis für die Datastores der VMs sehe ich das nicht unbedingt als unbedingt von nöten.
Und auch die Backupgeschichten bzw. die Filezugriffe sind nicht so langsam wie du es beschreibst, da gibts freilich auch Software die das gut macht. Im aller dümmsten Fall nutzt man einfach was ala WinSCP oder Filezilla um die Files wegzubekommen, wenn der VMware Browser zu lahm ist
WinSCP ist im Vergleich zu NFS oder SMB furchtbar langsam. Daneben gibt es mit Windows Zugriff auf Snapshots mit vorherige Version.
Ich sehe das Ganze halt schon sehr stark von der Storageseite. Ausserdem hatte ich, jetzt nicht unbedingt bei ESXi schon mehrere Datenverluste die mir mit ZFS nicht passiert wären. ESXi ist da aber sicher nicht besser als ntfs oder extfs. Ein sicheres datastore ist mir schon was wert (So gut es eben geht)
Shared storage ist das NFS oder iSCSI datastore auf dem die VM's liegen, nicht die ESXi/SAN-Bootplatte. Wenn die abraucht, kann ich mit einer Reserveplatte booten oder den Pool einfach in die nächste Maschine stecken, mounten und dort die VM nach ein paar Minuten wieder hochfahren - oder eben auf das replizierte Backup zurückgehen. Das geht bei lokalem ESXi Raid-datastore nicht so einfach.
Richtig, deshalb auch das SAN. Ob extern oder virtualisiert ist zunächst zweitrangig. Ich virtualisere das eben, damit jede ESXi völlig autark arbeitet. 10 ESXi Server = 10 SAN. Ich nutze es als ultra-komfort local datastore mit viel Extras. SAN ist bei mir nicht das eine große Ding das furchtbar viel Geld kostet (Danke nochmal an SUN für die Freigabe von ZFS und OpenSolaris als OpenSource). Ausserdem brauche ich nur halbsoviel Server und nicht die teure redundante SAN-Verkabelung die auch kaputtgehen kann.
Dis Storage VM ist in der Tat nicht sehr flexibel, wozu auch. Die wird nicht verschoben. ESXi System Snapshots brauchts auch nicht (gehen aber offline). Die kann ZFS eh selber. Die Storage VM und ESXi haben da ein Verhältnis wie bei XEN die Dom0 zu XEN, sind immer als Einheit, als lokales OS zu sehen.
(Wobei ich ehrlicherweise die Zukunft eher bei KVM sehe: Storage mit eingebauter Virtualisierung ist einfacher umzusetzen als Virtualisierung + separates StorageOS)
Die kostenlose Version probieren, die zeigt auch 10 Gb an. Ist aber komplett egal, was die anzeigt. Da es kein physikalisches Medium gibt, erreicht man auch mit E1000 und VMCI mehrere Gbit/s im ESXi internen Datenverkehr.
Zuletzt bearbeitet:
Ich sehe sowas immer gern aus der Praxis Sicht... Da ich viel mit Windows Systemen zu tun habe, nutzen mir solche Storage Replikationen ohne konsistenten Zustand der VM selbst gar nix
Da kann man dann eher sich glücklich schätzen, wenn die VM selbst überhaupt noch bootet aus dem Replikationsspeicher. Von irgendwelchen Datenbanken usw. ist da noch keine Rede
Zum anderen. Im Firmenumfeld ist alles, was nicht mit Support belegtbar ist ne Bastellösung
Unabhängig ob es taugt oder nicht.Bei mir eben gar nix...
Da laufen Systeme teils schon seit 10 Jahren + im Dauerbetrieb. Ohne Reboot oder sonstigen Unterbruch. Nix mit Filesystemproblemen.
Ich kann mir aber ehrlich gesagt auch nicht wirklich vorstellen, das es da überhaupt ernste Probleme gibt, die nicht irgendwie auf Usereinwirkung oder Fremdverschulden zurückzuführen wären. Normale Filesysteme jenseits von ZFS können das alles nicht und werden dennoch überall genutzt. Selbst in Hochverfügbarkeitssystemen usw.
ZFS selbst ist da würde ich behaupten eher mäßig vertreten... Was wohl zeigt, wie viel man da an Problemen erwarten darf.
Also in den Größenordnungen, wo man dann drüber nachdenkt, und wo es vor allem auch sinnvoll ist definitiv mit shared externem Storage zu arbeiten aus genannten Gründen, legt man für die Systeme und die Lizenzen so viel Kohle auf den Tisch, das das Storage quasi mit abfällt
Ne aber mal im Ernst. Ein bisschen blöd mit dem externen Storage läuft das schon... Will man das haben, kostet einen das. Hat man nur zwei oder drei Hosts braucht man trotzdem einen bzw. zwei FC Switches und ein bzw. zwei SAN Kisten für die doppelt redundante Anbindung.
Andererseits, der der sagen wir 20 Hosts hat, lebt mit zwei SAN und zwei FC Switches immernoch sicher... Um so weniger Hosts, desto stärker fällt die SAN Infrastruktur selbst ins Gewicht. Ich denke man muss hier einfach über einen gewissen Punkt kommen, ab dem sich das dann rechnet. Nach oben hin wirds dann ja deutlich einfacher.
Zum letzten, ich hab das grad mal probiert, gestaltet sich aber schwer auf meinem ESXi Zuhause. Der packt nichtmal 1GBit Speed intern auszufahren
... Läuft ziemlich an der Brechgrenze das gute Stück. Aber bis was neues kommt, muss es noch tuckern...Ich guck mal vllt schaff ich das morgen auf der Arbeit mal zu testen.
Wenn das so stimmt wie du sagst, ich hab zwei DL 380 G7 mit 5er kostenfrei Key wo die VMs 1GBit NICs bekommen. Und dazu im Vergleich RX 300 S6 Büchsen mit Enterprise Plus Key und 10 GBit NICs (außer XP Maschinen die haben 1,4GBit NIC Speed)
Normal sollte ich da eine Abstufung sehen wenn es beim NIC Speed limitiert, wovon ich bis dato immer ausgegangen bin...
Ich sehe sowas immer gern aus der Praxis Sicht... Da ich viel mit Windows Systemen zu tun habe, nutzen mir solche Storage Replikationen ohne konsistenten Zustand der VM selbst gar nix
Da kann man dann eher sich glücklich schätzen, wenn die VM selbst überhaupt noch bootet aus dem Replikationsspeicher. Von irgendwelchen Datenbanken usw. ist da noch keine Rede
Zum anderen. Im Firmenumfeld ist alles, was nicht mit Support belegtbar ist ne Bastellösung
Es kommt darauf an
Es gibt nicht nur das normale Firmenumfeld wo bei Systemhaus x etwas gekauft wird das dann von diesem installiert und in einem bestimmten Zeitfenster wieder repariert wird und ansonst wird die Lösung nicht angefasst.
Im Hochschulumfeld (da arbeite ich), bei Entwicklern, SoHo, @home oder in IT Bereichen selber sieht das ganz anders aus. Da gibt es eben nicht immer eine Enterprise Lizenz von VMware, kein net-app SAN und keine Cisco Switche und FC für jede kleine Anwendungs,- Test- oder Laborinstallation dafür aber oft sehr viel Know-How und ausreichend Personal/ Ingenieure/ Auszubildende (Fachinformatiker)/ Studierende. Es kostet dann viel weniger und man weiss selber was man hat (oft die flexiblere und modernere Lösung) und kann es selber modifizieren und gezielt anpassen. Und man möchte natürlich das volle Programm: Virtualisierung, ein SAN oder NAS und Performance.
Bei einer normalen Firmen-IT mit Personalmangel und genug Geld würde ich da aber auch nichts machen.
Zur SAN Replikation.
Die ist selber zwar immer cold (status der VM wie nach hartem Ausschalten). Bei kritischen VM's z.B. nicht transaktionssicheren Datenbanken muss davor deshalb ein ESXi Hot-Snap gemacht werden auf den man dann nach einem Restore zurückgehen kann. Der kann dann aber sofort gelöscht werden damit er nicht bremst.
Zuletzt bearbeitet:
Moin,
ich habe ein sehr spannendes Problem - mein ESXi 5 hat irgendwie keine Lust mehr, seine Konfig zu sichern...
Angefangen hats damit, dass ich vor ein paar Tagen die Management IP geändert habe... Gestern Abend reboot des Hosts und er kam nicht wieder hoch, die Autostart-VMs aber schon... Hat nen Moment gedauert, bis ich kapiert hatte, was los ist - aber wie sich herausstellte, waren alle Konfig-Änderungen der letzten paar Tage weg.
Ich habe dann logischerweise noch etwas herumgespielt: Es ist eigentlich egal, welche Änderungen ich an der ESX Konfig mache - nach einem Reboot sind sie weg... Selbst neue VMs verschwinden aus der Bestandsliste (Auf dem Datastore liegen sie aber noch)...
Hat da jemand eine Idee zu? Ich habe leider keine Ahnung, wo ich hingreifen soll und per google konnte ich bis jetzt auch nichts hilfreiches finden...
ich habe ein sehr spannendes Problem - mein ESXi 5 hat irgendwie keine Lust mehr, seine Konfig zu sichern...
Angefangen hats damit, dass ich vor ein paar Tagen die Management IP geändert habe... Gestern Abend reboot des Hosts und er kam nicht wieder hoch, die Autostart-VMs aber schon... Hat nen Moment gedauert, bis ich kapiert hatte, was los ist - aber wie sich herausstellte, waren alle Konfig-Änderungen der letzten paar Tage weg.
Ich habe dann logischerweise noch etwas herumgespielt: Es ist eigentlich egal, welche Änderungen ich an der ESX Konfig mache - nach einem Reboot sind sie weg... Selbst neue VMs verschwinden aus der Bestandsliste (Auf dem Datastore liegen sie aber noch)...
Hat da jemand eine Idee zu? Ich habe leider keine Ahnung, wo ich hingreifen soll und per google konnte ich bis jetzt auch nichts hilfreiches finden...
Ich dachte mal gehört zu haben, dass ein Host sobald er ein VM startet, im Order auf dem Datastore ein Lock-File anlegt, was verhindern soll, dass ein anderer Host die VM startet. Hab aber bei uns in den Datastores nichts gefunden, also KA ob das stimmt.
Ich blättere mal meine Bücher durch
Sinn macht es freilich nicht so etwas über eine VMDK zu lösen, da hast du schon Recht.
EDIT: VMFS übernimmt das locking
Danke übrigens für die ausführliche Antwort. Ich schreibe jetzt noch eine Anforderungen und dann mal schauen wann wir das Update anpacken.
@FlintX: Ihr nutzt nicht zufällig Autodeploy?
Zuletzt bearbeitet:
Nein... Bootet von USB...
Hm kann mir vorstellen, dass die Einstellungen nur im RAM liegen und nicht auf dem USB gespeichert werden.
Hab leider noch keinen ESXi auf einem USB-Stick laufen lassen, aber vll. hilft dir einer der Links weiter(falls du die noch nicht gefunden hast):
ESXi host losing settings at reboot – checking system partitions of ESX host | PS C:>(Get-Virtual).info
ESXi lost configuration on reboot - PowerEdge OS Forum - Servers - Dell Community
VMware Communities: ESXi lost configuration on reboot
Hab leider noch keinen ESXi auf einem USB-Stick laufen lassen, aber vll. hilft dir einer der Links weiter(falls du die noch nicht gefunden hast):
ESXi host losing settings at reboot – checking system partitions of ESX host | PS C:>(Get-Virtual).info
ESXi lost configuration on reboot - PowerEdge OS Forum - Servers - Dell Community
VMware Communities: ESXi lost configuration on reboot
Hey durchforste mal /var/log/messages ob du war von von einer "state,tgz" bzw "locale.tgz" findest:
Evtl. hat deine Kiste Probleme seine Konfig zu sichern bzw. wieder auszulesen.
Die Files werden in der ersten Minute nach einer vollen Stunde gesichert. Sollte also jetzt z.B. von 23:01 sein das File.
Zuletzt bearbeitet:
Merci! Dank eurer Tipps hab ich das Problem gelöst - es war genau so simpel wie dämlich...
Beim letzten Umbau hab ich den USB-Stick abgezogen, um ihn nicht versehentlich abzubrechen... Nachdem der Server am neuen Platz war, hab ich den Stick im "Blindfug" wieder hinten in den Kasten eingesteckt...
Wie es scheint kann der ESX über einen USB 3.0 Port booten - er erkennt aber nachher den Stick an dem Port nicht, die Filesysteme werden nicht gemountet und er kann dann logischerweise die Config nicht speichern...
Stick in den richtigen (USB 2.0) Steckplatz und alles läuft wie gewünscht...
Ohhhh man... Herr lass Hirn regnen... in diesem Sinne... Gute Nacht!
Beim letzten Umbau hab ich den USB-Stick abgezogen, um ihn nicht versehentlich abzubrechen... Nachdem der Server am neuen Platz war, hab ich den Stick im "Blindfug" wieder hinten in den Kasten eingesteckt...
Wie es scheint kann der ESX über einen USB 3.0 Port booten - er erkennt aber nachher den Stick an dem Port nicht, die Filesysteme werden nicht gemountet und er kann dann logischerweise die Config nicht speichern...
Stick in den richtigen (USB 2.0) Steckplatz und alles läuft wie gewünscht...
Ohhhh man... Herr lass Hirn regnen... in diesem Sinne... Gute Nacht!