Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

Konstant Daten schreiben - was geht schief

Alles zum Thema vSphere 6, ESXi 6.0 und vCenter Server.

Moderatoren: irix, continuum, Dayworker

Member
Beiträge: 13
Registriert: 05.03.2017, 23:25

Konstant Daten schreiben - was geht schief

Beitragvon sleepless » 06.03.2017, 13:17

Hallo ihr,

ich habe ein Problem, das mir dauerhaft eine Platte am rödeln ist, obwohl alles im idle läuft. Bevor ich um Hilfe schreie, beschreibe ich meine Situation genauerer.

Also:
Ich habe eine Migration & Erweiterung meines RAID 5 durchgeführt. Nachdem aus 3x1TB schrott-Fesplatten 4x4TB Enterprise Platten wurden ist nun das Problem, das nur eine einzige Platte am rödeln ist und die restlichen halt nur bei einem Aufruf.

Es ist genau die Platte, die ich später zum erweitern des Raid 5 genommen habe. Also 3x4TB und dann diese 4TB dazu.

Um ein defekten Raid Controller (HP SmartArray P420) auszuschließen nenne ich ein Grund:
Sobald sämtliche VM's ausgeschaltet sind, ist ruhe.
Schalte ich auch nur irgendeine der Maschinen wieder ein, geht's wieder munter weiter.

Hat dort einer eine Idee?
Ist Esxi falsch geconft? Kann man daran etwas drehen?

Fakt ist: Egal welche VM ich von 6 vorhandenen starte, sobald eine eingeschaltet wird, geht's los und hört net wieder auf. Das schließt jetzt aus, das die VM selbst das Ärgernis verursacht. Und es ist auch nur eine (!?????) Platte aus dem Raid 5. Die mit dem das Raid 5 erweitert worden ist.

Bitte nennt alles - sei es noch eine so "schräge" Idee.

Gruß & Danke

Guru
Beiträge: 2519
Registriert: 23.02.2012, 12:26

Re: Konstant Daten schreiben - was geht schief

Beitragvon ~thc » 06.03.2017, 13:29

Sind das 512e oder 4K-Platten und kann der Controller damit umgehen?
Wie genau hast du den Tausch und die Erweiterung durchgeführt?
Erste Anlaufstelle ist das Eventlog des Controllers - da sollte etwas zu finden sein.

Experte
Beiträge: 1776
Registriert: 04.10.2011, 14:06

Re: Konstant Daten schreiben - was geht schief

Beitragvon JustMe » 06.03.2017, 14:16

Wie sieht es denn aus, wenn bei ausgeschalteten VMs einfach nur Daten auf den Datastore geschrieben werden?

Wurde nach dem Hinzufuegen der vierten 4TB-Platte zum vorhandenen Array aus 3x 4TB ein "Resync" (in diesem Falle: Neusortieren der Daten- und Redundanz-Bloecke) des vergroesserten Arrays beobachtet? Duerfte nicht unter 1 Tag gedauert haben...

Was sagt HP als Controller-Hersteller dazu?

Profi
Beiträge: 858
Registriert: 18.03.2005, 14:05
Wohnort: Ludwigshafen

Re: Konstant Daten schreiben - was geht schief

Beitragvon Martin » 06.03.2017, 14:48

Wurde vielleicht beim Hinzufügen die schnelle bzw. Hintergrund-Initialisierung gewählt?
Dann ist der Controller einfach noch dabei, die Checksummen und Datenblöcke auf die neue Platte zu verteilen.

(Edit: man sollte sich nicht zu lange Zeit zum Antworten nehmen, sonst schreibt jeman anderes schnelle das gleiche... ;))

King of the Hill
Beiträge: 13319
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: Konstant Daten schreiben - was geht schief

Beitragvon Dayworker » 06.03.2017, 15:16

Neben dem bereits gesagten zur Schnell-/Hintergrundinitialisierung, stellt sich mir gerade die Frage, wieso man ein ideal performendes Raid5 aus drei Platten ein weniger performantes Verhalten aufzwingt und eine vierte Platte verbaut. Platztechnisch mag das ja ein Zugewinn sein, aber das war es dann auch schon. Je nach Grösse der zu schreibenden Daten lassen sich diese nicht in einem Rutsch auf die 3 Platten plus Parity aufteilen und müssen dann in 2 Anforderungen sowie Parityberechnung weggeschrieben werden.

Member
Beiträge: 13
Registriert: 05.03.2017, 23:25

Re: Konstant Daten schreiben - was geht schief

Beitragvon sleepless » 06.03.2017, 18:00

Hui, bin selten so schnell antworten gewöhnt. :grin:

Also, verbaut sind 2x seagate Ironwolf und 2x WD Red -> alles 4TB / 5xxx Upm

Meine vorgehensweise:
Eine 4TB in den noch freien einschub des Microservers Gen8 reingesopft -> neues Array -> alle Daten vom Raid 5 auf diese Kopiert.
Dann Raid 5 raus und 3 neue 4TB rein -> Raid 5 erstellt -> und innerhalb der nächsten 5min das endlose Rückkopieren von der einzelnen Platte gestartet.
Danach dann das 1er Array gelöscht -> Die freie Platte dem bestehenden Raid 5 hinzugefügt -> 1-2 VM's gestartet und dann die Transformation abgewartet.
Ende der Trafo -> Array erweitert -> VMFS erweitert und alle VM's hochgefahren.
Nun nach 2 Tagen meldet der Controller den Abschluss der Paritätserstellung.

Heute - weitere 2,5 Tage nach der Paritätsfinishmeldung - rödelt der Bock aber immer noch - auf einer Platte. Die anderen zucken mal zwischendurch, aber das ist ja normal.

Dann heute noch auf esxi 6.5 geupgraded und nichts neues zu berichten - außer das ich nun sehen kann, was bei den Festplatten vorgeht.
Dabei ist mir etwas aufgefallen: Der Bursche zeigt mir die Latenz an - und ich frage mich, wie er das ermittelt.
Indem er laufend kleine Mistdateien schreibt/liest???
(Siehe Bild)

Was ist mit der Hintergrundinitialisierung genau gemeint?
Soweit ich mich erinnere, hatte ich diese aktiviert, weil ich sonst - so meine ich in der Controller warnung gelesen zu haben - das Array erst mal nicht zur Verfügung steht, sondern erst, wenn das durch ist.
Oder betraf das die Paritätserstellung??? WTF, weiß nicht mehr genau.

Und wie lang kann denn bei der "Auslastung" meiner Platten die Initialisierung dauern? Der ist doch sicher schon seid mehr 3-4 Tagen dabei...
Dateianhänge
festplatte.jpg

King of the Hill
Beiträge: 13319
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: Konstant Daten schreiben - was geht schief

Beitragvon Dayworker » 06.03.2017, 19:08

Ich vermute mal, daß ihn die 4 Platten deutlich länger beschäftigen und auch der Controller damit seine liebe Not hat. Raid5 fühlt sich am wohlsten mit 3, 5 oder 9 Platten an. Die übliche Blocksize dürfte fast unabhängig vom OS wohl 4KB sein und wie willst du die performant auf 3 Datenplatten plus Parity verteilen?

Die Frage ist sowieso, ob man bei den Plattengrössen heutzutage überhaupt noch auf Raid5 setzen sollte...

Guru
Beiträge: 2519
Registriert: 23.02.2012, 12:26

Re: Konstant Daten schreiben - was geht schief

Beitragvon ~thc » 06.03.2017, 19:58

Ich halte RAID5 für einen guten Kompromiss in kleineren Betrieben bei nicht zu vielen Platten. Das es "magic numbers" beim RAID5 gibt, ist mir persönlich neu - gibt es da Literatur? Da der Standard-Strip-Size bei RAIDs oft 64 kB ist, muss der Controller sowieso immer X mal 64 kB schreiben - auch wenn man nur 1 Bit ändert.

Dabei ist mir etwas aufgefallen: Der Bursche zeigt mir die Latenz an - und ich frage mich, wie er das ermittelt.
Indem er laufend kleine Mistdateien schreibt/liest???

Nein, die wird bei den normalen Disk-I/O-Vorgängen ermittelt.
Was ist mit der Hintergrundinitialisierung genau gemeint?

Wie du vermutest, dass das RAID schon zur Verfügung steht, wenn die Initialisierung noch läuft.

Und was sagt das Eventlog des Controllers?

Member
Beiträge: 13
Registriert: 05.03.2017, 23:25

Re: Konstant Daten schreiben - was geht schief

Beitragvon sleepless » 06.03.2017, 23:54

Wo finde ich den Eventlog des Controllers? In der Weboberfläche bei 6.5?

Hab sowas schon bei 6.0 nicht gefunden... Also, weder im Client noch jetzt bei der 6.5 Weboberfläche... Logs ja, aber nichts vom Controller...

Lediglich den Status bekomme ich angezeigt - also ob Platte kaputt ist oder das Raid z.B. in Transit steckt etc...

Um jetzt z.B. herauszufinden ob der fertig mit der Paritätserstellung war, nutze ich das neustarten vom Upgrade ESXI um mal ebend im HP Storage Manager vorbei zu booten... -> In ESXI ist davon nichts zu finden...

Guru
Beiträge: 2519
Registriert: 23.02.2012, 12:26

Re: Konstant Daten schreiben - was geht schief

Beitragvon ~thc » 07.03.2017, 07:41

Das Log des Controllers ist Sache der Management-Software des Herstellers. Wie das bei PERCs ist , kann ich mangels Erfahrung nicht sagen, bei meinen LSIs lese ich das Log mit MegaCLI oder StorCLI aus.

Member
Beiträge: 13
Registriert: 05.03.2017, 23:25

Re: Konstant Daten schreiben - was geht schief

Beitragvon sleepless » 07.03.2017, 15:42

Hat jemand Ahnung, wie man die Firmware des Controllers Updatet? -> HP Smart Array P420

King of the Hill
Beiträge: 13319
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: Konstant Daten schreiben - was geht schief

Beitragvon Dayworker » 08.03.2017, 00:58

Auf dieselbe Art wie Dell... Am einfachsten per CD/ISO oder du baust dir mit Rufus einen USB-Stick zusammen, wo du alle notwendigen Tools draufpackst.

Member
Beiträge: 13
Registriert: 05.03.2017, 23:25

Re: Konstant Daten schreiben - was geht schief

Beitragvon sleepless » 08.03.2017, 06:53

Ich wüsste nicht, das Dell ein Smart Array P420 hat...

Aber egal, Prinzip ist dasselbe. Nur HP gibt das nicht kostenlos raus. Was fürn Schwachsinn.
Hat jemand ein link zu dem ISO? oder auch nur zu dem reinen P420 Upgrade link?

Ich hatte gestern von meinem Monitoring für ein Intervall ein Hardwaresensor fault bekommen -> Eine Festplatte war kurzfristig (angeblich) komplett weg.
Das ist der Grund meines Update der Firmware - denn ein Rebuild hat der Controller danach nicht durchgeführt, wäre sie wirklich ausgefallen.
Von daher denke ich, der Controller spackt.

Zur Zeit lasse ich ihn die Stripsize verkleinern, mal sehen wie es sich danach verhält. Und in der Zwischenzeit wäre es cool, ein Firmwareupdate zu finden, was ich nach der Transfo aufspielen könnte...

Member
Beiträge: 13
Registriert: 05.03.2017, 23:25

Re: Konstant Daten schreiben - was geht schief

Beitragvon sleepless » 13.03.2017, 12:04

Also:

Nachdem ich auf 64k Stripsize bin, den Controller und alles weitere auf den aktuellsten Stand geupdatet habe fängt es wieder an :evil:

Erst einmal brauchte der Dieter 4 Tage zum ändern der Stripsize. Sonntag um 0.xx Uhr war er damit fertig.
Bis dahin war alles astrein. Dann lief es wunderbar - bis vor einer Stunde :x

Hat jemand eine Idee, wie man die Controller aktivität auslesen kann?
Der Controller meldet nichts mehr im Status des HP SSA - weder Paritätserstellung noch sonst was. Er ist laut Status im normalen Betrieb. Gleiches meldet ESXi und das HP ILo.

Noch eine Idee: Angenommen eine Platte ist kaputt - und zwar so, das der Raid-Controller schreiben&lesen kann, der Festplattencontroller aber irgendwie selbst nicht klar kommt.
Merkt sowas der Raid Controller?
Weil ich merke sowas ja nicht, selbst wenn der Festplattencontroller Hyroglyphen schreibt anstatt das, was der Raid-Controller will.. oder merkt der das auch?

Guru
Beiträge: 2519
Registriert: 23.02.2012, 12:26

Re: Konstant Daten schreiben - was geht schief

Beitragvon ~thc » 13.03.2017, 16:24

sleepless hat geschrieben:Noch eine Idee: Angenommen eine Platte ist kaputt - und zwar so, das der Raid-Controller schreiben&lesen kann, der Festplattencontroller aber irgendwie selbst nicht klar kommt.
Merkt sowas der Raid Controller?

Das ist ein bisschen in sich widersprüchlich. Wenn die Festplatte nach oben zum RAID-Controller "alles bestens" meldet, dann geht der RAID-Controller natürlich davon aus, dass das stimmt. Wenn der onboard-Controller der Festplatte dann nur Mist baut, kann der RAID-Controller davon nichts wissen. Ich halte das aber für zu stark konstruiert. Wahrscheinlicher ist, dass der RAID-Controller da etwas tut.

Member
Beiträge: 13
Registriert: 05.03.2017, 23:25

Re: Konstant Daten schreiben - was geht schief

Beitragvon sleepless » 13.03.2017, 23:47

Ja, er tut was.

Auffällig ist nun ganz klar: Das passiert nur im Leerlauf!
Sobald der beschäfitgt wird ist vorbei mit der ratterei und er konzentriert sich merklich auf das, was er machen soll.

Nun hat der Controller eine Einstellung: Oberflächenanalyse.
Der start ist nach dem Idle verzögerbar.

Was macht das Teil dabei? :?: :?: :?:
Smart-Status abfragen??

Gibt's vielleicht mal eine ausführliche Doku zu dem P420?

Profi
Beiträge: 858
Registriert: 18.03.2005, 14:05
Wohnort: Ludwigshafen

Re: Konstant Daten schreiben - was geht schief

Beitragvon Martin » 14.03.2017, 09:58

Im Englischen heißt das Data Scrubbing.
Hierbei geht der Controller im Hintergrund die Datenbereiche durch und überprüft, ob die Checksummen noch korrekt sind und somit z.B. defekte Blöcke im Voraus zu erkennen

Experte
Beiträge: 1335
Registriert: 25.04.2009, 11:17
Wohnort: Thüringen

Re: Konstant Daten schreiben - was geht schief

Beitragvon Supi » 14.03.2017, 10:45

Bei Dell nennt sich das glaube ich Patrol Read.

bei einem Raid 4x4TB kann das wohl dauern. Und wenn der das alle 2 Wochen macht und das selbige einige Tage... Dann kann das schon den Eindruck erwecken, dass das immer läuft.
Läuft der Host denn dauerhaft? Nicht das du den auch noch regelmäßig ausschaltest und das Überprüfen wird dann immer neu gestartet.

Guru
Beiträge: 2519
Registriert: 23.02.2012, 12:26

Re: Konstant Daten schreiben - was geht schief

Beitragvon ~thc » 14.03.2017, 12:52

Darf ich mal darauf hinweisen, dass es um die Frage geht, warum der Controller nur auf der dem RAID zuletzt hinzugefügten Platte herumkaut und nicht auf den anderen RAID-Membern.

King of the Hill
Beiträge: 13319
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: Konstant Daten schreiben - was geht schief

Beitragvon Dayworker » 14.03.2017, 23:02

Entweder hat die neue Platte einen Knacks weg oder nicht nur für den Controller ist ein Raid5 mit 4 Membern suboptimal.
Wenn es nur rattert, wenn die Platten Leerlauf haben, wurde das entweder so konfiguriert oder ist ein Controller-Standardeinstellung von HPE. Hier mal ein öffentlich einsehbares PDF zum HPE Smart Array P420 Controller. Darin wird allerdings auch nur ESXi5.5 erwähnt. Entweder habe ich ein altes PDF erwischt oder das ist des Rätsels Lösung, obwohl ich das eigentlich nicht glaube.

Member
Beiträge: 13
Registriert: 05.03.2017, 23:25

Re: Konstant Daten schreiben - was geht schief

Beitragvon sleepless » 15.03.2017, 02:02

Google hat mir bisher noch keine sehr gute Doku ausgeschmissen - HP behält sich das wohl eher dem Business gegen viel Geld vor :evil:

Es klingt jedenfalls ganz nach sanften gekratze.

Das die Festplatte schrott ist, bezweifle ich doch irgendwie - soviel Infos der Controller dort ausliest (was für mich wirklich bömische Dörfer sind) sollte der wohl mitbekommen, wenn diese Verreckt. Insbesondere mit dieser Oberflächenanalyse.
Zitat HP:
Die Oberflächenscan-Analyse ist ein automatischer Vorgang, der im Hintergrund abläuft und
gewährleistet, dass Daten im Falle eines Laufwerksausfalls wiederhergestellt werden können. Der
Scanvorgang überprüft physische Laufwerke in fehlertoleranten logischen Laufwerken auf
beschädigte Sektoren. In RAID 5- oder RAID 6 (ADG)-Konfigurationen wird zudem die Einheitlichkeit
von Paritätsdaten überprüft.


Weiß jemand, wo geschrieben steht, was welche LED zu bedeuten hat? Für den p440 hab ich ne Liste gefunden, sicher geistert doch iwo eine für meinen p420 rum... :?:
Weil auf der Kiste eine grüne LED Kontinuierlich in einem 2Hz Takt blinkt...

King of the Hill
Beiträge: 13319
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: Konstant Daten schreiben - was geht schief

Beitragvon Dayworker » 15.03.2017, 11:52

Du hast doch einen HP/HPE-Server? Andernfalls könnten deine Probleme auch dadurch kommen. HP/HPE garantiert die einwandfreie Funktion immer nur in freigegebener HW. Auf einem Wald-und-Wiesen-Rechner mit zuvor funktionierendem Controller kann da bereits ein Bios-Update alles zunichte machen. Das kann zwar auch auf HP/HPE-zertifizierter HW passieren, aber dann muß der Hersteller ran und kann sich nicht rausreden.

Schau dir mal alle Platten genauer auch hinsichtlich Jumperung an, nicht das da noch was verquer ist. Das mixen von neuen 4K- und alten bzw auf 512B gejumperten Platten sollte man tunlichst vermeiden und von Schrott habe ich auch nicht gesprochen. Ich hatte selber eine WD-RE-Platte, die ohne ersichtlichen Grund und Vorwarnung nach 23h eingegangen ist, obwohl SMART auch nach dem Ausfall immer noch von einer einwandfreien Platte überzeugt war. SATA kann auch nicht prüfen, ob Daten auf dem Weg zur Platte über RAM, Controller und Kabel verändert wurden, denn sowas wurde erst bei SAS spezifiert.

Bevor du dieses Problem/Verhalten nicht gelöst hast, würde ich auch von weiteren Änderungen der Stripe-Size etc absehen. Ist der Controller ggf überhaupt für ESXi6.5 freigegeben?

Member
Beiträge: 13
Registriert: 05.03.2017, 23:25

Re: Konstant Daten schreiben - was geht schief

Beitragvon sleepless » 15.03.2017, 15:37

Jup, ein HP Server.

Jetzt musst du mich ein wenig aufklären - soll nicht provokant sein - sondern eher ein lernwilligen User aufschlauen, sodass ich mal weiter nach dem Fehler suchen kann.

Jumpering bei SATA...? Meinst du jetzt die Jumper für die 8 Pins direkt an der Platte? Soweit ich weiß, sind die Dinger für power up beim Booten oder Bus-Geschwindigkeiten etc. - also reine Hardware Geschichten - und eigentlich auch völlig überflüssig.
Was meinst du also mit 4k & 512B gejumpert?

Und zu guter letzt: Wie kommst drauf, das 4 Platten Raid5 suboptimal ist? (Kannst mir auch ein Link zu einem Artikel senden, der das mal näher erläutert)

King of the Hill
Beiträge: 13319
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: Konstant Daten schreiben - was geht schief

Beitragvon Dayworker » 02.04.2017, 16:16

Jumpering ist immer noch ein probates Mittel, Platten an unwilligen Controllern zur Zusammenarbeit zu überreden. Je nach FW-Stand kommen eben nicht alle Controller mit neuen Platten und deren 4KB-Sektorgrösse zurecht.

Bezüglich Raid5, optimaler Config und wie ich das verstehe. Der ESXi6.0 kommt meiner Info nach nicht mit 4K-Platten klar und dem ESXi muß daher das Raidvolume mit 512Byte-Sektorgrösse präsentiert werden. Übliche OS-Anforderungen werden in Grössen von 2KB, 4KB, 8KB usw getätigt. Mit 2 oder 4 Datenplatten wirst du wesentlich häufiger eine Teilung ohne Rest hinbekommen als mit 3 Datenplatten. Nimm mal an, daß 2KB an Daten weggeschrieben werden sollen. Bei 3 Datenplatten und 1 Parity könntest du 3 Blöcke a 512Byte gleich 1536Byte direkt wegschreiben, würdest dann die Parity der 3 Blöcke auf Platte 4 schreiben und den fehlenden 512Byte-Block plus Parity in einem zweiten Schreibvorgang wegschreiben. Der Controller-Cache kann dem zwar entgegen wirken, aber diesen völlig unnötigen Schreibvorgang nicht verhindern. Die Stripesize ist hier in meinen Augen auch kein Ausweg, da diese ja für Schreib- und Lese-IO zutreffend ist. Man will beim Raid5 aber gerade die performancesteigernde Wirkung ausnutzen, daß die Daten möglichst von allen Raidmitgliedern gelesen werden und das limitiert die Stripesize. Ist diese zu groß, kommen die Daten im Extremfall nur von einer Platte und auch der Verschnitt wird grösser, da mehr Nullen geschrieben und somit Blöcke belegt werden. Ist die Stripesize zu klein, werden zwar im Lesefall alle Mitglieder eingebunden, aber im Schreibfall läßt sich die Anforderung nicht optimal aufteilen. Die optimale Stripesize ist daher sowohl vom Controller als auch den verwendeten Daten abhängig und eine kleine Wissenschaft für sich, wenn man das absolute Optimum herausholen will.

Member
Beiträge: 13
Registriert: 05.03.2017, 23:25

Re: Konstant Daten schreiben - was geht schief

Beitragvon sleepless » 26.04.2017, 21:13

Also, nach langem Forschen habe ich herausgefunden, das es 512e platten sind. Alle 4 Stück.
Also native 4k, die aber 512 simulieren.

ESXI 6.0 erkennt einfach keine 4k. Von daher sind es 512.

Ich habe mittlerweile so alles probiert, was sich nur ausdenken lässt - eine Lösung ist nicht greifbar. :cry:
Mittlerweile kratz er definitiv nicht nur auf einer Platte rum, es sind alle queerbeet. Ich denke, das hat er am Anfang auch gemacht, ich habe mich da nur etwas verwirren lassen, das es keine HD Activity LED gibt...

Das geschrieben wird, zeigt auch die Auswertung des Controllers - die Seagate Platten loggen nämlich schön den gesamttraffic mit und errechnen sogar den Workload... und mit 24TB/Monat bei der einen bin ich schon weit, weit, weit, weit aus über die eigentliche Nutzung hinaus geschossen...

Hat jemand eine Idee, ob es unter ESXI 6.5 eine tiefgründigere Analyse der Festplattenauslastung gibt?
Denn ich beschreibe mal den Bootvorgang:
Kiste Power Up -> leichtes Kratzen -> ESXI Boot Menü (dabei leichtes Kratzen weiterhin) -> er läd dann die Komponenten fürs Grundsystem (RUHE!!! Absolute RUHE!!!) -> Das kratzen fängt dann wie dämlich an, sobald vmbf-irgendwas geladen wird...

Bitte wirklich um jeden weiteren Rat.

BTW: Die Oberflächenanalyse ist schon seid einer Woche deaktiviert! Trotzdem keine änderung...


Zurück zu „vSphere 6.0“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast