[Sammelthread] Proxmox Stammtisch

Sync Write ist ein Sonderfall. Hier geht es um transaktions-sicheres Schreiben.
Um das schnell zu beherrschen braucht es teures Equippment, entweder Hardware Raid mit BBU oder ein schnelles ZIL was ähnlich teuer ist.

Ansonsten ist ZFS perfekt für Standard Hardware (ok, ECC ist nicht Standard sollte man bei einem Server aber immer machen. Viele Home/SoHo ZFS Systeme laufen problemlos ohne ECC, so wie mein Home Backup System)

Sync braucht man auch nicht immer. Das ist der Sonderfall. Ein SMB Server z.B. macht kein sync und braucht es auch nicht. Wenn der Server beim Schreiben abstürzt ist es wie unter Windows. Die Datei ist kaputt. Der Unterschied ist, das Dateisystem ZFS bleibt valide während ntfs eventuell im Wald ist. Sync wünscht man sich nur bei Datenbanken oder VM Storage mit "alten" Dateisystemen und nimmt dann ähnlich wie bei Raid+BBU die Kosten in Kauf.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
...danke für die rege Diskussionsbeteiligung. Das ganze ist nur ein Testsystem um ein wenig in Proxmox zu finden. Ich habe vor mir einen ML10v2 zu bestellen. Würde gerne zwei WD RED als ZFSpool (mirror) einbauen und eine SSD für Proxmox einbauen, dazu 16 GB RAM. Kann ich davon ausgehen, dass die Performance dort annehmbar ist (für einen Hoemserver)?
Habe ich richtig verstanden, dass Sync=disabled nur im worst case ein Problem macht und im "Normalbetrieb" Sync ruhig disabled sein darf?
 
Zuletzt bearbeitet:
...danke für die rege Diskussionsbeteiligung. Das ganze ist nur ein Testsystem um ein wenig in Proxmox zu finden. Ich habe vor mir einen ML10v2 zu bestellen. Würde gerne zwei WD RED als ZFSpool (mirror) einbauen und eine SSD für Proxmox einbauen, dazu 16 GB RAM. Kann ich davon ausgehen, dass die Performance dort annehmbar ist (für einen Hoemserver)?
Habe ich richtig verstanden, dass Sync=disabled nur im worst case ein Problem macht und im "Normalbetrieb" Sync ruhig disabled sein darf?

Der ML10v2 ist für einen Home-Server auf alle Fälle ausreichend, ich hab hier seit ein paar Jahren einen HP MicroServer N54L mit 16G und 2x WD RED im Heimnetz laufen (zwar mit FreeNAS ZFS, aber das macht wohl keinen großen Unterschied). Kriege auf dem N54L lesend meist bis zu 110MB/s (über Gigabit-LAN), schreibend knapp unter 100 MB/s. Der ML10v2 ist gegenüber dem N54L auch mti dem Pentium schon deutlich potenter und kann dank gesockeltem Prozessor auf Xeon aufgerüstet werden, außerdem geht das RAM bis 32GB.

Als Faustregel für RAM bei ZFS sagt man, dass man pro 1TB im Pool mindestens 1GB RAM für ZFS "draufschlagen" sollte gegenüber dem RAM was man ohne ZFS verbauen würde, wenn Du also 2x4TB (?) als Mirror verbaust, bist Du mit 16GB in der Komfortzone.

Synchrones schreiben stellt sicher, dass bei Stromausfall alles geschrieben wurde. Wie gea schon geschrieben hat, würdest Du ohne sync bei einem Stromausfall zwar evtl. einen Datenverlust haben, aber ZFS stellt die Integrität des Filesystems sicher. Bei anderen Filesystemen kann das iin einem korrupten Filesystem enden. Datenbanken und NFS benutzen synchrones Schreiben
 
Der ML10v2 ist für einen Home-Server auf alle Fälle ausreichend, ich hab hier seit ein paar Jahren einen HP MicroServer N54L mit 16G und 2x WD RED im Heimnetz laufen (zwar mit FreeNAS ZFS, aber das macht wohl keinen großen Unterschied).

Die Frage ist evtl. die Virtualisierung? Vielleicht macht die VM auf dem ZFS-pool nochmal eine Performancebremse dar?
 
Die Frage ist evtl. die Virtualisierung? Vielleicht macht die VM auf dem ZFS-pool nochmal eine Performancebremse dar?

Willst Du das ZFS-Filesystem in einer VM laufen lassen? Virtualisieren von Storage ist IMHO keine so gute Idee, abgesehen davon, dass es möglicherweise auch die Performance drückt, musst Du den anderen VMs das Storage dann über NFS oder iSCSI zugänglich machen und das ist reichlich umständlich und riecht nach unnötiger Komplexität.

Ich experimentiere hier ja auch schon lange rum und will zum Jahreswechsel umstellen. Werde es wohl so machen, dass ZFS "ganz unten" läuft und alles andere in VMs, d.h. insbesondere auch Samba, NFS, etc.
 
Willst Du das ZFS-Filesystem in einer VM laufen lassen? Virtualisieren von Storage ist IMHO keine so gute Idee, abgesehen davon, dass es möglicherweise auch die Performance drückt, musst Du den anderen VMs das Storage dann über NFS oder iSCSI zugänglich machen und das ist reichlich umständlich und riecht nach unnötiger Komplexität.

Ich experimentiere hier ja auch schon lange rum und will zum Jahreswechsel umstellen. Werde es wohl so machen, dass ZFS "ganz unten" läuft und alles andere in VMs, d.h. insbesondere auch Samba, NFS, etc.

Nein, nein. Die idee war nur Proxmox auf der SSD zu installieren, einen pool erzeugen dann über STORAGE hinzufügen ZFS und dort die Vms drauf. Ist der Gedanke richtig bzw. gut?
 
Nein, nein. Die idee war nur Proxmox auf der SSD zu installieren, einen pool erzeugen dann über STORAGE hinzufügen ZFS und dort die Vms drauf. Ist der Gedanke richtig bzw. gut?

Wenn ich Dich richtig verstehe machst Du das gleiche wie ich: Proxmox auf eine SSD (mit ext3/4) installieren. Dann manuell einen ZFS-Pool aus HDDs im Proxmox-Debian anlegen und über die Proxmox-GUI einen Teil des ZFS-Pool für die VMs freigeben. Das erscheint mir für den geplanten Einsatz als Home-Server auch sinnvoll. Man sollte halt noch die relevanten Verzeichnisse der SSD (/etc) regelmäßig in den Pool sichern, damit man beim Ausfall der SSD nicht alles neu einrichten muss.

Beim Hinzufügen des Pools zum Storage darauf achten, dass Du es als ZFS hinzufügst und nicht als Directory/Folder, sonst gibt es Probleme beim Booten mit dem ZFS-Automount, da ist eine Racecondition drinnen (Proxmox befüllt die Ordner die dann vom zfs-Automount-Daemon nicht mehr gemountet werden können).

Samba, NFS und sonstige Dienste kommen dann in eigene Container, d.h. auf Proxmox-Ebene läuft fast nix außer das was Proxmox ohnehin mitbringt (vielleicht ein paar Snapshot / Backup Cronjobs).

So in etwa hab ich mir das auch gedacht, ob das so schlau ist, wird sich rausstellen. Was mir nicht so gut gefällt ist, dass Proxmox relativ "offen" ist, bei FreeNAS ist es schon nicht ganz einfach das System aus versehen oder absichtlich zu kompromitieren, weil das ganze Root-Filesystem read-only auf USB-Stick gemountet ist.
 
Wenn ich Dich richtig verstehe machst Du das gleiche wie ich: Proxmox auf eine SSD (mit ext3/4) installieren. Dann manuell einen ZFS-Pool aus HDDs im Proxmox-Debian anlegen und über die Proxmox-GUI einen Teil des ZFS-Pool für die VMs freigeben. Das erscheint mir für den geplanten Einsatz als Home-Server auch sinnvoll. Man sollte halt noch die relevanten Verzeichnisse der SSD (/etc) regelmäßig in den Pool sichern, damit man beim Ausfall der SSD nicht alles neu einrichten muss.

..wie genau sieht Deine Hardwarekonfiguration aus und wie steht es bei dir mit der Performance. Wieviel und welche Vm´s hast Du am laufen?
 
Miserable Werte typisch ZFS ohne SSD als Cache und dazu nur zwei Spindeln.
Ein L2ARC auf einer SSD lohnt sich für Heimanwender kaum, einige haben das mal getestet und katastrophal schlechte Hit-Ratios gehabt. Darüber kann man höchstens nachdenken, wenn man alle anderen Parameter perfekt angepasst und eine große Menge RAM (>= 64 GB) zur Verfügung hat, weil die Adressierung des Caches dauerhaft Speicher im RAM belegt (hier ein ausführlicher Beitrag zu dieser Problematik). ZFS profitiert in allererster Linie von RAM, weshalb dieser immer zuerst maximal ausgebaut werden sollte, bevor man über weitere Schritte nachdenkt.
 
Zuletzt bearbeitet:
..wie genau sieht Deine Hardwarekonfiguration aus und wie steht es bei dir mit der Performance. Wieviel und welche Vm´s hast Du am laufen?

Aktuell hab ich den ML10v2 nur im Experimentalbetrieb und die Hardware ist deutlich überdimensioniert (32GB ECC, eine 128GB SSD und 3xWD RED 4TB). Er läuft auch noch nicht 24/7, ich probier nur ab und zu ein paar Dinge aus. Echte Performance-Tests hab ich bisher noch nicht gemacht, einmal einen bonnie++-Test auf Proxmox-Ebene, der war sehr gut, ansonsten probiere ich mehr mit Containern herum und versuche herauszubekommen, ob ich den Systemwechsel zu Proxmox überhaupt machen will. Die für einen Home-Server ökonomisch nicht mehr sinnvolle Hardware ist einfach da um "Luft nach oben" zu haben. Ziel ist es, zum Jahreswechsel umzustellen und bis dahin herauszubekommen, wie ich es machen werde. Grundsätzlich könnte es auch wieder ein FreeNAS werden, aber momentan gefällt mir Proxmox schon ganz gut. Was mich am meisten stört ist das etwas unsicherere Grundkonzept - in FreeNAS ist es schon ziemlich schwer das System aus Versehen oder absichtlich kaputt zu machen, da das root-Filesystem vom USB-Stick read-only gemountet ist.

Mein "Produktivserver" ist seit ein paar Jahren ein FreeNAS was von USB-Stick bootet auf einem HP MicroServer N54L mit 16GB RAM und 2xWD RED Platten. FreeNAS ist rock-solid und eigentlich erfüllt es auch all meine Anforderungen als Home-Server, aber der Platz wird mir langsam zu Eng, also muss ich ohnehin demnächst etwas tun. Da ich mehr Erfahrung mit Linux-Containern sammeln will und mit meiner bisherigen Backup-Lösung unzufrieden bin (HDD-Docking-Station + eigene Skripte), dachte ich daran inkrementelle Backups auf einen zweiten Server zu machen, der immer nur kurz eingeschaltet ist und ansonsten als Cold-Standby dient. Vielleicht bekomme ich unter Linux die Backups mit Docking-Station auch besser hin als unter FreeNAS, dann wäre es ein reiner Cold-Standby und ich würde auf rotierende HDDs Backups machen...

Die Hardware-Leistung des N54L ist jedenfalls deutlich schlechter als beim ML10v2 (Passmark: der (2-Kern) N54L hat 1390, der (ebenfalls zweikern) Pentium ML10v2 schon 3278, mit dem (4/8-Kern)Xeon E3-1231v3 hat er sogar 9617 Passmark-Punkte). N54L hat auch nur SATA II, beim ML10v2 sind zwei SATA-Ports schon SATA III. N54L schafft über NFS oder SMB locker 110 MB/s, Schreibend meist um die 95 MB/s, das reicht mir bisher vollkommen aus und ich denke der ML10v2 wird nicht langsamer werden.

Als Anwendung habe ich vor allem NFs und SMB Share (u.a. Mac TimeMachine-Backup), zwei LogitechMediaServer mit meiner Musik für meine Squeezeboxen (getrennt für die Kids und die Erwachsenen), einen Plex-Server und noch ein paar andere Sachen (OwnCloud, BitTorrent), aber produktiv sind eigentlich nur die SMB-Shares und der Squeezebox-Server wichtig, weil sich sonst meine Frau bzw. die Kinder beschweren :) Achja, einen FHEM-Server will ich dann auch noch dahin migrieren, der läuft z.Zt. noch auf einem BananaPi.
 
SSDs sind eher zum verbrauchsgut geworden :)
120+ GB kosten grad mal 40€ ( 240er 70€/ 480er 130€) (da kann man mal super 2 im Mirror betreiben, was auch lohnt zwecks i/o) ... außer i/o limitiert ja kaum noch was (Anmerkung: ich lieben Marvel based SSDs)

Proxmox ist sicherlich nicht das "top notch" in Sachen Performance (wobei es wirklich super auch mit 40+ KVMs läuft), aber in Sachen Kosten/Nutzen und Easy use/Features

Auch bietet es (wenn auch nicht per GUI) sehr viele Features, grad nun bei 4.x welche Andere sich sehr teuer bezahlen lassen

fehlen tut eigentlich (für mich) nix ... da es auf einem debian läuft ...

klar ist BSD etwas "sicherer", "stormproof" ... aber um ehrlich zu sein.... im Bereich wo man proxmox einsetzt ist es top

Daheim hab ich auch Spice nun lieben gelernt :) - wobei Guacamole - http://guac-dev.org/ immernoch interessant bleibt (für daheim)

mobil liebe ich x2go :)
 
Zuletzt bearbeitet:
Hallo zusammen,

ich muss nächste Woche einen neuen Proxmox Server aufsetzen (6-Kern Intel, 64 GB Ram) und habe die Wahl zwischen 2x3 TB Sata + 2x 240 GB SSD (Softwareraid) und 4x600 GB SAS (HWR 10).

Nun Frage ich mich, was im Endeffekt performanter sein dürfte. Ich würde die die SSDs mittels LVM als SSD-Cache einbinden. Die Lösung von LVM setzt dabei meines Wissens nach auf dm-cache auf.
Hat da jemand eine Meinung zu oder eventuell sogar Erfahrungen?

Vielen Dank.
 
warum nicht 2 SSDs + 2HDDs (jeweils als SWR 1 oder ZFS Mirror) ?

mixen würde ich nicht (das macht mehr aufwand als nutzen)

SSDs für Basis und die HDDs für 2. (aka Base Drive auf SSDs und 2. auf HDDs) - natürlich Thin Prov

zum Einstieg wäre ein SWR 1 einfacher
 
Zuletzt bearbeitet:
warum nicht 2 SSDs + 2HDDs (jeweils als SWR 1 oder ZFS Mirror) ?

mixen würde ich nicht (das macht mehr aufwand als nutzen)

SSDs für Basis und die HDDs für 2. (aka Base Drive auf SSDs und 2. auf HDDs) - natürlich Thin Prov

zum Einstieg wäre ein SWR 1 einfacher

Ich würde durchaus auch ZFS nutzen, allerdings sind meine bisherigen Erfahrungen mit ZoL nicht so berauschend gewesen (unter Solaris hingegen sehr gut).

SSD und HDD einfach getrennt im Raid 1 zu nutzen wäre auch eine Alternative. Allerdings ist das wegen schwer vorhersagbarer und stark schwankender Last auf den einzelnen VMs nicht so schön wie eine "automatische" Verteilung SSD Leistung via Cache.
 
Ich würde durchaus auch ZFS nutzen, allerdings sind meine bisherigen Erfahrungen mit ZoL nicht so berauschend gewesen (unter Solaris hingegen sehr gut).

SSD und HDD einfach getrennt im Raid 1 zu nutzen wäre auch eine Alternative. Allerdings ist das wegen schwer vorhersagbarer und stark schwankender Last auf den einzelnen VMs nicht so schön wie eine "automatische" Verteilung SSD Leistung via Cache.

ich merkte ja an, dass ich auch SWR 1 bevorzugen würde an deiner Stelle

die "Last" liegt eigentlich auf den SSds und die HDDs dienen als Storage - aka OS auf SSds und ein Store auf HDDs


auch geht es ohne jeden Raid ... dann halt per Backup (aka Bootstick auf Nas etc) .. ein Raid ist eh nur eine "Laufzeit" Sicherung und kein Backup
 
Zuletzt bearbeitet:
Ohne Raid 1 ist absolut keine Option. Ich mache natürlich täglich Backups aber Downtimes außerhalb des Wartungsfensters sind unbedingt zu vermeiden.

Die SATA Platten sind halt langsam und bisweilen erzeugen meine Webserver und die Windows VMs schon ordentlich Last. Das passt nicht unbedingt alles auf die SSDs, also wäre eine funktionierende Caching Lösung schon sehr praktisch.

Letztlich sollte doch DM-Cache von alleine alles was häufig angefragt wird im Cache halten und außerdem die vielen kleinen Schreibzugriffe (diverse Log-Dateien, SQL Server etc...) puffern. Oder?
 
mach was du magst :)

ich schilderte meine tipps

evtl haben andere mehr Tipps für dich "Die SATA Platten sind halt langsam und bisweilen erzeugen meine Webserver und die Windows VMs schon ordentlich Last" zeigt mir schon, dass du nicht gelesen hast
 
Zuletzt bearbeitet:
mach was du magst :)

ich schilderte meine tipps

evtl haben andere mehr Tipps für dich "Die SATA Platten sind halt langsam und bisweilen erzeugen meine Webserver und die Windows VMs schon ordentlich Last" zeigt mir schon, dass du nicht gelesen hast

Ich bin ja dankbar für jede Hilfestellung und du kannst dir sicher sein, dass ich jeden Post auf den ich antworte auch lese. Aber was du damit nun sagen willst erschließt sich mir nicht ganz...
Mein Problem ist ja nun mal, dass nicht alles was auf die SSDs müsste auch auf die SSDs passt und dass sich diese Verteilung bisweilen ändert. Wenn alles was Random Writes erzeugt auf die SSDs passen würde, dann wäre ja alles gut und ich müsste über Caches nicht nachdenken. Ich habe z.B. Windows VMs die meistens vor sich hin dümpeln, aber 1-2x pro Woche stark genutzt werden. Die würden von SSD Speicher dann super profitieren, aber es lohnt sich eben nicht dauerhaft, da ich die Leistung an anderer Stelle häufiger benötige.

Also zurück zur Ausgangsfrage: Hat irgendjemand Erfahrungen mit SSD-Caches unter Proxmox? Wie ist die Leistung von 4x600 GB SAS im Raid 10 im Vergleich zu der Sata HDD + SSD Kombination einzuschätzen?

Ich habe die Wunschvorstellung, dass ein SSD-Cache all die kleinen Random-Writes abfangen würde, die ein Sata Raid 1 bei Proxmox so schrecklich langsam machen.
 
was "muss" bei dir auf ne SSD ?

ein web stack inkl os verbraucht 1-2GB
 
Meine letzten versuche mit dmcache, bcache, etc waren nicht so berauschend...
 
was "muss" bei dir auf ne SSD ?

ein web stack inkl os verbraucht 1-2GB

Die MySQL DBs und unbedingt und wenn möglich auch die OS Installationen und Programme.

Ich denke ich probiere die Caching Lösung einfach aus (wenn ich Zeit habe sogar im Vergleich mit SAS Raid 10) und entscheide dann. Bei Interesse würde ich die Ergebnisse hier teilen.
 
Was willst du bitte mit 240 GB Cache? Ich bin mir ziemlich sicher, dass du nicht den von dir gewünschten Performanceschub spüren wirst, außer es wird wenig geschrieben und es werden immer die gleichen statischen Inhalte abgerufen. Dann könnte man die Daten aber auch gleich auf eine SSD legen.
 
Was willst du bitte mit 240 GB Cache? Ich bin mir ziemlich sicher, dass du nicht den von dir gewünschten Performanceschub spüren wirst, außer es wird wenig geschrieben und es werden immer die gleichen statischen Inhalte abgerufen. Dann könnte man die Daten aber auch gleich auf eine SSD legen.

Das soll ja nicht bzw. nicht nur eine Lese Cache, sondern vor allem ein Schreibcache sein. Das Problem bei vielen virtuellen Maschinen ist ja, dass es ununterbrochen viele kleine verteilte Schreibzugriffe gibt und damit bricht die Leistung eines SATA HDD Raid 1 eben stark ein.
 
Mit ZFS? Das nimmt sich nie soviel Cache...bzw. ist das auch kein Schreibcache im wortwörtlichen Sinne.

Code:
                                                             capacity     operations    bandwidth
pool                                                      alloc   free   read  write   read  write
--------------------------------------------------------  -----  -----  -----  -----  -----  -----
backup-2tb                                                 810G  1.02T      0      0  1.34K  4.37K
  mirror                                                   810G  1.02T      0      0  1.34K  4.37K
    dm-name-2tb1                                              -      -      0      0    345  4.73K
    dm-name-2tb2                                              -      -      0      0  1.02K  4.73K
logs                                                          -      -      -      -      -      -
  mirror                                                   144K  4.97G      0      0      0      0
    ata-Samsung_SSD_840_PRO_Series_S1AXNSAD808066T-part3      -      -      0      0      2      2
    ata-Samsung_SSD_840_PRO_Series_S1AXNSAD808021W-part3      -      -      0      0      2      2
--------------------------------------------------------  -----  -----  -----  -----  -----  -----
data-4tb                                                  2.08T  1.54T      0      0  12.0K  5.25K
  mirror                                                  2.08T  1.54T      0      0  12.0K  4.36K
    dm-name-4tb1                                              -      -      0      0  6.29K  4.39K
    dm-name-4tb2                                              -      -      0      0  5.78K  4.39K
logs                                                          -      -      -      -      -      -
  mirror                                                   256K  4.97G      0      0      0    912
    ata-Samsung_SSD_840_PRO_Series_S1AXNSAD808066T-part2      -      -      0      0      2    962
    ata-Samsung_SSD_840_PRO_Series_S1AXNSAD808021W-part2      -      -      0      0      2    962
--------------------------------------------------------  -----  -----  -----  -----  -----  -----
rpool                                                     6.06G  68.4G      0     30    837   141K
  mirror                                                  6.06G  68.4G      0     30    837   141K
    sdd2                                                      -      -      0      8    383   152K
    sda2                                                      -      -      0      8    488   152K
--------------------------------------------------------  -----  -----  -----  -----  -----  -----
vm-400g                                                   58.0G   340G      0     49  9.25K   359K
  mirror                                                  58.0G   340G      0     49  9.25K   359K
    dm-name-400g1                                             -      -      0     17  4.30K   374K
    dm-name-400g2                                             -      -      0     17  5.27K   374K
--------------------------------------------------------  -----  -----  -----  -----  -----  -----
 
Ne ich dachte eher an den in LVM integrierten DM-Cache. ZFS war mein erster Plan, aber das scheint für mein Vorhaben nicht so geeignet zu sein.
Außerdem habe ich ein paar schlechte Erfahrungen mit ZoL gemacht.
 
Ein 240 GB großer Write-Cache ist aber nicht wirklich sinnvoll.
 
Ein 240 GB großer Write-Cache ist aber nicht wirklich sinnvoll.

Er muss ja nicht 240 GB groß sein.

Ich dachte mir ich mache mir ein paar SSD LVs für MySQL und gebe den Rest über DM-Cache dem ganzen System.
Was meinst du, welche Größe bei ca. 1 TB Daten gerechtfertigt ist?


edit: Wie gesagt, Erfahrungen mit DM-Cache unter Proxmox scheint es fast nicht zu geben, also probiere ich es jetzt einfach mal aus.
Wenn es nichts bringt, kann ich die Konfiguration immer noch ändern oder mich für 4x600 GB SAS entscheiden.
Tipps zu Konfiguration oder Ideen um die DM-Cache Performance zu testen nehme ich gerne entgegen
 
Hallo Zusammen,

ich sitze gerade vor einem Problem und hoffe ich bekomme hier etwas Rat :)

Habe Xpenology in einer VM auf Proxmox am laufen.

Nun hätte ich gerne zwei physikalische USB3 Ports von meinem Dell T20 fest auf die Xpenology VM gemappt.

Laut Proxmox Wiki habe ich die IDs der Ports herausgefunden und in die qemu conf eingetragen.

Leider kann ich in die Ports reinstecken was ich will taucht nichts auf in der Synology Oberfläche.
Reiche ich allerdings einen USB Stick / Platte per -args und USB Geräte ID durch klappt es problemlos.

Kann mir hier jemand weiterhelfen?

Cheers!
Chris
 
SSDs sind eher zum verbrauchsgut geworden :)
120+ GB kosten grad mal 40€ ( 240er 70€/ 480er 130€) (da kann man mal super 2 im Mirror betreiben, was auch lohnt zwecks i/o) ... außer i/o limitiert ja kaum noch was (Anmerkung: ich lieben Marvel based SSDs)

Proxmox ist sicherlich nicht das "top notch" in Sachen Performance (wobei es wirklich super auch mit 40+ KVMs läuft), aber in Sachen Kosten/Nutzen und Easy use/Features

Auch bietet es (wenn auch nicht per GUI) sehr viele Features, grad nun bei 4.x welche Andere sich sehr teuer bezahlen lassen

fehlen tut eigentlich (für mich) nix ... da es auf einem debian läuft ...

klar ist BSD etwas "sicherer", "stormproof" ... aber um ehrlich zu sein.... im Bereich wo man proxmox einsetzt ist es top

Daheim hab ich auch Spice nun lieben gelernt :) - wobei Guacamole - http://guac-dev.org/ immernoch interessant bleibt (für daheim)

mobil liebe ich x2go :)

Danke für die Erwähnung von Guacamole, das muss ich mir mal ansehen.

Bezüglich der Sicherheit: sehr nett an FreeNAS finde ich, dass es mir E-Mails schickt, wenn es z.B. fehlgeschlagene Login-Versuche gibt oder an Mounts, Interface-Konfiguration oder so etwas geändert wurde, oder komische Dinge im Syslog stehen... das geht schon ein bisschen in Richtung Intrusion Detection. Gibt's da ein bewährtes, einfaches System, mit dem man auf Proxmox aufsetzend ähnliches machen kann?
 
Hallo zusammen,

ich versuche seit 3h Proxmox auf meinem Server zu installieren

Die HW sieht so aus: Supermicro X9SAE, Intel Xenon E3-1225v2, 16GB RAM, Crucail SSD

Mal davon abgesehen dass die Installation vom USB Stick nicht wirklich starten will, hilft dann nur die ISO von hand zu mounten.
Leider hängt sich das Setup noch vor der GUI auf. Irgendwie scheint ihm meine Onboard Audio nicht zu gefallen.

Habe das Setup auch schon von einer DVD ausprobiert, da ich die Lösung vom ISO mounten erst später gefunden habe, da läuft es aufs selbe raus.

Folgendes in etwas kommt raus
[44.085189] hdaudio hdaudioC0D0: unable to bind the codec
[44.085189] hdaudio hdaudioC0D3: unable to bind the codec

So sieht es aktuell aus
IMG_20151101_125335.jpg

Das beim ersten Versuch
IMG_20151101_121330.jpg

Habe den Jumper für die Onboard Audiokarte wieder auf enable gesetzt.
Jetzt mag er meine Ethernetkarte wohl nicht
Hat von euch einer einen Rat?
 
Zuletzt bearbeitet:
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