ESX / ESXi - Hilfethread

Das ist so richtig, wie du das eingestellt hast... Die VM sollte nun in VLAN 10 sprechen können. Intern in der VM Test, also in den Netzwerksettings dieser VM darfst du natürlich kein VLAN mehr mit geben/angeben!!
Wenn das nun nicht geht, dann prüfe am Besten den Switchport.

Alternativ kannst du dir auch nen Client schnappen, auf welchem du VLAN Tags am Netzwerkadapter mitgeben kannst -> diesen kannst du temporär mal an den Port "vmnic1" klemmen und ihm dann VLAN 10 drauf taggen... Dann sollte ebenso kommunikation durch gehen.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hallo und danke für deine Hilfe:)

ich habe so langsam das Gefühl, dass der NIC nicht richtig unter ESXI funktioniert....

Der erste NIC, der als Management fungiert funktioniert auf den Port am Switch, der bisher nicht mit dem zweiten NIC arbeitet anstandslos. Dort kann ich VLANs hinterlegen wie ich lustig bin. Ich schließe daher aus, dass die Konfiguration am Switch liegt. Zuvor funktionierte die Konfiguration auch mit Hyper-V.

NIC1 Intel® i210AT ESXI Management
NIC2 Intel® i217LM NIC für VMs
 
Kann durchaus sein, könntest ja mal versuchen, andere Treiber einzubinden respektive mal die VMware Foren zu durchwühlen, ob da wer noch Probleme mit dem Typ von NIC hat...

Wenn ein und der selbe Switchport mit einer anderen physischen NIC (inkl. VLANs) geht, dann sollte die Switchconfig in Ordnung sein.
Hyper-V und ESXi ist dahingehend ein massiver Unterschied, da bei Hyper-V die stino 0815 Windows Treiber funktionieren während es für ESXi oftmals entweder nur abgespeckte Versionen, irgendwelche Community-Ports oder offizielle, teils aber eben nicht vollends unterstützte Versionen gibt. Könnte also schlicht auch sein, dass die zweite NIC ein Problem mit VLANs hat, weil der Treiber da Bockmist baut und das bei der ersten NIC nicht der Fall ist!
 
Ich habe momentan keine Nerven mehr. Soviel probiert und nichts hat geholfen. Brauche nun etwas Ruhe von ESXI:d

Ich probiere es nächste Woche nochmal. Danke:)
 
Hi,

hab schon ein wenig Erfahrung mit Proxmox möchte jetzt aber das ganze auch mit Esxi Durchführung um dann zu entscheiden, welches eingesetzt wird.
Zu meiner Hardware:
- fujitsu d3417-b1 mit einem i3 6100 dazu ecc ram
-1x 60gb ssd
- 2x 120gb ssd
und storage....

Wie sollte man jetzt am besten vorgehen?
Meine Idee wäre.
Esxi auf USB Stick -> die 60gb ssd für napp-it -> dort einen mirror mit 2 x120gb für die VM an Esxi mit nfs freigeben.

Wäre das was oder hat jemand eine bessere Idee??

Dann noch eine wichtige Frage zum HBA. Hab das noch nicht ganz begriffen. Wie groß ist der Unterschied zu den Onboard Sata? Wenn ich jetzt das alles mit den Onboard Sata einrichte und mir später noch einen HBA hole kann ich das doch relativ einfach durch ZFS importieren oder? HBA passthrough und dann zfs pool importieren?
 
Swivel schrieb:
Dann noch eine wichtige Frage zum HBA. Hab das noch nicht ganz begriffen. Wie groß ist der Unterschied zu den Onboard Sata? Wenn ich jetzt das alles mit den Onboard Sata einrichte und mir später noch einen HBA hole kann ich das doch relativ einfach durch ZFS importieren oder? HBA passthrough und dann zfs pool importieren?
Zum Vergrößern anklicken....

Ja geht, habe ich im Prinzip gerade so gemacht. Pool auf Disk-an-onboard-SATA erstellt. SAS-HBA kam dann später dazu, Disk von onboard an HBA umgesteckt, läuft.

Ich musste nur den Pool einmal exportieren und wieder importieren, da Solaris/nappit für die Identifikation der zu einem Pool zugehörigen (SATA-)Disks offenbar Daten verwendet (SATA-Port-Nummern?), die sich beim Umstecken u.U. ändern. Kann man glaub auch beim Pool-Erstellen abweichend konfigurieren, hatte ich - weil nicht der Standard - aber versäumt.
 
Swivel schrieb:
Hi,

hab schon ein wenig Erfahrung mit Proxmox möchte jetzt aber das ganze auch mit Esxi Durchführung um dann zu entscheiden, welches eingesetzt wird.
Zu meiner Hardware:
- fujitsu d3417-b1 mit einem i3 6100 dazu ecc ram
-1x 60gb ssd
- 2x 120gb ssd
und storage....

Wie sollte man jetzt am besten vorgehen?
Meine Idee wäre.
Esxi auf USB Stick -> die 60gb ssd für napp-it -> dort einen mirror mit 2 x120gb für die VM an Esxi mit nfs freigeben.

Wäre das was oder hat jemand eine bessere Idee??

Dann noch eine wichtige Frage zum HBA. Hab das noch nicht ganz begriffen. Wie groß ist der Unterschied zu den Onboard Sata? Wenn ich jetzt das alles mit den Onboard Sata einrichte und mir später noch einen HBA hole kann ich das doch relativ einfach durch ZFS importieren oder? HBA passthrough und dann zfs pool importieren?
Zum Vergrößern anklicken....

Ich würde ESXi mit auf die 60er SSD packen, bootet einfach viel schneller.
Man kann prinzipiell die 120er Sata SSD per physical Raw Disk Mapping an die Storage VM durchreichen, geht aber nur manuell auf der ESXi Console, ein HBA (Dell H200, H310, IBM1015 oder ein originaler LSI) ist halt viel unkomplizierter und etwas schneller.

Zum RAM
ESXi braucht ca 2GB, ein 64 Bit Solaris auch etwa 2GB.
Wenn man 8 GB hat bleiben dann noch ca 4 GB für weitere VMs

Geht grad so zum Testen. Ein CopyOnWrite Dateisystem wie ZFS ist aber mit sowenig RAM arg langsam da es keinen RAM als Lesecache oder Schreibcache hat. Ideal wäre es der Storage VM ab 4GB zu geben, besser 8 GB oder mehr.
 
gea schrieb:
Ich würde ESXi mit auf die 60er SSD packen, bootet einfach viel schneller.
Man kann prinzipiell die 120er Sata SSD per physical Raw Disk Mapping an die Storage VM durchreichen, geht aber nur manuell auf der ESXi Console, ein HBA (Dell H200, H310, IBM1015 oder ein originaler LSI) ist halt viel unkomplizierter und etwas schneller.

Zum RAM
ESXi braucht ca 2GB, ein 64 Bit Solaris auch etwa 2GB.
Wenn man 8 GB hat bleiben dann noch ca 4 GB für weitere VMs

Geht grad so zum Testen. Ein CopyOnWrite Dateisystem wie ZFS ist aber mit sowenig RAM arg langsam da es keinen RAM als Lesecache oder Schreibcache hat. Ideal wäre es der Storage VM ab 4GB zu geben, besser 8 GB oder mehr.
Zum Vergrößern anklicken....

Na hab ja gesagt, dass der HBA auch kommen wird, Ram natürlich auch , keine Frage.

Die 120gb Single oder Mirror? Man könnte auch nur Single nehmen und diese regelmäßig auf das storage backup'en und die andere 120gb als zfs Cache nehmen?

An den HBA wird dann nur der Storage angeschlossen? Oder auch die SSD für die VM's?
 
Swivel schrieb:
Na hab ja gesagt, dass der HBA auch kommen wird, Ram natürlich auch , keine Frage.

Die 120gb Single oder Mirror? Man könnte auch nur Single nehmen und diese regelmäßig auf das storage backup'en und die andere 120gb als zfs Cache nehmen?

An den HBA wird dann nur der Storage angeschlossen? Oder auch die SSD für die VM's?
Zum Vergrößern anklicken....

Ich würde die 120GB als Mirror machen. Erfahrungsgemäß geht eine Platte immer dann kaputt wenn man am wenigsten Zeit hat und das Backup nicht aktuell sondern etwas älter ist. Ein SSD Cache ist viel langsamer als RAM-Cache daher bringt mehr RAM eine deutlich bessere Performance - bis auf den Aspekt daß eine zusätzliche SSD als L2ARC Cache auch optional read-ahead ermöglicht. Bei sequentiellen Daten kann das deutlich was bringen. Ein L2ARC SSD Cache sollte auch nicht größer als maximal 5-10 x RAM sein da RAM zum Verwalten des Cache benötigt wird.

Ansonsten
An Sata wird üblicherweise nur die Bootplatte mit ESXi und dem lokalen Datastore für die Storage VM angeschlossen (vmfs Dateisystem). Alle anderen Platten gehen an den HBA und werden von der Storage VM als ZFS Pool(s) verwaltet. Üblicherweise macht man zwei Pools. Einen als High Performance SSD Pool für NFS/SMB und VMs und einen Plattenpool für Filer und Backup.
 
Zuletzt bearbeitet:
Ohne HBA würde ich ESXi+StorageVM entweder:
(i) erstmal lassen, oder
(ii) du versuchst, den Onboard-SATA-Kontroller an die StorageVM per PCIE-passthrough durchzureichen.

Wenn (ii) müsstest Du aber was anderes als die onboard SATA-Anschlüsse als Anschluss für den Speicherplatz deiner StorageVM nehmen. Denn wenn du den onboard-kontroller durchreichst, ist der für ESXi selbst "weg".

Möglichkeiten dafür (nicht abschließend):

a) einen größeren USB-Stick als Bootmedium, auf den Du dann auch die StorageVM packst (geht - wenn ich mich richtig erinnere seit ESXi 6.0 - einfach übers Webinterface).

b) eine externe USB-Platte

c) eine (m.2-)PCIE-SSD (zur Not mit Adapter).

Möglichkeit c) wäre wohl der "sauberste" Weg. Und wenn du dann später den Onboard an ESXi "zurück gibst", kannste auf deine 60GB SSD als 2. ESXi-Datastorage eine 2. VMDK für die StorageVM anlegen und nachträglich in Solaris einen Software-Mirror über denen rpool anlegen... :d ...oder auch nur die PCIE-SSD wieder freigeben und die StorageVM einfach auf onboard-SATA "umziehen"... gibt viele Möglichkeiten).
 
Gibt es die Möglichkeit das 2x ESXi mit einander kommunizieren so das man 2x über ein GUI Steuert?
Gibt es die Möglichkeit einfach einzurichten das man 2 Ports für die direkte kommunikation der Server nutzt?
Ich will mir einen 2ten Server kaufen mit 3,5Zoll HDD einschüben und die "alten" HDD rein packen.
 
Damit sollte das alles gehen.
Virtualization for Small Businesses - VMware vSphere Essentials Kit


Kostenfrei wird das eher nichts.Wobei du für erweitere Features wie vMotion, HA etc. das Plus Kit benötigst, was deutlich teurer ist.
ca. 630 € vs. ca. 5000 €.

Ich bin mir nicht sicher, aber ich glaube Proxmox kann das alles out of the Box und kostenfrei.Ist halt dann kein ESXi sodern eben Proxmox.
 
Zuletzt bearbeitet:
Mehrere esxi werden über vCenter verwaltet(kostenpflichtig)

Sent from my SM-G935F using Tapatalk
 
Was für ein Produkt von VMWare brauche ich das ich die Virtuellen Maschinen im Betrieb auf den anderen Server verschieben kann?
Ich nehme an dafür muss die VM auf einen Zentralen Storage abgelegt sein?
 
Das ist richtig, für vMotion mit laufenden VMs ist ein zentrales Storage unabdingbar - vorallem wenn man eh mehrere Hosts hat - kein Mensch möchte doch an 1000 Geräten die Platten überwachen und RAIDgroups haben.
von VMware entweder die Essentials Plus oder eine Standard - die Standard kostet ~900€ pro CPU und da ist noch kein vCenter dabei
 
Welche Lizenzen würde ich da brauchen?
Gut so ein Storage ist auch ned Gratis.
 
konfetti schrieb:
Das ist richtig, für vMotion mit laufenden VMs ist ein zentrales Storage unabdingbar
Zum Vergrößern anklicken....

Das stimmt so nicht.
Du kannst Storage vMotion wie auch Host vMotion doch seit der 5.1 kombinieren. Es geht auch über mehrere vCenter hinweg, sogar über WAN und geroutete Netze.
Natürlich im laufenden Betrieb! Webclient aber Pflicht! CPU Kompatibilität ebenso. Sollte aber logisch sein :wink:
 
@fdsonne

hm, @ work bietet mir der vCenter (Standard + ESX Enterprise) beim verschieben der VM nur an, sie auf einen anderen Host zu schieben - oder eben das Storage zu wechseln.
bei einer ausgeschalteten VM kann ich sowohl Host als auch Storage verschieben, sprich ich kann eine VM vom zentralen SAN auch auf die lokalen Platten des ESX schieben - der ist logischerweise 4x Baugleich, also RAM, Disks, CPU, ... wir setzen derzeit noch ESX 6.0 U1 ein.

wenn das geht, wäre es natürlich schick.
 
Webclient!?
Im Classic Client ist es ausgegraut, der Webclient bietet es definitiv an... (der dritte Punkt)
Kannst dann wählen ob du zuerst das Storage oder zuerst den Host wählst.


Migrating Virtual Machines
"Hot Migration

Depending on the type of migration you are using, vMotion or Storage vMotion, you can move a powered on virtual machine to a different host, and move its disks or folder to a different datastore without any interruption in the availability of the virtual machine. You can also move a virtual machine to a different host and to a different storage location at the same time. vMotion is also referred to as live migration or hot migration."

Geht auch mit der Standard vSphere auf dem Host... (das aber glaube ich erst seit 5.5!?) -> Storage vMotion war mal Enterprise Feature, seid es in der Standard geht, geht auch Host + Storage vMotion.
 
Zuletzt bearbeitet:
Gut die CPU wären unterschiedlich das heist ich hätte da sowieso die arschkarte gezogen. Das heist offline kann man sie dann verschieben?
 
Das mit den CPUs ist nich unbedingt ein Problem dafür gibts ein Feature das sich EVC nennt kann man für einen Cluster im vCenter aktivieren dann werden die CPU Features der Hosts so maskiert das ein vMotion Vorgang möglich ist. Bezüglich Essentials Plus Lizenz diese kostet etwa 1500 ist für 6 Sockets und inkl. vCenter. beinhaltet HA und vMotion aber kein Storage vMotion als kannst du nicht auf einen anderen Datenspeicher verschieben. Alternativ könntest du die VMUG Eval Experience nutzen kostet etwa 200€ im Jahr und da ist alles dabei (Enterprise Plus Lizenz + vCenter)
 
Zuletzt bearbeitet:
Da diese Lizenzangaben, für ausenstehende meist etwas undurchsichtig sind, muss ich einfach mal blöd Fragen.
6 Sockets kann auch bedeuten, das ich z.B 6 einzelne Server habe mit einer CPU und x Cores ? (Ich muss allerdings auch zugeben, das mir in der x86 Welt noch keine Mainboards mit mehr als 4 Sockets unter die Augen gekommen sind - wenn man mal einen Clusterverbund auseracht lässt.)

Aber wenn man was mit Sicherheit nicht weiß, warum nicht einfach mal fragen.
 
Ja ursprünglich wurden die Essentials immer verkauft als für 3 Hosts mit jeweils 2 Sockets (Gesamt 6). Angeblich soll das jetzt auch funktionieren wenn du 6 Hosts mit 1 Socket hast. Das habe ich aber noch nie getestet. Und ich meine gelesen zu haben das das erst mit 6.5 geht.
 
Zumindest bei meinen vSphere Edu Lizenzen konnte ich schon immer entscheiden wie ich die Prozessor-Lizenzen aufteile. Ich wage jedoch zu bezweifeln das dass noch lange geht. Ein Single CPU System mit 16 Cores (eine Lizenz) is da doch viel billiger als ein Quad CPU System mit je 4 Cores (4 Lizenzen) bei annähernd vergleichbarer Leistung.
 
Bei den Essentials Lizenzen ist das künstlich beschnitten - ist ja nur für kleine Umgebungen gedacht.
 
Weis jemand ob es für Händler Rabatte oder sonst was gibt?
Ich hätte natürlich eine bessere Position wenn ich wüsste was es geben kann.
 
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