[Sammelthread] Proxmox Stammtisch

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Das Problem hatte ich mit meiner MAX 8 unter ESXi mit Linux Guest auch. Alle möglichen Sachen mit msi etc. im Treiber und den ESXi Einstellungen durchprobiert. Wollte einfach nicht funktionieren, daher hab ich es nach einer Weile aufgegeben. Passthrough in eine Windows VM ging aber ohne Probleme.

Leider nein: In der Win10-VM bleibt auch ein "!" auf dem Treiber hängen, die Tunertreiber werden nicht geladen. Mir scheint das ein neues Problem zu sein. Leider habe ich aber etliche Hardware gewechselt (i3->Epyc z.B.), so dass ich mich zeitlich außer Stande sehe, die Verantwortlichkeit zu suchen. Ich bin mir aber sicher, "es ging früher mal"... :/
Firmware ist up-to-date auf 1.15b. Auch die hatte ich erneuert vor Kurzem.
 
kurze frage zu proxmox zfs? wenn zfs pool aus x platten besteht und auf eine datei zugegriffen wird, laufen dann alle platten an bzw. unterstützt proxmox überhaupt hdd spindown?

aktuell habe ich unraid aber bin so semi-zufrieden.
 
Theroetisch ja....aber in einem Raid sind ja die Blöcke verteilt, wenn man nicht spiegelt. Und selbst dann liest man von beiden Platten, weil schneller. Praktisch laufen die also 24/7.
 
ZFS ist Echtzeit Raid. Das bedeutet dass die Daten über die Platten verteilt sind und daher alle laufen müssen.

Vorteil:
Performance wächst mit der Anzahl der Platten. ZFS Dateisysteme haben im Gegensatz zu "alten" Partitionen keine feste Größe sondern bedienen sich dynamisch aus dem Datenpool. Wächst der, haben alle Dateisysteme automatisch mehr Platz. Kontrolliert wird das durch Reservierungen und Quotas (Speichervirtualisiserung).

Spindown wird wohl schon gehen, ist aber suboptimal. Einerseits müssen immer alle Platten anlaufen (Lebensdauer), andererseits dauert es bis zu einer Minute bis ein Pool wieder online ist.

Selbst bei einem Mirror wird immer von beiden Platten gelesen weil das doppelte Leseperformance bringt.
 
Zuletzt bearbeitet:
Fakt ist:
Proxmox verhindert einem spindown indem absichtlich alle paar Sekunden auf die Platten zugegriffen wird. Das wurde mir damals von den Entwicklern im proxmox Forum erklärt.

Und: nutzt man striped mirrors, dann läuft nur das Platten-Pärchen an, auf denen die angeforderte Datei liegt. Die anderen bleiben im spindown. So ist es zumindest bei meinem OMV Server mit zfs.
 
Nicht dass ich es bestreiten wollte, aber bei der Darstellung von Fakten wäre sicher auch ein Verweis auf die ursprüngliche Quelle hilfreich. Nachdem Du vermutlich noch keine 100 Beiträge im Proxmox Forum geschrieben hast, wäre Dein Aufwand hierfür auch überschaubar und trotzdem hilfreich.
 
und was ist, wenn die Daten noch in einem SSD-Cache sind?
 
Soweit ich mich erinnere ging es dabei um Consumer SSDs und warum die so schnell kaputt wear-leveln. Das lag daran, dass die Datenbank für das gemountete /etc/pve Dateisystem quasi dauerhaft gesyncht und geschrieben wird (besonders im Cluster, aber selbst auf einem Node) und der pvestatd halt dauernd versucht, Daten über alle Platten zu erfassen und die Graphen schreibt. Irgendwie extra Platten aktiv halten um die Nutzer zu ärgern gibt es nicht als "Feature".
 
Meine Festplatten gehen jetzt im standby. Hoffe ich zumindest [emoji2]
 
Zuletzt bearbeitet:
Meine Festplatten gehen jetzt im standby. Hoffe ich zumindest [emoji2]

Wozu braucht man soetwas auf einem Virtualisierungshost? Ich meine, bei einem reinen NAS ist das ja noch verständlich. Aber laufende vServer sollen doch auch im Hintergrund stets verfügbar bleiben. Wenn es da um Sachen wie Stromverbrauch geht weil beispielsweise Nachts niemand darauf zugreift, warum fährt man dann nicht den gesamten Host zu einer bestimmten Uhrzeit automatisch herunter und weckt diesen morgens per WakeOnLAN wieder auf? ;)
 
Wozu braucht man soetwas auf einem Virtualisierungshost? ...

Falsche Frage... Warum sollte man Techniken zum Stromsparen/schonen der Festplatten nicht einsetzen können? Nur weil Hampel XY das nicht braucht heißt das nicht, dass es niemand braucht. Du hörst dich fast so an wie die BSD Entwickler "ich brauch das nicht, somit braucht das niemand, BASTA!"
 
Grundsätzlich verhindert Proxmox keinen Spindown, aber man muss halt jegliches Monitoring abdrehen und die VM´s auf andere Platten auslagern.
 
Wenn man Platten bei einem Virtualisierungsserver in den Schlafmodus schicken möchte, so ist das ok wenn es sich um exklusive Platten einer VM (Filer, Backup etc) handelt und die VM das initiert aber wenig sinnvoll wenn darauf VMs liegen oder der Virtualisierungsserver das handhabt. Bis die Hochfahren ist eine VM vermutlich öfter mal längst abgestürzt oder Offline wegen timeout.

Aus Sicht einer VM hängt ja einfach die System oder Datenplatte geraume Zeit/ zu lange.
 
Ich will die fehlenden Stromsparoptionen im Proxmox auch aufgreifen: warum gibt es da nichts im WebUI? Ich lasse z.B. nun alle HDDs über ZFS + Samba im Host laufen, alle VM liegen dagegen auf einer großen SSD. Die Daten auf den Shares werden nur von einzelnen Anwendungen teilweise sehr selten benötigt. von 24h dürfen alle HDDs gerne 20h schlafen. Ich will definitiv im Host 11 oder 12 HDDs schlafen legen. Klappt aber nicht, weil die Konfig von Proxmox das eben nicht will.
Vermutlich lege ich jetzt doch wieder eine "Fileserver-VM" mit Sata-Controller-PT an, damit das geht. Auch irgendwie unnötig, oder?
Ein "Green-IT"- Reiter im WebUI wäre m.E. dringend angeraten.
 
Bis die Hochfahren ist eine VM vermutlich öfter mal längst abgestürzt oder Offline wegen timeout.

Der default timeout bei Linux/Win liegt bei 60sec - kein Aufwecken dauert so lang - und der min APD timeout bei ESX ist meines Wissens nach 20sec - auch das reicht dicke.
 
Zuletzt bearbeitet:
Man wird ja nicht eine einzelne Platte schlafen lassen wollen wegen 4 Watt. Bei mehreren Platten kommt eventuell noch verzögertes Hochfahren hinzu. Hinzu kommt eine Verzögerung bis ZFS den Pool wieder auf Verfügbarkeit prüft und die Services dann wieder arbeiten.

Kann alles schon mehr als 60s bedeuten.
Bei VMs kommt hinzu dass nicht nur das OS eine begrenzte Zeit wartet. Ein laufender Dienst in einer VM kann Daten in erheblich kürzerer Zeit erwarten.

Insgesamt sehe ich VM Storage und Spindown als nicht praktikabel an. Dann eher zwei ZFS Pools, einmal schneller SSD Pool ohne Spindown und allenfalls zusätzlich Plattenpool (nicht für VMs) mit Spindown und das allenfalls @home als Filer und Backup.

Ein weiteres Kriterium ist z.B. sync write einer VM oder mehrere abhängige Schreibaktionen bei der die VM keine Kontrolle über die Platten hat sondern diese aus Sicht der VM plötzlich "weg" sein können. Da wird sicher manche VM und Applikation kritisch reagieren.
 
Zuletzt bearbeitet:
@gea

Das Festplatten in den Standby zu schicken suboptimal ist, scheinst du dir wohl sicher zu sein. Ohne Einzelheiten zur Konfiguration zu kennen, würde ich mich an deiner Stelle nicht so weit aus dem Fenster lehnen. Auch nicht was die Lebensdauer der Platten angeht.

Wenn jemand einmal die Woche oder alle zwei Wochen die Platte aufweckt, halte ich es für ein Gerücht das es bei einer modernen Festplatte schädlicher ist, als das sie ständig läuft.

Ich habe auf mein Proxmox 5 Festplatten. 1x m2 mit proxmox, vms und snapshots. Vms sind Xpenology und ein Debian. 1x ssd mit Medien wie Musik und Fotos. 1x 2TB HDD für Dreambox Aufnahmen. 2x 4TB WD Red für Daten. Die Mechanischen Platten werden mit Xpenology verwaltet (NAS). Kein raid, da ich mit ein Backup besser dran bin.

Und jetzt erkläre mir, weshalb es Suboptimal ist die Mechanischen HDDs in standby zu schicken?

Wenn die festplatten bei mir verrecken, dann sicherlich nicht an den Spindowns [emoji2]

@MisterY

Debian Buster installiert, in Proxmox umgewandelt und hdparm konfiguriert.
 
Zuletzt bearbeitet:
Aber die Platten gehen in den Standby. Komischerweise, benutzt man die Proxmox ISO, gehen die Festplatten nicht in den standby.

Probiers doch selbst [emoji12]

Hdparm -y kannst du es testen.

@morph027

Deine Theorie mit dem pvestatd kann nicht stimmen. Ich glaube nicht das es bei alle Laufwerke Daten schreibt.
 
Zuletzt bearbeitet:
Wenn jemand einmal die Woche oder alle zwei Wochen die Platte aufweckt, halte ich es für ein Gerücht das es bei einer modernen Festplatte schädlicher ist, als das sie ständig läuft.

.

Es geht nicht um die Platten sondern darum dass man bei VM Storage den VMs die Platten unkontrolliert unter dem Hintern wegzieht. Wenn eine VM das selber mir Platten im eigenen Zugriff managt, ok - nicht aber wenn das die zugrundeliegende Virtualisierungsumgebung mit virtuellen Platten macht.
 
Genau das ist es. Bei mir sind die HDDs nicht unter storage eingebunden. Lediglich die m2 ist sichtbar wo sich alles abspielt.

Wie schädlich sind für die m2 diese ständige Zugriffe? Wo finde ich diese Datenbank bzw. Logs und wie groß sind die?

Edit: Das würde bedeuten das mit der Proxmox ISO alle HDDs in storage eingebunden sind und deshalb sie nicht in den standby gehen. Man das jemand bestätigen?
 
Zuletzt bearbeitet:
Ich habe noch eine Frage. Würde es nicht in kann den sata Controller in einem Xpenology oder openmediavault vm durchzureichen? Dabei denke ich an die Smart Werte, Temperatur, Power und akustik Management Möglichkeiten [emoji4]
 
Lies Dir Deinen Satz bitte nochmal durch und stelle Deine Frage erneut:
>>Würde es nicht in kann den sata Controller in einem Xpenology oder openmediavault vm durchzureichen?
 
Hallo zusammen,

ich bin ganz neue im Bereich Proxmoxx und mich würde interessieren, ob es eine gute/einfache Möglichkeit gibt, einen VPN-Server über LXC-Kontainer aufzusetzen?

Danke schon mal.
 
Es gibt ein template dafür. Musst nur das tun0 device hinzufügen. Da gibt es ein paar Anleitungen für. Hat bei mir aber nie geklappt
 
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