ESX / ESXi - Hilfethread

@Tobias) Was ist mit den anderen onBoard NICs? Bekommst du da ein alive nach ping? Oder auch tot?

---------- Post added at 13:21 ---------- Previous post was at 13:12 ----------
fdsonne schrieb:
Kann ich nicht bestätigen...
Wir haben schon 2,5TB+ FC LUNs gehabt, welche out of the box vom ESX gefressen werden...
Zum Vergrößern anklicken....

RealJMC hat schon Recht, genau genommen kann ein LUN maximal 2 TB groß sein, jedoch kannst du ab ESXi 5 durch Kombination mehrere LUNs VMFS (also Dateisysteme) bis zu 64 TB erstellen. Ich hatte LUNs und VMFS bzw. vmdks selber durcheinander geworfen.

Also:
Max LUN size = 2 TB
Max VMFS size = 64 TB

Beliebig viele VMDKs innerhalb des VMFS (wobei die optimale Anzahl nat. von dem Workload der vms abhängt)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wobei ein VMDK auch nur maximal 2TB groß sein darf - und du das dann auf OS-Ebene wieder zusammenführen kannst...
 
antilope114 schrieb:
RealJMC hat schon Recht, genau genommen kann ein LUN maximal 2 TB groß sein, jedoch kannst du ab ESXi 5 durch Kombination mehrere LUNs VMFS (also Dateisysteme) bis zu 64 TB erstellen. Ich hatte LUNs und VMFS bzw. vmdks selber durcheinander geworfen.

Also:
Max LUN size = 2 TB
Max VMFS size = 64 TB

Beliebig viele VMDKs innerhalb des VMFS (wobei die optimale Anzahl nat. von dem Workload der vms abhängt)
Zum Vergrößern anklicken....

Und wie will ich das machen, wenn ich wie im Bild oben einen Raidcontroller mit lokalen Platten und einem einzigen Raid bzw. in dem Fall zwei Raid Arrays (wegen unterschiedlichen Platten) habe!?
Fakt ist, der ESX in der Version 5 frisst auch LUNs größer 2TB. Mehr gibts dazu nicht zu sagen...
 
Mal ne Frage an euch, wir haben nun mittlerweile ganz paar Hosts, welche alle Nase lang den Batteriestatus des Hosts als Alarm bringen. Was ich mir nicht erklären kann... Denn das Problem ist, der Raidcontroller besitzt keine BBU. Kann man die Meldung irgendwie wegbekommen?

Den Alarm bestätigen und dann löschen bringt nur bedingt Abhilfe, denn der kommt irgendwann von allein wieder...
 
LSI Controller? Da hab ich mich letztes Jahr mit dem LSI Support fast geschlagen wegen...

Wenn die Batterie nicht da ist wird gemeckert. Also LSI gefragt, die sagen "Frag vmware" - die sagen "Aber das kommt ja von dem LSI CIM Provider!"
Also wieder bei LSI nachgefragt, dann im nächsten Level gelandet "Aber das ist vmware schuld" - "Aber das tritt erst auf nach dem der LSI CIM installiert worden ist" - "Bekommen sie im MSM eine Warnmeldung?" "Nein" "Dann ist vmware schuld!"

Ich habs irgendwann aufgegeben und hab für die 3 Server Battery Packs bestellt weils mir zu doof geworden ist...
 
Jupp, sind Fujitsu Maschinen und die haben meine ich alle samt LSI Controller mit Fujitsu Label... Ich verwende auch das Fujitsu Install ISO inkl. CIM Provider und Tools... :(

Das doch alles Müll... Komischerweise mit nem 4.1er ESX/ESXi gehts ohne Meckern...
 
Jein, also kann gut sein, das es da was ab Werk gab. Aber, wir haben ganz paar Maschinen, wo es damals unter 4.x die HDDs nicht im Hardware/Sensormenü angezeigt hatte... Sprich wir wurden nicht über Plattenausfälle informiert. Nach Install des Fujitsu Images ging das dann aber... Scheinbar haben die also doch noch was hinzugefügt.
 
Vielleicht hat Fujitsu ja ne Möglichkeit das ganze besser bei LSI zu reklamieren - bei mir hat sich der Support da leider ziemlich "blöd" angestellt...
 
Hallo,

ich möchte eine Firewall virtualisieren. Was ist der beste/sichere Weg um einen OnBoard-Netzwerkport, welcher auch vom ESXi unterstützt wird der VM zur Verfügung zu stellen? Ein eigener vswitch und hier die VM mit der NIC verbinden oder die NIC mittels PassThrough der VM unterschieben?
 
je nachdem, wie sicher du es willst...

Es ist schonmal unsicherer, die Firewall auf nem Virtualisierungshost zu packen, als diese direkt auf die Hardware zu installieren. ;)
Mit dem Passthrough erkaufst du dir zumindest den Vorteil, das etwas mehr Sicherheit herscht, als wenn du gänzlich die Adapter mit anderen VMs sharest.


Unterm Strich ist es wohl aber für privat immernoch ziemlich egal. Vor allem, wenn man vor der Firewall VM immernoch irgend nen Router stellt, der die Einwahl tätigt und ein NAT macht.
Somit kommt der potentielle Angreifer optimalerweise nicht bis zur Firewall VM bzw. an den Host und kann auch nicht angreifen ;)
 
Da ich schon öfter davon lese dass man keine Firewall virtualisiert würd mich doch mal interessieren ob es tatsache praktische Angriffe auf den ESXi gibt welcher die virtuelle FW weniger sicher macht.

Hintergrund ist dass ich in Zukunft selbst ne Astaro betreiben will, im idealfall virtuell. Ich sags mal so, umsonst wird Astaro seine Appliance nicht auch als VM anbieten, oder?
 
mueder joe schrieb:
Da ich schon öfter davon lese dass man keine Firewall virtualisiert würd mich doch mal interessieren ob es tatsache praktische Angriffe auf den ESXi gibt welcher die virtuelle FW weniger sicher macht.
Zum Vergrößern anklicken....
Kommt halt drauf an, welches Szenario du betrachtest.

Wenn der Angriff von außen kommen soll, muss die Router-VM eine Lücke in einem Dienst haben, der von außen erreichbar ist. Optimalerweise läuft auf einem Router kein solcher Dienst. Dann bleibt nur der IP-Stack als Angriffsvektor oder die Schnittstelle vSwitch<->VM, die irgendwie mit speziellen Paketen angreifbar sein muss. In der Hinsicht wäre eine extra NIC per Passthrough als externes Interface "sicherer".

Wenn du allerdings virtuell Dienste hostest und diese in einer virtuellen DMZ sitzen, dann wird das ganze gleich mal ne Ecke komplexer. Wenn da ein virtueller Host mal brennt, ist eigtl der ganze ESXi-Host potentiell im Eimer.
 
Also ist das virtualisieren von der Firewall eher ein Design-Problem als denn ein generelles. Gut, extra NIC für den Router wollt ich schon nutzen das passt ja ;-)

Edit:
Dienste in einer DMZ sind übrigens nicht angedacht...
 
Zuletzt bearbeitet:
Ich sag mal so, du schaffst dir eine zusätzliche Abstraktionsschicht, wo selbst der Hersteller der Firewalllösung keinen Einfluss drauf hat, wie Sicher der ganze Spaß ist.

Und es ist ja nicht so, das besagte Firewalllösungen als virtuelle Appliance direkt public im WAN erreichbar sind, zumindest idR nicht. Sondern man nutzt eben das Feature eher dahingehen, das man eben unabhängig der Hardware gewisse Dienste bereitstellen kann.
Wir nutzen beispielsweise die Astaro Lösungen (virtuell) als Proxy und Mailgateway. Nur stehen diese Appliance in einer DMZ und nicht direkt im WAN.

Bei Kunden sind zwar auch ASG/UTMs im Einsatz, welche direkt im WAN erreichbar sind, nur sind das alle samt physische Appliances.
Es würde wohl auch niemand aus Sicherheitssicht auf die Idee kommen, einen Hyper-V, XEN, ESX(i) und Co. direkt via WAN erreichbar zu machen ;)


Unterm Strich bleibt der Punkt aber immernoch diskusionswürdig. Denn es kommt schlicht und einfach drauf an, was die VM absichern soll. Eine Firewalllösung, welche das interne LAN von einem weniger sichereren LAN (beispielsweise DMZ) trennt, kann durchaus virtuell sein. Aber dann hat man idR noch eine Router/Firewall Appliance davor stehen, welche zumindest verhindert, das potentielle Angreifer direkt bis zum Virtualisierungshost kommen. Und wenn es nur ein simpler Router ist, welcher via NAT Regeln das interne LAN vom WAN trennt.
 
fdsonne schrieb:
Wir nutzen beispielsweise die Astaro Lösungen (virtuell) als Proxy und Mailgateway. Nur stehen diese Appliance in einer DMZ und nicht direkt im WAN.
Zum Vergrößern anklicken....

So hab ich's vor. Und so wie ich das lese kann ich also beruhigt meine virtuelle Astaro (die schon zu Testzwecken existiert, inkl Home Use Linzenz - ist für mich auch privat gedacht)

fdsonne schrieb:
Bei Kunden sind zwar auch ASG/UTMs im Einsatz, welche direkt im WAN erreichbar sind, nur sind das alle samt physische Appliances.
Zum Vergrößern anklicken....

Naja, ich kenn die Kosten der größeren ASG's, da vergeht es einem schon :d
Genauso kenn ich den Ressourcenverbrauch bei ner Handvoll Clients. Die HW-Kosten könnte man sich sparen, da jeder halbwegs aktuelle Xeon die Astaro auf einer Backe absitzt. Deshalb auch meine Idee mit der VM.

fdsonne schrieb:
Es würde wohl auch niemand aus Sicherheitssicht auf die Idee kommen, einen Hyper-V, XEN, ESX(i) und Co. direkt via WAN erreichbar zu machen
Zum Vergrößern anklicken....

Kenn ich praktisch auch nicht, auf solche Ideen wäre ich auch gar nicht gekommen.

Ich halte also mal für mich fest: Mein Plan die Astaro auf nem ESXi hinter meiner Fritzbox zu positionieren ist aus Sicherheits-Sicht also vollkommen OK. Da ich eh mit mehreren NICs arbeiten wollte (ich wollte von Anfang an Internet und internes Netz über getrennte Hardware lösen) werd ich da wohl auch weniger Probleme haben.
 
Zuletzt bearbeitet:
fdsonne schrieb:
Es würde wohl auch niemand aus Sicherheitssicht auf die Idee kommen, einen Hyper-V, XEN, ESX(i) und Co. direkt via WAN erreichbar zu machen ;)
Zum Vergrößern anklicken....
Wie sieht es aus, wenn der ESXI Host zwei NICS hat, ein direkt für WAN, einen für LAN.
Dann läuft als VM eine Firewall/Router und am virtuellen LAN Anschlusss weitere VMs.
ESXI wäre durch eine lokale IP ja nur durch das LAN erreichbar.
Wäre das Sicherheitstechnich vertretbar?
Am NIC, welches direkt am Internet ist hängt dann ja eigentlich nur die Firewall VM.
 
mueder joe schrieb:
Naja, ich kenn die Kosten der größeren ASG's, da vergeht es einem schon :d
Genauso kenn ich den Ressourcenverbrauch bei ner Handvoll Clients. Die HW-Kosten könnte man sich sparen, da jeder halbwegs aktuelle Xeon die Astaro auf einer Backe absitzt. Deshalb auch meine Idee mit der VM.
Zum Vergrößern anklicken....

Im Grunde kost die Hardware gar nix ;) die Lizenzen kosten... Die Hardware gibts passend zur Lizenz dann dazu ;)
Des weiteren besteht zumindest im Firmenumfeld ein Unterschied zwischen dem Lizenzmodell von virtuell und Hardware. Bin aber kein Astaro Spezi... Lizenzen für die VM sind definitiv schweine teuer, gerade wenn es darum geht, das ganze zu clustern. ;)

Timsu100 schrieb:
Wie sieht es aus, wenn der ESXI Host zwei NICS hat, ein direkt für WAN, einen für LAN.
Dann läuft als VM eine Firewall/Router und am virtuellen LAN Anschlusss weitere VMs.
ESXI wäre durch eine lokale IP ja nur durch das LAN erreichbar.
Wäre das Sicherheitstechnich vertretbar?
Am NIC, welches direkt am Internet ist hängt dann ja eigentlich nur die Firewall VM.
Zum Vergrößern anklicken....

Im Grunde stellt sich die Frage eigentlich nicht. Da eben die virtualisierungs Lösung angreifbar ist. Und dir der Hersteller deiner Firewalllösung keine Garantie geben kann, wie sicher der Virtualisierer ist. Man kann es machen, es wird idR auch nciht viel passieren, würde ich behaupten, aber rein aus Sicherheitstechnischer Sicht ist es äußerst bedenklich... Vor allem dann, eben vor der Astaro nix weiter kommt an Routertechnik.
 
fdsonne schrieb:
Im Grunde stellt sich die Frage eigentlich nicht. Da eben die virtualisierungs Lösung angreifbar ist. Und dir der Hersteller deiner Firewalllösung keine Garantie geben kann, wie sicher der Virtualisierer ist. Man kann es machen, es wird idR auch nciht viel passieren, würde ich behaupten, aber rein aus Sicherheitstechnischer Sicht ist es äußerst bedenklich... Vor allem dann, eben vor der Astaro nix weiter kommt an Routertechnik.
Zum Vergrößern anklicken....

Geht um IpFire nicht Astaro, dass ist ja aber egal.
Ich denke ich werde es mit der virtualisierten Firewall ohne Schutz davor machen.
Das ist alles nur privat, keiner wird sich bei mir große Mühen machen, mich zu hacken.
Außerdem kann ich mir vorstellen, dass es unter ESXi viel weniger Sicherheitslücken als in den gebräuchlichen Consumerroutern gibt.
 
Hallo,

so wie Timsu100 es beschreibt wollte ich es machen. IPfire und eine noch freie Nic des ESXi-Host. Falls DMZ usw. verwendet werden sollte, habe ich aber auch noch eine 4fach PCI NIC zu liegen, die dann natürlich als PathTroughlösung. Ist aber erstmal nicht vorgesehen.
Davor steht noch ein Telekomrouter Speedport W920V. Wobei ich noch weis, ob das doppelte NAT ein Problem wäre, ansonsten würde ich nur das Modem des Telekomrouter verwenden.
Hauptsächlich geht es mir um einen Squid-Proxy, Dansguard, ClamAV, Zugangsbeschränkungen für Kinder usw.
Unsicherer als die üblichen Consumergeräte die vom Internetanbieter mitgeliefert werden wird diese Lösung wahrscheinlich auch nicht sein. Es geht nicht um ein Firmenumfeld.
 
Würde ich nicht sagen... Das Problem ist eben, niemand kommt auf die Idee den ESXi direkt ins WAN zu stellen. Ein Consumer Router hingegen ist immer im WAN erreichbar ;) Auch wenn hier und dort mal ein paar "Lücken" auftauchen, kann man sowas schon als halbwegs sicher bezeichnen...

Aber was hast du für ne INet Anbindung, wenn du direkt ne public IP an der Firewall VM hast!?


@millenniumpilot
doppeltes NAT ist nicht das Problem, aber wozu brauchst du das? Lass doch den Speedport das NAT machen und betreib die VM direkt als Router und Firewall. So sparst dir das doppel NAT und es kann ebenso nix passieren, weil die Firewall regelt ;)
 
Zuletzt bearbeitet:
Gibt es denn schon Berichte, dass ESXi mit vertretbarem Aufwand gehackt wurde?
Wenn nicht, denke ich nicht, dass es dass erste mal bei mir passieren wird:)
 
Im allgemeinen sind "plötzliche" Sicherheitslücken vorher nicht bekannt.

Wenn aber sowas auftritt und es schwerwiegend ist, dann kann das nen großen Knall geben.
Die Risikobereitschaft liegt aber bei jedem selbst.

1. FW dediziert
2. NIC durchreichen
3. VM Net=WAN (ESX)
4. FW VM unter Windows

Das sind die Abstufungen bezüglich Sicherheit.
 
Hallo fdsonne,

ich bin was Firewalls betrifft überhaupt nicht fitt, benutze die Dinger nur. Aber machen Lösungen wie IPCOP, IPFire etc nicht immer auch grundsätzlich NAT?
Wenn es keine Probleme macht, lasse ich den Speeport normal als Router weiterlaufen und Portweiterleitungen, Proxi etc macht dann die VM mit IPFire (mit durchgereichter Nic). Habe ich da einen Denkfehler?
 
Für den gemeinen Anwender bringt Ipfire und Co keinen Vorteil gegenüber einem normalen Router.

Und ja, die machen grundsätzlich NAT, was anderes würde im Internet auch garnicht funktionieren. Es gibt grundsätzlich für jeden Anschluß nur eine IP Adresse, daher muß alles andere über NAT laufen.

Richtiges Routing gibt es nur in sehr großen Netzen, bzw Uninetzen, wo selbst nen Drucker ne öffentliche IP hat.

Ipfire und co zeichnen sich durch die Logs und weitere Dienste aus.

Ipfire und co ist ja eigentlich keine Firewall, sondern ein Router. ASG hingegen ist eine Firewall, welche also eine andere Aufgabe übernimmt.
 
Naja, ASG ist eigentlich die EierlegendeWollmichsau und kann auch routen

Ich hoff bei Sophos versauen die nix :d

Edit:
Jetzt hab ich hier aber was losgetreten :d

Aber gleich nochmal ne Frage zum ESXi:
Wie schaut es mit dem durchreichen von Onboard Netzwerkkarten aus? Gibt's da bekannte Probleme?
 
Zuletzt bearbeitet:
Anmelden, um zu antworten.
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