ESX / ESXi - Hilfethread

Dann haben sie mit 6.7 den neuen AHCI-Treiber debuged.
Bei 6.5 war der neue AHCI-Treiber dran schuld, den musste man deaktivieren dass die Kiste den Legacy-Treiber genutzt hat. Dann ist Sata mit 6.5 kein Problem. Nur solange Passthrough von den Intel OB-Sata-Controllern nicht klappt, kann ich 6.7 nicht einsetzen, da mir sonst die Ports nicht reichen. Dann müsste ich noch nen LSI 940x HBA zustecken, damit Ports und NVME reichen würden.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich habe heute auf ESXi 6.7 upgedatet und bekomme jetzt für meine OMV VM eine Fehlermeldung bzgl. dem Gastbetriebsystem. Unter 6.5 hatte ich "Anderes 3.x Linux-System" ausgewählt. Dies führt jetzt zur Warnmeldung, da nun "Anderes 4.x Linux-System" erwartet wird. Diese Einstellung gibt es aber nicht in der Auswahl der Gastbetriebssysteme. Ich habe schon diverse Einstellungen probiert, die Warnmeldung bleibt.

Hatte das Problem bei meiner FreeNAS VM auch. Ich musste die VM auf die neuste Hardware Version upgraden, damit ich die OS Version auswählen konnte.
 
Weil für ne Liveumgebung würde ich nicht die aller neueste vSphere Version empfehlen. Mach da ein aktuelles 6.5er Release drauf und gut. Später, beim U1 oder nach dem U1 gehst du dann auf die 6.7 - dann sind auch die Kinderkrankheiten weg (meistens) ;)

Das hats gebracht, der Installer für 6.5U2 ist problemlos durchgelaufen :) Und er warnt sogar, falls er die DNS Einträge nicht richtig auflösen kann. Das ist mir im 6.7er nicht aufgefalle

PS: was übrigens vllt noch ein Anhaltspunkt sein kann wäre IPv6 - VMware und IPv6 ist nach wie vor recht grausig, vor allem wo das Ding offiziell zwar Dual Stack supportet irgendwie aber in Teilen hart in der vSphere Datenbank die IPs drin stehen, mit dem initial mal gearbeitet/aufgesetzt wurde.
Heist - für initial bleib bei v4 und schalt am Besten v6 komplett! ab, sowohl auf der Host als auch der vCSA Seite. Oder konfiguriere es 100% sauber auf v6 und hoffe drauf, dass da nicht irgendwo der Bock drin sind...
Bis jetzt habe ich IPv6 immer so gelassen, aber auf meinem Router deaktiviert. Werde ich auch mal auf VMware Seite deaktivieren.
 
Du bekommst, wenn du v6 auf der Host/vCenter Seite nicht richtig abschaltest ja trotzdem ne v6 Adresse - wenn die Autoaushandlung funktioniert, kommunizieren Host/vC ggf. trotzdem über v6, speziell dort, wo du vielleicht gar nicht über nen DNS Eintrag auf v4 zwingst, bspw. beim Kernelport für vMotion/FT. Da ist es mir leider schon mehrfach auf die Füße gefallen, wenn man Mischkonfig fährt. Ein Host mit v6 seit Begin an kann keine VMs auf einen Host schieben, der mit v4 in der vC-DB steht und umgekehrt. Der Knackpunkt ist hier die Konfig zum Zeitpunkt der Aufnahme ins vCenter. Sprich ist dort ne v6 aktiv oder nicht. Wenn ja, dann geht das nur bei v6 für alle sauber. Wenn nicht, dann sollte man die Hosts alle samt nur mit v4 aufnehmen und v6 später konfigurieren - sonst versucht der da von v6 auf v4 und umgekehrt zu sprechen - was in die Schlüpper geht.
Obwohl die Dinger sich via Ping erreichen und die Interfaces auch sauber konfiguriert sind. Workarround laut diversen VMware KB-Artikeln ist dann immer v6 zu deaktivieren... Bringt mir halt nichts, wenn ich v6 brauch :fresse:

Aber vllt hat sich das auch alles mit 6.5 schon gelegt, ich muss mal gucken wie ich meine Umgebung da umgebogen bekomme - im Moment lässen sich die VCSA Appliances nämlich nicht updaten, weil irgend so ein kryptischer Fehler zur Namensauflösung kommt - der allen Anschein nach genau damit was zu tun hat. Kurrioserweise lässt sich v6.0 immer weiter hoch patchen. U1, U2, U3 usw. alles kein Problem. Aber auf 6.5 gehts nicht - über den Migrationsassistenten.
In meinen Tests bin ich jetzt schon soweit, die Kisten komplett neu aufzuziehen und jeweils die Daten mitzunehmen... Damit die Basis unten drunter sauber ist und sich dann auch updaten lässt. Sprich die vier geclusterten PSCs jeweils neu machen und replizieren lassen und dann die beiden vCenter neu aufsetzen und aus dem lokalen Backup quasi über ein disaster Recovery zurück spielen. -> das scheint soweit zu funktionieren. Blöderweise steht der eine Knoten am anderen Ende der Welt - mit entsprechend "dicker" Anbindung und entsprechend zäher Ausführung des Ganzen.
 
Uuh, das klingt böse. Danke für den Hinweis! Dann werde ich v6 definitiv deaktivieren. Auf die Fehlersuche kann ich verzichten.
 
@derfahnder: Danke, dein Tipp führte zum Erfolg. Die Warnmeldung ist nach dem Upgrade der VM-Kompatibilität verschwunden. Nach dem ersten Neustart des OMV Servers hatte ich erst einmal einen Schreck bekommen, da alle HDD nicht angezeigt wurden. Das lag aber zum Glück nur daran, dass der zusätzliche Passthrough SATA Controller bei der Maßnahme aus der Konfiguration geflogen ist. Wieder eingebunden und alles ist gut.
 
Ja das Passthrough war bei mir auch fort. Hat mir nen schönen Schrecken eingejagt ;)
 
Gibt es eine (möglichst einfache) Möglichkeit eine Port Gruppe auf einen anderen vSwitch zu packen? Am liebsten ohne die VMs stoppen zu müssen, aber das wäre auch okay.

Es wäre halt mühsehlich die Portgruppe zweimal neu zu erstellen (will den Namen behalten), und alle VMs anpacken zu müssen.

Edit: aktuell ist der vSwitch an eine NIC gebunden, soll er aber nicht mehr. Dh. im Wunschzustand ist das ein rein interner vSwitch.

Weiterer Edit: Mittels vCenter war dies sehr einfach machbar:
1) dummy PortGruppe am Ziel vSwitch Erstellt
2) Mittels "Migrate VMs to another net" alle VMs zur temporären Portgruppe migriert
3) erste Portgruppe gelöscht und am neuen vSwitch neu erstellt
4) 1+2 wiederholt
 
Zuletzt bearbeitet:
@Dj3K
Hab ich hier rumliegen. Müsste ich mal freifliegend einbauen. Aber da ich den NUC eh gerade als ESX ausmuster, kann ich das probieren. Wird dann aber kein Dauertest.

Ist nur die Frage ob der von dir geplante NUC mit meinem 5er direkt vergleichbar ist.

In welchen NUC soll die eigentlich reinpassen? Da wirst du vermutlich am m.2-Teil löten müsssen um flacher zu werden.
Hatte das auf einer Webseite schon gesehen.
 
@Dj3K
Hab ich hier rumliegen. Müsste ich mal freifliegend einbauen. Aber da ich den NUC eh gerade als ESX ausmuster, kann ich das probieren. Wird dann aber kein Dauertest.

Ist nur die Frage ob der von dir geplante NUC mit meinem 5er direkt vergleichbar ist.

In welchen NUC soll die eigentlich reinpassen? Da wirst du vermutlich am m.2-Teil löten müsssen um flacher zu werden.
Hatte das auf einer Webseite schon gesehen.

Müsste auch ein Nuc der 5. Generation sein.
Und ich würde die Karte anstelle der Wifi m.2 reinpacken.
Da die Delock auch half-length format hat, müsste das direkt passen

Nur ein kurzer Test, ob die Karte sauber erkannt wird (idealerweise esxi 6.7) und vielleicht mal Latenzen überprüfen.
Im Voraus schonmal danke!
 
Tja,

da habe ich leider zuviel versprochen. Mein NUC 5i7RYH hat nur M.2. Das WLAN ist da anders realisiert. Somit leider kein passender Mini-PCIe-Slot.
Sorry, kann leider doch nicht helfen.

Allerdings liefen die Karten unter Linux als DRBD-Clusterverbindung einwandfrei. Und mein ESX Cluster hat die gleichen Chips als Onboard-NIC. Die laufen unter 6.7 mit den Treibern vom vibsdepot. Musst halt ein angepasstes Image machen oder später nachinstallieren.
Net55-r8168 - V-Front VIBSDepot Wiki

Aber wollte den NUC eh zerlegen um die USB-Erweiterung auszubauen. Somit ist es kein zusätzlicher Aufwand gewesen.

Evtl. ergibt sich noch eine Möglichkeit wenn ich die ESX am WE vermutlich umbaue. Da werden die alten DRBD-Boards für ESX verwendet. Da könnte man nochmal testen. Ist dann aber halt kein NUC.
 
Zuletzt bearbeitet:
Hi Luxxer,

auf meinem ESXI läuft eine FreeNAS 11.1U5 mit einem VMNetwork adapter. Ich hab mir jetzt mal so gedacht... eigentlich ist es doch besser wenn ich den NFS/ISCSI Storage nicht über das normale VMNetwork laufen lasse sondern ein eigenes Netzwerk für diese Dienste nutze, ist dies ein reines Netz was auf dem ESXI angelegt ist und nicht über meinen Router geht. Somit würde ich schlussfolgern, dass es auch schneller ist?

Meine Versuche der bestehenden FreeNAS-VM ein weiteren Netzwerkadapter zuweisen zu wollen, endeten aber immer damit das FreeNAS nicht mehr erreichbar war. Auch ein neu konfigurieren der Netwerke in der VM selber bringt keinen Erfolg.

Wo liegt mein Fehler?
 
Da geht zwischen den VMs innerhalb eines ESXI auch bei einem einzigen Adressbereich nichts über den Router, wenn die VMs die Storage-VM erreichen können.

Zwischen meinen VMs und der Storage-VM (Nas4free und damit fast das gleiche BSD wie FreeNAS), alle per VMXNET3-Vnic und im gleichen Adressbereich, kann mein ESXI mittels NFS derzeit etwa 2,4Gbyte/s wuppen.
Und das kann ja wohl schlecht über die Fritzbox (die auch in selbigen IP-Bereich läuft) laufen.
 
Zuletzt bearbeitet:
also ich hab mal in einer VM die auf ner NFS Freigabe liegt ein diskmark laufen lassen....

Diskmark
2GB_Diskmark.jpg

8GB_Diskmark.jpg

VM_Network
VM_Network.jpg

StoragePool
FreeNAS_pool.jpg

bei mir sieht das etwas anders aus. Vorallem die write Geschwindigkeit gibt mir zu denken.
 
Da geht zwischen den VMs innerhalb eines ESXI auch bei einem einzigen Adressbereich nichts über den Router, wenn die VMs die Storage-VM erreichen können.

Zwischen meinen VMs und der Storage-VM (Nas4free und damit fast das gleiche BSD wie FreeNAS), alle per VMXNET3-Vnic und im gleichen Adressbereich, kann mein ESXI mittels NFS derzeit etwa 2,4Gbyte/s wuppen.
Und das kann ja wohl schlecht über die Fritzbox (die auch in selbigen IP-Bereich läuft) laufen.

Ich bin gerade dabei meinen T20 als ESX Host umzubauen. Das Thema hatte ich auch schon im Sinn. Könntest Du vllt. mal die Konfig (VMNET3-Vnic) bei Dir im Detail erläutern. Sorry, dass ich Frage, aber ich bin da noch relativ neu. Hatte bisher mehr mit Hyper-V zu tun...

Noch eine andere Frage: Wenn der ESX auf dem USB-Stick "läuft". Könnte ich dann trotzdem eine USB Platte an eine Windows VM durchreichen?

Vielen dan vorab!
 
Moin!
Kann mir jemand einen Tipp geben, in welcher Art/wie man über cross-compiling einen Treiber selbst bauen kann für 6.7 oder 6.5u2?
Ich müsste das Linux-Äquivalent vom Intel Windows-NIC-paket >= V22.10 für meinen onboard 10G-X553 herstellen, also wohl Intel v5.x
Gibt's nicht von VMware oder Supermicro.
Die Allgemeinen Anleitungen für Community-Treiber habe ich gefunden, aber keine Compiling-Umgebung...
 
Special frage! Ich möchte eventuell auf einen neuen Server (den Ich noch nicht habe!) eine Grafik Intensive Software laufen lassen die 24/7 laufen soll.
Es gibt dafür nur eine Software die genau das kann was Ich brauche. Normal lässt man die Software auf einen Client laufen daher ist diese nicht für einen Server Betrieb konzipiert. Die Software ist auch schon recht alt.
Gibt es die möglichkeit das der Server mittels Grafikkarte alles berechnet was in einen Virtuellen Win7 lauft?

Könnte das damit gemeint sein: https://www.vmware.com/resources/compatibility/pdf/vi_vsga_guide.pdf

horizon-view-vsga.jpg


und funktioniert das mit den kostenlosen ESXi?
 
am einfachsten wäre es wohl, die Grafikkarte dediziert dieser einen VM durchzureichen - sofern die Hardware Paththrough unterstützt.
Dann hat das Programm direkt Zugriff auf die Resourcen der Grafikkarte. - ist ganz Nett, wenn man den Host auch als Workstation missbrauchen will XD
 
Grafik Intensive Software

Meinst du damit auch, dass die Software Berechnugen auf die Grafikkarte auslagern kann, oder das mit ihr nur Grafiken berechnet werden ?

Bei aller Wunder der Technik, ich glaube nicht das Treiber und Co das auslagern können, wenn es das Programm selbst nicht kann - zumindest war das mal früher so (CUDA).
 
Ich lese am Handy meist nur die Frage ohne auf den Autor zu achten. Wieder einmal lese ich die ersten ein, zwei Sätze und fühle mich genötigt nach oben zu scrollen ob das nicht doch wieder eine Frage von Boy2006 ist. Die Art der Fragestellung, möglichst weit außen rum zu reden ohne etwas konkretes zu sagen charakterisiert ihn einfach :d
Insofern typische Boy2006 Frage, wenn ich an die diverse Drumherumrederei zum Thema "fremde Funksignale entschlüsseln" u.a. denke.

Konkret dürfte die Lösung von konfetti die passendste sein. Passthrough der Graka an die VM und dann kann die strenggeheime Software alle zulässigen oder nicht zulässigen Berechnungen mittels der Graka durchführen.
 
Insofern typische Boy2006 Frage, wenn ich an die diverse Drumherumrederei zum Thema "fremde Funksignale entschlüsseln" u.a. denke.
Entschlüsseln nicht aber Decodieren das funktioniert bei mir schon 1A nur brauche Ich eben mehr Performance. :btt2:
dann kann die strenggeheime Software
Geheim ist sie nicht nur das was rein und raus kommt.
am einfachsten wäre es wohl, die Grafikkarte dediziert dieser einen VM durchzureichen
Nur was ist wenn ich über RDP zugreife wo wir dann das Bild berechnet?
wenn man den Host auch als Workstation missbrauchen will XD
Da gibts ein geiles Video vom Linus (den die Hersteller scheinbar die Hardware nur so hinten rein stecken) wo er mit einer Fetten Gamer Hardware und irgend welchen Server CPU und paar (!) Grakas die sicher 4 Stellig wären eine (!) Gaming Maschine mit 4 Virtuellen Pcs machte wo die Maus, Tastatur an die Virtuelle durchgereicht wurde. :xmas:
Meinst du damit auch, dass die Software Berechnugen auf die Grafikkarte auslagern kann, oder das mit ihr nur Grafiken berechnet werden ?
Es ist ganz easy die Software zeigt das Funkspektrum an ohne das man es deaktivieren kann. Leider ist das sehr GPU lastig so das selbst ne normale Graka beansprucht wird. Klar auf einen Server ohne (richtige) GPU wird das extrem laggen.

Sage ja das sind alles reine Consumer Software die ausgelegt sind das sie auf einen normalen Pc rennen und keine Server Software die in der Console rennt.
 
Wenn du rechnen willst musst du Nvidia Tesla Karten in die VM durchreichen. Dir Grids sind speziell dafür da virtuelle Desktops mit 3D zu versorgen.
 
Er scheint mit der Graka nicht "rechnen" zu wollen (im Sinne von z.b. Bitcoin), sondern eine Software zu haben, die das Frequenzspektrum wohl recht ineffizient rendert und dadurch viel GPU Ressourcen verbrät. Wenn die Software schon alt ist, dann wird sie wohl nicht weiter gepflegt und dementsprechend ist auch kein Fix in Sicht.

@Boy2006: um welche Software handelt es sich hierbei denn? MultiPSK?
 
Zuletzt bearbeitet:
Nein diverse. Ich werfe als beispiel mal: Signal Software from COAA in den Raum.
Naja "rendern" ist nett ausgedrückt das ist ne Client Software die halt auf den Display was anzeigt nur braucht das halt ein wenig mehr GPU leistung weil es eben für einen Client gedacht ist also ein Pc, Laptop,... und keine Virtuelle Umgebung.
 
Wenn es wirklich um 3D Leistung geht und es nur ein Client sein soll, dann würde auch eine Quadro gehen. Bei den Grid ist zu beachten, das die nur richtig Funktionieren, wenn man die Karten beim Serverhersteller passend für den Server kauft.
Anhand der Salamischeiben die du hier von dir gibst würde ich mal behaupten, das vom restlichen Aufwand her eine virtuelle Lösung unter VMware oder nicht in frage kommen wird da die dafür notwendige Infrastruktur (VMWare Horizon oder Citrix Xendexktop) etwas oversized wäre. Probier es mal mit Hyper-V und RemoteFX wenn es nur um ein oder wenige VMs geht.
 
So wie die Webseite aufgebaut ist, sollte eig. auch die simulierte GPU in VMware langen bzw. mit etwas mehr Power durch CPU Berechnung, wenn man "3D" aktiviert bei der VM...
 
Nur was ist wenn ich über RDP zugreife wo wir dann das Bild berechnet?
Über RDP wird das nix. Dazu braucht man PCoIP (VMware Horizon), HDX (Citrix XenDesktop) oder RemoteFX (Microsoft). RemoteFX und PCoIP funktioniert nur den Hypervisoren des jeweiligen Herstellers, HDX ist es egal ob es unter Xenserver, vSphere, Hyper-V oder auf physikalischen Blech läuft.
 
Zuletzt bearbeitet:
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