ESX / ESXi - Hilfethread

Ja dann sind wir uns ja einig... Ich glaube die billigen Ebay-Angebote sind einfach keygeneriert. Und den Keygen kann ich mir selbst runterladen, da brauch ich kein Geld irgendwohin schicken.
Wenn, dann kommt wohl nur die vmug-lizenz in Betracht - oder eben proxmox, der kann sr-iov ebenfalls.



Genau, es geht um den Hardware-Offload. Auf meinem Board ist ein Dual-NIC-Chip vom Typ x550. Also zwei logisch getrennte 10GBit-NICs in einem Chip. Jeder Port kann 10Gbit.

Wenn ich die 1Gbit Karten über den igbn oder die 10GBit Karten über den ixgben Treiber anspreche und somit als virtuelle Netzwerkkarte nutze, muss immer die CPU ein wenig mitarbeiten. Nicht viel, aber dennoch darf die CPU nicht am Anschlag sein um Latenzen niedrig zu halten.

Wenn ich einen kompletten x550 per Passthrough an die VM durchreiche, kann ich diese Karte bei nur genau einem Gast als PCIe-Device nutzen.

Mit SR-IOV hab ich aber die Möglichkeit, die beiden 10Gbit-Chips in jeweils bis zu 63 (tatsächlich gehen aus welchen Gründen auch immer bei mir nur 61) physische NICs aufzuteilen. Heißt so viel wie: Aus den zwei 10Gbit NICs werden 2x 63 = 126 physische NICs - und jede einzelne lässt sich dann über passthrough an bis zu 126 verschiedene VMs durchreichen.

Hier mal ein Beispiel, bei dem ich einen der beiden x550 in vier single root devices aufgeteilt habe:

1608217627027.png


Der Vorteil daran ist, dass jeder Gast, dem so eine SR-IOV-NIC zugewiesen wurde, das Hardware-Offloading der NIC nutzen kann. Das hängt dann wahrscheinlich auch noch davon ab, ob der Treiber in der VM diese Vorteile auch unterstützt (weiß ich aktuell nicht mal ob OmnisOS oder FreeBSD entsprechende Treiber mitbringen? Oder erkennt die NIC diese Protokolle sogar nativ und beschleunigt es ohne spezielle Treiber?).

Da dieser Server mein physisches Netzwerk mit 10Gbit befeuern soll, als auch den virtuellen NFS-Traffic zwischen Napp-IT und ESXi (für VMFS Datastores) vermitteln soll, erhoffe ich mir dadurch schon Latenzvorteile und Entlastung der CPU. Außerdem will ich aus Sicherheitsgründen Teile von meinem Netzwerktraffic durch eine opnsense-VM schicken - und für dieses Routing und Firewalling wäre die Hardwarebeschleunigung ebenfalls vorteilhaft.

Im Grunde hab ich hier kein Datacenter stehen, aber wenn derartige Netzwerkbandbreiten in einer Maschine anfallen, wird die CPU wahrscheinlich recht schnell am Limit sein - und ich erhoffe mir durch den Hardwareoffload, diesen Flaschenhals zu umgehen.

Edit: Interessant zu sehen wird, was performanter ist:
Den Traffic, der den Server nicht über RJ45 verlässt ohne Hardwareoffload zu behandeln oder diesen virtuellen Traffic durch die NIC zu leiten.

Es könnte sein, dass bei so einer Konstellation die Offload-Vorteile durch Traffic im I/O-Chip des Prozessors wieder aufgefressen werden, denn die Daten müssen ja irgendwie aus der CPU raus und zum x550 gelangen. Die PCIe-Lanes selbst sind jedenfalls kein Flaschenhals: CPU <-PCIe4.0x4*-> AMD x570 <-PCIe3.0x4-> Intel x550 dual NIC <-2x RJ 45 physisch

* Mein aktueller Ryzen 7 Pro 4750G hat sogar nur PCIe3.0x4, dafür kann er den Raminhalt verschlüsseln und hat erweiterten ECC-Support gegenüber None-Pro-CPUs.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Teile von meinem Netzwerktraffic durch eine opnsense-VM schicken - und für dieses Routing und Firewalling wäre die Hardwarebeschleunigung ebenfalls vorteilhaft.
Gerade für diesen Fall - Firewall - soll man die Hardwarebeschleunigung doch abschalten, damit die Firewall überhaupt prüfen kann ...?
 
Das wäre mir neu? Von welcher Prüfung genau sprichst du?

Es gibt NICs, bei denen ist die Hardwarebeschleunigung nicht ganz so sauber implementiert ist. Da muss mans abschalten, weil dann die Firewall nicht richtig läuft. Dann macht halt die CPU die Checksummenprüfung für Rx und Tx oder für Pakete etc.. Aber wenn das sauber gemacht ist, dacht ich, dass Hardwarebeschleunigung immer an sein sollte bei ner NIC?
 
Pfsense Doku und suricata Doku sagen das Gegenteil.

Hintergrund bei suricata ist wohl, dass TSO verhindern kann, dass suricata die Pakete "richtig" erkennt.

Irgendwo sagen sie pfsense Jungs auch, offloading habe auf einer Firewall - anders als bei sonstigen Applikationen, ZB Server! - generell nichts verloren. Denn die Firewall soll ja generell Probleme erkennen bei falschen checksums oder ähnlichem.
 
Man, man, man wie die Zeit verfliegt. @gea hatte bereits 2013 Probleme mit seiner AiO-Appliance im Zusammenhang mit TSO und dazu gab es folgenden Rat:
Ich würds mit dem "Allheilmittel" probieren:
Disable TCP segmentation offload (TSO)
Das scheint häufiger für Probleme zu sorgen. Den Rat zur Deaktivierung findet man jedenfalls im Kraken für Novell, Symantec, Cisco, pfsense, Citrix, RedHat etc. Bei pfsense findet sich in den Einstellungen unter "System: Advanced: Networking: Setting-Disable hardware TCP segmentation offload" die Erläuterung:
This offloading is broken in some hardware drivers, and may impact performance with some specific NICs.

Als Lösung wird beispielsweise im älteren Blogeintrag http://www.v-front.de/2011/05/network-troubleshooting-part-iii-real.html empfohlen, TSO nur im Gast-OS zu deaktivieren.
 
Das aktuelle update von ESXi 7 lässt sich bei mir leider nicht einspielen. Könnte jemand freundlicherweise einen funktionierenden download auf die aktuelle ESXi-Version zwecks Neuinstallation zur Verfügung stellen - bei funktioniert der button auf vmware.com leider nicht? Danke!

Edit: download von VMware scheiterte an einer DNS Blacklist. Ohne geht's.
 
Zuletzt bearbeitet:
@asche77
Hab mir gestern nen Image (7.0.1) mit eigenem Treiber gebaut, allen Anscheins nach hat der sich die ESXi Version dafür aus dem Internet von VMware heruntergeladen, ohne das dafür ein Login notwendig ist.
Habe mich dafür an dieser Anleitung orientiert: https://www.virten.net/2020/04/how-to-add-the-usb-nic-fling-to-esxi-7-0-base-image/

Es sollten für ein originales Image folgende Schritte notwendig sein:
Code:
Add-EsxSoftwareDepot https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
Get-EsxImageProfile
Export-EsxImageProfile -ImageProfile "myprofile" -ExportToIso -FilePath iso_name

Natürlich muss dafür die PowerCLI installiert sein, das Modul installiert sein und diese eine Code Ausführungsrichtlinie in der PowerShell aktiviert sein. Aber im Endeffekt sollte damit ein normales ISO bei raus kommen.
Bei dem ImageProfile "myprofile" den gewünschten Profilnamen eingeben der bei Get-EsxImageProfile gefunden wird (z.B. ESXi-7.0.1-16850804-standard).
 
Kleiner Nachtrag zu meinem letzten Post, habe hier eine schöne Liste der aktuell verfügbaren Image Profiles gefunden: https://www.virten.net/vmware/vmware-esxi-image-profiles/
Damit sollte man sich den Aufruf von Get-EsxImageProfile sparen.


Noch eine andere Information in die Runde, habe heute erfolgreich auf meinem Laptop (DELL G3 3590) ESXi 7.0U1c installiert. Da ich auf der internen SSD des Laptops Win10 installiert habe, habe ich mich für die ESXi Installation auf einer externen Festplatte (SSD 500GB, per USB angeschlossen) entschieden. Ferner musste ich einen externen USB Netzwerkadapter nutzen.
Ich habe mich dabei an dem Link aus meinem vorherigen Post orientiert und erfolgreich ein ISO erstellt der mit dem USB NIC Fling den benötigten Treiber für den Netzwerkadapter beinhaltet.

Danach habe ich die Installation ausgeführt, aber folgende Boot-Option gesetzt:
Code:
systemMediaSize=min
Das reduziert den zugewiesenen Speicherplatz für die ESX-OSData Partition. Ohne den Parameter füllt die Partition die gesamte SSD und ich kann keinen VMFS Datastore für VMs erstellen.
Mit dem Parameter ist die Partition nur noch 120GB groß und ich habe 348GB für VMs übrig.
Allerdings konnte ich danach keine VMFS Partition über die Web-Gui erstellen, dort trat eine Fehlermeldung auf. Nach etwas Recherche bin ich dann auf folgende Seiten gestoßen:
https://www.virten.net/2016/11/usb-devices-as-vmfs-datastore-in-vsphere-esxi-6-5/ und https://rakhesh.com/virtualization/...xi-on-a-usb-disk-and-using-it-as-a-datastore/
Daraus ergaben sich folgende Schritte für mich:
Code:
# Festplatten anzeigen lassen
ls -lah /dev/disks/

# Partitionsinformationen für die betroffene Festplatte anzeigen
partedUtil getptbl /dev/disks/mpx.vmhba32:C0:T0:L0

# Neue Partitionstabelle schreiben
partedUtil setptbl /dev/disks/mpx.vmhba32:C0:T0:L0 gpt "1 64 204863 C12A7328F81F11D2BA4B00A0C93EC93B 128" "5 208896 8595455 EBD0A0A2B9E5443387C068B6B72699C7 0" "6 8597504 16984063 EBD0A0A2B9E5443387C068B6B72699C7 0" "7 16986112 268435455 4EB2EA3978554790A79EFAE495E21F8D 0" "8 268437504 1000204851 AA31E02A400F11DB9590000C2911D1B8 0"

# Festplatten anzeigen lassen
ls -lah /dev/disks/

# Partitionsinformationen überprüfen
partedUtil getptbl /dev/disks/mpx.vmhba32:C0:T0:L0

# VMFS6 Partition erstellen
vmkfstools -C vmfs6 -S usb-esx1 /dev/disks/mpx.vmhba32:C0:T0:L0:8

Wichtig ist hier der Punkt neue Partitionstabelle schreiben. Der Befehl
Code:
partedUtil setptbl
überschreibt nämlich die gesamte vorhandene Partitionstabelle. Daher müssen die bestehenden Partitionen erneut definiert werden und am Schluss noch die neue angehangen werden.
Das Ergebnis wie es in der Web-Gui aussieht habe ich als Screenshot angehangen.

Fertig ist mein Testsystem und ich kann jetzt mal ein bisschen mit der 7er Version rumspielen :bigok:
 

Anhänge

  • usb-esx1.PNG
    usb-esx1.PNG
    14,5 KB · Aufrufe: 128
Gute Methode; da spart man sich das nachträgliche rumbriegeln an bereits angelegten Partitionen.
Muss ich gleich die Tage mal testen. 500er USB-SSDs als Spare hab ich eh im Schrank, potentiell muss man da dann nur die Sektorgrenzen des neuen VMFS Datastores an die SSD etwas anpassen.

Geht übrigens erst ab der ganz neuen 7.0U1c (Build 17325551), bei älteren Builds gibts diese Option noch nicht.
 
Zuletzt bearbeitet:
Noch eine andere Information in die Runde, habe heute erfolgreich auf meinem Laptop (DELL G3 3590) ESXi 7.0U1c installiert. Da ich auf der internen SSD des Laptops Win10 installiert habe, habe ich mich für die ESXi Installation auf einer externen Festplatte (SSD 500GB, per USB angeschlossen) entschieden. Ferner musste ich einen externen USB Netzwerkadapter nutzen.
Ich habe mich dabei an dem Link aus meinem vorherigen Post orientiert und erfolgreich ein ISO erstellt der mit dem USB NIC Fling den benötigten Treiber für den Netzwerkadapter beinhaltet.

Danach habe ich die Installation ausgeführt, aber folgende Boot-Option gesetzt:
Code:
systemMediaSize=min
Das reduziert den zugewiesenen Speicherplatz für die ESX-OSData Partition. Ohne den Parameter füllt die Partition die gesamte SSD und ich kann keinen VMFS Datastore für VMs erstellen.
Mit dem Parameter ist die Partition nur noch 120GB groß und ich habe 348GB für VMs übrig.
Laut der Versionshinweise zu VMware ESXi 7.0 Update 1c beträgt die Minimalgröße (systemMediaSize=min) für die Systemspeicherpartitionen lediglich 33 GB. Es wird zwar darauf hingewiesen, dass "Der ausgewählte Wert muss dem Zweck Ihres Systems entsprechen. Beispielsweise muss ein System mit 1 TB Arbeitsspeicher das Minimum von 69 GB für die Systemspeicherung verwenden." Aber das kann doch wohl kaum für einen Laptop gelten. Demnach sollten Dir doch eigentlich insgesamt etwa 435 GB für VMs zur Verfügung stehen...?
 
Ja, eigentlich sollte mir schon mehr Speicher zur Verfügung stehen. Verstanden habe ich es auch nicht wirklich. Vlt. funktioniert das ganze noch nicht so reibungslos und der Parameter min hat nicht gegriffen und stattdessen wurde default genutzt? Aber auch da passt die Größe nicht exakt...

Da ich vorerst mit den 348GB zurecht komme habe ich es dabei belassen und nicht weiter experimentiert.
 
Ja, eigentlich sollte mir schon mehr Speicher zur Verfügung stehen. Verstanden habe ich es auch nicht wirklich. Vlt. funktioniert das ganze noch nicht so reibungslos und der Parameter min hat nicht gegriffen und stattdessen wurde default genutzt? Aber auch da passt die Größe nicht exakt...

Da ich vorerst mit den 348GB zurecht komme habe ich es dabei belassen und nicht weiter experimentiert.
Da ich hier noch eine 250GB SSD rumfliegen hatte, habe ich es soeben getestet. Zunächst habe ich ESXi 7.0b-16324942, danach ESXi 7.0U1c-17325551 probiert und jeweils die Bootoption systemMediaSize=min gesetzt.

Resultat:
ESXi 7.0b berücksichtigt die Option nicht, von 234 GB hatte ich 100 GB direkt als datastore1 verfügbar (den musste ich also nicht nochmal separat anlegen).
ESXi 7.0U1c berücksichtigte jedoch die gesetzte Option, von 234 GB habe ich 201 GB als datastore1 verfügbar (musste also ebenfalls nicht separat angelegt werden).

Den Download von ESXi 7.0U1c musste ich neu bei VMware registrieren, bevor ich mir dann die 60-Tage-Trial-Version runter laden konnte. Die fertige EXSi 7.0U1c Installation hat meinen bereits vorhandenen Free-License-Key dann aber anstandslos akzeptiert.
 
Zuletzt bearbeitet:
Ich bin ratlos. Wie kann ich folgendes Phänomen erklären? Vielleicht ein Bug?


Ich hab in einen Gast OPNsense installiert. Mit vier vNICs startet die VM ohne Probleme und ich kann sie in der virtuellen Umgebung als auch im physischen LAN nutzen:
1609397638835.png



Sobald ich die fünfte (oder mehr) virtuelle Netzwerkkarte hinzufüge und boote ist die Sense nicht mehr erreichbar:
1609397688731.png


Schmeiße ich die fünfte Karte wieder aus der Konfig, komm ich wieder drauf. Es sind alles vmxnet3.

Jetzt zu den Beobachtungen:

Wenn ich vier Karten drin habe und mir die xml der Sense ansehe, werden die vier Karten alle alx vmx0 - vmx3 erkannt. Soweit ist das wie erwartet, weil Network Adapter 1 = vmx0 bis Network Adapter 4 = vmx3 entspricht.

Boote ich die VM mit fünf oder mehr Karten, werden die zuvor eingerichteten Interfaces weiterhin in der Konsole von opnsense gelistet (klar, stehen ja auch fix in der xml von der vorigen Konfig mit vier Karten). Ich sehe sogar, dass sich das PPPoE-Interface am DSL Provider anmeldet und eine Internet-IP bekommt. Ich kann sogar 1.1.1.1 pingen - jedoch nicht in oder von irgend einem lokales Netz.

Boote ich die Sense mit fünf oder mehr Karten und schmeiße nach dem Boot im Betrieb z.B. die fünfte und sechste Karte aus der Gast-Konfig raus, kann ich in der Konsole beobachten, wie vmx1 und vmx3 detached werden (wie weiter oben gesagt, sollte vmx1 und vmx3 aber sNetwork Adapter 2 und 4 entsprechen und nicht 5 und 6). :
1609397891446.png


Drehe ich den Spieß um und boote mit vier Network Adaptern und füge dann im Betrieb ein oder mehr Karten hinzu, werden diese jedoch richtigerweise als vmx4 und vmx5 erkannt:
1609397975794.png


In diesem Fall läuft die Sense weiter und ich kann auch die zwei neuen NICs im Webinterface der sense sehen, aber wenn ich sie als Interface konfigurieren will, speichert mir die Sense die Einstellung nicht ab (das liegt aber wohl an einem FreeBSD-Bug wenn man nach der Fehlermeldung sucht).

Merkwürdig ist ja, dass beim entfernen der fünften (und sechsten) NIC vmx1 und vmx3 detached werden und nicht vmx4 und vmx5. Das heißt ja, ESXi sortiert ab der fünften Karte die NICs intern um. Das dürfte dann auch erklären, warum nichts mehr geht: Die IP-Netze kommen wahrscheinlich nicht mehr auf dem Adapter an, an dem opnsense es erwartet. Vielleicht mit Ausnahme von vmx0 (was WAN/PPPoE ist), was weiterhin vmx0 bleibt.

Installiert ist 7.0U1c.



Unabhängig davon auch folgendes Problem:

Ich hatte zuerst versucht, nur drei NICs in die OPNsense zu konfigurieren. Eine für WAN, eines für Management, eines für VLANs. Ich habs aber nicht hinbekommen, die getaggten Ethernetpakete die ich in der VM(!) mit opnsense erzeuge durch die vNIC und den vSitch bis zum physischen Switch zu bekommen. Was muss man tun um das hinzubekommen, wenn man das VLAN-Handling nicht dem ESXi überlassen will?
 
Zuletzt bearbeitet:
Reich der VM doch einfach ne Dual/Quadport nic durch. Dann hast die Thematik mit VLAN@esx vom Tisch.
 
Warum tust du das?
VLANs und zwei Netzwerkkarten reichen dicke.
Du musst nur sicherstellen, dass ein VLAN zum WAN gereicht wird und der Rest ins LAN gekippt wird.
Ich hab immernoch nicht verstanden, wieso man eine Firewall virtualisiert.
Viel zu viele Abhängigkeiten...
Das WAN VLAN untagged auf eine VMK und die in OPNsense als WAN konfiguriert.
Die anderen VLANs (inkl. Mgmt-VLAN) tagged auf die andere VMK gelegt und erst in OPNsense auseinander genommen.
 
Eine Firewall zu virtualisieren, könnte Sinn machen, wenn man seine Gäste besonders abgrenzen oder irgendetwas ausprobieren will. Speziell die IoT-Geschichte benötigt da meiner Meinung nach reichlich Nachhilfe. Bevor man dazu noch weitere HW hinstellt, könnte man den Job doch virtualisiert durch einem eh laufenden ESXi erledigen lassen...
 
@Weltherrscher bin eig. auch kein Freund von virtualisierten FWs. Jedoch ist das mittlerweile ne Glaubensfrage geworden.
Bisher hab ich ne dedizierte Maschine dafuer.

In Zukunft wird jedoch ne AIO Kiste benoetigt, geht einfach nicht anders.
Und wenn man weiterhin NAS, paar VMs, Firewall etc... haben moechte dann bleibt leider nur ne virtualisierte uebrig :d
 
Hi

Hier auch Hardwarefirewall am Start; schon ewig. Hatte zwischendurch mal das ganze Netzwerk virtualisiert. Nie wieder. Trotzdem 7 pNICs belegt am Mainserver, bei 15vSwitches und jenen vLANs am Switch.

Wie Dayworker sagt: zum testen gehts virtuell, aber sonst besser physisch.

Und wenn virtuell, kann man ja den ganzen WLANs eigene SSID geben. Also an einem einzlnen Access Point, an einer pNIC. Bzw. am Switch.
 
Zuletzt bearbeitet:
Leute, danke für eure Reaktionen. Ich kann den Kern meiner Frage auch auf einen anderen Anwendungsfall auslegen:

Ich will meine Napp-IT-Installation in mehreren Netzen (sowohl physische Netze für andere Clients als auch virtuelle Netze für Server) bereitstellen. Außerdem noch andere Dienste. Ich kann aus rein praktischen Gründen nich für jede VM eine eigene NIC in den Server bauen und diese dann über passthrough bereit stellen. Dafür wollte ich eigentlich SR-IOV mit den Intel 10Gbit NICs nutzen, aber da bin ich ja wie weiter vorne schon festgestellt auf die Schnauze gefallen, weil ESXi free SR-IOV nicht zulässt. Mit der 200EUR/Jahr-VMUG-Lizenz hadere ich noch, also muss es erstmal so gehen...

Um dieses grunsätzliche Problem zu bewerkstelligen muss es möglich sein, im Gastbetriebssystem 802.1Q zu konfigurieren und die getaggten Ethernet-Frames nach außen zu bekommen. Das hab ich nich hinbekommen. Wie geht das? Mir scheint als würde der ESXi-Hypervisor 802.1Q aus den Ethernetframes rauszufiltern. Gibts dafür ein Tuneable oder sowas um das zu ermöglichen? Oder find ich einfach nur die Einstellungen nicht?

Um das Problem erstmal zu umgehen, wollte ich dem Router mehrere vmxnet 3 Adapter bereitstellen. Dabei ist mir oben beschriebenes Problem aufgefallen. Ich habs noch nicht getestet, aber es ist doch durchaus annehmbar, dass dieses beobachtet Phänomen generell auftritt - oder wieso sollte das abhängig vom Guest-OS sein? Bestehende Adapter sollten eigentlich beim Hinzufügen weiterer vmx-Adapter ihre Zuordnung behalten und kein russisch Roulett spielen, wenn weitere Adapter dazu kommen... oder nicht?

Selbst wenn ich die Zuordnung der vmx-Adapter immer wieder neu anpasse, lässt sich dieser Workaround nicht beliebig lange anwenden, denn mehr als 10 virtuelle Netzwerkkarten pro VM sind nicht möglich, ab der elften erscheint diese Fehlermeldung:
Failed to reconfigure virtual machine opnsense. Number of virtual devices exceeds the maximum for a given controller.

10 VLANs sind perspektivisch schnell belegt... Also, hat jemand eine Erklärung oder Lösung für das oben beschriebene Phänomen?


Ansonsten: Im Homelab hat man nicht die Möglichkeit (und aus Energietechnischen Gründen = KOSTEN ; Wohnung in der Stadt = KOSTEN pro m² Wohnfläche ; etc. PP) auch nicht das Interesse, beliebig viel Equipment aufzustellen.

Ich wollte auch keine Grundsatzdiskussion auslösen was die Virtualisierung von Firewalls angeht. Ich sehe das auch so, dass man für grundsätzliche Dinge eine Hardwarefirewall nutzen sollte. Dazu zählt für mich der Internetzugang, DNS und Zeitserverdienst, DHCP, ggf auch VPN. Dafür hab ich nach wie vor meine PC Engines APU mit opnsense drauf - die reicht für den 100mbit DSL-Anschluss noch bestens. Um den 10Gbit-Traffic geroutet zu bekommen und vor allem zu filtern, muss aber Leistung her. Es macht außerdem keinen Sinn, Traffic der in der virtuellen Umgebung erzeugt wird auf einen physischen Switch bzw. einen physischen Router/FW zu schicken, wenn das NAS und Serverdienste auf dem selben Blech in einer virtuellen Umgebung laufen. Da greift das Prinzip: Keep things local. Und wie schon weiter oben angemerkt, kann man auch in der virtuellen Umgebung für Sicherheit sorgen und sich DMZs aufbauen...
 
Zuletzt bearbeitet:
Die virtuellen ESXi vSwitches unterstützen vlans. Man kann also mehrere vnics einer VM je einem Vlan ungetaggt zuweisen. Da Solaris/OmniOS ihrerseits auch Netzwerkvirtualisierung mit virtuellen Switches und vnics unterstützen, kann man auch alle getaggten Vlan auf eine Nic aufschalten und innerhalb von Solaris/OmniOS auf interne vnics verteilen, siehe z.B. https://docs.oracle.com/cd/E26502_01/html/E28992/gmhfi.html
 
Ja, du sagst es. Mehrere. Aber das Limit ist 10 vNICs pro VM.

Bei einer Router/Firewall-Installation reicht das nicht. Wenn man WAN, "LAN", Management-LAN, mehrere WLAN-Netze anlegt, bleibt nicht mehr viel übrig für DMZs, Testumgebung, ...

Und genau das was du vorschlägst (Ethernetframes mit VLAN ID taggen) wird bei mir vom ESXi rausgefiltert und erreicht das physische Netz nicht.

Laut diesem Whitepaper sollte es gehen (ist aber stark veraltet): https://www.vmware.com/pdf/esx_vlan.pdf

Genau genommen will ich den auf Seite vier (Figure 5) beschriebenen VGT Mode nutzen.

Muss man das irgendwo aktivieren?
 
Zuletzt bearbeitet:
Wer es nicht schlauer die Firewall auf nen extra Gerät zu installieren ? Ich bin eh kein großer Freund von Virtuellen Firewalls.
 
@Ceiber3
Nein wäre es nicht und dazu hat @chicken bereits seine Meinung genau 3 Posts über deinem kundgetan.

@chicken
In deinem verlonkten PDF gehts um ESX-ohne-i und dann auch noch in der Version 2.x. Ich glaube kaum, daß das noch irgendetwas mit den aktuellen ESXi-Versionen gemein hat.
 
Ich habe hier mehrere virtualisierte Pfsense am Laufen.
Zu denen (da laufend mit Updates versorgt) habe ich erheblich mehr Vertrauen als in eine Hardware-Firewall ohne Updates über Wartungsvertrag und wenn ich da an meine Watchguards denke ist das richtig teuer...

Ganz nebenbei
Um eine aktuelle Firewall zu überwinden ist erhebliches Know How angesagt über das vor allem Geheimdienste verfügen. Gegen die wirds immer schwierig einen Schutz aufzubauen. Einfacher ist es bekannte Lücken alter Software auszunutzen. Bei ungepflegter Software, auch in Hardware-Firewalls ist das leicht auszunutzen. Oft genügt ein Netzscan aus China, Russland, USA,..

Ein gewöhnlicher Krimineller geht eh in die nächste Bahnhofskneipe und engagiert jemanden der einsteigt und den Server klaut. Kosten und benötigtes Know How: marginal
 
Ich kann mir meine Frage nach zwei Tagen Recherche selbst beantworten... Das verlinkte PDF ist zwar steinalt, im Kern funktioniert das aber auch bei aktuellen VMware-Hypervisoren noch genau so.

Hier gäbs aktuellen KB-Artikel dazu:

In der Standardeinstellung können Gastsysteme keine VLAN-Tags über den vSwitch leiten. Um das zu ermöglichen, muss man zuerst eine Portgruppe erstellen und dieser als VLAN-ID die 4095 zuweisen. Richtig gelesen, diese Adresse ist eigentlich außerhalb des VLAN-Adressbereichs. Mit dieser VLAN ID teilt man dem Hypervisor mit, dass der Gast sich selbst um VLAN-Tagging kümmert und die Tags dann auch auf den virtuellen sowie physischen Switch durchgereicht werden dürfen.

1609622112916.png


Dann wie gewohnt den Adapter in der VM der Wahl einbinden. Erstellt hab ich einen vmxnet 3 Adapter. Wahrscheinlich gehts auch mit dem E1000.

1609622344192.png


Zum Schluss im Betriebssystem des Gasts beliebig die VLANs konfigurieren.

Anzumerken ist, dass man bei den "Standard vSwitch" von ESXi Free KEINE Limitierung vornehmen kann, welche VLAN IDs überhaupt berechtigterweise vom vSwitch weitervermittelt werden dürfen. Wenn man das nicht berücksichtigt, könnte sich ein Angreifer durch Umkonfiguration des Gasts Zugriff auf alle auf dem Switch anliegenden VLANs verschaffen. Der Standard vSwitch hat also keinerlei Verarbeitungslogik drin, der verteilt nur stumpf Ethernetframes an alle virtuellen und physischen angeschlossenen Adapter. Regeln für erlaubte VLANs auf einem vSwitch geht wohl nur mit vNetwork Distributes Switches, die wahrscheinlich erst ab Enterprise Lizenzen enthalten sind?
Um hier Sicherheitsproblemen aus dem Weg zu gehen, müsste man je nachdem doch mit mehrere Standard vSwitches und ggf. doch mit mehr als einem physischen Netzwerkadapter arbeiten. Es erhöht aber auf jeden Fall die Flexibilität.
 
Zuletzt bearbeitet:
Ich hab meine OPNsense auf nen altes ITX-Board und ne X520 im PCIe x16 ausgelagert, belegt gerade mal eine HE und fluppt einwandfrei.

Somit auch immer aktuell und ich bin unabhängig von ESXi-Updates oder gar nem Ausfall des ESXi, das erhöht den WAF für die gesamte IT ganz enorm. :fresse2:
Wenn das Internet ausfällt, ist hier Polen offen... :-/
 
Ahjo. Ich habe auch für hiesige Verhältnisse recht unorthodox die Familie nur hinter einer Fritzbox und dann halt "alles andere" hinter einer weiteren ESXi-virtualisierten Firewall. Die Fritzbox ist zugleich "first line of defense" und zuverlässiger & nahezu "unverfrickelbarer" Dauerläufer zur Sicherung des Familienfriedens...
 
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