[Sammelthread] Proxmox Stammtisch

Ist nicht an eine IP gebunden, hört auf allen.
Zu sehen via Konsole
netstat -tpln
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hier wäre der passende Weg die Interfaces nur über entsprechende IPs oder Interfaces erreichbar zu machen.

Die passenden Hilfsmittel hierfür sind iptables gerne auch über ufw oder firehol.
 
Hmm also irgendwie klappt das nicht, ich habe einem Interface noch eine IP zugewiesen, aber unter dieser ist der Host weder unter SSH noch unter 8006 erreichbar.
Oder muss ich hier noch weitere Einstellungen tätigen.

Danke

Gruß Rocker
 
was genau hast du gemacht? sind die ports auch bei hetzner freigeschaltet, von einem anderen hoster kenne ich es so, dass es im kundenportal die möglichkeit gibt, seine root bzw. vps server zu konfigurieren und firewall einstellungen vorzunehmen, unabhängig vom direkten zugriff auf das hostsystem.

kannst du die neue schnittstelle pingen, sind das öffentliche ips die du hast oder gehst du über vpn, bitte beschreibe das mal etwas genauer und mach einen netzwerkplan?

pass bei ssh auf, dass du dich nicht aussperrst, würde mir auf jedenfall eine (sichere ) hintertür einbauen, falls mal was mit dem VPN sein sollte und du schnell auf den server musst.

die ports für ssh änderst du am host selber oder beschränkst diese über das onlinemangement. (bei hetzner kenne ich mich allerdings nicht aus, kann nur von meinem hoster sprechen)
 
Ich habe aktuell 4 interfaces auf meinem Proxmox

die Eigentliche Netzwerkkarte
VMBR0 das hängt an der Netzwerkkarte und ist von draußen mit SSH und 8006 erreichbar
VMBR1 auf das per IP Tables der komplette Traffic an eine weitere verfügbare IP geschoben wird /30iger Netz. Das ist die Schnittstelle der OpnSense die das externe Netz zum internen trennt.
VMBR2 Schnittstelle des internen Netzes

Ich habe auf VMBR2 eine IP Adresse vergeben und wollte über diese den Proxmox ansprechen, das ging aber leider nicht (ich befand mich per VPN in diesem Netz.)
Daher meine Frage ob weitere Schritte notwendig sind SSH und die Web GUI zu verschieben.

Danke

Gruß Rocker
 
Moin, ich hab mal ne Frage zu SMB von einer Proxmox-VM.
Szenario: Proxmox-Host ist mit Gigabit an einem Switch. Auf dem Host läuft eine TrueNAS-VM. Diese VM hat einen HBA durchgereicht, dieser hat 5 Platten angeschlossen, die im TrueNAS als raidz2 organisiert sind. Ich bekomme nur maximal 65MB Transferleistung auf den darin enthaltenen Datapool bzw. seine Datasets. Woran liegt das? Das ist dann doch etwas arg langsam...
 
Rocker schrieb:
VMBR1 auf das per IP Tables der komplette Traffic an eine weitere verfügbare IP geschoben wird /30iger Netz. Das ist die Schnittstelle der OpnSense die das externe Netz zum internen trennt.
Zum Vergrößern anklicken....
proxmox opnsense problem.jpg


Also so stelle ich mir das vor oder? Du wählst dich auf die Sense per VPN drauf, welche mittels IP-Tables von Proxmox den Traffic über VMBR0 auf VMBR1 weiterleitet... Das ist viel zu umständlich und das einzige was mir bei diesem Szenario auffällt ist, dass du das irgendwie per NAT oder Routing auf der Sense konfigurieren musst, damit du von VMBR2 wieder zum Netz der VMBR0 Schnittstelle kommst. Hört sich für mich so an als würde der Traffic dann nicht zu Proxmox durchkommen... der Fehler könnte Routing sein wie bereits erwähnt, weil kein Inetzugang Zugriff von der Sense auf VMBR2 zugelassen wird oder auf der Sense die Konfiguration falsch ist ... Was mir gerade noch einfällt ist, Proxmox müsste auch im Netz der VMBR2 sein, kann Proxmox sich selber auf der VMBR2 Schnittstelle pingen?

Also entweder hab ich hier einen Denkfehler oder du solltest dein Netzwerk nochmal umstruktuireren und anders designen!

Ansonsten zeichne das mal etwas präziser, so eine ferndiagnose ist nicht einfach!
 
Zuletzt bearbeitet:
Sorry für Doppelpost, ganz andere Frage: Ich habe ein Supermicro H11SSL-i, das kommt onbaord mit 8 normalen SATA-Anschlüssen verteilt auf 2 SATA Controller und 2 Mini-SAS Anschlüssen verteilt an einen dritten SATA Controller. Genau diesen letzten Controller will ich jetzt an eine VM durchreichen - woran erkenne ich denn jetzt welches der richtige Controller ist?
lspci |grep sata sagt :
07:00.2 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51)
42:00.2 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51)
64:00.2 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51)

Welcher ist nun der durchzureichende? :confused:
 
64 ist es. Musst allerdings aufpassen: dummerweise ändert sich die Nummerierung, wenn man Karten neu einsteckt...
 
Woher weißt du das? "Weiß man halt"? Oder wie? Ich weiß das es nicht 7 ist, denn daran hängen meine Platten laut
lshw -class disk -class storage
(Den Tip hatte ich mitlerweile gefunden).
 
Ich habe das gleiche Board (s. Sig), bei mir ist es die 62. Vermutlich hast du noch 1/2 PCIe-Karten drin.
 
Ääääää ja Sig anschauen hilft. Lol. Manchmal sind die Antworten direkt vor der Nase... :wall:
Ja, es ist ein HBA drin. Unser Aufbau gleicht sich ziemlich. Vielen Dank!
 
Gibt es irgendwo einen vernünftigen Guide wie man unter Proxmox in einer VM GPU acceleration einer Nvidia GPU für Jellyfin einrichtet?
 
Ich frag nicht umsonst nach einer VM. Ganz bewusst kein LXC. Ich installier doch keinen Nvidia Treiber auf meinem Hypervisor. Allein der Gedanke ist schon falsch.
Trotzdem danke. Ich habs auch mittlerweile hinbekommen, alles gut.
 
Wenn der Gedanke falsch wäre, würde es das nicht geben und von vielen Leuten genutzt werden. Leute, wir sind und bleiben hier bei HOMEservern. Da sind keine Staatsgeheimnisse drauf. Klar, Datenschutz usw. ist wichtig und richtig, aber wer jetzt schon offizielle Treiber als Problem ansieht...
 
Geht ja nicht um Datenschutz, geht darum, dass ein HV so dumm wie möglich sein sollte. Den will man ja notfalls schnell tauschen -> alle Logik in VMs/Container.
 
Dann legt man sich eine kleine Dokumentation an und fertig. Den Passthrough zur VM musst du im Hypervisor auch eintragen. Ob man da jetzt 3 CLI-Befehle mehr oder weniger eingibt, macht aber auch keinen großen Unterschied.
 
Erm. Nividia Treiber machen gerne mal Fuckup. So geschehen bei meinen Versuche das in der VM stabil hinzukriegen. Einen Treiber, der komische Dinge tut auf einem Hypervisor, der den Treiber nicht braucht, zu installieren ist ziemlich blöd. Homeserver hin oder her - die Stabilität des Hypervisors hat mMn Vorrang vor allem anderen auf dem System. Erst Recht wenn es dazu eine ziemlich einfache Alternative gibt. Und das Argument "das machen doch alle" ist als Argument nun wirklich nicht zu gebrauchen.
 
ich hatte noch nie Probleme. Egal ob mit einer Quadro oder GTX. Egal ob mit den offiziellen oder mit den offenen Treibern.
 
Das ist wunderbar, aber eben eine Anekdote und kein Argument. Das Argument ist: Den Hypervisor so unkomplex wie möglich betreiben.
 
und wenn man GPU passthrough in einer LXC verwendet, ist es so unkomplex wie möglich den Treiber zu installieren.
 
Nein, denn du greifst damit in den Hypervisor ein. Du kannst doch nicht allen ernstes behaupten das die Installation von Software (die nichtmal gebraucht wird, aber das ist irrelevant an der Stelle) auf ein System die Komplexität des Systems nicht erhöht?
 
dann installier ich mir besser auch kein qemu, kein pct, kein apt...ach was rede ich, ich ziehe einfach alle Stecker. Sonst wird ja die Komplexität des Systems erhöht.
 
Er hat schon irgendwo recht. Darum mag ich den esxi auch so gerne.
Installieren, moeglichst nichts per shell veraendern und fertig.

Time-To-Recovery wuerde ich auf 10 Minuten tippen.

Bei nem komplexen Hypervisor sieht die Welt halt anders aus. Das muss ich nicht zu hause haben.
 
Ich habe letztens mein System von einem R710 auf ein R620 umgezogen. Mit installation und updates hat es mich in etwa 30 minuten gekostet.
 
Anmelden, um zu antworten.

Ähnliche Themen

D
Bester Hypervisor für Windows VMs gesucht
Antworten
10
Aufrufe
1K
Supaman
Supaman
M
[User-Review] LG gram 17 17Z90S-G.AA78G
Antworten
7
Aufrufe
2K
mz_z
M
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