HP MicroServer Gen8 – sinnvolle Nutzungsideen?

Snuffchen

Snuffchen

Well-known member
Themenstarter
Registriert
7 Juli 2016
Beiträge
632
Hallo zusammen,

ich habe von einem Freund einen HP ProLiant MicroServer Gen8 mit 2 GB RAM und einem Celeron G1610T geschenkt bekommen.

Die vier verbauten Festplatten waren leider ziemlich am Ende – ich konnte gerade noch ein paar Bilder retten, bevor sie komplett den Geist aufgegeben haben. Inzwischen habe ich zwei „neue“ 2-TB-Festplatten eingebaut (Baujahr 2016, aber tatsächlich mit 0 Betriebsstunden) sowie eine SSD für das Betriebssystem.

Was ich allerdings ziemlich praktisch finde: iLO ist aktiviert. Leider läuft die Remote-Konsole nur mit einer alten .NET-Version bzw. einer veralteten Java-Version, was die Nutzung unter aktuellen Systemen etwas umständlich macht.

Der eingebaute B120i Smart-Controller ist ja mittlerweile doch recht betagt und wird von aktuellem Debian meines Wissens nach nicht mehr direkt unterstützt. Jetzt überlege ich, was man aus dem Server noch Sinnvolles machen könnte, außer ihn auf den Wertstoffhof zu bringen?

Ein RAM-Upgrade auf 16 GB (2×8 GB – das scheint ja das Maximum zu sein) wäre denkbar. Eventuell auch noch zwei zusätzliche SSDs.

Meine Idee wäre, ihn als kleinen Backup-Server zu nutzen, z. B. als Time-Machine-Ziel für Macs im Netzwerk.

Was meint ihr – lohnt sich das noch?
Habt ihr andere sinnvolle Einsatzideen für die Hardware?

Viele Grüße
Patrick
 
TimeMachine-Backup und OneDrive werde ich aber direkt auf der Maschine laufen lassen.
VPN-Router und Webdev-Kram kann dann als VM laufen
 
Ich vote auch für Proxmox. Bin etwas neidisch. Ich habe meinen N36l damals leider verkauft. Äußerst ärgerlich insb. aufgrund der Dicken Ram Ausstattung. Hege und pflege das Teil bis es außeinanderklappt. :)
Der pihole ist etwas performanter auf hardware mit wenig ram und CPU Leistung, da reicht ein pi zero aus. Da reichen 400-500m ram.
 
Ich hab in meinem Proxmox-System auch so allerhand laufen.
Unter anderem OpenMediaVault für die Freigaben.

Insgesamt ist man sehr flexibel und wird Software-Versuche auch schnell und Rückstandsfrei wieder los.
 
Ich bin so doof .. hab mich schon gefreut das ich die Xeon-CPU von einem deutschen Händler bei eBay gefunden hab.
War dummerweise LGA1151 statt LGA1155, also kommt das ganze jetzt nochmal hoffentlich richtig aus China 🫣
 
Ich würde alles in Proxmoxcontainern/VMs laufen lassen. Dann kannst du deinen Tiny mit den Proxmox-Backup-Server ausstatten & die virtuellen Systeme direkt einfach und automatisch backuppen.

Oder du packst auf den tiny auch Proxmox, machst aus beiden Systemen ein Cluster, kannst so z.b. Wireguard weiter darauf laufen lassen, aber auch nen Backup-Server als VM aufsetzen, der dann z.b. auf ne externe HDD backupt.
 
Ja da hast du ja recht, auf den Virtualisierungs-Hosts gehört sonst eigentlich nichts.
Der Tiny soll dann eigentlich wieder gehen, denn der HP ist ja Stromfresser genug und es ist letztlich für mich ja nur Spielerei.
Beitrag automatisch zusammengeführt:

Hab jetzt den Wireguard-Router und TimeMachine jeweils als LXC-Container erzeugen lassen, das spart Platz und Ressourcen.
Beitrag automatisch zusammengeführt:

Hab jetzt die zwei 2 TB Platten wieder raus, mit 9 Jahren sind mir die zu alt und zu laut. Stattdessen zwei 512 GB SSD rein. Stromverbrauch liegt jetzt bei 31 Watt, statt 35 Watt
Beitrag automatisch zusammengeführt:

Hab jetzt bei eBay noch günstig einen Intel Ethernet Server Adapter I350-T4 4x1GB I350T4G2P20 per Preisvorschlag ergattert, da könnte man ja sogar das VDSL-Modem anschließen und mit einer virtuellen OPNsense arbeiten. Es kommen immer mehr Ideen und das Groschengrab wird immer tiefer 🫣
 
Zuletzt bearbeitet:
Da der HP dann sowieso 24/7 laufen wird, kann er das ja direkt mitmachen und die virtuelle OPNsense ersetzt dann den TP-Link Multi-WAN-Router. Für den Notfall liegt der alte Router ja bereit und kann innerhalb von Minuten das Routing fürs Netzwerk übernehmen.
 
Vorhin kam die Intel I350-T4 Netzwerkkarte. Da noch kein Xeon im Server steckt, hab ich jetzt die erstmal nur als Bridges angelegt und in einer virtuellen OPNsense konfiguriert. Die OPNsense macht nun ab sofort den Internetzugang via PPPoE. Das klappt ziemlich gut und ich bekomme auch an den Clients die vollen 250 MBit die der VDSL-Anschluss liefert.
 
Laut DHL kommt mein Xeon E3-1265L V2 am Montag (hat dann ca. 10 Tage von China bis zu uns gebraucht). Seit Monat geht mein Heimnetzwerk über die virtuelle OPNsense ins Netzwerk und bisher funktioniert das einwandfrei. Hatte vorher noch ein kleine VM für das Wireguard-Routing, aber das macht die OPNsense nun direkt mit und der kleine Celeron schlägt sich erstaunlich gut als CPU im ProxMox-Server
 
Zuletzt bearbeitet:
Hab heute morgen nochmal auf den alten Router umgestellt, weil ein Prozessorwechsel ist ja nicht in 2 Minuten getan und und außerdem muss ich auch noch die I350-T4 Netzwerkkarte durchreichen. Ich würde dann vermutlich den Unmut meiner beiden Damen auf mich ziehen, wenn ich hier den Internetzugang für längere Zeit lahm lege. 😂
 
So einfach war das PCIe-Passthrough der I350-T4 Netzwerkkarte nicht, da es da mit Kernel 6.17 Probleme gibt. Ich hab mal die Versuche und Lösung von Claude zusammenfassen lassen, falls jemand auch mal das Problem hat:


PCIe Passthrough (Intel I350) broken after Proxmox Kernel 6.17 upgrade
System: Proxmox VE, Linux Kernel 6.17, Intel I350 Quad-Port NIC, VFIO-Passthrough an OPNsense VM

Symptom:
Nach Kernel-Upgrade auf 6.17 startete die VM nicht mehr bzw. die passierten Netzwerkkarten waren im Gast nicht sichtbar.
Im dmesg erschienen:
vfio-pci 0000:07:00.0: Firmware has requested this device have a 1:1 IOMMU mapping
DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR [0x00000000000e8000, 0x000000000010ffff]

Ursache (zweistufig)
1. Firmware-DMAR enthält fehlerhafte RMRR-Einträge
Das Mainboard-BIOS liefert eine ACPI DMAR-Tabelle (DMA Remapping Reporting), die für den I350 sogenannte RMRRs (Reserved Memory Region Reporting) enthält. Zwei davon zeigen in den Low-Memory-Bereich (0xe8000, 0xf4000) – ein bekannter Firmware-Bug bei manchen Server-Boards. Der Kernel 6.17 behandelt diese als fatal für VFIO-Passthrough.

2. Custom DMAR-Override wurde vom Kernel 6.17 still verworfen. Der übliche Workaround ist, eine bereinigte DMAR-Tabelle als Override in die initrd zu legen (via /etc/initramfs-tools/scripts/ oder direkt als AML-Datei). Das hat bis Kernel 6.16 funktioniert.

In Kernel 6.17 wurde in arch/x86/kernel/acpi/boot.c die Funktion acpi_os_physical_table_override() verschärft. Sie prüft nun per jae-Instruktion (jump if above or equal):

if (firmware_table->OemRevision >= override_table->OemRevision)
skip override; // Override wird verworfen!

Die Firmware-DMAR hatte OemRevision = 1. Unsere Override-DMAR hatte ebenfalls OemRevision = 1. Da 1 >= 1 → Override wurde stillschweigend ignoriert, obwohl die Datei korrekt geladen wurde. Kein Fehler, keine Warnung.

Fix
In der Override-DMAR-Tabelle (.aml-Datei) das Feld OemRevision von 1 auf 2 erhöhen und danach die Checksumme neu berechnen.

Binär-Patch (Hex-Editor oder Python):
# DMAR-Datei einlesen, OemRevision-Byte (Offset 0x18) auf 0x02 setzen,
# dann Checksumme (Offset 0x09) so anpassen, dass die Summe aller Bytes = 0x00 ergibt
data = bytearray(open('dmar_override.aml','rb').read())
data[0x18] = 0x02 # OemRevision erhöhen
data[0x09] = 0x00 # Checksum-Feld nullen
data[0x09] = (0x100 - (sum(data) & 0xFF)) & 0xFF # neue Checksumme
open('dmar_override.aml','wb').write(data)

Danach update-initramfs -u und Neustart.

Ergebnis
dmesg | grep -i "DMAR\|IOMMU\|rmrr"
  • Keine Firmware Bug: No firmware reserved region-Meldungen mehr
  • Keine 1:1 IOMMU mapping-Warnung für I350
  • Alle 4 I350-Ports korrekt an vfio-pci gebunden
  • OPNsense-VM startet und sieht alle Netzwerkkarten

Betroffene Setups

Jeder, der:
  • einen Custom DMAR-Override in der initrd nutzt (häufiger Workaround für I350/I210/onboard-NIC Passthrough)
  • auf Kernel 6.17 oder neuer aktualisiert hat
  • und danach VFIO-Passthrough still broken ist (kein expliziter Fehler über die Override-Datei)

Kernel 6.17 ignoriert ACPI-Table-Overrides mit gleichem OemRevision-Wert wie die Firmware.
Override-OemRevision muss größer als der Firmware-Wert sein.
Beitrag automatisch zusammengeführt:

Ein Problem kommt selten allein: Nachdem ich die OPNsense mit der neuen Netzwerkkarte erfolgreich zum Laufen gebracht habe, trat direkt das nächste Problem auf.

Nach einem Update auf OPNsense 26.1.4 scheint es zwei verschiedene Stellen im System zu geben, die denselben Prozess starten. Dadurch blockieren sich die Prozesse gegenseitig.

Konkret werden zwei dhcp6c-Instanzen für dasselbe Interface gestartet, allerdings mit unterschiedlichen Konfigurations- und PID-Dateien. Beide Prozesse landen dadurch dauerhaft in einer SOLICIT-Schleife, weil sie sich gegenseitig die DHCPv6-Antworten „wegnehmen“.

Die Folge ist, dass keine funktionierende IPv6-Prefix-Delegation zustande kommt. Dadurch wird im LAN kein IPv6-Präfix verteilt, und Clients erhalten keine IPv6-Adressen.

Weitere technische Details und die genaue Analyse sind im Bugreport beschrieben:
https://github.com/opnsense/core/issues/9924
 
Zuletzt bearbeitet:
War mein erster Bugreport. Also nochmal neu mit Template 🫣
Beitrag automatisch zusammengeführt:

Der Stromverbrauch ist durch den Xeon statt Celeron von 30 auf 37 Watt gestiegen
 
Zuletzt bearbeitet:
Proxmox ist Klasse, aber die 16 GB RAM schränken da doch sehr ein,
benutze es als ProxmoxBackupServer
 
Für Zuhause reicht mir das Dicke, hab noch einen etwas potenteren Server im RZ mit Hyper-V laufen.
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
  • ok1.de
  • thinkstore24.de
  • ok2.de - Notebook Computer Server
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben