ESX / ESXi - Hilfethread
- Ersteller XTaZY
- Erstellt am
Wenn denn alle Hosts vSphere 5 unterstützen würden... 
Der älteste Host (Fujitsu Primergy RX200S3) ist bis maximal ESX(i) 4.0 freigegeben, der soll aber demnächst ausgetauscht werden, dann wird das wohl auch alles auf vSphere 5 hochgezogen. Performancemäßig ist alles komplett im grünen Bereich, allerdings soll in einem anderen Gebäude auf dem selben Gelände ein weiterer Serverraum entstehen, wo dann ein neuer Host mit dicker Storage rein kommt, der notfalls alle virtuellen Maschinen übernehmen könnte. In dem Zuge wird der RX200S3 ausgemustert und der älteste Host ist dann ein RX200S4, der für ESXi 5.0 freigegeben ist.
Der älteste Host (Fujitsu Primergy RX200S3) ist bis maximal ESX(i) 4.0 freigegeben, der soll aber demnächst ausgetauscht werden, dann wird das wohl auch alles auf vSphere 5 hochgezogen. Performancemäßig ist alles komplett im grünen Bereich, allerdings soll in einem anderen Gebäude auf dem selben Gelände ein weiterer Serverraum entstehen, wo dann ein neuer Host mit dicker Storage rein kommt, der notfalls alle virtuellen Maschinen übernehmen könnte. In dem Zuge wird der RX200S3 ausgemustert und der älteste Host ist dann ein RX200S4, der für ESXi 5.0 freigegeben ist.
antilope114
Enthusiast
Habe einen PCIe Intel CT Desktop Adapter in meinen Server (s.u.) eingebaut (Intel 82574L Chipsatz). Wird von ESXi nicht erkannt. Mein Board (s.u.) hat einen ebensolchen Dual Port Adapter (auch 2x Intel 82574L) und die beiden werden bei Netzwerkadaptern gelistet. Wieso nicht der PCIe Adapter? Halte es für sehr unwahrscheinlich, dass er defekt ist.
Noiseless
Enthusiast
- Mitglied seit
- 05.07.2005
- Beiträge
- 1.441
Yeah, ich konnte auf meiner alten Gamingmaschine die meine Karte zu einer 9240i updaten. Über den vsphere Client habe ich die Karte sofort gefunden und durchgeschliffen. Im Client wird mir die Karte als Symbios Logic LSI2008 erkannt. Wenn ich jetzt allerdings dort eine neue Festplatte/LUN anlegen möchte, kann ich den Controller nicht auswählen. Das Feld bleibt einfach leer, als hätte ich keine Festplatte zur Verfügung. Auf dem Raidcontroller habe ich ein RAID1 erstellt.
Ich habe keine zusätzlichen Treiber oder so installiert. @esxi 5.0.0 Muss ich das machen obwohl der Controller richtig erkannt wurde?
Gruß noise!
Ich habe keine zusätzlichen Treiber oder so installiert. @esxi 5.0.0 Muss ich das machen obwohl der Controller richtig erkannt wurde?
Gruß noise!
antilope114
Enthusiast
Welches Betriebssystem denn? Nur weil ESXi die Karte erkennt heißt das noch nicht, dass das auch für das OS gilt
Bei Linux bzw. Unix basierten OS mit neuerem Kernel sollte das mit dem Controller z.B. kein Problem sein.
Zuletzt bearbeitet:
Hat der ESXi ja auch gar nicht, denn Du hast den Controller ja an eine virtuelle Maschine weitergegeben. Wenn dort die richtigen Treiber für den RAID-Controller installiert sind, wird die virtuelle Maschine das angeschlossene RAID 1 sehen.
antilope114
Enthusiast
Sobald du den Controller als Passthrough-device markiert hast steht er ESXi nicht mehr zur Verfügung - das ist ja der Sinn von passthrough (d.h. "Durchschleifen"). Der Controller gehört dediziert zu der VM, bei der du ihn als PCI Device hinzufügst.
Was willst du denn erreichen? Soll der Controller an eine vm durchgereicht werden und dann im ESXi über nfs oder iSCSI gemountet werden oder willst du die Platten direkt als datastore mounten? In letzterm Fall benötigst du kein passthrough!
Noiseless
Enthusiast
- Mitglied seit
- 05.07.2005
- Beiträge
- 1.441
Mhh, da stand ich mal wieder aufem Schlauch.
Ich habe jetzt einen RAID 1 an einen Windows 2k8 Server durchgereicht, aber ich bekomme gerade mal seq. 60MByte/s Lesen/Schreiben (ASSD) . Bei meiner zweiten Festplatte(non Raid) nicht durchgereicht. Da bin ich locker 94/90 Lesen/Schreiben MByte/s woran liegt denn das? Eigentlich sollte das doch genau umgekehrt sein oder?
Ich habe jetzt einen RAID 1 an einen Windows 2k8 Server durchgereicht, aber ich bekomme gerade mal seq. 60MByte/s Lesen/Schreiben (ASSD) . Bei meiner zweiten Festplatte(non Raid) nicht durchgereicht. Da bin ich locker 94/90 Lesen/Schreiben MByte/s woran liegt denn das? Eigentlich sollte das doch genau umgekehrt sein oder?
Hi,
kurze Zwischenfrage:
Möchte den esxi 5 in neue Hardware umziehen. Was geschieht dann mit den bestehenden Datastores? Aktuell sind auf fünf Platten Datastores mit Inhalt. Kann ich einfach das System aufsetzen und dann im VSphere Client über "Konfiguration->Speicher->Speicher hinzufügen" die vorhanden Stores hinzufügen? Oder werden dabei die Platten neu partitioniert?
Merci
kurze Zwischenfrage:
Möchte den esxi 5 in neue Hardware umziehen. Was geschieht dann mit den bestehenden Datastores? Aktuell sind auf fünf Platten Datastores mit Inhalt. Kann ich einfach das System aufsetzen und dann im VSphere Client über "Konfiguration->Speicher->Speicher hinzufügen" die vorhanden Stores hinzufügen? Oder werden dabei die Platten neu partitioniert?
Merci
Ich würde bei Install der neuen Hardware nur eine HDD (nämlich die, wo der ESXi installiert wird) in das System stecken... Dann die Install sauber durchdrücken und sauber booten.
Danach fährst die Kiste nochmal runter, schraubst die anderen HDDs um und bootest einfach den ESXi.
Normal sieht er die Platten selbst inkl. der Datastores und mountet diese automatisch. Wenn das nciht der Fall sein sollte, Datastore einfach händisch mounten.
Passieren kann da nix
Am besten dann noch das Filesystem auf die neueste VMFS Version migrieren, sofern noch nicht getätigt.
Schau mal nach den Hardware IDs, sprich der Vendor ID, die wird identisch sein und auf Intel zeigen, und der Device ID, welche mit 99,99% unterschiedlich sein wird, trotz anderem Namen.
Und da scheint deine Steckkarte eben nicht Treiberseitig beim ESXi dabei zu sein
Der Name sagt nix über die Hardware drunter aus.
Zuletzt bearbeitet:
antilope114
Enthusiast
Schau mal nach den Hardware IDs, sprich der Vendor ID, die wird identisch sein und auf Intel zeigen, und der Device ID, welche mit 99,99% unterschiedlich sein wird, trotz anderem Namen.
Und da scheint deine Steckkarte eben nicht Treiberseitig beim ESXi dabei zu sein
Aber der 82574L steht auf der ESXi HCL und da wird doch nicht nach Vendor ID unterschieden
Außerdem wird der hier auch erkannt http://www.heise.de/ct/hotline/VMware-ESXi-4-1-auf-dem-Selbstbau-Server-1128186.html
Zuletzt bearbeitet:
underclocker2k4
Mr. Alzheimer
Doch, das kann schon sein.
Treiber gehen nicht nach Hardwarenamen, sondern nach IDs, die sie von der HW bekommen. Passen diese Rückmeldungen der HW nicht zu den Treiberinfos, so ist der Treiber der Falsche, auch wenn er grundsätzlich funktionieren mag.
Treiber gehen nicht nach Hardwarenamen, sondern nach IDs, die sie von der HW bekommen. Passen diese Rückmeldungen der HW nicht zu den Treiberinfos, so ist der Treiber der Falsche, auch wenn er grundsätzlich funktionieren mag.
Wenn du, wie vorher beschrieben, kleiner Dateien überträgst wirst du die volle Bandbreite nicht erreichen. Wenn du mit großen Dateien(VMs, ISOs) die gewünschte Performance hast dann sollte doch eigentlich alles in Ordnung sein.
Btw. die Dateiübertragung über den vSphere Client ist generell etwas lahm; wenn du Dateien auf den Hypervisor übertragen willst würde ich eher über SCP gehen.
Hallo, hab hier ein Problem mit einem P410i Controller und 5 600er SAS Platten. Ich wollte eigentlich ein Radi 5 mit den Platten erstellen, das würde ein ca. 2,2TB großes Array ergeben. Also alles im Raid Controller konfiguriert und den ESXi 4.1 wieder gestartet, aber erkennt den Speicher nicht (siehe Screenshot). Wenn ich ein Raid mit nur 4 Platten erstelle wird alles erkannt und ich hab einen 1,64TB großen Datastore. Gibts beim Vsphere auch ein 2TB Limit, kann ich mir eigentlich nicht vorstellen
Zuletzt bearbeitet:
therealJMC
Enthusiast
- Mitglied seit
- 14.01.2010
- Beiträge
- 3.730
Jepp es gibt ein 2TB Limit
Also kannst du zwar eine 5-Disk Drivegroup erstellen, aber ein LV nur auf knapp 2TB kommen lassen...
Also kannst du zwar eine 5-Disk Drivegroup erstellen, aber ein LV nur auf knapp 2TB kommen lassen...
Das stimmt so nicht...
Wir haben hier jüngst FC LUNs im 5er Enterprise Plus ESXi gemoutet gehabt mit 2500GB Größe
Das geht.
Für gewöhnlich dürfte es keine Unterscheidung zwischen FC/iSCSI und internem Storage geben bei der Beschränkung.
Das größte Problem was ich aber sehe, der 4er ESX sieht idR dann das Volumen gar nciht mehr, sprich nichtmal 2TB sind nutzbar, es ist einfach weg... -> was sehr ärgerlich ist.
therealJMC
Enthusiast
- Mitglied seit
- 14.01.2010
- Beiträge
- 3.730
Oder was ich damals bei meinem ersten Versuch hatte: Nur der Bereich über 2TB war sichtbar und somit nutzbar... Waren in meinem Fall dann irgendwie 200GB von 2,2TB
Sumatrabarbe
Enthusiast
Hallo Profi's,
ich bin mal auf euren Hirnschmalz angewiesen
Folgende Situation: 4.1u2 DRS-HA-Cluster mit einem Ressourcenpool von 289 GHz und 3 TB RAM. Dem Pool sind 100 VM's zugewiesen. Auf dem Pool sind keine Reservierungen und auch keine Grenzwerte eingetragen.
Nun haben sich einige der Application-Betreuer gemeldet und angemeckert, dass ihre System gefühlt langsamer laufen als ihre Hardware Maschinen.
Jetzt haben wir mal durchgerechnet, wie viel MHz einer vCPU zur Verfügung stehen (Anteile sind alle auf Normal gesetzt und Pro vCPU gibt es 1000 Anteile).
Wir sind auf 1 GHz pro vCPU gekommen. Jetzt überlegen wir, wie wir diesen Wert erhöhen können, ohne der VM mehr vCPU's zu weisen zu müssen. Die Fragestellung dazu, was passiert wenn wir die Anteile einiger VM's erhöhen? Laut Pool sind z.Z 51 GHz belegt und auch 51 GHz Aktiv. Heißt ja theoretisch, es liegen über 200 GHz brach. Wie habt ihr das bei euch so gelöst? Hatten schon überlegt den betroffenen VM's Reservierungen zu geben, wäre dann aber für den Failover-Fall nicht so schön. Oder hab ich jetzt einfach nur einen Denkfehler und die CPU-Ressourcen werden doch noch genutzt, falls die VM sie wirklich braucht, egal wie viel Anteile ihr zugesprochen wurden?
lg
ich bin mal auf euren Hirnschmalz angewiesen
Folgende Situation: 4.1u2 DRS-HA-Cluster mit einem Ressourcenpool von 289 GHz und 3 TB RAM. Dem Pool sind 100 VM's zugewiesen. Auf dem Pool sind keine Reservierungen und auch keine Grenzwerte eingetragen.
Nun haben sich einige der Application-Betreuer gemeldet und angemeckert, dass ihre System gefühlt langsamer laufen als ihre Hardware Maschinen.
Jetzt haben wir mal durchgerechnet, wie viel MHz einer vCPU zur Verfügung stehen (Anteile sind alle auf Normal gesetzt und Pro vCPU gibt es 1000 Anteile).
Wir sind auf 1 GHz pro vCPU gekommen. Jetzt überlegen wir, wie wir diesen Wert erhöhen können, ohne der VM mehr vCPU's zu weisen zu müssen. Die Fragestellung dazu, was passiert wenn wir die Anteile einiger VM's erhöhen? Laut Pool sind z.Z 51 GHz belegt und auch 51 GHz Aktiv. Heißt ja theoretisch, es liegen über 200 GHz brach. Wie habt ihr das bei euch so gelöst? Hatten schon überlegt den betroffenen VM's Reservierungen zu geben, wäre dann aber für den Failover-Fall nicht so schön. Oder hab ich jetzt einfach nur einen Denkfehler und die CPU-Ressourcen werden doch noch genutzt, falls die VM sie wirklich braucht, egal wie viel Anteile ihr zugesprochen wurden?
lg
Das stimmt so nicht...
Wir haben hier jüngst FC LUNs im 5er Enterprise Plus ESXi gemoutet gehabt mit 2500GB Größe
Das geht.
Für gewöhnlich dürfte es keine Unterscheidung zwischen FC/iSCSI und internem Storage geben bei der Beschränkung.
Das größte Problem was ich aber sehe, der 4er ESX sieht idR dann das Volumen gar nciht mehr, sprich nichtmal 2TB sind nutzbar, es ist einfach weg... -> was sehr ärgerlich ist.
Habt ihr die Luns dann mit VMFS formatiert und waren dann auch 2,5TB nutzbar?
Hallo Profi's,
ich bin mal auf euren Hirnschmalz angewiesen
Folgende Situation: 4.1u2 DRS-HA-Cluster mit einem Ressourcenpool von 289 GHz und 3 TB RAM. Dem Pool sind 100 VM's zugewiesen. Auf dem Pool sind keine Reservierungen und auch keine Grenzwerte eingetragen.
Nun haben sich einige der Application-Betreuer gemeldet und angemeckert, dass ihre System gefühlt langsamer laufen als ihre Hardware Maschinen.
Jetzt haben wir mal durchgerechnet, wie viel MHz einer vCPU zur Verfügung stehen (Anteile sind alle auf Normal gesetzt und Pro vCPU gibt es 1000 Anteile).
Wir sind auf 1 GHz pro vCPU gekommen. Jetzt überlegen wir, wie wir diesen Wert erhöhen können, ohne der VM mehr vCPU's zu weisen zu müssen. Die Fragestellung dazu, was passiert wenn wir die Anteile einiger VM's erhöhen? Laut Pool sind z.Z 51 GHz belegt und auch 51 GHz Aktiv. Heißt ja theoretisch, es liegen über 200 GHz brach. Wie habt ihr das bei euch so gelöst? Hatten schon überlegt den betroffenen VM's Reservierungen zu geben, wäre dann aber für den Failover-Fall nicht so schön. Oder hab ich jetzt einfach nur einen Denkfehler und die CPU-Ressourcen werden doch noch genutzt, falls die VM sie wirklich braucht, egal wie viel Anteile ihr zugesprochen wurden?
lg
Habt ihr euch mal die Performance Charts bzw. via ESXTOP auf dem Host, der betroffenen VMs (und der Hosts) angesehen, ob diese wirklich ausreichend vCPUs haben? Checkt mal die CPU READY time, die besagt, dass die VM gerne CPU Cycles hätte aber keine bekommt. Hohe RDY time = schlecht!!
CPU Power habe ich noch nie als limitierenden Faktor live gesehen. Habt ihr euch bei der Menge an VMs Gedanken um einen ordentlichen Storage Backend/SAN gemacht? Checkt auch hier mal die Latenzen und Queues der Datastores, nicht das es evtl. hier klemmt!
Ggf. die Shares einiger wichtiger VMs hochdrehen. Das heißt, dass diese VMs beim Kampf um Resources bevorzugt werden und eher CPU Cycles bekommen.
---------- Post added at 21:34 ---------- Previous post was at 21:23 ----------
Nö, VMFS 5 Datastores können nun auch 64 TB sein!
http://www.vmware.com/pdf/vsphere5/r50/vsphere-50-configuration-maximums.pdf
Zuletzt bearbeitet:
Sumatrabarbe
Enthusiast
So,
SAN-Storage ist definitiv nicht der limitierende Faktor, im Einsatz ist ein Eternus DX8700. Wenn man sich die Performance-Charts der VM's anschaut, sieht man je nach Uhrzeit 70-80% CPU Usage. Läuft also eigentlich nicht gegen den Poller. Das mit der Ready Time ist nochmal eine gute Idee, das werde ich mal beobachten. Danke für den Tipp! Parallel kommen nächste Woche noch 2 neue Trägersysteme, da werden wir dann zum Check mal ein paar der VM's exklusiv laufen lassen, um auszuschließen das es an der virtuellen Umgebung liegt.
SAN-Storage ist definitiv nicht der limitierende Faktor, im Einsatz ist ein Eternus DX8700. Wenn man sich die Performance-Charts der VM's anschaut, sieht man je nach Uhrzeit 70-80% CPU Usage. Läuft also eigentlich nicht gegen den Poller. Das mit der Ready Time ist nochmal eine gute Idee, das werde ich mal beobachten. Danke für den Tipp! Parallel kommen nächste Woche noch 2 neue Trägersysteme, da werden wir dann zum Check mal ein paar der VM's exklusiv laufen lassen, um auszuschließen das es an der virtuellen Umgebung liegt.
Naja, die Performance-Charts sind ja nicht allzu genau, was die zeitliche Auflösung betrifft, da wird immer über einen gewissen Zeitraum gemittelt. Wenn da dann 70-80% CPU-Usage auftaucht, kann die betreffende virtuelle Maschine ruhig einen Kern mehr bekommen, wenn nicht sogar zwei.
Habe ein Porblem mit der Installation von VMware ESXI 5.0. Es lädt alles normal, doch dann erhalte ich den fehler "Trying to get a vail VMKerne MAC Adress". Wie kann ich das Lösen?
Mein System: Mainboard Saphire Fusion Mini e350, 2GB ram.
Hat mir jemand eine Lösung?
Mein System: Mainboard Saphire Fusion Mini e350, 2GB ram.
Hat mir jemand eine Lösung?
Zuletzt bearbeitet:
Hallo Profi's,
ich bin mal auf euren Hirnschmalz angewiesen
Folgende Situation: 4.1u2 DRS-HA-Cluster mit einem Ressourcenpool von 289 GHz und 3 TB RAM. Dem Pool sind 100 VM's zugewiesen. Auf dem Pool sind keine Reservierungen und auch keine Grenzwerte eingetragen.
Nun haben sich einige der Application-Betreuer gemeldet und angemeckert, dass ihre System gefühlt langsamer laufen als ihre Hardware Maschinen.
Jetzt haben wir mal durchgerechnet, wie viel MHz einer vCPU zur Verfügung stehen (Anteile sind alle auf Normal gesetzt und Pro vCPU gibt es 1000 Anteile).
Wir sind auf 1 GHz pro vCPU gekommen. Jetzt überlegen wir, wie wir diesen Wert erhöhen können, ohne der VM mehr vCPU's zu weisen zu müssen. Die Fragestellung dazu, was passiert wenn wir die Anteile einiger VM's erhöhen? Laut Pool sind z.Z 51 GHz belegt und auch 51 GHz Aktiv. Heißt ja theoretisch, es liegen über 200 GHz brach. Wie habt ihr das bei euch so gelöst? Hatten schon überlegt den betroffenen VM's Reservierungen zu geben, wäre dann aber für den Failover-Fall nicht so schön. Oder hab ich jetzt einfach nur einen Denkfehler und die CPU-Ressourcen werden doch noch genutzt, falls die VM sie wirklich braucht, egal wie viel Anteile ihr zugesprochen wurden?
lg
Um wie viele Hosts geht es denn im konkreten!?
Wir fahren beispielsweise auf Arbeit vier Dual Hexacore Intel Nehalem Maschinen mit jeweils 64GB RAM. Und dort liegen aktuell ~105VMs drauf. Als SAN kommen drei NetApps FAS 3040 zum Einsatz. Jeweils mit vier Shelfs vollbestückt mit 300GB 10k SAS Platten.
Der RAM wird langsam knapp, CPU technisch ist aber lange kein Ende in Sicht. Was aber massiv bremst bzw. bremsen kann, ist das Storage...
Wenn du schreibst, 289GHz, da ist das mal locker doppelt so viel, wie unsere Hosts auf der Arbeit. Je nachdem, was für VMs da drauf tuckern.
Das Problem ist, man kann hier pauschal eigentlich nicht so mir nix dir nix eine Aussage treffen.
Eine VM, welche vier vCPUs zugewiesen hat, kann diese auf voll belegen. Und je nach verfügbarer Rechenressourcen sind diese nicht spürbar langsamer, als ein adequater physischer Host mit gleicher CPU Power. Das gleiche gilt für den RAM (wobei hier virtualisierungsbedingt der RAM Speed logisch geshared ist)
Wenn sich also die Leute beschweren, dann muss da irgendwo der Wurm drin sein
Die Frage ist, wo?
Wie schaut denn die Host Auslastung im RAM und CPU aus?
Sind die VMs so verteilt, das die Hosts möglichst gleich ausgelastet sind?
Eventuell wichtig ist zu wissen. Die 4.1er Version kann offiziell noch nicht vCPUs in Cores und CPUs unterscheiden. Das geht mittels Trick über einen Parameter in den vmx Files.
Problematisch könnte nämlich sein, je nach Hostmaschine und zugewiesener vCPU Zahl beziehen VMs unter Umständen ihre Ressourcen von verschiedenen NUMA Nodes. Das heist, vCPU0 liegt beispielsweise auf Core0 CPU0 und vCPU1 liegt auf Core0 CPU1. Die Kommunikation untereinander und auch das Austauschen der gecachten Daten in der CPU erfolgt über den Interconnect zwischen den CPUs, bzw. bei älteren Systemen über den FSB. Was erhelbliche Leistungseinbußen zur Folge hat.
Workarroundtechnisch hat sich bei mir bewährt der VM maximal so viele vCPUs zu geben, wie es Cores an einem Stück in der CPU gibt. Das heist, bei S771 Intel Xeon CPUs sind das maximal zwei vCPUs (ein Quadcore Xeon besteht aus zwei Dualcore DIEs über den FSB verbunden), bei Nehalem Xeons wären das vier vCPUs bzw. sechs vCPUs, wenn Hexacores zum Einsatz kommen.
Sandy-E E5 Xeons können mit bis zu acht vCPUs dort Punken.
Dazu sollte man drauf aufpassen, das nur so viele Maschinen auf einem Host tuckern, das sich dieses Prinzip nicht massiv überbucht.
Euer Problem könnte aber auch ein ganz anderes sein, nämlich das die Anwendungen in der VM für kurze Zeit die Rechenpower auch wirklich abfordern, was zur Folge hat, das diese Langzeit Statistiken zur Auslastungen nichts taugen, weil eben die Spitzen nicht sichbar sind. Und genau diese Spitzen fallen den Kollegen auf, weil diese von Zeit zu Zeit immer mehr gedeckelt werden.
IdR braucht man dort in meinen Augen nicht mit Reservierungen arbeiten, das braucht man nur, wenn man wirklich so viele Maschinen hat, die viele Ressourcen brauchen, und diese eben ungünstigerweise teils zeitgleich ins Limit eines Hosts laufen.
Wenn du 12 physische CPU Kerne hast, und sagen wir sechs VMs mit je vier vCPUs hast, und diese alle in Summe zur gleichen Zeit mal Volllast wollen, dann geht der Host zweifelsfrei in die Knie
Hier kannst du entweder reservieren (was aber nur ein verschieben der Ressourcen ist, schneller wirds dann da nicht in Summe) oder aber du verteilst die VMs so auf die Hosts, das eben die Hosts die gleichzeitig die Last erzeugen nicht in der Lage sind, ihren drunter liegenden Host in die Ecke zu fahren.
Ja, es war VMFS5. ESXi5 in der neuesten Version.
Wobei ich ehrlich gesagt nicht genau weis, wie sich das verhält, wenn man wirklich das LUN mit größer 2TB versucht zu mappen.
Wir haben unser LUN für den Test VDR 2.0.1 von 2TB auf 2,5TB angehoben, und das ging im Lifebetrieb
Grund dafür war, unser Monitoringsystem hat wegen des Füllstand des Datastores gemeckert, weil die LUN eben quasi Randvoll war mit der vmdk für den VDR.
Mittlerweile ist aber einiges klarer. VDR verträgt sich nicht so richtig mit Volumes größer 1TB. Wir fahren nun 950GB vmdks für die Backups auf dem Backup NAS und nutzen dafür mehrere VDRs um die Kapazität in Summe bereit zu stellen. Das passt aber soweit. Wenn auch es sich etwas umständlich erscheint, weil es keine VDR Übergreifende Konsole gibt und man eben die Fenster händisch vergleichen muss.
Zuletzt bearbeitet: