"Homeserver" Software ändern
- Ersteller Lenny88
- Erstellt am
mercury
Lieutenant
- Registriert
- Jan. 2009
- Beiträge
- 748
also nur als Erfahrungseinwurf. ich wollte mir in meinem Fall auch eine VM sparen und Pihle (inkl. DHCP) gedockered laufen lassen. war ein PITA weil sobald DHCP eigneschaltet wurde, ist der Container bzw pihole slebst in einer Dauerschleife ständigen neustartens gefangen gewesen. nach 3 Tagen googlen (iwas wegen -net host als parameter ein Problem beim Container erstellen), hab ichs aufgegeben und in einem Hyper-V RaspianOS aufgesetzt und die Sache war nach 5min erledigt...
eine Frage nur bzgl. ioBroker: wenn ich neustarte gibts bei mir für 2min mal keine Neuen IPs bzw keine DNS Auflösung. Sobald die VM wieder läuft rennt alles sofort wieder. (sogar die Systemzeit ist korrekt?) wo wäre das Problem. und ganz ungefragt startet Windows ja trotzdem nicht neu.
Ich würd mir an deiner Stelle die ganze Arbeit sparen, es lassen wie es ist oder wieder zurückgehen, einen RPi für Pihole und ioB aufsetzen und die Windowsmaschine macht deine ganze Backup/daten arbeit. fertig.
PS: noch das hier gefunden: https://www.normanbauer.com/2019/02/23/iobroker-unter-windows-installieren/
w#re das eine Alternative für dich?
eine Frage nur bzgl. ioBroker: wenn ich neustarte gibts bei mir für 2min mal keine Neuen IPs bzw keine DNS Auflösung. Sobald die VM wieder läuft rennt alles sofort wieder. (sogar die Systemzeit ist korrekt?) wo wäre das Problem. und ganz ungefragt startet Windows ja trotzdem nicht neu.
Ich würd mir an deiner Stelle die ganze Arbeit sparen, es lassen wie es ist oder wieder zurückgehen, einen RPi für Pihole und ioB aufsetzen und die Windowsmaschine macht deine ganze Backup/daten arbeit. fertig.
PS: noch das hier gefunden: https://www.normanbauer.com/2019/02/23/iobroker-unter-windows-installieren/
w#re das eine Alternative für dich?
Grundsätzlich stimmt das, ein "normaler" Neustart ist nach 3-5 Minuten erledigt, was sich durch eine SSD statt der 2,5" Platte noch deutlich beschleunigen ließe. Das ist alles kein Problem. Wenn z.B. aber mal größere Updates anstehen oder das Betriebssystem warum auch immer abstürzt (schon vorgekommen), läuft halt auch mal für längere Zeit nichts. Wenn ich dann nicht zu Hause bin kann keiner was machen.
Jetzt bin ich z.B. für ne Woche außer Haus. Hier ist niemand sonst im Haushalt der ansatzweise wüsste, was dann zu tun ist wenn Pi-Hole nicht mehr läuft und es besteht auch kein Interesse sich da einzuarbeiten. Also nehme ich Pi-Hole vorsorglich komplett aus dem Netz raus und gehe einem, vermutlich nicht auftretenden, Problem so aus dem Weg.
Ich tendiere aktuell zu zwei Ansätzen:
1.) alles so lassen wie es ist und ggf. zumindest Pi-Hole wieder auf einem Pi betreiben, da das das "kritischte" System ist was immer laufen sollte. Mein aktuell laufendes Konstrukt nachzubauen, nur mit Linux statt Windows ist für mich vermutlich zu schwierig.
2.) Proxmox mit einer VM für Pi-Hole, einer für ioBroker. ZFS Pool direkt in Proxmox anlegen und max. noch ne kleine VM mit Debian oder so um diesen Pool per Sambas verfügbar zu machen. Dann muss ich mir aber noch ne Lösung für die Backups überlegen, außer den VMs, überlegen.
ioBroker auf Windows hatte ich anfangs direkt so laufen, gab aber nur Probleme. Zumal dort dann eben das Snapshot Feature der VMs fehlt, was ich nicht missen möchte.
Jetzt bin ich z.B. für ne Woche außer Haus. Hier ist niemand sonst im Haushalt der ansatzweise wüsste, was dann zu tun ist wenn Pi-Hole nicht mehr läuft und es besteht auch kein Interesse sich da einzuarbeiten. Also nehme ich Pi-Hole vorsorglich komplett aus dem Netz raus und gehe einem, vermutlich nicht auftretenden, Problem so aus dem Weg.
Ich tendiere aktuell zu zwei Ansätzen:
1.) alles so lassen wie es ist und ggf. zumindest Pi-Hole wieder auf einem Pi betreiben, da das das "kritischte" System ist was immer laufen sollte. Mein aktuell laufendes Konstrukt nachzubauen, nur mit Linux statt Windows ist für mich vermutlich zu schwierig.
2.) Proxmox mit einer VM für Pi-Hole, einer für ioBroker. ZFS Pool direkt in Proxmox anlegen und max. noch ne kleine VM mit Debian oder so um diesen Pool per Sambas verfügbar zu machen. Dann muss ich mir aber noch ne Lösung für die Backups überlegen, außer den VMs, überlegen.
ioBroker auf Windows hatte ich anfangs direkt so laufen, gab aber nur Probleme. Zumal dort dann eben das Snapshot Feature der VMs fehlt, was ich nicht missen möchte.
Jesterfox
Legende
- Registriert
- März 2009
- Beiträge
- 44.484
Das Problem mit der langen Installationszeit der Updates hätte man mit Linux tatsächlich nicht mehr, das kann die im Hintergrund installieren und braucht dann nur noch evtl. den Neustart.
Fürs Backup kannst du ja evtl. dein Macrium auf einer Windows VM ausführen (die Windows Lizenz hast du ja schon)
Fürs Backup kannst du ja evtl. dein Macrium auf einer Windows VM ausführen (die Windows Lizenz hast du ja schon)
mercury
Lieutenant
- Registriert
- Jan. 2009
- Beiträge
- 748
ich weiß, physische server sind schwerer zu migrieren, zum testen herhalten usw., was spräche dagegen einfach ein Linux aufzusetzen wo ioB, pihole und samba läuft? und backups werden dann wohl auch noch zu bewerkstelligen sein (freefilesync zB.?!)
ganz ohne VMs und Windows.
ganz ohne VMs und Windows.
NJay
Rear Admiral
- Registriert
- Aug. 2013
- Beiträge
- 5.518
Was fuer einen Zugriff meinst du genau? PiHole per Docker zu starten ist ne sache von 5 Minuten und aleuft dann problemlos.Andi_bz schrieb:
mercury schrieb:
Also bei mir uns sehr vielen leuten die ich kenne (und sehr vielen leuten im Internet) laeuft PiHole in Docker problemlos.
mercury
Lieutenant
- Registriert
- Jan. 2009
- Beiträge
- 748
NJay schrieb:
sorry der hijack, aber kurzer Kommentar dazu:
Das ist mir bewusst, und auch wenn ich nicht auf die Formulierung geachtet hab, wollte ich nicht bashen. ich schließ mich selbst als Fehlerursache nicht aus. aber ich hatte genug Zeit vertan. Drum einfach dann auf HyperV umgestiegen und gut wars.
NJay
Rear Admiral
- Registriert
- Aug. 2013
- Beiträge
- 5.518
Im Docker-Container bist du auch root... Was willst du denn so konfigurieren, was du in Docker nicht kannst?Andi_bz schrieb:
Ergänzung ()
Dann musst du aber halt wieder ein ganzes OS updaten, etc und nicht nur einen Container... Gerade bei so kleinen Diensten, die einen Zweck erfuellen sind Container einfach am besten. Muss ja kein Docker sein, aber eine VM ist da einfach unnoetiger Overhead.mercury schrieb:
Sorry aber dann hast du die Funktionsweise von Docker nicht verstanden. Anpassungen kann man wunderbar persistent machen. Wenn du beim Start eigene Configfiles rein kopieren willst oder Anpassungen an installierten Paketen im Container vornehmen willst nimmst dein eigenes Dockerfile und wenn es nur um Config- und/oder Nutzdaten geht dann nimmt man bei Docker entsprechende Volumes.
DAS ist ja gerade der vergleichsweise große Vorteil von Docker. Die komplette und vollständige Trennung von Anwendung und Nutzdaten, also Inhalt der Anwendung und deren Konfiguration. Habe ich Backups der Volumes kann ich das gesamte Konstrukt jederzeit auf nem Laptop, Raspi, Server, $Cloud (also Server der anderen gehört), etc starten lassen und hochziehen und muss nicht nach Installation des OS damit anfangen die einzelnen Pakete zu installieren, irgendwas zu konfigurieren und so weiter.
DAS ist ja gerade der vergleichsweise große Vorteil von Docker. Die komplette und vollständige Trennung von Anwendung und Nutzdaten, also Inhalt der Anwendung und deren Konfiguration. Habe ich Backups der Volumes kann ich das gesamte Konstrukt jederzeit auf nem Laptop, Raspi, Server, $Cloud (also Server der anderen gehört), etc starten lassen und hochziehen und muss nicht nach Installation des OS damit anfangen die einzelnen Pakete zu installieren, irgendwas zu konfigurieren und so weiter.
Zuletzt bearbeitet:
mercury
Lieutenant
- Registriert
- Jan. 2009
- Beiträge
- 748
Das ist mir alles klar. drum wollte ich es ja auch so machen. wenn ich wieder mehr Luft hab, kann ichs mir ja wieder anschauen. ich wollte es einfach nur mal zum laufen bringen und fertig. wirklich eine Belastung durch die VM hab trotzdem nicht, die CPU AUslastung lt. Windows Anzeige rödelt so bei 3-5% im "idle" dahin. kann also nicht so schlimm sein^^NJay schrieb:
Mir ist schon klar für was man Docker verwendet. Wenn ich aber die Config selbst anpassen muss ist der nutzen ja schon wieder weg. Dann nimmt sich LXC(oder LXD) und Docker ja nicht viel.
Die vollständige Trennung von Anwendungen und Nutzerdaten hast du mit LXC auch. LXC unterscheidet sich nicht so viel zu Docker. Ist aber wenn man selbst viel Konfigurieren will oder muss das einfachere Format. Sind persönliche Erfahrungen die ich gemacht habe. Mit den Backups verhält es sich ähnlich. Wobei ich nicht den drang habe solche Container auf meinen Laptop laufen zu lassen.
Die vollständige Trennung von Anwendungen und Nutzerdaten hast du mit LXC auch. LXC unterscheidet sich nicht so viel zu Docker. Ist aber wenn man selbst viel Konfigurieren will oder muss das einfachere Format. Sind persönliche Erfahrungen die ich gemacht habe. Mit den Backups verhält es sich ähnlich. Wobei ich nicht den drang habe solche Container auf meinen Laptop laufen zu lassen.
Jo korrekt. Docker ist ja aus LXC heraus entsprungen und hat den Gedanken weiter entwickelt indem es den Buildprozess gibt der eben nen Basis Container nimmt, die vom Maintainer des Zielcontainers gewünschten Änderungen vornimmt wie z.B. die Installation von $Anwendung und das am Ende zu einem neuen Image packt was du dann laden und benutzen kannst.
Die von irgendwelchen Leuten bereit gestellten Images sind halt relativ generisch und wenn die eigene Situation Anpassungen notwendig macht muss man dies halt selber basteln.
Bei einem Single Host kann man, wenn man selbst viel anpassen will und muss das manuell per Hand machen oder mit Ansible, Chef, Puppet oder was auch immer und auf einen LXC los lassen. Oder ich nehm das Base Image und schreibe die gewünschten Anpassungen ins Dockerfile.
Ob ich jetzt ein Playbook oder Recipe oder Dockerfile schreibe ist relativ egal. So oder so muss ich es einmalig schreiben. Wenn sich dann eine Komponente ändert hab ich bei Docker den Vorteil der etwas einfacheren Versionierung. Ich lade das neue Image, baue mit meinem Dockerfile mein Ziel Image und starte daraus einen neuen Container parallel und kann gucken ob alles funktioniert hat.
Bei LXC würde ich den bestehenden Container klonen und manuell oder wieder per Playbook/recipe/whatever ein Update anstoßen.
Gerade weil man bei Docker vor dem Start alle Anpassungsschritte bereits eindeutig formuliert haben muss hat es sich ja so verbreitet. Egal wo ich das Image starte kann ich sicher sein, dass es sich identisch verhält und ich außer dem Docker Daemon keine weitere Abhängigkeit habe solange ich ggf. die Daten meines Volumes und den Docker Run Befehl bzw. die compose.yml oder vergleichbares für k8s habe. Wenn ich ein portables LXC haben will muss ich irgendwie auf das neue System ja meine Anpassungen bekommen.
Ich hab mich auch anfangs mit LXC beschäftigt und brauchte dann paar Monate intensives lernen um die etwas anders laufenden Mechanismen von Docker zu verstehen und anzuwenden.
Mit der Portabilität kann ein Entwickler etwas bei sich auf dem PC testen und wenn es läuft auf unsere Cluster schieben und es wird dort genau so laufen ohne dass ich daran etwas anpassen muss.
Aber ja dieses Konstrukt von Docker kann Hirnknoten erzeugen und macht es heute noch oft genug bei mir und wer den Quatsch nicht beruflich regelmäßig machen muss für den ist LXC vermutlich deutlich angenehmer und verständlicher.
Die von irgendwelchen Leuten bereit gestellten Images sind halt relativ generisch und wenn die eigene Situation Anpassungen notwendig macht muss man dies halt selber basteln.
Bei einem Single Host kann man, wenn man selbst viel anpassen will und muss das manuell per Hand machen oder mit Ansible, Chef, Puppet oder was auch immer und auf einen LXC los lassen. Oder ich nehm das Base Image und schreibe die gewünschten Anpassungen ins Dockerfile.
Ob ich jetzt ein Playbook oder Recipe oder Dockerfile schreibe ist relativ egal. So oder so muss ich es einmalig schreiben. Wenn sich dann eine Komponente ändert hab ich bei Docker den Vorteil der etwas einfacheren Versionierung. Ich lade das neue Image, baue mit meinem Dockerfile mein Ziel Image und starte daraus einen neuen Container parallel und kann gucken ob alles funktioniert hat.
Bei LXC würde ich den bestehenden Container klonen und manuell oder wieder per Playbook/recipe/whatever ein Update anstoßen.
Gerade weil man bei Docker vor dem Start alle Anpassungsschritte bereits eindeutig formuliert haben muss hat es sich ja so verbreitet. Egal wo ich das Image starte kann ich sicher sein, dass es sich identisch verhält und ich außer dem Docker Daemon keine weitere Abhängigkeit habe solange ich ggf. die Daten meines Volumes und den Docker Run Befehl bzw. die compose.yml oder vergleichbares für k8s habe. Wenn ich ein portables LXC haben will muss ich irgendwie auf das neue System ja meine Anpassungen bekommen.
Ich hab mich auch anfangs mit LXC beschäftigt und brauchte dann paar Monate intensives lernen um die etwas anders laufenden Mechanismen von Docker zu verstehen und anzuwenden.
Mit der Portabilität kann ein Entwickler etwas bei sich auf dem PC testen und wenn es läuft auf unsere Cluster schieben und es wird dort genau so laufen ohne dass ich daran etwas anpassen muss.
Aber ja dieses Konstrukt von Docker kann Hirnknoten erzeugen und macht es heute noch oft genug bei mir und wer den Quatsch nicht beruflich regelmäßig machen muss für den ist LXC vermutlich deutlich angenehmer und verständlicher.
So, mal ein kurzes Update und weitere Fragen von meiner Seite.
Gestern ist meine neue SSD angekommen. Ich habe mich dann entschieden, dort einfach mal Proxmox zu testen.
Gesagt getan und mittlerweile läuft PiHole problemlos in einem LXC Container und ioBroker + Deconz in einer Debian VM (VM habe ich genommen, da ich doch öfter von Problemen mit dem Durchreichen von USB Sticks gelesen habe). Das ging alles viel einfach als ich gedacht hätte und bisher bin ich schwer begeistert von Proxmox.
Bleibt nur noch ein zu lösender Zweck - die NAS Funktionalität. Zum Testen habe ich einfach mal eine kleine SSD mit in den Rechner gehangen und mit Ext4 formatiert. Ext4 deshalb, da ich für ZFS denke ich nicht genug RAM habe und die Vorteile nicht benötige. Die Platten sind eh gespiegelt als 1:1 Backup außerhalb des Rechners vorhanden und ändern sich praktisch kaum.
Erst habe ich direkt im Proxmox Host Samba installiert und die SSD freigegeben. Da ich ja aber zukünftig noch automatisierte Backups mit Cryptomator/Google Drive möchte habe ich dann doch noch eine Ubuntu VM erstellt.
Bitte denkt immer daran, dass ich keine Linux Kenntnisse habe ;-)
Soweit so gut - ich habe die SSD freigegeben bekommen und kann sowohl mit Windows und Chromebook zugreifen, die Geschwindigkeit ist mit 5-6 MB/Sek. beim Schreiben allerdings sehr niedrig unabhängig davon ob Freigabe direkt in Proxmox oder über die Ubuntu VM mit durchgereichter SSD. Lesen ist ca. doppelt so schnell.
1.) wo liegt der Fehler? Ich wollte gerne Samba nutzen, da es wohl die größte Kompativilität bietet. Ist die Geschwindigkeit deswegen so niedrig?
2.) eigtl. würde ich die Freigabe gerne auf der Host-SSD machen und keine separate SSD nutzen, da die eh zu groß ist. Kann ich die nachträglich noch irgendwie partitionieren, so dass ich von der 240 GB System SSD noch 20 GB abzwacken kann für die Netzwerkfreigabe?
3.) wie gehe ich nun bei meinen 3 TB Datenplatten vor, von denen jeweil zwei gespiegelt sind? zwei löschen, mit Ext4 formatieren, in Proxmox einbinden und dann per Netzwerkfreigabe die Daten wieder rüber schaufeln? Dauert bei o.g. Geschwindigkeit natürlich ewig.
Danke!
Gestern ist meine neue SSD angekommen. Ich habe mich dann entschieden, dort einfach mal Proxmox zu testen.
Gesagt getan und mittlerweile läuft PiHole problemlos in einem LXC Container und ioBroker + Deconz in einer Debian VM (VM habe ich genommen, da ich doch öfter von Problemen mit dem Durchreichen von USB Sticks gelesen habe). Das ging alles viel einfach als ich gedacht hätte und bisher bin ich schwer begeistert von Proxmox.
Bleibt nur noch ein zu lösender Zweck - die NAS Funktionalität. Zum Testen habe ich einfach mal eine kleine SSD mit in den Rechner gehangen und mit Ext4 formatiert. Ext4 deshalb, da ich für ZFS denke ich nicht genug RAM habe und die Vorteile nicht benötige. Die Platten sind eh gespiegelt als 1:1 Backup außerhalb des Rechners vorhanden und ändern sich praktisch kaum.
Erst habe ich direkt im Proxmox Host Samba installiert und die SSD freigegeben. Da ich ja aber zukünftig noch automatisierte Backups mit Cryptomator/Google Drive möchte habe ich dann doch noch eine Ubuntu VM erstellt.
Bitte denkt immer daran, dass ich keine Linux Kenntnisse habe ;-)
Soweit so gut - ich habe die SSD freigegeben bekommen und kann sowohl mit Windows und Chromebook zugreifen, die Geschwindigkeit ist mit 5-6 MB/Sek. beim Schreiben allerdings sehr niedrig unabhängig davon ob Freigabe direkt in Proxmox oder über die Ubuntu VM mit durchgereichter SSD. Lesen ist ca. doppelt so schnell.
1.) wo liegt der Fehler? Ich wollte gerne Samba nutzen, da es wohl die größte Kompativilität bietet. Ist die Geschwindigkeit deswegen so niedrig?
2.) eigtl. würde ich die Freigabe gerne auf der Host-SSD machen und keine separate SSD nutzen, da die eh zu groß ist. Kann ich die nachträglich noch irgendwie partitionieren, so dass ich von der 240 GB System SSD noch 20 GB abzwacken kann für die Netzwerkfreigabe?
3.) wie gehe ich nun bei meinen 3 TB Datenplatten vor, von denen jeweil zwei gespiegelt sind? zwei löschen, mit Ext4 formatieren, in Proxmox einbinden und dann per Netzwerkfreigabe die Daten wieder rüber schaufeln? Dauert bei o.g. Geschwindigkeit natürlich ewig.
Danke!
Klassischer Anfängerfehler^^ Du änderst dölfzig Dinge auf einmal und parallel nutzt du Dinge an den vorgesehenen Leitplanken vorbei.
Ja, man kann bei Proxmox noch zig weitere Dinge installieren und in den meisten Fällen ist das kein Problem solange dies die vorgesehenen Funktionen nicht beeinträchtigt oder irgendwie damit interagieren soll. Dann kann es zwar funktionieren aber man sollte wissen was man da macht.
Ansonsten klassische Fehlereingrenzung und suche oder: Teile und herrsche. Entferne unnötige Komplexität, eliminiere Variablen und grenze das Problem ein.
Wenn es da schon lahm ist stimmt irgendwas mit der SSD nicht oder falsches Alignment etc aber du brauchst dann den Fehler nicht im Netzwerk oder bei Samba suchen.
Zu 2: Kommt drauf an, wie diese jetzt partitioniert ist. Der Installer fragte dich was du willst. Also: Was hast du da angegeben und ausgewählt? Alternativ finde heraus, wie das System jetzt partitioniert ist. Proxmox basiert auf Debian, also sollten alle möglichen Debian oder Ubuntu Tutorials/Wikis/etc ein brauchbarer Ansatz sein. Wenn wir wissen, wie die jetzige Situation aussieht dann können wir weiter sehen.
Zu 3: Backups der Daten anlegen, Disks löschen, in Proxmox einbinden, optional per zfs oder mdadm gewünschtes Raidlevel erzeugen, Dateisystem anlegen, Disks mounten. Backup zurück spielen. Wenn du sinnvollerweise zuerst 1) löst dann geht das zurück spielen auch schneller
Ja, man kann bei Proxmox noch zig weitere Dinge installieren und in den meisten Fällen ist das kein Problem solange dies die vorgesehenen Funktionen nicht beeinträchtigt oder irgendwie damit interagieren soll. Dann kann es zwar funktionieren aber man sollte wissen was man da macht.
Ansonsten klassische Fehlereingrenzung und suche oder: Teile und herrsche. Entferne unnötige Komplexität, eliminiere Variablen und grenze das Problem ein.
Nein, das ist nicht normal. Erste Idee: Mach nen Benchmark unter Proxmox. Hier oder hier.Fabian schrieb:
Wenn es da schon lahm ist stimmt irgendwas mit der SSD nicht oder falsches Alignment etc aber du brauchst dann den Fehler nicht im Netzwerk oder bei Samba suchen.
Zu 2: Kommt drauf an, wie diese jetzt partitioniert ist. Der Installer fragte dich was du willst. Also: Was hast du da angegeben und ausgewählt? Alternativ finde heraus, wie das System jetzt partitioniert ist. Proxmox basiert auf Debian, also sollten alle möglichen Debian oder Ubuntu Tutorials/Wikis/etc ein brauchbarer Ansatz sein. Wenn wir wissen, wie die jetzige Situation aussieht dann können wir weiter sehen.
Zu 3: Backups der Daten anlegen, Disks löschen, in Proxmox einbinden, optional per zfs oder mdadm gewünschtes Raidlevel erzeugen, Dateisystem anlegen, Disks mounten. Backup zurück spielen. Wenn du sinnvollerweise zuerst 1) löst dann geht das zurück spielen auch schneller
@snaxilian
Hmm grundsätzlich habe ich "neben den Leitplanken" her ja nur Samba direkt im Host installiert und mittlerweile auch wieder deinstalliert, oder was meinst du sonst noch damit?
Zu meinen Tests:
In der ubuntu VM per dd eine 1 GB große Datei anlegen dauert 5 Sekunden. In der ubuntu VM innerhalb der Netzwerkfreigabe im gleichen Ordner Datei kopieren und einfügen läuft auch mit >50 MB/s.
Hmm grundsätzlich habe ich "neben den Leitplanken" her ja nur Samba direkt im Host installiert und mittlerweile auch wieder deinstalliert, oder was meinst du sonst noch damit?
Zu meinen Tests:
- Geschwindigkeitstests direkt auf dem Host und auch in der Ubuntu VM auf beiden SSD mit >200 MB/Sek. unauffällig
- SSDs wurden beide direkt in Proxmox formatiert, daher denke ich auch das ist korrekt gelaufen
- während der Installation habe ich ausgewählt, das die gesamte erste SSD für Proxmox genutzt werden soll, eine erweiterte Konfiguration habe ich nicht gemacht
- die zweite SSD ist ebenfalls mit ext4 direkt auf dem Host mit einer Partitionen partitioniert worden
In der ubuntu VM per dd eine 1 GB große Datei anlegen dauert 5 Sekunden. In der ubuntu VM innerhalb der Netzwerkfreigabe im gleichen Ordner Datei kopieren und einfügen läuft auch mit >50 MB/s.
Zuletzt bearbeitet:
Proxmox bietet ja neuerdrings auch eine Installation direkt mit ZFS an. Falls es ZFS ist, dann ggf. mal für das Dataset sync auf disabled setzen. Sync Writes ohne passende Hardware drunter ist sehr langsam.
Ansonsten macht Samba direkt auf dem Proxmox Host keine Probleme. Habe einige Instanzen so am laufen. Manche tau frisch installiert, manche bereits vor Jahren installiert und einfach nur Versionsmäßig mit hochgezogen. Auf keinem der Hosts gibts Performancesprobleme mit Samba
Was sagt den die VM Auslastung während des Kopierens von einem externen Client über CIFS? CPU Load? Load? Ram Auslastung? Was für eine Netzwerkkarte als du deiner VM verpasst? VirtIO?
Ansonsten macht Samba direkt auf dem Proxmox Host keine Probleme. Habe einige Instanzen so am laufen. Manche tau frisch installiert, manche bereits vor Jahren installiert und einfach nur Versionsmäßig mit hochgezogen. Auf keinem der Hosts gibts Performancesprobleme mit Samba
Was sagt den die VM Auslastung während des Kopierens von einem externen Client über CIFS? CPU Load? Load? Ram Auslastung? Was für eine Netzwerkkarte als du deiner VM verpasst? VirtIO?
Zuletzt bearbeitet:
Installiert ist Proxmox auf Ext4, nicht ZFS.
CPU Auslastung liegt beim Schreiben bei ca. 20%. Speicherauslastung ist generell bei 2 GB Ram bei ca. 80-90% also immer relativ voll.
Und ja, VirtIO.
CPU Auslastung liegt beim Schreiben bei ca. 20%. Speicherauslastung ist generell bei 2 GB Ram bei ca. 80-90% also immer relativ voll.
Und ja, VirtIO.
Zuletzt bearbeitet:
So und nochmal verwunderliches von meiner Seite.
Ich habe nun schon einmal eine 3 TB Platte direkt in Proxmox eingebunden und zwar mit NTFS, da dies ja mittlerweile unterstützt wird.
Daraufhin habe ich einmal getestet wie die Geschwindigkeit so ist. Siehe da, selbst über W-LAN 60 MB/s schreiben und knapp 90 MB/s lesen.
Daraufhin habe ich es noch mal mit der zweiten SSD probiert und auch dort sind die Geschwindigkeiten massiv gestiegen. Außer einem Neustart von Proxmox und dem Einbau der 3 TB Platte habe ich nichts gemacht
naja soll mir recht sein.
So, meine Konfiguration ist nun wie folgt:
240 GB SSD als Systemplatte auf der auch die VMs gespeichert sind - ext4 formatiert
40 GB SSD als "persönliche Cloud" - ext4 formatiert
3 TB Datenplatte aus dem Windows PC - NTFS formatiert
nun noch einmal bitte eure Meinung. Gibt es wirklich gute Gründe, die 3 TB Platte nun auf ext4 umzuformatieren? Die Daten ändern sich praktisch nicht mehr und sind als 1:1 Backup auf externer Platte vorhanden. Ich sehe momentan nicht wirklich einen Grund, alles zu löschen um es dann wieder zurück zu kopieren, oder übersehe ich was?
Danke.
Ich habe nun schon einmal eine 3 TB Platte direkt in Proxmox eingebunden und zwar mit NTFS, da dies ja mittlerweile unterstützt wird.
Daraufhin habe ich einmal getestet wie die Geschwindigkeit so ist. Siehe da, selbst über W-LAN 60 MB/s schreiben und knapp 90 MB/s lesen.
Daraufhin habe ich es noch mal mit der zweiten SSD probiert und auch dort sind die Geschwindigkeiten massiv gestiegen. Außer einem Neustart von Proxmox und dem Einbau der 3 TB Platte habe ich nichts gemacht
naja soll mir recht sein.So, meine Konfiguration ist nun wie folgt:
240 GB SSD als Systemplatte auf der auch die VMs gespeichert sind - ext4 formatiert
40 GB SSD als "persönliche Cloud" - ext4 formatiert
3 TB Datenplatte aus dem Windows PC - NTFS formatiert
nun noch einmal bitte eure Meinung. Gibt es wirklich gute Gründe, die 3 TB Platte nun auf ext4 umzuformatieren? Die Daten ändern sich praktisch nicht mehr und sind als 1:1 Backup auf externer Platte vorhanden. Ich sehe momentan nicht wirklich einen Grund, alles zu löschen um es dann wieder zurück zu kopieren, oder übersehe ich was?
Danke.
