VMware ESXi - zu langsamer Datentransfer mit NAS4Free

B

ByteJunkie

Neuling
Thread Starter
Mitglied seit
27.12.2016
Beiträge
83
Ort
Deutschland, Thüringen
Hallo,

ich habe auf meinem HP Microserver G8 VMware ESXi 6 installiert, um verschiedenste Betriebssysteme gleichzeitig laufen zu lassen. Als NAS-OS habe ich mich für NAS4Free entschieden. Nun habe ich das Problem, dass wenn ich Daten (bspw. Videos >3G) auf das NAS kopiere, habe ich eine Übertragungsrate von ca. 40-50 MB/s trotz Gigabit-Anbindung (auf meine WD-MyCloud kopiere ich mit ~100 MB/s).
Die Festplatte ist eine WD Red 4 TB (später kommt noch eine WD Red Pro 3 TB dazu).
Die Festplatte ist als UFS formatiert (keine Ahnung, ob man das so sagt :d ), da ZFS mehr RAM benötigen würde, den ich noch nicht zur Verfügung habe.
Liegt das Problem bei der Festplatten-Virtualisierung? Würde Raw-Device-Mapping helfen?

Vielen Dank im Voraus ;)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
D.h. Du hast einen Teil des Datastores der Nas4free-VM zugeteilt und hast auch andere VMs auf diesem Datastore? Dann bräuchtest Dich nit zu wundern.
Damit Du volle Storage-Performance siehst, musst Du die Platte dediziert dem Nas4free geben, ohne das diese gleichzeitig Datastore spielt. => D.h. eigener Controller und den der VM durchreichen und da dran die Platte oder notfalls per RDM.

Und: Wieviel Ram ist verbaut? Du brauchst genug Ram für die Nas4free-VM. D.h. z.B. bis 8GB Ram und ESXI brauchst da gar nicht versuchen; da wirst nie Performance bekommen.

PS: Meine beiden Nas4free-VMs (auf je einem ESXI-Server (Hauptserver und Backupserver)) haben je 12GB Ram und nen LSI-Controller durchgereicht bekommen (1*6 HDDs und 1*8 HDDs); natürlich ZFS. Da rennen sequentiell schon 700-800 mb/s. => Nas4free kann vritualisiert also schnell; am OS liegts also nicht. :d
 
Zuletzt bearbeitet:
Danke für die Antwort.
NAS4Free ist Hauptsächlich auf der SSD installiert, wo auch ESXi und andere Gäste installiert sind. Ich habe die Festplatte zusätzlich der VM hinzugefügt. Das Problem, was ich bei RDM habe ist, wenn ich einen virtuellen Container erstellt habe, dann "vorhandene virtuelle Festplatte verwenden" auswähle -> Container auswählen -> weiter -> Knoten SCSI (0:1) -> Modus abhängig -> ok -> "Inkompatibles Backing für Gerät '0'."

PS: Da werde ich mir wohl doch 16GB RAM kaufen müssen ;)
 
Die Hardwarevorraussetzung für ESXi selbst lautet ja schon 8 GB RAM.
Das ZFS viel RAM braucht stimmt nur eingschränkt, da hier meist die Aussage 1GB RAM / TB HDD bei Deduplikation verallgemeinert wird.
Richtig ist, daß ZFS (und NAS4Free) bereits mit 2 GB RAM auskommt (FreeNAS hätte gerne 8 GB als Systemvorraussetzung).
Da ZFS aber den RAM als Cache verwendet gilt: je mehr RAM desto "Bums" :)
 
Hmm ich habe nun 2 zusätzliche Festplatten NAS4Free gegeben (jeweil 931 GB). Es hat nun 4 GB RAM bekommen und 2 CPU Kerne (mehr hab ich nicht). Ich habe auch eine Swap-Datei auf der nicht benutzten zweiten Festplatte erstellt (3 GB). Wenn ich nun bspw. ein Video (12 GB) auf die erstellte Freigabe kopiere, dann wird in den ersten paar Sekunden das Video mit ~100 MB/s übertragen, aber danach bricht es ein und überträgt nur mit ca. 50-65 MB/s. Danach sind 32% vom RAM ausgelastet und der Swap wurde gar nicht beschrieben.
PS: Die Festplatte ist als ZFS formatiert. Die zweite als UFS und ist auch gemountet.
 
Die Zielfestplatte ist eine WD Red 4TB. Die sollte das eigentlich schaffen. Die Festplatte wird auch von keiner anderen VM occupiert.

- - - Updated - - -

Ich habe es nun so gemacht, dass die VM 5 GB RAM bekommt. Die Übertragung ist nun konstanter. Ich habe mich also entschieden diesen RAM zu kaufen, damit die VM mehr Kapazitäten hat (RAM: https://www.amazon.de/Kingston-KVR1333D3E9SK2-16G-Arbeitsspeicher-240-pin/dp/B0064R7LH8?tag=meintechblog-141108-21&th=1 ). Das sollte auch der richtige RAM sein, oder?
 
Da das ganze über eine virtuelle NIC läuft, ist hier auch noch etwas overhead zu beachten.
Mir ist aber auch bei einem Filer in Hardware schon aufgefallen, das bei NAS4Free die Geschwindigkeit einbricht, wenn die Datei größer als die Hälfte an verfügbarem RAM ist.
Sprich, mein Filer hat 24GB RAM - kopier ich Dateien bis 12GB Größe hab ich vollen Speed, ist die Datei aber größer, bricht nach einiger Zeit die Geschwindigkeit ein.

In einer Virtuellen Umgebung hab ich das noch nicht getestet.
 
Genau das ist mir auch aufgefallen. Ich probiere es nochmal mit UFS statt ZFS. Mal schauen, was da so herauskommt.

- - - Updated - - -

Okay... mit UFS ist es noch langsamer (~20-30 MB/s) ._.
 
Digi-Quick schrieb:
Die Hardwarevorraussetzung für ESXi selbst lautet ja schon 8 GB RAM.
Das ZFS viel RAM braucht stimmt nur eingschränkt, da hier meist die Aussage 1GB RAM / TB HDD bei Deduplikation verallgemeinert wird.
Richtig ist, daß ZFS (und NAS4Free) bereits mit 2 GB RAM auskommt (FreeNAS hätte gerne 8 GB als Systemvorraussetzung).
Da ZFS aber den RAM als Cache verwendet gilt: je mehr RAM desto "Bums" :)
Zum Vergrößern anklicken....

Man muss aber dazusagen, dass das nur die Stabilität betrifft.
Da reichen 1-2 GB für ein aktuelles 64bit OS mit ZFS aus. Systeme, die nicht auf Solaris bauen wie BSD (FreeNAS, Nas4Free) oder Linux brauchen minimal mehr, da die ZFS interne Speicherverwaltung die ja fürs Caching benutzt wird (noch) auf Solaris ausgelegt ist und auf anderen Plattformen minimal mehr RAM braucht. Vermutlich einer der Gründe warum Solarish (noch) die schnellste ZFS Platttform ist.

Die riesigen absolut dargestellten Anforderungen vor allen aus dem FreeNAS Bereich mit mindestens 8GB RAM bzw mindestens 1 GB RAM/TB Daten und zwar unabhängig von Dedup - das kommt noch obendrauf, muss man aber schon kritisch sehen bzw richtig "deuten". Ich sehe zwar nicht, warum ZFS mit weniger RAM instabil werden sollte, es ist aber in jedem Fall nicht sonderlich schnell, wegen CopyOnWrite mit sehr wenig RAM sogar meist langsamer als "alte" Dateisysteme. Das liegt daran, dass die Daten relativ gleichmäßig auf der Platte verteilt werden, damit eine hohe Fragmentation entsteht. Selbst bei sequentiellen Workloads (eine Person schaut ein Video das zuvor auf den leeren Pool kopiert wurde) entsteht beim Lesen kein Datenstrom aus fortlaufenden Sektoren sondern es müssen ständig kleine Datenpackete (Metadaten und Daten) von verschiedenen Bereichen der Platte gelesen werden. Die Performance ist daher eher durch die Pool iops limitiert, Ausreichend RAM kann das enorm beschleunigen da zumindest alle Matadaten aus dem Lesecache kommen können. Für ein schnelles Multiuser Profisystem ist die Faustregel mindestenst 1 GB RAM/TB Daten ohne dass Dedup genutzt wird deshalb ganz ok. Für ein Homesystem mit ein oder zwei Usern ist das aber übertrieben.

Ich habe dazu kürzlich ein paar Tests gemacht bei denen ich den Lesecache deaktiviert habe. Das ist vergleichbar einer Situation, bei der man nur sehr wenig RAM hätte (z.B. 1-2GB).

Ergebnis:
Lesen von sehr langsamen Platten (WD Green): 3 MB/s
Lesen von schnellen Platten (HGST Ultrastar): 85 MB/s
Lesen von schnellen SSD: ca 300 MB/s

https://forums.servethehome.com/ind...m-or-readcache-disabled-and-slow-disks.12170/

Insbesondere unter ESXi als VM Speicher sollte man also schon mindestens 4-8 GB für die Storage VM bereithalten. In meinen AiO Systemen unter OmniOS habe ich meist 64 GB RAM mit 32 GB für die Storage VM
 
Zuletzt bearbeitet:
Danke für die ausführliche Antwort! Das "Problem" am Microserver G8 ist, dass man ihn mit maximal 16 GB RAM bestücken kann. Das werde ich auch ausreizen. Darf ich fragen, welchen Server du hast?
 
@konfetti: Die virtuelle Nic sollte in dem Szenario hier keinerlei Engpass darstellen; egal ob E1000 oder Vmxnet3. Selbst eine E1000 wuppt mehrere hundert MB/s.
Nicht desto trotz setze ich natürlich auf die Vmxnet3, wo immer es nur geht (und Nas4free/FreeBSD kann mit ihr seit der 10er-Version und ESXI 5.5U2 gut).

@ ByteJunkie: Du musst natürlich noch drauf achten, dass das 4k-Sektor Alignment passt. Bin mir nicht sicher, ob Nas4free das automatisch richtig macht (und damit Ashift=12 setzt). Ich richte die Platten und den Pool daher sicherheitshalber händisch über die Konsole ein.
 
Zuletzt bearbeitet:
ByteJunkie schrieb:
Danke für die ausführliche Antwort! Das "Problem" am Microserver G8 ist, dass man ihn mit maximal 16 GB RAM bestücken kann. Das werde ich auch ausreizen. Darf ich fragen, welchen Server du hast?
Zum Vergrößern anklicken....

Ja mit dem G8 kann es eng werden.
Wenn man für ESXi 2GB rechnet, dann 6-8 GB für die NAS VM bleiben 6-8GB für alle anderen VMs.

Ich selber nutze praktisch ausschließlich SuperMicro Systeme mit der Standardversion von ESXi 6.0u2 und neuerdings 6.5; die aktuellen habe ich in einer Empfehlung hier zusammengefasst: http://www.napp-it.org/doc/downloads/napp-it_build_examples.pdf
 
Ich hab maximal 3 andere VMs am laufen, welche jeweils mit 1GB auskommen. Da kann NAS4Free problemlos 10GB bekommen ;) Aber wenn es dann nicht richtig läuft...
 
Du musst halt schaun, dass Nas4free die Platte nativ ansprechen kann und nicht als virtual Disk. Auch für ZFS wichtig, dass es direkt mit der Platte "sprechen" kann.
D.h.: Kein Raidcontroller, keine Virtual Disk dazwischen.
Drum reicht man der NAS-VM idealerweise einen einfachen Hostbusadapter ohne Raid-Funktionen (LSI=Avago=Broadcom haben sich bewährt) per vt-d/Passthrough durch und klemmt da die Platten dran. ESXI sieht dann diese Hardware nicht mehr als Storage für sich und seine VMs.
Ist bei Nas4free/FreeBSD genauso wie bei Solarish-Lösungen.

Allerdings kann man dann aus der Nas-VM heraus dann z.B. Speicherplatz via NFS-Protokoll dem ESXI wieder anbieten und dort dann weitere VMs drauflegen. Stichwort: geas All-in-one-Lösung.
 
Zuletzt bearbeitet:
Okay... Wenn ich eine neue VM erstelle, versuche ich die "erstellte Festplatte" hinzuzufügen, welche ich vorher mit "vmkfstools -z /vmfs/devices/disks/t10.ATA_____WDC_WD40EFRX2D68WT0N0_________________________WD2DWCC4E2ZTJ6SA /vmfs/volumes/HDD2/RDM1.vmdk" erstellt habe. Aber ich bekomme die Fehlermeldung: Inkompatibles Backing für Gerät '0'. Leider finde ich auf diversen Internetseiten keine passende Lösung....
 
Zuletzt bearbeitet:
So, ich muss mich leider nochmal melden :(

Ich habe (wie angekündigt) 16 RAM eingebaut. ich habe der NAS4Free-VM 10GB RAM zugewiesen. Ich habe alle ZFS Einstellungen auf Standard gelassen. Ich habe auch keine Komprimierung aktiviert. Bei der Samba-Konfiguration habe ich lediglich "Asynchrones I/O (AIO)" aktiviert und den Standardwert bei 1024 gelassen.
Wenn ich nun eine sehr große Datei (~20G) auf die Freigabe kopiere, dann wird bis ~10% die Datei mit >100 MB/s übertragen. Danach gibt es einen abrupten Abfall, bis es sich bei ca. 65 MB/s einpegelt.
Nach der Dateiübertragung ist der RAM zu 98% ausgelastet. Was mich auch wundert, der Swap wird gar nicht angefasst. Der Swap hat eine Größe von 10 GB und er ist zu 0 B ausgelastet.

Nochmal alles im Überblick:
[Hardware]
CPU: Intel Celeron G1610T @2,3 GHz
RAM: 16 GB Installiert (10 GB der VM zugewiesen)
Datenfestplatte: WD Red 4 TB (WD40EFRX)

[Software]
OS (Server): ESXi 6.0.0U2
OS (Gast): NAS4Free 11.0.0.4 (Revision 3330)

[NAS4Free]
ZFS-Version: 5
Server Max Protokol: SMB3
-> ZFS-Einstellungen alle auf Standard
-> Samba auf Standard, außer AIO aktiviert
-> Übertragungsrate bis ca. 10% > 100MB/s, danach ca. 65 MB/s
-> CPU-Auslastung bei ~70-90%

Was habe ich falsch gemacht bzw. an welcher Stelle kann ich mein System optimieren?
Vielen Dank im Voraus!
 
Zuletzt bearbeitet:
Swappen, sprich auslagern von Arbeitsspeicher auf Datenträger, soll da auch gar nichts; sonst hast ein großes Performanceproblem.

Poste mal die ersten Zeilen der BSD Top-Abfrage (Nas4free-Menüpunkt "Status"->"Process" der Weboberfläche); das sollte dann so in etwa aussehen (hier mit 8GB kurz nach dem Einschalten).
Code: 
Mem: 78M Active, 45M Inact, 172M Wired, 7360K Buf, 7620M Free
ARC: 690K Total, 65K MFU, 522K MRU, 16K Anon, 12K Header, 74K Other
Swap:

Einmal leer nach dem Hochfahren der VM und sofort nachdem die 20GB übertragen sind.
 
Trambahner schrieb:
Swappen, sprich auslagern von Arbeitsspeicher auf Datenträger, soll da auch gar nichts; sonst hast ein großes Performanceproblem.

Poste mal die ersten Zeilen der BSD Top-Abfrage (Nas4free-Menüpunkt "Status"->"Process" der Weboberfläche); das sollte dann so in etwa aussehen (hier mit 8GB kurz nach dem Einschalten).
Code: 
Mem: 78M Active, 45M Inact, 172M Wired, 7360K Buf, 7620M Free
ARC: 690K Total, 65K MFU, 522K MRU, 16K Anon, 12K Header, 74K Other
Swap:

Einmal leer nach dem Hochfahren der VM und sofort nachdem die 20GB übertragen sind.
Zum Vergrößern anklicken....

Sofort danach:
Code: 
Mem: 3300K Active, 126M Inact, 9482M Wired, 8772K Buf, 172M Free
ARC: 8622M Total, 273K MFU, 8588M MRU, 16K Anon, 19M Header, 14M Other
Swap: 10G Total, 10G Free

Nach einem Reboot:
Code: 
Mem: 75M Active, 43M Inact, 817M Wired, 8222K Buf, 8849M Free
ARC: 989K Total, 180K MFU, 702K MRU, 16K Anon, 18K Header, 72K Other
Swap: 10G Total, 10G Free

Was mir sofort auffällt ist, dass der Header extrem groß ist nach der Übertragung :confused:
 
Zuletzt bearbeitet:
Ok, der Speicher kommt beim ARC an; das ist schonmal gut. Header? Natürlich braucht ZFS gewisse Metadaten im Speicher. Die paar M sind doch unwichtig. ZFS weiss schon richtig mit dem Speicher umzugehen.:)

Probier mal, bei Samba die "Send Buffer Size" und "Receive Buffer Size" ordentlich hochzudrehen; ich hab da für 10GBit jeweils fast 16Mbyte drin; die default 65k sind IMO deutlich zu wenig. Vielleicht mal mit jeweils 1310720 (also 1MB) probieren.

Auch wichtig: Bei den ZFS-Datasets atime=off setzen (Access Time (atime) in der GUI) und bei einem Haswell-Pentium als Komprimierung entweder OFF oder LZ4 verwenden. Niemals ON oder andere Kompression als LZ4. Frisst sonst zuviel CPU-Last
(mein Tip: LZ4 ; das kann man eigentlich immer einsetzen). atime=off und compression=LZ4 gleich am besten auf dem Pool anwenden, dann erben es dort drauf erstellte Datasets.
NIEMALS in so einem Setup die Deduplikation einschalten. NIE!. Dedup ist nur in sehr ausgewählten Szenarien wirklich nützlich. Falls Du es schonmal an hattest, darfst den Pool neu aufsetzen weil ganz wird man es, soweit ich gelesen hab, nicht mehr los.

Btw, als virtuelle Netzwerkkarte VMXNET3 nehmen. Nas4free 11 sollte out-of-the-box damit zurecht kommen.

Tja, und guterletzt aber extrem wichtig: die HDD muss als Datastore weg und nicht als virtuelle Platte von FreeBSD angesprochen werden. Sonst muss der ganze Datenstrom durch das Vmware-Filesystem und deren Puffer; ferner muss das 4k-Alignment auf der HDD passen, da Du eine Platte hast, die 4k-Sektoren hat und nach aussen 512Byte emuliert. Stichwort richtiger Ashift.
 
Wie wäre es denn einfach mal auf der Kommandozeile des NAS Systems (also nicht dem ESXi, sondern in der VM) einen HDD Bench durchzuführen?

Weil ich mein, du testest hier seit Tagen schon Durchsatz, wo viele Unbekannte am Werkeln sind und wunderst dich, warum die Diskperformance so grausig ist.
Dabei lässt das Verhalten ganz klar darauf schließen, dass einfach der Storagedurchsatz zu gering ist.
Das kann nunmehr viele Gründe haben.

Auch das Thema mit dem RDM, hast du das nun gelöst? Oder wie sind die Platten nun eingebunden...
Ein nicht Cache gestütztes lokales Storage am/im ESXi ist meist grottig langsam. Es läuft zumeist auch im write through mode und lässt sich nicht anders erzwingen. Ob der ESXi dabei den HDD Cache verwendet, keine Ahnung, möglich... Einen Schalter um diesen händisch ein/auszuschalten, scheint es mir allerdings nicht zu geben? Also nachprüfen ist dahingehend eher schlecht.

Der widerholte Tip, nach einem HBA, der der VM durchgereicht wird ist dahingehend nämlich durchaus "sinnig". Die VM hat damit die Kontroller über die Disks und den Controller. Und kann, je nach System auch ganz klar deutlich schneller als der ESXi durch write through ohne lokalen Disk/RAM Cache es tätigen würde...
Anders sieht es mit einem Cachegestützten Controller und lokalem ESXi Datastore aus -> das geht auch mit nem anständigen Controller richtig schnell. Auch bis in die VM rein und fast "native" im Durchsatz, wie das System hart aufs Blech installiert, wenn niemand anderes (VMs) dazwischen funken... Nur nutzt dir das so nix, weil es dem Sinn hinter der Storage Appliance etwas entgegensteht. Du willst ja das ZFS Storage als Basis. Und möglicherweise gar mit mehreren Disks da über Redundanzlevel usw. usf Vorteile erzielen. Ein Diskcontroller inkl. Cache am ESXi wäre also eher Unsinn. Nur so wie du es jetzt hast, als VMDK Container auf dem nicht Cache gestützten lokalen Datastore KANN es aus meiner Sicht auch nicht richtig fix laufen.

Nur so als kleine Anmerkung nebenbei ;)
 
Zuletzt bearbeitet:
@Trambahner:
Danke für die ganzen Tipps! Nachdem ich den Wert eingefügt habe, schreibe ich zuerst mit gewohnter Geschwindigkeit (>100 MB/s), aber schon nach 3% wieder mit 65 MB/s. Ich denke, dass es daran liegt, weil ich kein RDM verwende.

@fdsonne:
Das Theme RDM konnte ich noch nicht lösen. Egal welches Tutorial ich verwende, es klappt einfach nicht ... Auch dir nochmal Danke für die ganzen Erklärungen!

Was meint ihr: Ist es doch besser, wenn auf einem NAS-Server kein ESXi o.ä. installiert ist, sondern das OS direkt installiert ist?
 
Ich persönlich bin mittlerweile ein Fan der ESXI All-in-one Lösung mit Storage-VM und durchgereichtem Hardware-HBA. Einfach weil weniger Hardware aktiv rumsteht, diese besser ausgenutzt wird und man Dinge einfacher ausprobieren, snapshoten und wieder löschen kann.
Ausserdem ist man ESXI-intern nicht auf den Durchsatz des physischen Netzwerks beschränkt, sondern hat die volle Pool-Leistung für die auf der gleichen Maschine laufenden VMs zur Verfügung. Und: ich kann ausser der Storage-VM meine VMs auf den ZFS-Pool legen ohne dass eine weitere physikalische Maschine läuft und hab damit alle ZFS-Vorteile direkt für die VMs, ohne dass die ZFS kennen müssen. Alleine schon die LZ4-Komprimierung für die virtuellen Platten und dass sich Random-Schreibzugriffe durch das ZFS-System serialisieren und Lesezugriffe puffern lassen.
 
ByteJunkie schrieb:
Was meint ihr: Ist es doch besser, wenn auf einem NAS-Server kein ESXi o.ä. installiert ist, sondern das OS direkt installiert ist?
Zum Vergrößern anklicken....

Es ist eine Design-Entscheidung, die man einfach treffen muss... Vor- und Nachteile gibts halt, egal wie man es dreht.


PS: ich bin mittlerweile sogar eher ein Freund davon, ALLES, Ausnahmslos (ok nur fast, die Access Clients und Workstations noch nicht) zu virtualisieren... Warum? Weil es A) einheitlich ist -> sprich im Händling nicht unterschiedliche Hardware von verschiedensten Generationen zu beachten ist, B) es sich durch Snapshots und Co. eben einfach besser "spielen" lässt und auch C) Themen wie Backups oder Systemmigration usw. usf. alles doch viel einfacher sind, da der Virtualisierungslayer unten IMMER der gleiche ist. Da gibts also meist keine Kompatibilitätsprobleme IN der VM.

Das beist sich allerdings oftmals eben genau beim Thema Storage... Eine Snapshot basierte Backuplösung von der Storage VM wäre irgendwie unsinn, vor allem bei einem System mit ZFS :fresse:
Eine Storage VM als globales Hoststorage mit durchgereichten HBA und "vollem" Speed hingegen ist wieder sinnig... So halbgewalkte Lösungen sind aber eher kappes. Von daher...
 
Okay danke für die Meinungen. Ich (als Anfänger) finde ESXi schon echt super. Aber es wurden ja eigentlich schon alle Vorteile genannt :) Aber zurück zu meinem Problem: Wenn ich diese Anleitung befolge (https://kb.vmware.com/selfservice/m...nguage=en_US&cmd=displayKC&externalId=1017530), dann bekomme ich diesen Fehler, wenn ich versuche die vorhandene virtuelle Festplatte hinzuzufügen: "Inkompatibles Baking für Gerät '0'" :confused:

Update: https://communities.vmware.com/thread/404192?start=15&tstart=0 - Diese Anleitung funktioniert leider auch nicht zur Fehlerbehebung :(
 
Zuletzt bearbeitet:
Starte mal bitte den vSphere Client auf Englisch (wie man das macht, findest du in der KB bei VMware -> einfach mal fix google anwerfen) und poste die exakte Fehlermeldung nach einem erneuten Versuch hier...
Die Übersetzung ins deutsche ist leider teils echt "grausig" und vor allem, die Masse der Hilfestellungen und Beiträge zu diesen oder ähnlichen Themen im Netz kann mit der grausigen Übersetzung wenig bis nix anfangen.

Heist also, als aller erstes, Umstellung auf ENG und dann die Meldung in ENG hier posten mit möglichst exaktem Wortlaut und allen Details in den Logs...
 
Anmelden, um zu antworten.

Ähnliche Themen

L
systemwechsel weg vom HP ProLiant DL380p Gen8
Antworten
4
Aufrufe
536
Haldi
Haldi
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