[Sammelthread] Proxmox Stammtisch

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
@morph027: Ja war der Falsche Thread^^Hier die Nachricht ;)

ja, der passthrough ist in proxmox zwar ok, aber immer ne kleine Baustelle (lösbar)
dafür ist es zu stark auf "normales" Hosting ausgelegt ... was es dafür umso besser macht (imho)
bin auf jedenfall dankbar für proxmox ... will es nie mehr missen :)

Nach langem testen hat sich herausgestellt:

Die 10GB Karte x540-T1 von Intel lässt sich unter Windows einfach nicht aktivieren. Nicht weiter schlimm, da es nur ein Test sein sollte und die Karte sowieso nativ von Debian/Proxmox genutzt werden soll. Vertauen in ein stabiles System steigt hierdurch aber auch nicht. :)
Wichtiger ist die TV Karte und die 1GB-Ports der i350 Netzwerkkarte. Hier habe ich festgestellt, dass ich von den 0-3 Ports (4 Stück) nur Port 1-3 durchreichen kann. Sobald ich Port 0 durchreiche (kernel-driver-in-use wechselt von igb auf vfio) sind bis zum Neustart alle Ports instabil. Unter VMware hatte ich ähnliches, da konnte ich erst gar nicht Port 0 für Passthrough freigeben. Ist das Verhalten normal? Hat jemand auch eine Mehr-Port-Netzwerkarte und kann dies bestätigen? Port 0 nativ funktioniert einwandfrei.
Fazit bisher: Port 1-3 kann ich durchreichen, teste nun die TV Karte.

Ich habe nicht gesagt, dass man generell nicht blacklisten muss. Dies galt nur der Cine S2, da ich diesen Tip mal im VDR-Forum erhalten habe. Und das funktioniert bei mir super. Habe es auch nie anders getestet.
Meinen LSI-3008 SAS-Controller (mpt3sas) habe ich allerdings geblacklisted. Wie ich das gemacht habe, hatte ich neulich im Proxmox-Forum geschildert:
https://forum.proxmox.com/threads/proxmox-ve-4-2-pci-passthrough-lsi-3008-mpt3sas.29577/
Leider hat dort nie jemand auf meine Fragen reagiert.
Wenn die VM exklusiven Zugriff auf die Hardware hat, musst du wohl nicht blacklisten. Bei dem SAS-Controller war mir das aber zu heikel, da sich dahinter ein RAID-Z2 bestehend aus 8x4TB befindet. ;)
Gruß Hoppel

Habe mir dein Post im Proxmox Forum angeschaut. Hast du dein Problem lösen können? Ganz verstehen tue ich das mit der blacklist nicht. Proxmox kann wohl dynamisch den "Kernel driver in use" ändern, sodass man nicht blacklisten braucht. Auch im offiziellen PCI-Passthrough Wiki Eintrag steht davon nichts. Hast du es mal ohne Blacklist probiert oder den blacklist-Eintrag nicht nach modprobe.d/mpt3sas.conf sondern direkt in die pve-backlist.conf reingeschrieben?

In einem LXC siehst du die gesamte Hardware direkt mit lspci. Bei der TV-Karte musst du dann aber wohl /dev/dvb in den Container über die "vmid.conf" mounten.
Ja, via lspci sehe ich alles in LXC aber ich kann auf die Geräte nicht zugreifen. Wie genau mounte ich den /dev/dvb in der vmid.conf?
 
@bogomil: Du verwendest als "machine type" in der Windows-VM den "q35"-Typ: Das ist unnötig (q35 ist nach wie vor experimentell) und möglicherweise ein Grund, warum es beim Passthrough Probleme gibt. Ein einfaches "hostpci" Statement ohne "driver" und "pcie" parameter sollte reichen, wenn Du einfach beim Proxmox Default-Machine-Type (440fx) bleibst. Treiber-Blacklisting ist ebenfalls nur für Geräte nötig, die Probleme beim nachträglichen Treiber-Unbind machen. Typischerweise sind das Grafikkarten, bei den meisten anderen Karten (inkl. der x540 und i350) funktioniert das normal problemlos.

Hast Du schon mal verifiziert, ob die einzelnen PCIe-Functions der i350 auch in jeweils einer eigenen IOMMU landen? ("find /sys/kernel/iommu_groups/ -type l").
Weiterhin kannst Du bei der luxuriösen Hardware-Ausstattung auch mal SR-IOV ausprobieren. Damit kannst Du sowohl die vier i350 NICs als auch die X540-T1 auf dem Host in Dutzende von virtuellen NICs (VFs, "Virtual Functions") aufteilen, die sich dann per PCI-Passthrough an VMs durchreichen lassen. Hat den Vorteil, dass die VFs in Hardware virtualisiert werden und somit wesentlich weniger Overhead beim Assignment erzeugen als emulierte oder selbst paravirtualisierte (virtio) NICs. Dafür muss Dein Board aber entsprechenden SR-IOV Support bieten.
 
Zuletzt bearbeitet:
So, nachdem ich nun recht zufrieden bin, habe ich noch ein paar Fragen:

- Was wählt man als Image aus? RAW, qcow2 oder das andere, was ich gerade vergessen habe?
- Discard ist für SSD-Trim, richtig?
- Wann sollte man IO-Thread auswählen?
- Wann macht es Sinn bei CPU "Host" auszuwählen?
- SSDs/HDDs: VirtIO oder SCSI?
- Windows-VMs: Netzwerktreiber VirtIO oder Intel?
- LXC-Container oder VM?
- USB-Passtrough ohne IOMMU möglich? HDDs kann man auf jedenfalls durchreichen.
- Wenn ich einen Zweitserver als Knoten einfüge, kann ich dorthin die VMs kopieren, den ersten Knoten nochmal neu aufsetzen mit ZFS und dann wieder zurückkopieren/migrieren?
- Wie oft sollte man ein Backup der HDD/SSD/Container/VMs machen?
- inkrementielle Backups möglich?

Ich weiß, viele Fragen :fresse:

Grüße
 
@bogomil: Du verwendest als "machine type" in der Windows-VM den "q35"-Typ: Das ist unnötig (q35 ist nach wie vor experimentell) und möglicherweise ein Grund, warum es beim Passthrough Probleme gibt. Ein einfaches "hostpci" Statement ohne "driver" und "pcie" parameter sollte reichen, wenn Du einfach beim Proxmox Default-Machine-Type (440fx) bleibst. Treiber-Blacklisting ist ebenfalls nur für Geräte nötig, die Probleme beim nachträglichen Treiber-Unbind machen. Typischerweise sind das Grafikkarten, bei den meisten anderen Karten (inkl. der x540 und i350) funktioniert das normal problemlos.

Hast Du schon mal verifiziert, ob die einzelnen PCIe-Functions der i350 auch in jeweils einer eigenen IOMMU landen? ("find /sys/kernel/iommu_groups/ -type l").
Weiterhin kannst Du bei der luxuriösen Hardware-Ausstattung auch mal SR-IOV ausprobieren. Damit kannst Du sowohl die vier i350 NICs als auch die X540-T1 auf dem Host in Dutzende von virtuellen NICs (VFs, "Virtual Functions") aufteilen, die sich dann per PCI-Passthrough an VMs durchreichen lassen. Hat den Vorteil, dass die VFs in Hardware virtualisiert werden und somit wesentlich weniger Overhead beim Assignment erzeugen als emulierte oder selbst paravirtualisierte (virtio) NICs. Dafür muss Dein Board aber entsprechenden SR-IOV Support bieten.

Danke, ich werde es testen :) Dachte immer pcie=1 ist ein muss wenn man PCIe-Karten durchreichen will. Ohne den Zusatz q35 aber mit pcie=1 starten die VM'S nicht. SR-IOV schaue ich mir mal an. Bisher klappt die TV Karte soweit auch mit Passthrough unter Windows. Einzig die x540 nicht und Port 0 der i350.

--------------------------------------------------------------

Zu den Fragen von MisterY. Ich versuche mal zu beantworten was ich kann. Ich beschäftige mich selber erst grad mit Proxmox. Bei falschen Aussagen, verbessert mich :)
Was wählt man als Image aus? RAW, qcow2 oder das andere, was ich gerade vergessen habe?

Wenn du ZFS als Storage nutzt, nur RAW, da qcow2 selber auch CopyOnWrite hat und das dann doppelt wäre. Allg.: Im Proxmox Forum habe ich gelesen, dass .RAW ca 10% "schneller" sein soll als qcow2. Qcow2 bietet aber mehr Funktionen für Snapshot & Co. (zusätzlicher Layer). Im Promox-Forum findet man da einige Einträge zu.

Discard ist für SSD-Trim, richtig?
Die Checkbox habe ich bisher immer übersehen^^. Spontan habe ich diesen WIKI Eintrag gefunden. Was meinen die Anderen?

Wann sollte man IO-Thread auswählen?
Siehe hier:
The option IO Thread can only be enabled when using a disk with the VirtIO controller, or with the SCSI controller, when the emulated controller type is VirtIO SCSI. With this enabled, Qemu uses one thread per disk, instead of one thread for all, so it should increase performance when using multiple disks. Note that backups do not currently work with IO Thread enabled.

Soll nach dieser Aussage die Performance erhöhen, wenn du mehr Discs hast, aber damit sind keine Bckup möglich. Also lieber deaktiviert lassen :)

Wann macht es Sinn bei CPU "Host" auszuwählen?
Siehe HIER. Standardmäßig ist es deaktiviert um die Migration der VM zu gewährleisten. Andererseits fehlen dem Guest dann die ganzen Features die ein CPU hat (SSE, AES-NI,..). Ich habe es auf host gestellt, da ich nicht ständig die VM zw. verschiedenen Hardware-Systeme wechse.

SSDs/HDDs: VirtIO oder SCSI?
Windows-VMs: Netzwerktreiber VirtIO oder Intel?
Hängt denke ich von dem Guest System ab. Allgemein wird bei neueren Windows Systemen soweit ich weiss immer VirtIO für HDD als auch für Network empfohlen (ist performanter). Linux hat die VirtIO Treiber auch auch bereits integriert. Würde mich auch interessieren was die Anderen hier bevorzugen? Immer VirtIO?

LXC-Container oder VM?
Auch abhängig vom Guest OS. Soweit ich weiss gehen nicht-Linux-basierte OS nur als VM. Falls du aber Debian & Co. virtualisieren möchtest ist ein LXC leichtgewichtiger. Hier können die Profis mal Antworten :)


Die unteren Fragen kann ich nicht beantworten :)
 
Zuletzt bearbeitet:
Danke dir, hilft mir schonmal viel weiter :)
Afaik ist VirtIO ein 10Gbit-Adapter? Sollte deshalb immer genommen werden, habe ich verstanden. Bei Windows muss man aber die Treiber während der Installation laden, richtig?

Wie sieht es eigentlich mit caching aus? Da kann man ja auch so viel auswählen :fresse:
Kann man zusätzliche SSDs als Cache verwenden? Bringt das was?
Und wie kann man Daten zwischen zwei VMs hin und her schieben? Nur per FTP/NFS? Das wäre ja ein wenig mühselig :fresse2: Oder kann man irgendwie einen shared-speicher erstellen?

Achja: Wie kann ich verhindern, dass jemand, der auf eine auf einem LXC-Container gehosteten Website (Wordpress) zugriff auf die anderen VMs oder gar Server im Netzwerk erhalten kann? Reicht da eine simple Portweiterleitung von Port 80 auf den Webserver und das reicht?
 
Zuletzt bearbeitet:
Hi,

machst es eigentlich einen nennenswerten Unterschied hinsichtlich der Performance wenn ich einer VM fixen Arbeitsspeicher zuweise oder ihn von 16GB Ram bis 18GB Ram allozieren lasse?
 
In dem kleinen Bereich sowieso nicht ;) Du kannst natürlich zwischen 1GB und 18GB zuweisen, dann nimmt der sich den schon, wenn er den braucht. Performance leidet da nicht drunter.
 
alles klar danke, ich glaube FreeNAS unterstützt kein Dynamic Memory Allocation :(


EDIT: "-Use Fixed memory allocation in VMs where performance is needed. Do Not use variable memory specially on Windows based VM."

Source: https://forum.proxmox.com/threads/s...per-threading-fixed-vs-variable-memory.20265/


Noch eine Frage hinten dran:
Hat mal jemand von euch versucht OmniOS auf Proxmox zu installieren? Ich erhalte "No SOF interrupts have been received..USB UHCI is unusable", jemand eine Idee.
 
Zuletzt bearbeitet:
​Hi,

folgende Situation:

- Server 1 (Fileserver). OMV3; Einziges Programm, was Internetzugriff hat (ausser die updates) ist Plex.

- Server 2 (Webserver). Proxmox-Host mit mehreren Gästen (Linux und Windows).

- beide hängen an einen Switch, der wiederum an einem TP-Link Archer C5 v1.2 hängt

- 3 Domains (ww.seiteA.de; ww.seiteB.de; ww.seiteC.de)

auf Server 2 laufen folgende Gäste:

- Debian 8 als Wordpress-Server (ww.seiteA.de; ww.seiteB.de)

- Ubuntu Server 16.10 als Nextcloud-Server (ww.seiteC.de)

- OMV3 als FTP-Server (ww.seiteC.de)​

- Win 7

des Weiteren auf Server 1: (ww.seiteC.de)​

nun, ich möchte auf dem Debian 8 so 1-2 Internetseiten hosten. Natürlich soll nicht jedes Kellerkind gleich auf mein gesamten Netzwerk zugreifen können.

Wie richte ich das am besten ein, dass wenn man ww.seiteA.de und ww.seiteB.de aufruft, man nur auf die Debian 8-VM zugreifen kann und nur dort? es soll KEINE Zugriffsmöglichkeit zu den (v)Servern unter ww.seiteC.de geben. Ist das möglich?
 
Da gibt es verschiedene Möglichkeiten der Separierung. Am saubersten wäre es natürlich wenn du deine Hosts in die DMZ stellst. Wenn das nicht möglich ist, dann kannst du deiner Firewall explizit anweisen, dass Debian 8 als einziger von der Ferne erlaubt sein darf (Port 80 + 443). Zumindest solltest du dieser VM eine IP Adresse zuweisen, die NICHT im LAN zusammenhängt. Ob dein TP-Link VLAN-Tagging beherrscht kann ich nicht sagen, das wäre aber auch ein weiterer Schritt der Seperarierung.
 
Zuletzt bearbeitet:
DMZ funktioniert hier leider nicht, nur als exposed host.

Was meinst du mit einer anderen IP? also anderes subnetz? Könnte ich das in Proxmox selber machen?
 
Ja genau, es war ein anderes Subnetz gemeint. also statt 192.168.55.0/24 nun 192.168.66.0/28 oder so ähnlich. Du kannst deiner VM natürlich ein anderes virtuelles Interface zuordnen und diesem dann eine IP manuell zuweisen. Ich weiß nicht, wieviele Interfaces du hast aber schön separiert ist das nicht, wenn alles über eine physische Schnittstelle läuft und nur logisch getrennt ist, aber das musst du wissen.

@morph027: Ich müsste nur noch wissen, wie ich dem Proxmox diese "disable-ehci=true,disable-uhci=true" optionen mitgebe :/
 
Ich könnte natürlich noch eine zusätzliche NIC einbauen. Soll ich die dann direkt an die VM durchreichen oder soll ich in nem Gast ipfire oder so installieren?
 
Das würde sowohl als auch gehen. Entweder reichst du der VM direkt die NIC durch und setzt auf dem Host noch ein paar IPtables Regeln oder du hast davor eine vernünftige FW. Ob IPFire o.Ä. mit einer NIC nun sinnvoll ist möchte ich nicht abstreiten aber es geht auch ohne.
 
Also eine zusätzliche NIC vom Switch (oder Router?) und dann dort eine eigene vNIC erstellen und dann diese an die bestimmte VM binden?
 
Hm wenn du die NIC vom Router nimmst, wird auch jeder auf dein LAN zugreifen können sofern du keine Restriktionen im Router hast, denn der Router routet eben :d Also schau lieber ob dein Router eine ordentliche FW mitbringt. Der Switch ist dumm und könnte mit VLANs separieren. Wichtig ist eben dein Layer-3 device.

Du brauchst dann keine vNIC erstellen, du startest deine VM ohne zusätzlicher NIC, denn das machst du in deiner <VM-ID>.conf Je nach PCI-Schnittstelle: https://pve.proxmox.com/wiki/Pci_pa...our_PCI_card_address.2C_and_configure_your_VM
 
mein Server unterstützt kein IOMMU, weshalb ich nicht davon ausgehe, dass ich die NIC durchreichen kann.

Naja der Switch hängt ja auch am Router im selben Subnetzbereich, also ist es doch Pott wie Deckel wo ich ihn anschließe. Die Firewall ist glaube ich recht in Ordnung. Würde dann nur Port 80 an die VM weiterleiten?
 
Achso, ja dann geht das leider nicht mit dem durchreichen. Wenn du "ihn" am Switch anschließt und ein anderes Subnetz einrichtest, kommen deine LAN Clients zumindest nicht mit der VM in Kontakt, also wenn deine VM kompromittiert wurde, sollte der Angreifer nur auf der VM bleiben können. Ist "er" am Router, hat der Angreife freie Bahn. Welche Ports durch forwardest ist dir überlassen, wenn du nur HTTP anbietest dann reicht Port 80 klar.
 
Achso? Weil der Switch (unmanaged, "dumm") hängt doch auch am Router?

Aktuell habe ich es so in die Proxmox-Firewall eingetragen: Firewall.png

Ich kann zwar die VM anpingen, von der VM aber nicht. Läuft also.
Wenn ich das nun noch in zwei NICs auftrenne, sollte es doch ausreichen, oder?
 
Wie du kannst die VM anpingen? Von wo denn? ICMP sollte die VM besser auch nicht erlauben sondern nur HTTP-Verkehr. Du solltest Proxmox explizit mitteilen, dass die VM nur von Quell-IP mittels Protokoll (HTTP) auf Source (ANY) zugreifen darf bzw. Source (ANY) über Protokoll (HTTP) auf Quell-IP. Mit deiner Regel kommt die VM zwar zum Router aber du willst ja auch, dass Internetverkehr auf deine VM kommt und die kommt vom Router.
 
Von einem Client aus kann ich die VM anpingen.

Ja du hast recht, da hatte ich einen Denkfehler. :fresse:
Kannst du mir mal so eine Firewallregel erstellen und ein Screenshot machen?
 
Was hat es eigentlich mit CEPH auf sich? Nutzt das jemand? Was kann das?

Wie sieht es mit Clustern aus? Ich will gerne eine zweite Node erstmal als Backup einrichten. Nutzt das jemand?

Was ist mit ISCSI? Wie richtet man das ein? Oder lieber NFS? Kann ich so auch rein theoretisch auf Server1 die VM auf Server2 installieren und nutzen? Wenn ja, macht das mit 1Gbit Sinn? Oder sollte man 10gbit mit crossover einsetzen?
 
Zuletzt bearbeitet:
2 Knoten im Cluster sind Mist und nicht offiziell unterstützt. Wegen Multimaster Design hast du bei Ausfall der Verbindung zwischen den beiden immer split brain.

Ceph ist für gewisse Sachen sehr geil, macht auch nur Sinn auf vielen Platten und Knoten. Und skaliert massiv über das Netzwerk, also unter 10G macht das kein Spass (geht schon, gerade für Heimnutzung und rumspielen, aber eben nicht für produktiv).

Generell hast du bei den ganzen verteilten Storage-Diensten immer das Problem des Single Point of failure. Was ist, wenn ISCSI/NFS Server wegranzen? Dann läuft da gar nichts mehr...Für Backup dann eher ZFS und massiv kurzatmige Snapshots die dann automatisch übers Netz auf den anderen Server geschoben werden. Der muss dann dazu nicht mal im Cluster sein (Siehe split brain)...
 
Zuletzt bearbeitet:
Also entweder 1 oder 3 oder mehr? Ich wollte gern Kopien von meinen VMs auf einen zweiten knallen
 
Es gibt zwei ganz grundsätzliche verschiedene Ansätze - einer ist "Replikation" und der andere ist "Cluster". Gilt ähnlich für VMs wie Storage.

Ich versuch's mal in kurz und vereinfacht:

Bei der Replikation hast du einen primären und einen sekundären Host. Beide gleichen in gewissen Abständen die Daten ab und der sekundäre wird auf den Stand des primären Hosts gebracht. Willst Du vom primären Host auf den sekundären wechseln, hast Du eine gewisse Downtime, bis der Kram da hochgefahren/verfügbar ist und das Ganze erfordert dem Prinzip nach regelmäßig einen manuellen Eingriff vom Admin. Da somit immer nur "eine Seite" rennt, hast Du tendenziell weniger Probleme mit Splitbrain-Szenarien.

Im Cluster laufen die Hosts quasi parallel und Du kannst (je nach System) sogar ohne spürbare Downtime von Host1 zu Host2 schwenken (oder Clients mal auf A und mal auf B gleichzeitig lesen/schreiben). Die Verteilung machen die Hosts sogar manchmal automatisch untereinander aus abhängig von der Last auf dem jeweiligen Host. Das Problem dabei ist, dass der Cluster aber wissen muss, wo jetzt jeweils die aktulleste Version ist. Wird in einem Cluster aus 2 Maschinen die Verbindung getrennt, wissen die Hosts später nicht, wenn die Verbindung wieder kommt, "wer recht hat" und wessen Daten vorgehen. Im Zweifel denken beide, sie wären eben aus dem Cluster raus (weil sie keine andere Maschine mehr sehen). Bei einem Cluster z.B. aus 3 Maschinen wissen ggf. eben noch 2, dass sie sich finden (also der Cluster sind) und 1 dass sie allein ist.

Sicherlich so stark verkürzt und im Detail nicht exakt, verdeutlicht aber hoffentlich worum es geht.

Wenn es Dir darum geht, ein Backup der VMs auf einem anderen Host liegen zu haben, reicht also replikation.

Lustiger ist aber in meinen Augen ein Cluster, da es einfach Spaß macht, VMs hin und her zu schubsen und man eben mal eine Kiste aus dem Cluster runterfahren kann, ohne viel nachzudenken. (Deshalb finde ich es auch so schön, dass man mit Hyper-V inzwischen für lau einen voll funktionsfähigen Cluster bauen kann.)

Wenn ich das hier richtig quer mitgelesen habe, geht das aber auch mit Proxmox (nur kann ich dazu nichts beitragen).
 
Zuletzt bearbeitet:
Danke dir für deine Erklärung.
Replikation wäre in der Tat ausreichend, aber könnte ich den zweiten Host auch für anderes benutzen?
Host1 wäre ein Opteron Octacore, der aber eine recht bescheidene Singlecore-Performance hat. Wenn ich mal hin und wieder eine Berechnung laufen lasse, die nicht parallelisiert werden kann, würde ich die schon gerne auf den zweiten Host laufen lassen, da dieser einen FX4100 und bessere singlecore performance hat.
Ein absoluter Traum wäre natürlich, dass wenn ich etwas mache, was parallelisiert werden kann (beispielsweise Videokonvertierung), dass dies auf mehreren Servern läuft.

Kann Proxmox die VMs von selbst klonen/backuppen? Weil ich hatte damit gerechnet, dass ich das 1* Wöchentlich manuell machen muss.
 
Zuletzt bearbeitet:
Sorry, zu Proxmox muss ich mangels Erfahrung komplett passen.
 
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