[Sammelthread] Proxmox Stammtisch

[AliManali]

Macht das wer?

Nein.

Sorry, ist einfach keine Hilfe.

Falls tatsächlich wer den Filer auf dem durchgereichten HBA betreibt, bitte Hände hoch. Diejenigen die den Filer dagegen virtuell laufen lassen auch Hände hoch.

 

[BobbyD]

Dass da wer den Filer im durchgereichten HBA Storage hochzieht, höre ich zum ersten mal. Macht das wer?

Hab ich auch noch nicht gehört. Mit Hyper-V würde das z.B. gar nicht gehen. Würde daher Abstand davon nehmen.

 

[AliManali]

Würde meinen, wenn der HBA im IT Modus ist, kann gar nicht davon gebootet werden? Zumindest in meinem Host tauchen die Platten erst auf, nachdem der gestartet wurde. Die seh ich nicht im BIOS, oder (in meinem Fall unter ESXi) im Hostclient. Die Platten sehe ich erst im gestartetem Filer, und von dem HBA BIOS sehe ich gar nie was. Kommt aber auch auf den HBA und die Firmware an. Die ganzen ZFS Freaks mögen ja die IT Firmware.

 

[pwnbert]

So, ich hab hier die Option, von der vorher gesprochen wurde, hilft aber nicht weiter.

Würde meinen, wenn der HBA im IT Modus ist, kann gar nicht davon gebootet werden?

Okay, ich glaub euch schon, dass das unüblich ist.
Aber es geht ja wunderbar - also why not? Soll ich euch ne Bildergeschichte machen, damit ihr es glaubt?

Es ist so, mit SeaBios rebootet er irgendwann nachm HBA initialisieren. Wenn ich da ESC drücke für die Boot-Optionen (mehr gibt das SeaBios mit dem Proxmox Logo ja nicht her offenbar), wähle ich dort 1. legacy (wie am ersten Screenshot), dann bootet er mir sauber.

 

[AliManali]

Frag mal @gea, die ist da super Profi. Die kann das sicher besser erläutern. Halte mich da auch nur an Vorgaben, die von den ganzen Nerds gemacht werden. Eine davon ist, dass für ZFS der HBA im IT Mode sein sollte. Damit er nirgends rein funkt hardwaremässig. Im IT Mode ist er halt dumm, und das OS regelt alles. IR Mode ist eher für Hardware RAID und sowas gedacht.

 

[wenzilinho]

Warum soll das "richtig" sein? Warum soll ich das OS aufn virtuelles Drive machen, geht doch wunderbar auf ein durchgereichtes.
Muss nur irgendwie automatisch gehen.

Sorry, die Antwort ist sinnlos. Das is so wie "welche Grafikkarte soll ich für den Gaming PC kaufen" und jemand sagt "kauf einfach ne PS5". Yeah right.

Sorry, ist einfach keine Hilfe.

Richtig im Sinne von "best practice". War vielleicht falsch ausgedrückt. Beim virtuellen OS kannst halt easy Backups machen oder vorm Update noch nen Snapshot.
Will dir in dein Gebastel nicht reinreden, finde es interessant.

Die anderen Möglichkeiten wollte ich nur erwähnt haben. Für dich keine Hilfe, klar, weil du Truenas nutzen willst. Aber für andere vielleicht eine Hilfe.

 

[pwnbert]

Versteh schon. Nachdem es aber offenbar (irgendwie) funktioniert, frag ich mich, wie wohl richtig.
Ich könnte es natürlich nochmal am HBA neu installieren... wer weiss?

Ehrlich gesagt bin ich selbst am überlegen, ob ich das OS einfach virtuell machen soll... damit habt ihr schon recht. Geht am Ende ja nur um die Konfiguration.
Ich fände es trotzdem irgendwie elegant.
Hat wohl beides seine Vor und Nachteile.


Begonnen hat mein Plan damit, dass ich mit möglichst wenig Aufwand ein TrueNAS von baremetal auf Proxmox übersiedeln wollte, wenn der Rückweg ebenso problemlos und kinderleicht ist, wäre das natürlioch kein Schaden, dachte ich.

 

[AliManali]

Wenn Du virtuell installierst, hast Du sowohl die virtuelle Boot Platte als auch den HBA Storage an TrueNAS. Genauso wie wenn Du es vom HBA aus bootest.

Wenn Du den bestehenden Storage importieren willst a) backup Config einspielen, oder b) Pools rasch importieren. Bei b) werden praktischerweise auch die ganzen Berechtigungen übernommen; war selbst ganz erstaunt, dass das geht. Zumindest unter napp-it.

Es war/ist/handelt sich um einen ZFS Storage, oder? Wenn ja, würde ich mich erst mal darum kümmern, ob der HBA im IT Mode läuft...

Und Rückweg gibt es nicht. Also schon. Aber nicht auf dem highway to rabbit hole. Keine Ahnung, hatte seit 15 Jahren kein Blech mehr am laufen.

 

[gea]

Als Anmerkung
Bei ESXi ist AiO die einzige Möglichkeit, lokales ZFS Storage im ESXi Server zu haben. Das ist da alternativlos.

Bei Proxmox hat man ja bereits ein Debian mit aktuellem ZFS serienmäßig. Da bringt eine Storage VM egal ob mit einem weiteren Debian (TN) oder Solaris/OmniOS ZFS mäßig überhaupt keinen Vorteil sondern nur den Komfort einer Weboberfläche für ZFS Management, kostet nur dafür aber ordentlich Speicher und CPU. Bei Solaris/OmniOS hätte man immerhin noch den kernelbasierten SMB Server statt SAMBA und etwas weniger Resourcenbedarf.

Bei Proxmox lautet die Alternative, SAMBA einfach nachzuinstallieren ohne Storage VM. Für ZFS Management gibt es ja neben meinem napp-it eine ganze Reihe von ZFS Web-GUIs für Linux.

Bei ESXi ist NFS das Mittel der Wahl. Bei Proxmox genügt eigentlich SMB für Datentransfers, NFS brauchts nicht. Damit umgeht man das Problem dass NFS3 keine Authentifizierung oder Authorisierung kann (nur Restriktionen auf ip) und NFS4 gerne imständlich wird. Bei SMB sind ACL Rechtevergaben kein Problem (ok SAMBA ist da eine Katastrophe im Vergleich zu Solaris/Illumos/Windows)

Booten vom HBA ist kein Problem wenn man die Biosunterstützung nicht weggeflasht hat. IT und IR gehen beide problemlos mit ZFS sofern man kein Hardwareraid mit dem IR Mode macht.. SSD Trim soll mit IR Probleme bereiten können.

Konsistente SMB ACL Rechte geht eigentlich nur mit Illumos und Windows ohne Gewürge weil beide weltweit eindeutige (AD) SID als Security Referenz nutzen. SAMBA nutzt als Referenz einfache uid/gid Nummern. Die können auf jedem Server einen anderen Nutzer kennzeichnen. Das dann nötige Mapping uid <-> SID ist der Grund warum SMB Rechte unter SAMBA und Linux so kompliziert sind.

 

[pwnbert]

ob der HBA im IT Mode läuft...

Mensch jaaaaa!

Booten vom HBA ist kein Problem wenn man die Biosunterstützung nicht weggeflasht hat. IT und IR gehen beide problemlos mit ZFS sofern man kein Hardwareraid mit dem IR Mode macht.. SSD Trim soll mit IR Probleme bereiten können.

Erzähl mir mehr davon.

Die Sache ist ja auch eine grundsätzliche, vom HBA booten können zu wollen. Selbst wenn ich kein virtuelles TNS verwende sondern ne ZFS GUI auf Proxmox (was ich mir ja durchaus einreden lasse mal zu probieren, wenn ich etwas Zeit finde), benatwortet es ja die Frage ja nicht direkt... klar, man kann das umschiffen.
Nüchtern betrachtet kann ich den Bootvorgang auch händisch überwachen, wird nicht oft vorkommen... nur is dann halt kein Auto-Start bei Power-Loss. Meh.

Also nochmal, es funktioniert ja.

1. VM startet, Proxmox Logo
2. HBA initiallisiert, schreibt die HDDs auf, die davor hängen, sieht so aus:


3. Bild springt weiter, nicht erkennbar auf was. => Hier springt er wieder zu 1.
=> Das ist mein "Loop", in dem ich hänge (automatisch).

=> Aus diesem Loop kann ich manuell ausbrechen, indem ich bei:
1. dem Proxmox-Logo-Einschalt-Screen ESC drücke, dann kommt:
1.a. Ein Bootmenü mit den Einträgen "1. Legacy Boot ...", "2. QEMU ... irgendwas" (das virtuelle CD Laufwerk), "3. ..." (müsste diese Bios Shell sein oder so) - Wortlaut im Detail hab ich mir nicht gemerkt, kein Screen da ATM.
==> Wenn ich nun in 1.a. den Punkt 1 mit Enter auswähle, startet mir die Kiste, wie sie soll. Von der HDD am HBA, welcher im HBA-Bios entsprechend als Boot-Medium markiert ist.



Es funktioniert ja, nur nicht automatisch. Was übersehe ich?

 

[MisterY]

der einzige Grund, warum ich TrueNAS einsetze ist, dass man hier recht einfach ein ISCSI-Target erstellen kann. Mehr aber auch nicht. Alleine, dass man keine Pakete installieren kann per Shell ohne alles zu zerschießen, ist ein NoGo für mich.

 

[Weltherrscher]

@pwnbert:
Wieso ist die EFBX als Boot-Laufwerk ausgewählt?
Wolltest du nicht von der SSD (BEKT) booten?

 

[gea]

Mensch jaaaaa!
Anhang anzeigen 1034305


Erzähl mir mehr davon.

Die Sache ist ja auch eine grundsätzliche, vom HBA booten können zu wollen. Selbst wenn ich kein virtuelles TNS verwende sondern ne ZFS GUI auf Proxmox (was ich mir ja durchaus einreden lasse mal zu probieren, wenn ich etwas Zeit finde), benatwortet es ja die Frage ja nicht direkt... klar, man kann das umschiffen.
Nüchtern betrachtet kann ich den Bootvorgang auch händisch überwachen, wird nicht oft vorkommen... nur is dann halt kein Auto-Start bei Power-Loss. Meh.

Also nochmal, es funktioniert ja.

1. VM startet, Proxmox Logo
2. HBA initiallisiert, schreibt die HDDs auf, die davor hängen, sieht so aus:


3. Bild springt weiter, nicht erkennbar auf was. => Hier springt er wieder zu 1.
=> Das ist mein "Loop", in dem ich hänge (automatisch).

=> Aus diesem Loop kann ich manuell ausbrechen, indem ich bei:
1. dem Proxmox-Logo-Einschalt-Screen ESC drücke, dann kommt:
1.a. Ein Bootmenü mit den Einträgen "1. Legacy Boot ...", "2. QEMU ... irgendwas" (das virtuelle CD Laufwerk), "3. ..." (müsste diese Bios Shell sein oder so) - Wortlaut im Detail hab ich mir nicht gemerkt, kein Screen da ATM.
==> Wenn ich nun in 1.a. den Punkt 1 mit Enter auswähle, startet mir die Kiste, wie sie soll. Von der HDD am HBA, welcher im HBA-Bios entsprechend als Boot-Medium markiert ist.

Es funktioniert ja, nur nicht automatisch. Was übersehe ich?

Ich vermute, die 1. im Bios eingestellte Platte ist nicht bootfähig.

Wenn man von einem bootfähigen PCI Device z.B. einem HBA booten möchte (egal ob Proxmox barebone oder eine VM via passthrough) so muss man in den Bioseinstellungen (Mainboard oder VM) die entsprechende Platte als 1. Bootdevice einstellen.
Bei einem ZFS Softwaremirror die zweite Platte als 2. Bootdevice einstellen damit es davon bei Ausfall der ersten Platte davon bootet. Eventuell Sachen wie secure boot ausschalten und legacy+efi einstellen.

Bei einer VM sehe ich aber kaum einen vernünftigen Grund die direkt von Hardware zu booten statt von einer virtuellen Platte auf ZFS (mit Redundanz und Backup per Replikation).

Beitrag automatisch zusammengeführt: Heute um 10:10

der einzige Grund, warum ich TrueNAS einsetze ist, dass man hier recht einfach ein ISCSI-Target erstellen kann. Mehr aber auch nicht. Alleine, dass man keine Pakete installieren kann per Shell ohne alles zu zerschießen, ist ein NoGo für mich.

TN hält halt eine Datenbank mit eigener API für ZFS und Systemsachen. Da sollte man ausserhalb der GUI möglichst nichts machen. Ist für mich auch ein Nogo. Eine Web-GUI sollte transparent zu CLI Einstellungen arbeiten.

Aber wozu iSCSI? Ich versuche schon NFS zu vermeiden und damit geht vieles viel einfacher als mit iSCSI. Königsweg ist für mich SMB. Da geht Multiuser Access, saubere Rechtevergabe und es ist mit SMB Multichannel schnell, mit SMB direct sogar erheblich schneller als jede ip Methode (iSCSI, NFS, SMB) ohne RDMA.

 

[Darkwing Duck]

Service läuft, Platte leer, System nicht ausgelastet. Ich glaube, es hat etwas mit meiner NAS zu tun welche ich lediglich am morgen für ein Backup starte. Habe schon sämtliche Workarounds durch, logs gelöscht etc.
Habe jetzt mal die Ordner in "/var/lib/rrdcached/db" gelöscht - mal schauen wies weitergeht..

Liegt wirklich am Backup - solange ich die NAS nicht starte, und Proxmox nicht auf PBS Nas Freigabe zugreifen kann, werden die Logs geschrieben. Kann mir da jemand helfen? Ich habe ehrlich gesagt keinen Plan wie ich das Problem lösen könnte.

Via influx und z.B. Grafana habe ich lückenlose Logs. Kann damit leben...

Hallo, ich wollte mich kurz zurückmelden, da ich nun eine Lösung habe.
Meine Syno startet täglich für 2 Stunden nur fürs Backup via PBS. Sobald die Nas offline ist, wurde die Summary nicht mehr geschrieben.

Mit dem folgenden crontab Eintrag kann das Problem dann gelöst werden. Mag für viele hier trivial sein, ich hab längere Zeit gebraucht, das Problem zu lösen

Mounten vom volume namens pbs um 13:03, unmounten um 15:00 Uhr
3 13 * * * /usr/sbin/pvesm set pbs --disable 0
0 15 * * * /usr/sbin/pvesm set pbs --disable 1

3 13 * * * /usr/sbin/pvesm set synology-nas --disable 0
0 15 * * * /usr/sbin/pvesm set synology-nas --disable 1

Vielleicht hilfts jemandem weiter.

 

[pwnbert]

Wieso ist die EFBX als Boot-Laufwerk ausgewählt?
Wolltest du nicht von der SSD (BEKT) booten?

Hmmm, ich muss nochmal nachsehen. Danke für den Hinweis.

Könnte aber auch einen trivialne Grund haben:
Ich muss gestehen, ich hab die Screenshots jetzt aus einer Unterhaltung mit einem Kumpel genommen, möglicherweise ist der eine Screenshot vom schwarzen Init-Screen veraltet. Müsste ich nochmal prüfen.
Wollte um 3 in der Früh nicht nochmal alles hochfahren für Screens.
Ist btw. keine SSD sondern ne 250gb WD Black 2.5" Laptop-Festplatte, die lag grad rum, und für meine Test-Konfig reicht das ja... btw. läuft das NAS damit auch nicht schlechter.

Evtl. könnte ich noch testen die HDDs solang umzustecken bis mein Boot-Drive am Platz 0 liegt.

Ich vermute, die 1. im Bios eingestellte Platte ist nicht bootfähig.

Im Bios ist gar nix eingestellt, ich hab ja kein echtes Bios mit dem Sea-Bios, im UEFI sehe ich den Controller nicht.

die entsprechende Platte als 1. Bootdevice einstellen.

Hm, aber wenn das Bios nicht "hinter" den Controller sieht? Sollte es aber idR. wohl, oder? Hm.

Bei einer VM sehe ich aber kaum einen vernünftigen Grund die direkt von Hardware zu booten statt von einer virtuellen Platte auf ZFS (mit Redundanz und Backup per Replikation).

Hmja, ich versteh schon. Per Config File ist das ja alles schnell gemacht bei TrueNAS.


Ich wollte die Sache aber noch nicht ganz aufgeben, da ich es allgemein interessant finde, den originalen Datenträger in der VM zu booten.
Ich finde die Möglichkeit ganz hübsch.


Was ich eben nicht verstehe ist, warum es manuell geht, und automatisch in dieses Loop fällt.
Gibts in Proxmox irgend eine Start-Option, mit der ich das machen kann? Ich müsste der VM ja nur irgendwie mitteilen, dass sie im Sea-Bios-Bootmenü von 1. booten soll.... ich hab nur keine Ahnung wie das gehen könnte.

 

[Weltherrscher]

--- snip ---
Aber wozu iSCSI? Ich versuche schon NFS zu vermeiden und damit geht vieles viel einfacher als mit iSCSI. Königsweg ist für mich SMB. Da geht Multiuser Access, saubere Rechtevergabe und es ist mit SMB Multichannel schnell, mit SMB direct sogar erheblich schneller als jede ip Methode (iSCSI, NFS, SMB) ohne RDMA.

Um Blockgeräte durchzuziehen?
Versuche mal beispielsweise eine Steam-Bibliothek über SMB durchzureichen.
(Das ist mein UC für iSCSI)
ZVOL für iSCSI durchgereicht, auf dem Client mit ext4 formatiert und ganz normal gemountet.
Ich bezweifele, dass SMB da performanter ist, vor allem, bei vielen kleinen Dateizugriffen.

//Edith:
Also SMB abseits von Windows.
Oder geht SMB direct und SMB Multichannel mit TN, PX und Linux allgemein?
Hab bei ner schnellen Suche nur Kram für Windoofs gefunden...

 

[gea]

Im Bios ist gar nix eingestellt, ich hab ja kein echtes Bios mit dem Sea-Bios, im UEFI sehe ich den Controller nicht.

Jede Virtualisierungsumgebung emuliert einen kompletten PC inkl Devices wie nic, Grafikkarte oder eben Bios.

Beitrag automatisch zusammengeführt: Heute um 11:51

Um Blockgeräte durchzuziehen?
Versuche mal beispielsweise eine Steam-Bibliothek über SMB durchzureichen.
(Das ist mein UC für iSCSI)
ZVOL für iSCSI durchgereicht, auf dem Client mit ext4 formatiert und ganz normal gemountet.
Ich bezweifele, dass SMB da performanter ist, vor allem, bei vielen kleinen Dateizugriffen.

Man muss da zwischen Sharing bzw Übertragungs Protokoll und Daten unterscheiden.
Prinzipiell ist iSCSI, NFS und SMB bei gleichen Einstellungen und Daten ähnlich schnell (z.B. sync). Performance bringt Multichannel bei allen und ganz besonders RDMA statt ip Transfers. Als Königsweg sehe ich da SMB direct/RDMA weil eben SMB auch ansonst überragende Features hat.

 

[pwnbert]

Jede Virtualisierungsumgebung emuliert einen kompletten PC inkl Devices wie nic, Grafikkarte oder eben Bios.

Beitrag automatisch zusammengeführt: Heute um 11:51

Man muss da zwischen Sharing bzw Übertragungs Protokoll und Daten unterscheiden.
Prinzipiell ist iSCSI, NFS und SMB bei gleichen Einstellungen und Daten ähnlich schnell (z.B. sync). Performance bringt Multichannel bei allen und ganz besonders RDMA statt ip Transfers. Als Königsweg sehe ich da SMB direct/RDMA.

Na das ist mir schon klar.

Wenn ich das richtig verstehe, ist das SeaBIOS eine "dünne" Version, bei der man eig. nichts einstellen kann, die idR. ausreichend ist und läuft.

Das virtuelle UEFI findet den HBA offenbar nicht, der ist in den Boot-Optionen da einfach nicht drin.
Zudem muss ich ja ein UEFI File anlegen. Müsste ich das eigentlich auf die UEFI-Partition der Boot-Disk verlinken? Zudem muss ich gestehen, dass mir da das Wissen fehlt, inwiefern der Maschienntyp 440i oder Q35 der richtige ist... und die damit verbundenen Optionen. Bin mit beidem nicht weiter gekommen.

Mich wundert eben hauptsächlich, warum das SeaBIOS wohl booten kann, allerdings nur manuell und nicht automatisch. Offenbar ist ja alles da, bis auf den Tastendruck.

 

[Weltherrscher]

@pwnbert:

Die Hilfe zu ProxMox hat dir nicht geholfen?
Also, unter Options die Boot-Order auf "hostpci0" zu stellen?
(In PX kannst die Reihenfolge per Drag'n'Drop ändern und die Hackeln bei den restlichen optional raus nehmen.)
hostpci0 sollte dein durchgereichter Controller sein.

(Jaja, süffisant, ich habs auch erst jetzt gefunden, an der Boot-Reihenfolge und deren Einstellungen bin ich auch schon oft gescheitert, weils versteckelt unter nem anderen Reiter ist... )

//Edith:
Screenshot meiner Storage-VM:

 

[pwnbert]

Also, unter Options die Boot-Order auf "hostpci0" zu stellen?

Selbstverständlich hab ich das getan.

Ein kompletter DAU bin ich ja auch nicht - wobei - man kann schon ab und zu gut über "seine eigenen Füße fallen" ... insofern ist mir natürlich jeder Hinweis recht.