_alo_

Da 35GB > 10GB hätte er versuchen müssen, diese 60GB auf disk1 zu schreiben und in jedem Fall scheitern müssen. Das sollte unabhängig vom Zielordner innerhalb desselben Shares sein…. Versteh ich nicht Ja, macht Sinn Aber mach das Verschieben nicht über deinen Mac, sondern direkt auf der unraid Konsole. Da dauert das Sekunden und er transferiert nicht erst alle Daten zu deinem Client und zurück in den anderen Ordner. U.u. Bist du da wieder ewig beschäftigt…. Einfach im Ordner Filme allen Inhalt mit „mv * ../„ eine Ebene hochschieben sollte reichen.

Das habe ich ja mit dem Screenshot aus der Doku und ausführlichem Text versucht deutlich zu machen. Du brauchst mindestens so viel (empfohlen doppelt so viel) "minimum free space" wie die größte zu erwartende Datei eben groß ist! DAS verstehe ich allerdings auch nicht, sofern dein Split-Level ja anscheinend richtig eingestellt ist. Vielleicht kommt unraid durcheinander, weil du 2x "Filme" im Ordner hast 🤔 Warum hast Du das überhaupt? macht für mich wenig Sinn in der Freigabe Filme noch einen Ordner Filme mit dem Filmen reinzulegen.... Also ich kann mir dieses Verhalten gerade nicht erklären, Du @DataCollector ? Die Datei dürfte doch eigentlich nicht auf disk3 landen, sondern er müsste versuchen, diese auch auf disk1 zu schreiben und dann ebenfalls abbrechen aufgrund der zu kleinen Angabe🤔 Warum sollte etwas in /mnt/user/Filme/Filme reinpassen, was in /mnt/user/Filme/Filme/Final Destination" nicht reinpasst? Wie groß war denn diese Datei (21GB?) und wieviel war zu diesem Zeitpunkt auf der Platte noch frei?

jein, das Bild zu deinen Dateien interessiert hier nicht, ich meinte die Ordnerstruktur, kannst Du im Finder umstellen ;) interessant wäre ja Was meinst Du mit Hauptordner? ich nehme mal an, Dein Share "Filme" Was ist der Unterordner, in dem deine Datei nicht mehr reingeht? Ich habe das von der Struktur her z.B. so ähnlich: /mnt/user/Filme-Sammlung (Share) /mnt/user/Filme-Sammlung/Serien /mnt/user/Filme-Sammlung/Dokumentationen /mnt/user/Filme-Sammlung/Filme /mnt/user/Filme-Sammlung/Trailer Ich habe dich jetzt so verstanden, dass Du z.B. etwas in /mnt/user/Filme-Sammlung/Serien nicht reinkopieren kannst (weil er immer nur disk1 versucht und scheinbar das Split Level nicht berücksichtigt), in /mnt/user/Filme-Sammlung/ dann aber schon (weil hier das auto-Split funktioniert und er auf disk3 schreibt)? "Jedes VZ automatisch aufteilen" bedeutet ja, dass er im Bedarfsfall den Ordner auf der neuen disk ebenfalls anlegt und die Datei dann dahin schreibt. Bei dieser Einstellung ist es also unerheblich, welcher Ordner wo liegt, die Begründung "weil dort der Unterordner drauf ist" gibt es also hier nicht. Wenn Du im Split-Level was anderes auswählst, dann ggf. aber schon 😉 Das wäre also merkwürdig, da ja alles innerhalb des gleichen Shares passiert, also auf den gleichen Einstellungen beruht.... (Es sei denn unraid merkt sich die Einstellungen pro Ordner, wenn Du hier Einstellungen mit der Zeit änderst, aber das kann ich mir beim besten Willen nicht vorstellen.) Hast Du die Freigabe nach Änderung von Einstellungen auch immer neu gemountet? Er hat den Ziel-Ordner also nicht angelegt auf disk3, sondern immer disk1 gewählt, obwohl du /mnt/user/Filme-Sammlung gemountet hast und kein disk-Share? Hätte er die Datei kopiert, wenn du den Ordner dort vorher selbst angelegt hättest? Kannst du diese Datei in einen anderen Unterordner kopieren, betrifft das nur einen bestimmten Unterordner?

ok, dann bauen die wohl verschiedene Controller in ihre 4TB SSDs.... Unklar, was Du mit PCIe3 meinst: Ob es jetzt PCIe gen3.0 oder 4.0 ist, definierst Du im Bios. Ob es jetzt der dritte PCIe Slot ist? k.A. wie die das nummerieren.... Ich meine diesen einzigen X4 Slot auf dem Board: Ja, mechanisch ist es X16, aber elektrisch (siehst Du an den Kontaktflächen & Lötpunkten) nur X4. Ich wollte den nur abgrenzen von dem oberen "GPU"-X16-Slot (mechanisch&elektrisch), siehe meinen Post zu Verwendung der 10G Karte darin...

das ist seltsam und sollte so nicht sein. kannst Du nicht mal die Einstellungen deines Shares als screenshot posten? Und deine Ordnerstruktur? Dann kann man das am Real-Beispiel durchgehen. welches "automatisch" meinst du? da gibt's doch mehrere Optionen auf mehreren Ebenen! das würde nämlich als Begründung nicht zum automatischen Split passen....

Ok, du meinst die 4tb Patriot Viper VP4300lite? Die werden bei mir ja entgegen der 2TB Version mit Lexar NM790 Controller angezeigt. Vielleicht verbauen die verschiedene unter ihrem Label, auch TenaFe? 🤷‍♂️ Meinen Post zu den Slots hast du gelesen? Ist dein x4 nicht noch frei?

Ich befürchte nein Wovon wir reden sind Share-Einstellungen, also der freigegebene Ordner, den du zb unter Windows als Laufwerk einbindest. Ordner können nicht voll sein, nur Festplatten. Es wird auch nicht nur in einzelnen Ordnern geschaut ob die Platte noch genug Platz hat. Wenn sie nicht in den unterordner passt kann sie auch nicht in den hauptordner (ich verstehe das als dein Share Rootverzeichnis) passen. In ein anderes Share mit anderen Einstellungen dagegen sehr wohl… Beim Split Level stellst du ein ob er unterordnet über mehrere disks aufteilen darf, dh wenn die letzte Datei nicht in „Serien“ passt und dieser aufgesplittet werden darf, erstellt unraid in deinem Share auf der nächsten disks ebenfalls den Ordner „Serien“ und packt da nur diese eine Datei rein. Wenn nicht, kann die Datei nicht kopiert werden. Beim Split Level regelst du auf welcher Ebene er Ordner splitten darf.

Wie loggst du dich denn auf diese VM ein, d.h. Bei welchem Client geht das nicht? Per ssh, irgendeinem vnc, ….?

Ich glaube du hast meine verlinkte Doku zu diesem Thema nicht ganz verstanden (oder ich?), daher mal ein Beispiel: Wenn du nur noch 15GB auf einer disk frei hast und als „Minimum free Space“ 10GB angegeben hast und du jetzt noch ein 30GB Video draufkopieren willst, wirst du die von dir zitierte Fehlermeldung bekommen und dein rsync oder was auch immer für eine kopiersoftware bricht eben mit dieser Fehlermeldung ab! Warum? Unraid weiß zum Start des Schreibvorgangs nicht, wie groß die Datei ist, wie viel also noch kommt. Unraid schreibt und schreibt den dateiinhalt auf das Share bis die Platte voll ist. Wenn die Datei dann noch nicht abgeschlossen ist, gibt’s die Fehlermeldung/Abbruch (und die unfertige Datei wird wieder gelöscht). Empfohlen wird also ein Wert größer (sicherheitshalber doppelt so groß) wie die größte Datei die jemals geschrieben werden soll. Also im obigen Beispiel: Wenn die größte Datei 30GB hat, solltest du als „Minimum free Space“ 30-60gb auswählen, sagen wir mal 40GB. Wenn also nur noch 42GB frei sind, würde er die Datei noch erfolgreich draufkopieren wollen und auch können! Wenn dann nur noch 12GB (<40GB) frei sind, würde er anhand von allocation Methode und Split Level die nächste zu kopierende Datei (egal wie groß) auf die nächste Platte schreiben. D.h. „Minimum free Space“ sorgt nicht dafür, dass genau soviel Platz auf der disk noch frei bleibt, sondern ist nur der trigger für das Auswählen des nächsten Schreibziels

Das finde ich völlig in Ordnung für das Produktive System

Ich meinte die anderen beiden, hab daher extra „TenaFe“ dazugeschrieben:

ja ok 100GB hattest du oben geschrieben...aber vielleicht reicht sogar das bei dir nicht.... Oder wenn es wirklich nur 10GB sind - dann ist es bei Filmen/Serien ja sehr wahrscheinlich, dass am Ende der Platte mal eine Datei kommt, die dieses Limit überschreitet 😉 Auszug aus der unraid-Doku: d.h. Deine Fehlermeldung "zu wenig Speicherplatz" bezog sich nur auf die letzte übertragene Datei, weil auf der Disk wohl nicht genügend "minimum free space" konfiguriert war und das ganze rsync ist deswegen abgebrochen. Vielleicht klappt das gerade zufällig mit der Qnap-App, weil die einfach eine andere Reihenfolge der zu kopierenden Dateien auswählt und knallt dann evtll bei der zweiten Disk genauso?!

Naja, soo viel hat das bei mir am nackten System aber eigentlich auch nicht mehr ausgemacht.... Daher vermute ich noch weitere Punkte wie Netzteil, Messgerät, USV,....was für ne CPU steckt eigentlich nochmal drin? ja genau. Das, was ich dazu geschrieben habe, war ja an ihn gerichtet: Ich hab den ASM einfach angelassen (falls man den mal braucht) und den USB3 Stick an den USB2 Anschluss gesteckt. Das war quasi mein Vorschlag an ihn bzw die indirekte Frage, wie er es denn hat 😉 Ich meine das Thema hatten wir in diesem Thread schonmal, bin aber gerade auch zu faul zum Suchen. Klar versuchen kann man das Abschalten des USB-Controllers, aber bei mir war/ist das halt nicht nötig. Ich vermute ein anderes Problem, bzw. sollte er erstmal auf allen Devices ASPM enablen bevor man sie verucht abzuschalten - es geht ja definitiv!

Ich meinte zum einen die Größe von /mnt/remotes/(qnap_nas)/(filmordner auf qnap)/, die gesamtgröße, also wie viel Daten willst Du kopieren? Und die Größe bzw. eher freier Speicherplatz von /mnt/user0/(filmordner auf unraid), also hast Du genug Platz? Du könntest auch mal die komplette share-config von "(filmordner auf unraid)" als Screenshot teilen. Nicht, dass hier z.B. nur disk1 included wäre - das würde ja auch erklären, wieso das Kopieren dann mit Fehler abbricht...

jetzt wieder im Office mal etwas ausführlicher... Ja stimmt, hatte ich am Handy fehlerhaft editiert ("beide reaktek devices")🤦‍♂️ Erst fiel mir nur die RTL8125 auf und dann noch das zweite Device, der ASM USB-Controller. Bestimmt kann man USB-Controller auch im Bios abschalten, aber das war bei mir nicht nötig, der ASPM-Helper reichte dafür, ASPM auch hier zu enablen (siehe erster Post in diesem Thread). Wir hatten hier allerdings auch schon die Diskussion um den verwendeten USB-Port für den Bootstick. Die Vermutung war, dass das Verwenden der high-speed / super-speed Ports des ASM3042 evtl. tiefere Pkg-C-States verhindert? Ich habe zum Booten vom SanDisk UltraFit den USB-2.0-Port genommen (der obere schwarze ohne blaue Umrandung ca. in der Mitte der ATX-Blende), die anderen habe ich übrigens nicht in Verwendung (also könnte ich den ASM-Controller auch abschalten): Ich würde sagen, starte mal erst nur mit der RTL8125 im ASPM-Helper. Bei mir sieht der ASPM-Helper z.B. so aus. Ich habe lediglich die Info "Found Device / Root" mit Mode=2 ins Setup übernommen: Wenn ich nun allerdings die beiden Reiter "ASPM Info" und "ASPM Current" vergleiche, unterscheiden (disabled-->enabled) die sich nur in den Zeilen zu 00:1c.0 00:1d.2 03:00.0 (RTL8125) 06:00.0 (ASM3042) ....hm, das widerspricht jetzt ein wenig dem Setup im ersten Reiter 🤔oder ich missinterpretiere diese beiden Reiter als "vorher/nachher")... Naja, m.M.n. braucht es zumindest zwingend den Eintrag für die RTL8125 (bei mir 03:00.0/00:1c.0/2), damit hier ASPM enabled wird und solltest kein Treiber-Plugin installieren! wie gesagt: teste mit den Devices / Bridges / Modes mal ein bisschen rum und als Hinweis: ich wähle hier nur den Mode=2 (L1) und habe das auch so im Bios auf dem PCH konfiguriert: Dann wie Data schon schrieb, mal docker/VM deaktivieren um auszuschließen, das die Last davon kommt. Zusammen mit den 8 HDDs (je ca. 1W im Spindown) und 4NVMe erklärt das aber m.M.n. nicht den hohen Stromverbrauch. Zum Vergleich zieht mein produktives System ja kaum mehr als dein nacktes System (meins aktuell 26W mit 4 NVMe, 1 SSD, 6 HDDs, 10G). Mein nacktes System lag bei 11,3W - Ich schätze, da passt an deiner Basis schon irgendetwas nicht (Messgerät, Netzteil, USV mitgemessen?, Bios Einstellungen, "Low Power S0 Idle Capability", ....). Aus Interesse: was sind das für NVMe mit dem TenaFe Controller?

Ich gehe stark davon aus, dass es an den beiden realtek devices liegt, bei denen du kein aspm enabled hast. Teste auch mal alles auf Mode=2

Die Fehlermeldung "zu wenig Speicherplatz" hat aber nichts mit der Ordneranzahl zu tun... kannst du mal deinen verwendeten Befehl posten und die Größe der jeweiligen Ordner?

Was der Kollege in seinem Lösungsweg (1. Post, mehr hab ich nicht gelesen 😉) beschreibt, ist das rüberkopieren auf /mnt/disk1/glallery und wenn Du der Anleitung gefolgt bist, wunderst Du dich, dass nur die erste Platte beschrieben wird? 🤔 Hättest Du hier den Zielordner /mnt/user/Filme genommen, hätte er auch das ganze Array beschrieben, also nach und nach die Platten gefüllt. Mit der Aufteilung ganzer Ordner auf einzelne Disks wird es allerdings schwieriger. Das müsste man dann schon so machen wie beschrieben: z.B: "Serien" auf /mnt/disk1/Serien kopieren, "Dokus" auf /mnt/disk2/Dokus usw. Wenn Du das wolltest und so gemacht hast, was war die Fehlermeldung? Waren die Ordner jeweils größer als die Ziel-Disk? Über den Sinn lässt sich streiten. Beispiel: Entweder verschwendest Du Platz auf der für "Serien" eingeplanten Disk3, weil du (noch) nicht genug Dateien hast, um die Platte zu füllen, oder der Platz darauf reicht irgendwann nicht mehr aus, dann hast du den Ordner Serien doch auf zwei Disks 🤷‍♂️ beides dann eher unschön. Was wäre der Vorteil? Du könntest Ordner-weise Backups machen und wüsstest genau, welchen Ordner ("Serien",...) bzw. welches Backup Du zurückspielen musst bei Ausfall. (z.B. disk3 fällt aus: "ok, alle Serien sind weg, nur die bzw. das Serien-Backup muss ich restoren...") Aber dann kannst du auch einfach statt Ordner-basiert ("Serien",...), auch die Ordner /mnt/disk1, /mnt/disk2 ,... sichern (also die komplette Plate) und zurückspielen, egal was drauf ist. Könnte man z.B. gut mit einzelnen USB-Platten machen. Problem dabei ist aber eben, dass Backupziel jeweils genauso groß wie die einzelnen Platten im Array sein muss. Oder man sichert den ganzen Ordner /mnt/user/Filme auf ein weiteres großes Array (zweiter Server, USB-Array, Cloudspeicher,...) und bei einem Restore über Rsync würden dann nur die fehlenden Dateien aus diesem großen Ordner kopiert, die eben auf der ausgefallenen Platten lagen. Fazit: es ist eigenlich egal, auf welcher Platte welche Daten liegen, wenn man eine entsprechende Backpustrategie hat 😉

Von den Specs mal wieder super von CWWK 👍 danke für den Hinweis. Die Frage ist aber wie immer, ob sich dieses Board dann auch stromsparend betreiben lässt...(und wie der Support ausschaut, ob z.B. das Bios auch weiter gepflegt wird etc.) Bislang waren ja gerne Komponenten verbaut, die dieses verhindern (sieht hier auf den ersten Blick nicht so aus), oder entsprechende Bios-Optionen nur mit CheatCodes erreichbar, oder sie funktionierten einfach nicht wie erwartet... Ich habe selbst eine AQC113C (ohne "S") RJ45-NIC von aliexress in meinem unraid-Server. Mit der richtigen ASPM-fähigen FW (genau für diese Karte) läuft sie gut und das System geht weiterhin bis in C10. Der ASM1164 lässt sich bekannterweise ja auch entsprechend gut mit neuer FW stromsparend betreiben. Unklar natürlich, welche FW hier jeweils bereits installiert sind und ob sich diese onboard-controller genauso einfach updaten lassen wie die PCIe-Varianten und nachher bestenfalls auch noch funktionieren 😉 Bei meiner Netzwerkkarte gab es auch Berichte von gebrickten Karten bei Verwendung von falschen Updates, also hier ist definitiv Vorsicht und ausreichende Recherche geboten.... Wäre aber sicherlich interessant, wie sich dieses Board gegen andere W680 Boards (oder auch andere hier öfter vertretene) schlägt...

davon wurde nichts geschrieben, oder?

Settings --> Network Setting --> ganz unten: aber denk dran, dass der Rückweg auch entsprechend passen muss! d.h. die Antworten müssen dann auch von diesem Gateway kommen (und nicht z.B. von deinem def-gw), damit du keine dreiecksbeziehung aufbaust, denn dann würde die Verbindung abbrechen

dann richte ne Route ein

Also hast Du zwei Gateways in Deinem Netz und eins hast Du als default gateway eingerichtet? Wenn der eine docker container jetzt das andere nutzen soll, dann befinden sich dahinter ja bestimmte Netze, die Du dann dem unraid über routen bekannt machst. def.-Gateway bedeutet ja nur: wenn du keine bestimmte Route findest, route das default-mäßig hierhin..... zwei def-GWs kann es nicht geben. und einem docker jetzt ein anderes def-gw geben als den anderen? dafür fehlt mir gerade die Vorstellungskraft, wofür man das bräuchte 🤔

ok, sorry, ich hab jetzt auch endlich mal kurz in den von @alturismo verlinkten Thread reingeschaut um mich über das Thema aufzuschlauen und ja, der docker container arbeitet ja so wie ich es verstanden habe: er nimmt dir nur die Einrichtung der von mir verlinkten Anleitung ab und bietet ein paar Zusatzfeatures: Automatic VM Monitoring: Regularly checks the status of the VM and restarts it if it has been shut down unexpectedly, ensuring Home Assistant is always available. Seamless Integration with Docker & VM WebUI: Combines Docker container management with VM monitoring. Clicking the “WebUI” link from the Unraid Docker tab will automatically redirect to the Home Assistant WebUI inside the VM. Dynamic IP Management: Automatically determines the internal IP address of the Home Assistant VM and updates the Docker WebUI redirect der erste Punkt: hm, wenn der HA Server crasht, gibt es dann nicht einen Grund dem man auf den Grund gehen will? will man automatische Restarts und funktionieren die überhaupt bzw. muss man i.d.R. nicht eh manuell ran? Gut, kann vielleicht hilfreich sein, meine VM ist in fast 2 Jahren nicht einmal abgestürzt.... der zweite Punkt: ok, wenn man viel über das unraid dashboard arbeitet, kann das vielleicht hilfreich sein, aber ich nutze gerade für HA die Apps/Browser auf Mobiltelefon/Tablet (mit fest konfigurierter URL) oder auf dem PC einfach den denselben Link, meinetwegen mit einer schicken subdomain über NPM. Warum sollte ich mich in unraid einloggen und da auf dem docker die "WebBUI" auswählen? Finde ich zu kompliziert.... der dritte Punkt: und hier wird es m.M.n. fehleranfällig, da der docker offenbar ermittelt, welche DHCP-IP die VM bekommen hat und anhand dieser die Weiterleitung dynamisch anpasst. Klingt für mich, als wenn das alles unnötig und fehleranfällig ist. man braucht diesen redirect nicht (siehe Punkt 2) und man braucht kein dynamisches IP MGMT (siehe KEIN DHCP bei Servern). Meine Meinung.

DAS scheint auch wirklich der einzige Grund zu sein, der Rest ist ja docker vs. VM. Ich hatte mich damals an o.g. Anleitung von HA gehalten und fand die paar Punkte jetzt auch nicht wirklich schwierig.... Ich befürchte, dieser in-a-box-Krams macht es insgesamt eher komplizierter als einfacher, wie dieser Thread ja zeigt....😉 (davon, dass die HACS-Plugins innerhalb des HA als docker-container laufen, kriegt man ja eigentlich gar nichts mit...und sollte hier auch nicht Thema sein) und genau DAS verstehe ich hier nicht so richtig (da ich das in-a-box noch nicht ausprobiert hatte). Fungiert der docker Container nachher als eine Art Proxy/Weiterleitung, oder wie? Ich dache nicht?! Was heißt "dort erreichbar"? Ich dachte, man gibt die Wunsch-IP hier nur an und der docker container erstellt/konfiguriert dann die HA-VM entsprechend, oder? Aus Neugier: Wie läuft diese Einrichtung mit diesem in-a-box-docker ab? Läuft in dem docker-Container ein Skript oder eine Webseite, die die Werte für eine automatische HA-VM-Installation abfragt? Oder gibt man alles als container-Variablen an, startet den docker und wartet bis die Einrichtung durch ist? Die IP dieses docker Containers ist doch dann irrelevant, oder (lass ihn einfach auf "host" stehen)? Ich denke immer noch, Dein Einrichtungs-docker läuft auf der .45, wo eigentlich dein HA laufen sollte (so hab ich deinen Wunsch verstanden). Die IP des HA stellst du aber in der vom in-a-box-docker erstellten VM ein. Diese steht bei dir wahrscheinlich auf "Automatisch" - ich habe, wie beschrieben, hier meine Wunsch-IP statisch im HomeAssistant eingetragen (unter Einstellungen->System->Netzwerk), sollte das nicht dein docker-container machen bei der Einrichtung? Was steht da bei Dir, wenn die VM läuft? Jein, was man da macht ist, dem DHCP Server der Fritz!Box sagen "wenn diese MAC eine IP anfragt, vergib diesem Client immer folgende IP (dem Rest wird irgendeine freie aus der übrigen Range gegeben)". Sozusagen eine Reservierung innerhalb der DHCP-Range. Hierüber eine IP außerhalb der DHCP Range zu vergeben, sollte nicht möglich sein! Wenn Du als Range 50-200 konfiguriert hast, solltest Du über den DHCP-Server eigentlich keine .45 verteilen können. Vielleicht geht das (nie probiert, ist das überhaupt RFC.konform?), aber das macht das Ganze ja noch unübersichtlicher.... naja, fest konfigurierte werden nicht mehr "geholt" (holen klingt für mich nach DHCP, was ich ja dringend vermeiden würde) wenn man kein DHCP nutzt, ist diese Aussage nicht falsch 😉 Die Fritz!Box blockiert hier nichts, NUR im Rahmen von DHCP. Du kannst die IP schon noch woanders statisch vergeben und die FritzBox reserviert die weiterhin für Anfragen der alten Hardware. Diese dürfen dann eben nicht parallel kommen, sonst knallt's (Ip Adresskonflikt, weil zwei MACs dieselbe IP haben). Falls du die alte Hardware für was anderes verwenden willst, sind also Probleme vorprogrammiert. DESHALB Muss man diese DHCP-Konfig löschen oder noch besser, sowas eben gar nicht erst machen! Was richtig ist: wenn du weiter DHCP machen willst und die Fritz!Box die .45 immer der MAC der alten Hardware geben will, wird diese nie auf die neuen MAC kommen. Auch dann musst du diese Konfig anpassen. Was ist denn die MAC deiner VM und wie hast du jetzt die Fritz!Box konfiguriert? Mein Punkt hierzu war: Lass DHCP bei Servern sein, vergib sie außerhalb der DHCP-Range selbst, manuell, statisch (in unraid, docker-container und VMs) und dann hast du nix mit diesen Reservierungen und notwendigen Anpassungen zu tun! Generell: Der Haken für die Reservierung innerhalb des DHCP-Servers der FritzBox bzw. diese Funktion ist eigentlich ausschließlich für Geräte denen man keine statische IP geben KANN., weil dann ist das die einzige Möglichkeit, sie "immer" untern der gleichen IP zu erreichen. Das ist aber ein bisschen eine Notlösung, denn die LeaseTime und das Neuaushandeln der IP findet ja trotzdem statt, d.h. eine kurze Downtime hast Du mit dieser Krücke immer. Daher: bei Servern kein DHCP!