Onboard Sata Controller durchreichen, wo finde ich ihn?

tomtom45

Member
Feb 11, 2024
4
0
6
Hallo, ich habe einen Microserver Gen10Plus (v1) und möchte den Onboard Sata Controller durchreichen an eine VM. Proxmox ist auf einer M.2 installiert welche im PCIe Slot sitzt.

Die Geräte die Proxmox findet sind aber nur folgende:

Code:
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.

root@pve:~# lspci

00:00.0 Host bridge: Intel Corporation 8th/9th Gen Core Processor Host Bridge/DRAM Registers [Coffee Lake] (rev 07)

00:01.0 PCI bridge: Intel Corporation 6th-10th Gen Core Processor PCIe Controller (x16) (rev 07)

00:12.0 Signal processing controller: Intel Corporation Cannon Lake PCH Thermal Controller (rev 10)

00:14.0 USB controller: Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller (rev 10)

00:14.2 RAM memory: Intel Corporation Cannon Lake PCH Shared SRAM (rev 10)

00:16.0 Communication controller: Intel Corporation Cannon Lake PCH HECI Controller (rev 10)

00:16.4 Communication controller: Intel Corporation Cannon Lake PCH HECI Controller #2 (rev 10)

00:1b.0 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #21 (rev f0)

00:1c.0 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #1 (rev f0)

00:1d.0 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #9 (rev f0)

00:1d.1 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #10 (rev f0)

00:1d.2 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #11 (rev f0)

00:1d.3 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #12 (rev f0)

00:1f.0 ISA bridge: Intel Corporation C242 Chipset LPC/eSPI Controller (rev 10)

00:1f.5 Serial bus controller: Intel Corporation Cannon Lake PCH SPI Controller (rev 10)

01:00.0 System peripheral: Hewlett-Packard Company Integrated Lights-Out Standard Slave Instrumentation & System Support (rev 07)

01:00.1 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200eH3 (rev 02)

01:00.2 System peripheral: Hewlett-Packard Company Integrated Lights-Out Standard Management Processor Support and Messaging (rev 07)

01:00.4 USB controller: Hewlett-Packard Company iLO5 Virtual USB Controller

02:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)

02:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)

02:00.2 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)

02:00.3 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)

07:00.0 Non-Volatile memory controller: Intel Corporation NVMe Optane Memory Series


Ich hätte erwartet ich finde irgendetwas mit dem Namen "Sata". Versteckt sich das ganze hinter einem dieser Namen?
 
Last edited:
Ja ich überlege ein Nas mit TrueNAS zu virtualisieren möchte aber auf Proxmox nicht verzichten, momentan eigene Hardware dafür.
Ja mit Festplatten dran probiere ich später mal aus, hab sie abgehangen um beim Testen sicherzugehen dass nicht ausversehen dort etwas überschrieben wird.
 
Du kannst ja mal eine EFI-Shell (eventuell extern, wenn keine im BIOS integriert ist) laden und dort mit "pci" schauen, ob ein Gerät angezeigt wird.
Aber seltsam erscheint es natürlich, dass kein offensichtlicher Storage Controller zu finden ist.
 
Last edited:
  • Like
Reactions: Johannes S
Die gängige Methode zum Durchreichen an TrueNAS wäre doch nicht auf Ebene des Controllers, sondern der Platten?
So mit
Code:
qm set <VM-ID> -scsi<n> /dev/disk/by-id/SOME-DISK-ID
 
Nunja, Der einzige Hinweis dort ist das problematische write ordering. Und um das ganz klar zu sagen, das schalte ich auch unter PVE direkt immer ab, indem ich den Schreibpuffer der Platte auf 1 setze, seitdem ich festgestellt habe, dass es unter write pressure keine Garantie für ein echtes Flushing des SATA write buffers gibt.

Ich hatte nämlich genau damit Probleme, es traten immer wieder Pool Fehler auf und im Log konnte ich dann timeouts sehen.

Deshalb läuft bei mir im /etc/rc.local immer:

Code:
# set TLER to 7 seconds
for d in $(ls /dev | grep -E 'sd[a-z]$'); do
    # DO NOT DO THIS with ZFS, as the drives do not come up fast and will be faulted
    #smartctl -s standby,off /dev/$d >/dev/null ;
    #
    # set TLER to 7 seconds
    smartctl -d sat -l scterc,70,70 /dev/$d >/dev/null ;
    echo 1 >/sys/block/${d}/device/queue_depth
done

Will sagen: Für das Problem braucht es nicht mal passthru.
 
Last edited:
  • Like
Reactions: Johannes S
Nunja, Der einzige Hinweis dort ist das problematische write ordering. Und um das ganz klar zu sagen, das schalte ich auch unter PVE direkt immer ab, indem ich den Schreibpuffer der Platte auf 1 setze, seitdem ich festgestellt habe, dass es unter write pressure keine Garantie für ein echtes Flushing des SATA write buffers gibt.
Und damit sind wir dann schon direkt im Bereich der Sachen, auf die ein Anfänger gar nicht mal kommen würde ;) Also woran so ein Problem liegen könnte und wie man das löst. Von daher finde ich die Faustregel "Reich einen Storage-Controller durch oder lass das mit der NAS-Virtualisierung" nach wie vor stimmig. Plus das (auch bei Punkt 3) genannte Problem, dass das NAS nicht mehr an die SMART-Daten kommt (die zugegebenermaßen auch nur begrenzt vorwarnen, aber eben immer noch besser als nichts)..
 
Das mit dem Smart-Zugriff ist kein Problem, wenn man es auf dem PVE-Host macht (Punkt 4). Und wie gesagt, Punkt 3 glaube ich, ist das selbe, was ich beschrieben habe. Witzigerweise ist das übrigens bei aktuellen Kernels und / oder ZFS-Versionen gelöst - wobei ich nicht weiß, wie. Eventuell hat irgendwer geschnallt, dass der Plattencontroller keine längste Verweildauer garantiert und lässt vor dem Timeout die Queue leerlaufen.

Aber stimmt schon - ich habe das auch nur einmal probiert, als ich noch glaubte, TrueNAS unter PVE machte Sinn. In der Praxis ist das großer Mist.

Es gibt Dinge, die ich niemals mehr virtualisiert machen würde:

1. Firewall-Appliances wie OpnSense (abgesehen von Teststellungen).
(P.S.: Sonderfälle wie ungeeignete Hardware oder Cloudlösungen sind natürlich auch ausgenommen, siehe weiter unten)
2. NAS-Appliances wie TrueNAS. Tatsächlich ist das im Detail problematisch. Versucht mal, einen automatischen Ablauf hinzubekommen, mit Wake-On-LAN und Shutdown hinterher. Da schlagt Ihr Euch mit Skripten auf beiden Ebenen herum. Auch gut sind dann so Dinge wie zeitgleiche ZFS-Scrubs auf Wirt und Gast.

Ich setze aber auch nicht unbedingt ein separates Bare-Metal-NAS ein, sondern installiere eben NFS und Samba auf dem PVE-Host selbst. Entweder man traut der Virtualisierung oder man tut es nicht - da spielt es kaum eine Rolle, ob eine VM per Netzwerk oder direkt Zugriff auf die Platten hat.

Backup natürlich physisch davon getrennt und nur per Pull-Sync.
 
Last edited:
  • Like
Reactions: Johannes S
Oder man packt sich eben einen NFS- bzw. Samba-Server in eine VM oder einen Container je nach Usecase. Nur halt ohne das Appilance-Gerümpel. Bin bei mir ja auch am Überlegen, ob ich meine TrueNAS-VM nicht durch so ein Kontrukt ersetzen sollte, sobald ich den RAM brauche, mache ich das vermutlich auch ;)
Eine andere Frage ist, wie man generell zu Appilances steht, es gibt ja Leute die da grundsätzlich nichts von halten ( siehe https://blog.koehntopp.info/2004/07/13/appliances/ ). Ich sehe das nicht so absolut (setze ja selbst OPNsense und TrueNAS ein), aber Teile der Argumentation kann ich schon nachvollziehen. Vor Urzeiten musste ich mal mit einer Monitoring-Appilance arbeiten, das war genauso eine Blackbox wo intern ein hoffnungslos veraltetes Nagios lief, geil ist was anderes.


Firewall-Appliances wie OpnSense (abgesehen von Teststellungen).
Meintest du dazu nicht in deinen OPNSense-Forums-Beitrag dass es unter bestimmten Umständen schon sinnvoll sein kann (https://forum.opnsense.org/index.php?topic=44159.0 )? Und zwar wenn die Linux-Treiber der Netzwerkkarte besser ist oder man eine Firewall auf einen Mietserver benötigt? Sind das die berühmten Ausnahmen von der Regel oder würdest du dort dann stattdessen zum Einsatz einer linux-basierten Alternative (etwa OpenWRT oder vyos) bzw. der Proxmox-eigenen Firewall raten?
 
Das eine ist m.E. eine Notlösung, wenn man den Fehler gemacht hat, eine Hardware zu kaufen, die eigentlich für OpnSense ungeeignet ist. Besser wäre es natürlich, sich vorab zu informieren ;-) Zu den üblichen Fehlern gehört auch, eine ungeeignete SSD zu verwenden - ich habe gerade einen Bekannten, der hat eine 25 TBW/TB No-Name-SSD mit 512 GByte in einem Mini-PC. Nach einem Monat Betrieb sind 10% Lebenszeit verraucht.

Virtualisierung beim Cloudhoster ist natürlich legitim, zudem das SPOF-Argument ja wegfällt, wenn alles andere sowieso auf dem selben PVE-Host läuft. Im lokalen Netzwerk mit Clients dagegen würde ich bei Ausfall des PVE-Hosts nicht gleich auch noch ganz auf Netzwerkzugriff verzichten wollen.

Und wie gesagt, zum Testen kann es auch ganz nützlich sein. Ich habe sogar virtuelle Installationen bei Leuten laufen, die eine Fritzbox als eigentlichen Router einsetzen. Wenn man dann einen vernünftigen Reverse-Proxy oder einen richtigen VPN-Server braucht, kann man eine virtuelle OpnSense hernehmen.
 
  • Like
Reactions: Johannes S
Ihr seid minimal vom Thema abgekommen.

NAS aufm Proxmox funktioniert auf alle Fälle, hab ich auch schon mehrfach aufgesetzt. Mit einem durchgereichten SATA-Controller fahren die auch runter, aber WOL widerspricht sich ja selbst, weil man das Blech doch nie abschaltet...

Habe aber noch nie irgendwo mitbekommen, dass der Chipsatz-SATA-Controller direkt durchgereicht wurde. Das würde m.E. auch aufgrund der Vielzahl an ineinander verschränkten Funktionen eines Chipsatzes niemals funktionieren.

Ordentlichen ASmedia mit 4 Lanes kaufen und die SATA-Laufwerke da einstecken, das klappte bei mir in mehreren Blechen immer ohne Einschränkung. Die Laufwerke am Controller werden dann halt nicht vom PBE gebackupt, aber das ist ja klar. Wenn die Kiste nur einen pcie hat, muss der TE die HDDs direkt durchreichen. Hatte ich auch schon, ist aber nicht so gut.
 
  • Like
Reactions: Johannes S
Wenn die Kiste nur einen pcie hat, muss der TE die HDDs direkt durchreichen. Hatte ich auch schon, ist aber nicht so gut.
Das Problem ist, dass (siehe Link im TrueNas Forum Punkte 3 und 4) auch nicht ganz unproblematisch ist ;) Wenn man sich dessen bewusst ist und mit den Einschränkungen/Risiken leben kann, go for it, meyergru hat da ja oben was zu geschrieben. Aber man sollte sich das zumindestens vorher klar machen.