ESX / ESXi - Hilfethread

Aber das geht doch garnicht in dem Fall? Die Exchange VM hat 900GB Fat, der Datastore hat 930GB, nimmt man noch das Speicher-File dazu (16GB) bleibt da doch eigentlich so gut wie kein Platz für ne andere VM ;)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wie sind denn die 2 esx netzwerktechnisch verbunden?

Beide im selben Netz.

Falls du mal einen Snapshot machst kann es halt sein das dir der Datastore voll läuft und die VMs die in diesem Datastore liegen stehen bleiben.

Snapshots mache ich beim Exchange ja keine.

Aber das geht doch garnicht in dem Fall? Die Exchange VM hat 900GB Fat, der Datastore hat 930GB, nimmt man noch das Speicher-File dazu (16GB) bleibt da doch eigentlich so gut wie kein Platz für ne andere VM ;)

Hmm...ja, das befürchte ich auch. Ist unglücklich dass ich die VM bei Exchange so groß gemacht habe. Dann kauf ich eventuell neue Platten und mach nen neuen Datastore.


VG
 
Zuletzt bearbeitet:
Das habe ich auch zuerst befürchtet, aber die Maschine ist auf dem Screenshot doch schon eingeschaltet und dementsprechend die Swapfile schon erstellt, sollte also passen. Sonst nochmal im Datastore Browsen und alles zusammenzählen.

Würde dem Datastore trotzdem Speicherplatz hinzufügen!, der läuft dir mit der Zeit voll, laufen ja bestimmt auch die Logs und Dumps drauf?
 
Kann mir einer sagen, ob ein MS-FailoverCluster bzw. ein RDM mit einem SAS SAN (HP P2000) funktioniert UND Supported ist? Auf Vmware seite muss man wohl unter den advanced configs einen haken setzen bzw. rausnehmen, weil das SAS SAN nicht als shared Storage erkannt wird. Aber ich finde auf Seiten MS nur Angaben zu FC SANs für einen Cluster?! :-[

Was meinst du mit MS FailoverCluster?
Meinst du damit die Clusterfunktionalitäten von Windows OSen? Wenn ja, dann musst du wohl auf VMware Seite sogut wie gar nix machen...
Denn die Clusterfunktionen kommen vom Gast OS in den VMs.

Willst du hingegen die Failover Funktionen von VMware nutzen, brauchst du ein shared storage. Normal sollte das auch mit SAS Storages gehen... Die müssen nur eben so konfiguriert sein, das mehrere Hosts auf ein und das selbe Storage zugreifen können. Oftmals sind bei den Kisten zwar zwei Controller verbaut mit dann auch genügend Ports, aber die Raidgruppen werden bei einfachen Geräten normal nur von einem Controller gehalten. Die Controller selbst arbeiten im Active/Standby Mode... Nicht im Active/Active Mode.
-> das könnte potentiell ein Problem sein.

Aber wie gesagt, mich wundert das MS vor FailoverCluster!?

Anbei ein Screenshot aus dem vSphere Client zur Speichernutzung der Exchange-VM. Der Datastore auf dem Zielhost hat total 930GB. Das sollte dann grad so passen. Ist das problematisch wenn der Datastore an der Kapazitätsgrenze läuft?

Die Performance wird ein Stückweit langsamer, wenn die HDDs voll sind. Wie viel, kann ich aber nicht benennen...
Ansonsten bleibt die Snapshot Problematik. Es müssen ja nicht Snapshots im laufenden Betreib sein. Ist die VM aus, bekommt man auf definitiv einen konstistenten Snapshot hin. -> der auch Rückspielbar ist. Zwar immernoch mit dem Problem der fehlenden Mails die in der Zeit zwischen Snapshot erstellung und Rückspielung reinkommen, aber das könnte ggf. verschmerzbar sein. Denn wenn die Kiste ganz um ist, sind sie auch weg! ;)
 
Also einen Exchange zu snapen und wieder zurück zu spielen würde ich nur dann wagen, wenn wirklich nix anderes mehr geht.
 
Also kommt auf die Snapshots an :)

Wir machen zb Snapshots auf Netapp Basis mit Exchange Snapmanager damit kann ich sogar einzelne Emails wiederherstellen.
 
Das hat aber nix mit Snapshots der VM zu tun sondern läuft innerhalb der Maschine in Verbindung mit der Netapp :)
 
Das würd ich so niemanden unterstellen wollen, es heisst halt alles "Snap" - wir hatten das als wir noch Netapp hatten auch mit dem SQL Server so, jetzt wo wir IBM Streched Cluster haben ists halt nicht SnapManager sondern FlashCopyManager... Aber das macht nunmal kein Snapshot der Maschine.

Es ist halt möglich das so bis aufs feinste zu machen weil es auf Storage-Ebene arbeitet und die Systeme darübr nicht allzuviel davon mitbekommen, ausser grob gesagt: "VSS EVENT! Bitte mal konsistenten Zustand erstellen!" - das ist ja der große Vorteil davon. Zum wirklichen Backup würde ich das aber persönlich nicht einsetzen weils immer noch auf dem gleichen Storage liegt. Wir hatten und haben das nur für regelmäßige (15 minütige) Snaps des SQL Servers wenn da was verbastelt wird im Tagesverlauf...
 
War ja nicht so gemeint.
Klar, es heißt alles Snap. Und VMWare hat Begriff wohl auch nicht erfunden ^^

Es gibt viele Lösungen die auf Storage-Ebene laufen und die VMs bekommen davon nix mit (z.B. DataCore).
 
Wo habe ich was von VMware Snapshots geschrieben ???

@ LaMagra-x

Danke aber ich muss hier im Forum nicht ständig nach ESXi oder Exchange Administration fragen *zwinker*

@therealJMC

Wir haben Snapmanager für Exchange sowie für alle 4 SQL Server und zusätzlich wird alles täglich noch mit Backuptodisk auf Backupserver gesichert und am WE auf Band.
 
Wobei der NetApp Snapmanager oder wie sich das Dingens genau schimpft, dennoch glaube ich nen Snapshot der VM selbst erstellt. Denn den benötigt es soweit mir bekannt um die Daten auf Storage Seite ebenso einfrieren zu können. Denn das Problem ist, geht nur ein Event in die VM zum Gast OS selbst, so weis der ESXi ja immer noch nicht, in welchen Datenbereichen auf dem Storage nun die Daten stehen. -> aber das muss der ESXi wissen, denn er ist das Bindeglied zwischen Snapmanager und dem Storage...

Muss aber dazu sagen, ich hatte mich seinerzeit nur kurz in der Theorie mit den NetApp Backup Mitteln beschäftigt... Denn die Einrichtung ist irgendwie grausam.
 
Zuletzt bearbeitet:
Muss aber dazu sagen, ich hatte mich seinerzeit nur kurz in der Theorie mit den NetApp Backup Mitteln beschäftigt... Denn die Einrichtung ist irgendwie grausam.


Das stimmt leider aber wenn es mal läuft ist das eine schöne Sache gerade wenn Leute mal wieder Emails gelöscht haben oder Daten vom CIFS :)
 
Wie sind denn die 2 esx netzwerktechnisch verbunden?
Beide im selben Netz.

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
 
Das stimmt leider aber wenn es mal läuft ist das eine schöne Sache gerade wenn Leute mal wieder Emails gelöscht haben oder Daten vom CIFS :)

Und wie läuft das dann praktisch ab? Revert to Snapshot und die VM dann in einem gesicherten Bereich mounten und das Postfach einbinden? Oder geht das richtig auf Exchange-Ebene?

PS: Zur Exchange Administration direkt frage ich hier ja nicht *zwinker*
 
Zuletzt bearbeitet:
Snapshot wird am Backupserver gemountet danach kann ich mit dem Programm "Single Mailbox Recovery" von Netapp mir die Source und Target holen und per drag und drop die Emails wiederherstellen :)

Geht sehr gut und schnell :)

Ist halt ein größerer Aufwand bis alles mal sauber eingerichtet ist und gab da am Anfang auch Probleme da wird ein etwas komplizierteren Exchange Aufbau haben.
 
also wir nutzen seit neuestem das Asigra Backup für unsere VMs und auch den Exchange und damit kann man aus ner VM auch auf Fileebene Dateien wiederherstellen - sehr nett das ganze ;)
 
Wobei das bei Netapp irgendwie immer nach "komplizierter Aufbau bei Ihnen" klingt. Hier wurde der Snapmanager für SQL installiert, hat aber nach kauf 1,5 jahre gedauert eh er wirklich lief. Erst lags daran, dass der Volltextindex zu den Datenbanken auf einem anderen Volume lag, dann lags daran, dass irgendwas anderes war, dann lags an Server 2008 und DANN lags daran, dass es 64bit war. Muss wohl ein Abenteuer gewesen sein :d
 
Das hat aber nix mit Snapshots der VM zu tun sondern läuft innerhalb der Maschine in Verbindung mit der Netapp :)

Naja, wenn du den Exchange virtualisiert hast musst du natürlich auch noch die VM irgendwie auf der NetApp snapshoten. Der SnapManager for Exchange sorgt da nur für konsitente Snapshots des Exchange.
Was die Anzahl der Tools zum Backup angeht spielt NetApp ganz oben mit. :d

Das stimmt leider aber wenn es mal läuft ist das eine schöne Sache gerade wenn Leute mal wieder Emails gelöscht haben oder Daten vom CIFS :)

Man sollte danach aber nicht mehr versuchen was zu ändern. Das gibt auch gerne mal Probelme. Die Tools von NetApp sind da manchmal etwas zickig. *g*
Wenn du CIFS von der NetApp direkt nutzt hast du ja immerhin auch die Möglichkeit das die User sich die Dateien selbst wiederherstellen.
 
Man sollte danach aber nicht mehr versuchen was zu ändern. Das gibt auch gerne mal Probelme. Die Tools von NetApp sind da manchmal etwas zickig. *g*
Wenn du CIFS von der NetApp direkt nutzt hast du ja immerhin auch die Möglichkeit das die User sich die Dateien selbst wiederherstellen.


Ja aber nicht unsere User :) das sind Beamte und Angestellte usw da wurde am Anfang gleich mal die falschen Dateien überschrieben deswegen ist das bei uns abgeschaltet und wir machen das lieber selber :)
 
Naja, wenn du den Exchange virtualisiert hast musst du natürlich auch noch die VM irgendwie auf der NetApp snapshoten. Der SnapManager for Exchange sorgt da nur für konsitente Snapshots des Exchange.
Was die Anzahl der Tools zum Backup angeht spielt NetApp ganz oben mit. :d

Jupp, so sehe ich das auch... Normal müsste der ESXi nen Snapshot auf dem Datastore anlegen... Welcher dann sogar via SnapManager konsistent ist und welchen man dann sogar vollständig wiederherstellen könnte. Der ESXi schreibt die Daten, die geändert werden dann soweit mir bekannt im Snapshot weiter und nach dem ganzen Prozess wird der Spaß wieder zusammen geführt.
Also quasi ähnliches Verfahren wie VCB oder VDR, nur eben, das die NetApp gleich intern die Daten aus dem Snapshot wegsichern kann via SnapMirror/SnapVault -> was deutlich schneller ist.
 
Jupp, so sehe ich das auch... Normal müsste der ESXi nen Snapshot auf dem Datastore anlegen... Welcher dann sogar via SnapManager konsistent ist und welchen man dann sogar vollständig wiederherstellen könnte. Der ESXi schreibt die Daten, die geändert werden dann soweit mir bekannt im Snapshot weiter und nach dem ganzen Prozess wird der Spaß wieder zusammen geführt.
Also quasi ähnliches Verfahren wie VCB oder VDR, nur eben, das die NetApp gleich intern die Daten aus dem Snapshot wegsichern kann via SnapMirror/SnapVault -> was deutlich schneller ist.

Genauso funktioniert das auch bei der NetApp. Nur das den SnapManager nicht direkt vaulten oder mirrorn kann. Dafür braucht man dann wieder ein anderes Tool oder Skript.
Man hat eben viele, viele kleine Tools im Einsatz. *g*
 
Hallo zusammen.
Ich habe ein Problem mit einem Server und ESXi 5 Update 1.

Im BIOS des Servers ist jetzt 16.00 Uhr eingestellt. Im ESXi ist aber 18.00 Uhr eingestellt.

Wenn ich nun den ESXi auch auf 16.00 Uhr stelle, stellt es das BIOS der Hardware ebenfalls um 2 Stunden zurück.

Wie kann ich nun dem ESXi die richtige Serverzeit verpassen?

Grüße
 
via NTP...

Mal ganz davon ab, wie stellst du die Zeit ein?
Über den vSphere Client? -> denn der operiert mit dem Offset der Zeitzone von der Windows Installation, von der er aus gestartet wird.
 
Ich hab die Zeit ja bisher nicht eingestellt, weil es nicht nötig war. Denn der ESXi hatte ja bisher die BIOS Zeit.

Nun hat er 2 Stunden Versatz. Und wie gesagt, wenn ich das im vSphere unter "Uhrzeit" ändere, wird das BIOS auch umgestellt. Und die VMs haben dann auch entsprechend eine falsche Zeit.

Deswegen meine Frage hier.

VG
 
Zeitzonen gibts nicht umsonst. Das BIOS sollte immer in UTC laufen und das OS die Zeitzone verwalten.
 
viel wichtiger ist, das man die VMs auch per NTP mit Zeit versorgt und nicht über die vmware tools die host zeit synct ;)
 
Ich hab die Zeit ja bisher nicht eingestellt, weil es nicht nötig war. Denn der ESXi hatte ja bisher die BIOS Zeit.

Nun hat er 2 Stunden Versatz. Und wie gesagt, wenn ich das im vSphere unter "Uhrzeit" ändere, wird das BIOS auch umgestellt. Und die VMs haben dann auch entsprechend eine falsche Zeit.

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.
 
Hat hier schon jemand Praxiserfahrungen mit SSDs im ESXi 5.1?
Bin gerade am überlegen ob ich mir 2x 1 TB Velocis rein stecken soll oder lieber 2x 512 GB SSDs, da käme für mich preislich die Samsung 840 Basic in Frage, die Pro ist mir eigentlich gerade etwas zu teuer.
Die würden dann am Fujitsu (LSI) SAS 2 Controller im RAID 1 laufen.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh