ESX / ESXi - Hilfethread

weiss zufällig jemand, ob man für den 7er ESXi für SR-IOV auch wieder eine Enterprise-Lizenz benötigt oder ob das auch mit der Free-Variante geht?

Und gab's da noch wichtige Einschränkungen bei der Free im Hinblick auf Kerne o.ä,? Sockel hätt' ich nur einen...
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
besterino schrieb:
weiss zufällig jemand, ob man für den 7er ESXi für SR-IOV auch wieder eine Enterprise-Lizenz benötigt oder ob das auch mit der Free-Variante geht?

Und gab's da noch wichtige Einschränkungen bei der Free im Hinblick auf Kerne o.ä,? Sockel hätt' ich nur einen...
Zum Vergrößern anklicken....
1625362530312.png


Ich kann das zumindest anklicken und konfigurieren. Habs jedoch nicht im Einsatz.
-->
Version:
7.0 Update 1

Limit bei Free: Max 8Virtuelle Cores pro VM.
 
wenn ich mich richtig erinnere kommt die Fehlermeldung erst, wenn man den SR-IOV Adapter der VM hinzufügt oder sogar erst, wenn man sie startet. Weiß noch, dass ich da schon bei 6.7 recht spät zunächst dumm aus der Wäsche geschaut hatte.
 
Ich kanns aktuell leider schlecht testen da das hier unser Router ist und direkt der Krieg ausbricht wenn das Ding steht :d
 
hehe. Danke trotzdem. Ich probier' evtl. einfach mal mein Glück. Momentan kämpf' ich noch an ganz anderen Fronten...
 
Hmm... also ich bekomm mit der ConnectX-4 unter 7.0.2 ums Verrecken kein SR-IOV aktiviert. Der Host behauptet dauernd, "Aktiviert / Erfordert Neustart".

Firmware ist aktuell. Ist die offiziell Funktionierende: 12.28.2006
Code: 
[root@localhost:~] /opt/mellanox/bin/flint -d mt4115_pciconf0 query
Image type:            FS3
FW Version:            12.28.2006
FW Release Date:       15.9.2020
Product Version:       12.28.2006
Rom Info:              type=UEFI version=14.21.17 cpu=AMD64,AARCH64
                       type=PXE version=3.6.102 cpu=AMD64
Description:           UID                GuidsNumber
Base GUID:             248a070300b59732        8
Base MAC:              248a07b59732            8
Image VSD:             N/A
Device VSD:            N/A
PSID:                  MT_2190110032
Security Attributes:   N/A
Treiber auch. Offiziell aktuelle Version, ist die 4.21.71.101.
Code: 
root@localhost:~ esxcli software vib list | grep nmlx
nmlx5-core                     4.21.71.101-1OEM.702.0.0.17630552    MEL     VMwareCertified   2021-07-04
nmlx5-rdma                     4.21.71.101-1OEM.702.0.0.17630552    MEL     VMwareCertified   2021-07-04
nmlx4-core                     3.19.16.8-2vmw.702.0.0.17867351      VMW     VMwareCertified   2021-07-04
nmlx4-en                       3.19.16.8-2vmw.702.0.0.17867351      VMW     VMwareCertified   2021-07-04
nmlx4-rdma                     3.19.16.8-2vmw.702.0.0.17867351      VMW     VMwareCertified   2021-07-04
NIC steht auch auf ETH, SR-IOV ist aktiviert bei max 8 virtual functions (ich will nur 4 aktiveren).
Code: 
root@localhost:~ /opt/mellanox/bin/mlxconfig -d mt4115_pciconf0 query

Device #1:
----------

Device type:    ConnectX4
Name:           MCX456A-ECA_Ax
Description:    ConnectX-4 VPI adapter card; EDR IB (100Gb/s) and 100GbE; dual-port QSFP28; PCIe3.0 x16; ROHS R6
Device:         mt4115_pciconf0

Configurations:                              Next Boot
         MEMIC_BAR_SIZE                      0
         MEMIC_SIZE_LIMIT                    _256KB(1)
         FLEX_PARSER_PROFILE_ENABLE          0
         FLEX_IPV4_OVER_VXLAN_PORT           0
         ROCE_NEXT_PROTOCOL                  254
         NON_PREFETCHABLE_PF_BAR             False(0)
         VF_VPD_ENABLE                       False(0)
         STRICT_VF_MSIX_NUM                  False(0)
         VF_NODNIC_ENABLE                    False(0)
         NUM_PF_MSIX_VALID                   True(1)
         NUM_OF_VFS                          8
         FPP_EN                              True(1)
         SRIOV_EN                            True(1)
         PF_LOG_BAR_SIZE                     5
         VF_LOG_BAR_SIZE                     1
         NUM_PF_MSIX                         63
         NUM_VF_MSIX                         11
         INT_LOG_MAX_PAYLOAD_SIZE            AUTOMATIC(0)
         PCIE_CREDIT_TOKEN_TIMEOUT           0
         PARTIAL_RESET_EN                    False(0)
         SW_RECOVERY_ON_ERRORS               False(0)
         RESET_WITH_HOST_ON_ERRORS           False(0)
         CQE_COMPRESSION                     BALANCED(0)
         IP_OVER_VXLAN_EN                    False(0)
         MKEY_BY_NAME                        False(0)
         UCTX_EN                             True(1)
         PCI_ATOMIC_MODE                     PCI_ATOMIC_DISABLED_EXT_ATOMIC_ENABLED(0)
         TUNNEL_ECN_COPY_DISABLE             False(0)
         LRO_LOG_TIMEOUT0                    6
         LRO_LOG_TIMEOUT1                    7
         LRO_LOG_TIMEOUT2                    8
         LRO_LOG_TIMEOUT3                    13
         TX_SCHEDULER_BURST                  0
         LOG_DCR_HASH_TABLE_SIZE             14
         DCR_LIFO_SIZE                       16384
         LINK_TYPE_P1                        ETH(2)
         LINK_TYPE_P2                        ETH(2)
         ROCE_CC_PRIO_MASK_P1                255
         ROCE_CC_PRIO_MASK_P2                255
         CLAMP_TGT_RATE_AFTER_TIME_INC_P1    True(1)
         CLAMP_TGT_RATE_P1                   False(0)
         RPG_TIME_RESET_P1                   300
         RPG_BYTE_RESET_P1                   32767
         RPG_THRESHOLD_P1                    1
         RPG_MAX_RATE_P1                     0
         RPG_AI_RATE_P1                      5
         RPG_HAI_RATE_P1                     50
         RPG_GD_P1                           11
         RPG_MIN_DEC_FAC_P1                  50
         RPG_MIN_RATE_P1                     1
         RATE_TO_SET_ON_FIRST_CNP_P1         0
         DCE_TCP_G_P1                        1019
         DCE_TCP_RTT_P1                      1
         RATE_REDUCE_MONITOR_PERIOD_P1       4
         INITIAL_ALPHA_VALUE_P1              1023
         MIN_TIME_BETWEEN_CNPS_P1            0
         CNP_802P_PRIO_P1                    6
         CNP_DSCP_P1                         48
         CLAMP_TGT_RATE_AFTER_TIME_INC_P2    True(1)
         CLAMP_TGT_RATE_P2                   False(0)
         RPG_TIME_RESET_P2                   300
         RPG_BYTE_RESET_P2                   32767
         RPG_THRESHOLD_P2                    1
         RPG_MAX_RATE_P2                     0
         RPG_AI_RATE_P2                      5
         RPG_HAI_RATE_P2                     50
         RPG_GD_P2                           11
         RPG_MIN_DEC_FAC_P2                  50
         RPG_MIN_RATE_P2                     1
         RATE_TO_SET_ON_FIRST_CNP_P2         0
         DCE_TCP_G_P2                        1019
         DCE_TCP_RTT_P2                      1
         RATE_REDUCE_MONITOR_PERIOD_P2       4
         INITIAL_ALPHA_VALUE_P2              1023
         MIN_TIME_BETWEEN_CNPS_P2            0
         CNP_802P_PRIO_P2                    6
         CNP_DSCP_P2                         48
         LLDP_NB_DCBX_P1                     False(0)
         LLDP_NB_RX_MODE_P1                  OFF(0)
         LLDP_NB_TX_MODE_P1                  OFF(0)
         LLDP_NB_DCBX_P2                     False(0)
         LLDP_NB_RX_MODE_P2                  OFF(0)
         LLDP_NB_TX_MODE_P2                  OFF(0)
         DCBX_IEEE_P1                        True(1)
         DCBX_CEE_P1                         True(1)
         DCBX_WILLING_P1                     True(1)
         DCBX_IEEE_P2                        True(1)
         DCBX_CEE_P2                         True(1)
         DCBX_WILLING_P2                     True(1)
         KEEP_ETH_LINK_UP_P1                 True(1)
         KEEP_IB_LINK_UP_P1                  False(0)
         KEEP_LINK_UP_ON_BOOT_P1             False(0)
         KEEP_LINK_UP_ON_STANDBY_P1          False(0)
         DO_NOT_CLEAR_PORT_STATS_P1          False(0)
         AUTO_POWER_SAVE_LINK_DOWN_P1        False(0)
         KEEP_ETH_LINK_UP_P2                 True(1)
         KEEP_IB_LINK_UP_P2                  False(0)
         KEEP_LINK_UP_ON_BOOT_P2             False(0)
         KEEP_LINK_UP_ON_STANDBY_P2          False(0)
         DO_NOT_CLEAR_PORT_STATS_P2          False(0)
         AUTO_POWER_SAVE_LINK_DOWN_P2        False(0)
         NUM_OF_VL_P1                        _4_VLs(3)
         NUM_OF_TC_P1                        _8_TCs(0)
         NUM_OF_PFC_P1                       8
         VL15_BUFFER_SIZE_P1                 0
         NUM_OF_VL_P2                        _4_VLs(3)
         NUM_OF_TC_P2                        _8_TCs(0)
         NUM_OF_PFC_P2                       8
         VL15_BUFFER_SIZE_P2                 0
         DUP_MAC_ACTION_P1                   LAST_CFG(0)
         SRIOV_IB_ROUTING_MODE_P1            LID(1)
         IB_ROUTING_MODE_P1                  LID(1)
         DUP_MAC_ACTION_P2                   LAST_CFG(0)
         SRIOV_IB_ROUTING_MODE_P2            LID(1)
         IB_ROUTING_MODE_P2                  LID(1)
         PCI_WR_ORDERING                     per_mkey(0)
         MULTI_PORT_VHCA_EN                  False(0)
         PORT_OWNER                          True(1)
         ALLOW_RD_COUNTERS                   True(1)
         RENEG_ON_CHANGE                     True(1)
         TRACER_ENABLE                       True(1)
         IP_VER                              IPv4(0)
         BOOT_UNDI_NETWORK_WAIT              0
         UEFI_HII_EN                         False(0)
         BOOT_DBG_LOG                        False(0)
         UEFI_LOGS                           DISABLED(0)
         BOOT_VLAN                           1
         LEGACY_BOOT_PROTOCOL                PXE(1)
         BOOT_INTERRUPT_DIS                  False(0)
         BOOT_LACP_DIS                       True(1)
         BOOT_VLAN_EN                        False(0)
         BOOT_PKEY                           0
         P2P_ORDERING_MODE                   DEVICE_DEFAULT(0)
         DYNAMIC_VF_MSIX_TABLE               False(0)
         EXP_ROM_UEFI_ARM_ENABLE             False(0)
         EXP_ROM_UEFI_x86_ENABLE             True(1)
         EXP_ROM_PXE_ENABLE                  True(1)
         ADVANCED_PCI_SETTINGS               False(0)
         SAFE_MODE_THRESHOLD                 10
         SAFE_MODE_ENABLE                    True(1)

SR-IOV und IOMMU ist auch im BIOS aktiviert.

Fällt sonst noch jemandem etwas ein? Auf meinem Xeon 4108 Silver mit 6.7 (ohne U) lief die problemlos mit SR-IOV. Liegt also entweder an der ESXi-Version oder an dem neuen Unterbau (Threadripper auf TRX40D8).

Gegentest: mit der Onboard Intel X710-AT2 funktioniert SR-IOV auf anhieb.

Doof sowas.

Ja leck' mich doch am A**** - auf 6.7U3b funktioniert SR-IOV ebenfalls auf Anhieb auch mit der ConnectX-4. Und tschüss ESXi 7...
 
Zuletzt bearbeitet:
JFYI. Deskmini X300 mit 4350G: Bios 1.70 führt zu PSOD bootet kein 7.01 und auch der Installer von 7.02a bombt mich violett aus.

Zurück zu 1.46G.
 
Hi zusammen, ich habe aktuell folgende Situation und komme einfach nicht weiter:

Mein altes Q1900DC-ITX mit baremetal XPEnology hat die Grätsche gemacht (on-board Stromversorgung kaputt).

Jetzt habe ich mir ein ASRock J4105-ITX geholt, weil das VT-d kann und ich endlich den eingebauten HDMI Port nutzen wollte.
Also ESXi 6.7u3 mit Realtek Treibern (für Realtek RTL8111H NIC) auf dem J4105 installiert und XPEnology als erstes virtualisiert.
Die XPEnology VM mit durchgereichtem ASMedia SATA Controller funktioniert absolut perfekt (baremetal modus, also die VM ist nur der bootloader, damit ich im Notfall auch einfach mit XPEnology Bootstick an die Platten komme).

Jetzt wollte ich eine Linux VM mit durchgereichter Intel UHD 605 iGPU (+ Audio) betreiben die einfach zum surfen/streamen am TV per HDMI gedacht ist.
Ich kriege ein HDMI Bild und Ton, aber die Video-Performance (ich tippe auf fehlende HW-acceleration) ist unterirdisch.
Die Linux VM scheint die Intel GPU zu erkennen, ich hab schon tausende Variationen von Parametern (VM Parameter in ESXI, i915 grub-Parameter, Xorg Parameter, Berechtigungen geprüft, etc.) getestet, aber es will einfach nicht so wie es soll. Entweder ist der Bildschirm nach dem Start von Xorg komplett schwarz, mal mit starken Artefakten (i915.modesetting=1), oder es ist alles glasklar aber mit Software-Renderer...
Versucht hatte ich zuerst Xubuntu, dann Ubuntu, dann Debian, dann LibreELEC, etc.

Ich muss dazu sagen, dass ich kein wirklicher Linux-Experte bin, deshalb kann ich absolut nich sagen, ob die VM dioe iGPU korrekt durchgereicht bekommt, aber ich hab ungefähr jeden Tweak aus dem Internet mit dem Thema GPU Passthrough/ESXi/i915 erfolglos versucht.

Kann ESXi technisch überhaupt die onboard iGPU korrekt durchreichen? Die XPEnology VM funzt so gut, dass ich fast am liebsten auf ESXi bleiben würde
 
Hast du das Problem auch mit der aktuellen VMware vSphere Hypervisor (ESXi) 7.0U2a ? Oder gibt es einen bestimmten Grund eine sehr alte ESXI Version zu nutzen ?
 
Ich habe da mal eine spezielle Frage: Ich muss an eine Kassen VM ein USB TSE Stick durchreichen. Den TSE USB Stick will ich an den Server stecken und per Passthrought direkt an die Kassen VM durchreichen.
Kann es da zu Problemen kommen ?

Oder soll ich mir gar nicht den Stress machen und gehe über den Client (RDP) und binde den Stick darüber an.
 
Zuletzt bearbeitet:
Probleme <kann> es imemr geben, das weis man immer erst hinterher bzw ist je nach Art des USB Dongles ausprobiererei.

Zum durchreichen von USB gibt es 3 Möglichkeiten:
- direkt an an ESX und dann einer VM zuordnen
- vom Client per RDP durchreichen
- einen USB->LAN Adapter verwenden (z.B. von Silex) und dann in der VM mounten
 
Jo die Möglichkeiten sind bekannt, mir ging es eher um Software Probleme (Anbindung/Zuordnung/Haschwerte/elektronische Signatur usw,). Ich habe jetzt ein wenig recherchiert und werde es direkt über RDP (falls noch ein USB Port am Client frei ist) anbinden. Ich denke das ist am stressfreiesten.
Grüße


Nachtrag: Über RDP war es nicht möglich da der Stick als Ordner durchgereicht wird. Über ESXI (USB Gerät durchreichen) war es problemlos und supereinfach erledigt.
 
Zuletzt bearbeitet:
Das kommt immer drauf an, WAS es ist. Ein Dongle von einer exorbitant teuren Software habe ich lieber im Serverraum. Wenn es nämlich ganz dumm kommt, und das Ding ist mal weg, und der Hersteller sperrt sich einen neuen herauszugeben, kann man die Software neu kaufen.

Das eine oder andere Gerät habe ich per RDP durchschleifen icht zum laufen bekommen, da blieb dann nur noch die Sliex LAN Box.
 
Ich habe eine Frage zum Storage, da fehlt mir einfach die Erfahrung. Soweit ich weiß, sollten die VMs auf Storage liegen, der insbesondere mit IOPS glänzen kann - mit dieser Anforderung lande ich bei NVMe-Storage, richtig? Gibt es eine Möglichkeit, NVMe-Storage als Raid 1 für ESX verfügbar zu machen, ohne einen relativ aktuellen und teuren Raid-Controller zu kaufen? Ich habe da bisher wenig gefunden und stehe für mich daher vor der Entscheidung, NVMe ohne Redundanz zu betreiben (eben mit häufigen Backups) oder SSDs als Raid 1 zu nehmen.
Ich will mir die Kiste in den Keller stellen und eine Handvoll VMs darauf laufen lassen, ich betreibe kein DC mit entsprechenden Budget, daher kann ich keinen Controller für 1000€ kaufen ...

Welcher Weg macht Eurer Erfahrung nach mehr Sinn, NVMe solo oder SSDs als Raid 1? Oder gibt es weitere Optionen?
 
ESXi ist einfach nur ein 'dummer' Virtualisierer.
Das Ding hat rein gar nichts mit Storage zu tun.

Wenn du nun unbedingt nen NVMe Storage direkt im ESXi verwenden moechtest, dann _NUR_ ueber einen supporteten Controller.

Andernfalls per Storage-VM und durchgereichten NVMe Geräten. Wird aber schnell frickelig wenn keine Enterprise-Hardware vorliegt.
 
p4n0 schrieb:
ESXi ist einfach nur ein 'dummer' Virtualisierer.
Das Ding hat rein gar nichts mit Storage zu tun.

Wenn du nun unbedingt nen NVMe Storage direkt im ESXi verwenden moechtest, dann _NUR_ ueber einen supporteten Controller.

Andernfalls per Storage-VM und durchgereichten NVMe Geräten. Wird aber schnell frickelig wenn keine Enterprise-Hardware vorliegt.
Zum Vergrößern anklicken....
Möchte ich denn unbedingt NVMe nutzen? ;) Ich kann nicht einschätzen, ob ich mit z.B. SATA-SSDs auch glücklich werde.
 
Grds genügen (Enterprise) SATA SSD für leichte VM Last. Was noch "leicht" ist ... ??
 
asche77 schrieb:
Grds genügen (Enterprise) SATA SSD für leichte VM Last. Was noch "leicht" ist ... ??
Zum Vergrößern anklicken....
Was wäre ein Beispiel für eine solche Enterprise SSD? Sowas wie eine Seagate Ironwolf pro, WD SA500 oder meinst Du eine andere Kragenweite? Die wären ja durchaus noch bezahlbar.

Ich glaube, dass das bei mir schon eher als „leichte Last“ durchgeht …
 
Jede "Datacenter" (DC) oder "Enterprise" oder "Server" SSD bzw jede mit (echter) Power Loss Protection.

Ältere Aufstellung:
Enterprise SATA SSD zB
- Intel DC S3500, S3510, S3610, S3700, S3710, S4500 / S4510 / S4600(?) / S4610
- Samsung PM963, SM863, PM863a, SM863a, ...
- Micron 5100 eco/pro/max, 5200 eco/pro (ION würde ich nicht nehmen)
- Toshiba HK3, HK4, HK5, ...
- Sandisk CloudSpeed, CloudSpeed II
- ...

Neu meist ziemlich teuer, gebraucht uU günstiger zu bekommen, (teils dann aber mit smart Error )
 
Tjo, da ist guter Rat teuer (*tschatsching*, 5 Euro für's Phrasenschwein).

Gibt so viele Möglichkeiten... welche es sein soll, hängt aber auch von der verwendeten Software und deinem persönlichen Risikoprofil ab.

Dummerweise braucht man ja immer ein wenig Speicherplatz unter ESXi - der von den VMs auf diesem Host unabhängig ist - auf dem mindestens die Storage-VM liegt (auf deren Storage dann die weiteren VMs liegen können). Jedenfalls zumindest deren Konfig, in der Regel aber eben auch der virtuelle Datenträger mit dem OS dieser VM. Wenn Du den Inhalt dieses Datenträgers per RAID gegen Ausfälle absichern willst, geht das eben nur, wenn das auf Ebene von ESXI (=Raidcontroller, der ESXi nur ein entsprechendes Volume zur Verfügung stellt) passiert, oder deine Storage-VM kann auch für ihre Systemdisk (inkl. Bootloader & Co.) ein Software-Raid nutzen deren virtuelle Platten "darunter" dann auf zwei unterschiedlichen einzelnen ESXi-Datenträgern liegen. Letzteres ist also quasi Raid1 mit zwei virtuellen Festplatten auf zwei unterschiedlichen physischen Datenträgern (mit dem Ergebnis, dass die VM noch funktionsfähig ist, wenn einer der beiden physischen (oder virtuellen) Datenträger ausfällt.

So hab ich das mit Solaris gemacht:
ESXi hat zwei SM883 (je 240GB) bekommen, die jeweils als einzelne Datenträger ("Disk1" und "Disk2") als Speicher für/von ESXi sichtbar und verwaltbar sind.
Meine Storage VM hat zwei VMDKs mit je 64GB verpasst bekommen, eine VMDK liegt auf Disk1 und eine auf Disk2. (Note: Die restlichen Datenträger bekommt die Storage-VM dann per passthrough.)
Nach der Installation auf Disk1 hab ich unter Solaris dem rpool (die "Systemdisk") die zweite virtuelle "Festplatte" von Disk2 als mirror zugeordnet und nach ein oder zwei Kommandos kann man von beiden VMDKs unabhängig booten (ließ (lässt?) sich leider nicht direkt bei der Installation als/auf Mirror installieren). Fertig ist das Raid1 der Storage-VM auch mit dem Systemdatenträger ganz ohne Raidcontroller.

Was Du damit aber noch nicht erreicht hast, ist die Gesamtkonfiguration deines ESXi-Hosts (inkl. Einstellungen der VMs) über ein Raid abzusichern. Das ist für mich aber nicht so wichtig: ESXi ist schnell installiert und die wesentlichen Konfigs schnell gemacht. Wichtig ist für mich nur, die Storage-VM schnell wieder am Laufen zu haben und dafür muss ich quasi nur den ESXi-Host zur Not wieder neu aufsetzen, Grundeinstellungen (virtuelle Switches, passthrough usw.) vornehmen und zur Not die ESXi-Settings der Storage-VM konfigurieren (falls es ausgerechnet diesen Datenträger dahingerafft haben sollte).

Davon ab ist so ein mirror-rpool eh was Feines. :d

Ob das mit deinem Wunsch-OS für die Storage-VM auch so (oder so ähnlich) geht, weiss ich nicht.

Statt wie beschrieben über ESXi-Storage mit SATA-SSDs könntest Du theoretisch auch zwei (weitere) NVMe der Storage-VM per passthrough geben und dann daraus das Software-Raid1 in der VM bauen. Dann brauchst Du aber trotzdem noch einen Speicherplatz, wo ESXi zumindest die Konfiguration der VMs, Installations-ISOs usw. ablegen kann (also mindestens eine weitere Disk). Außerdem ist meines Erachtens (!) NVMe-Speicherplatz 1.) nur als System-Disk für die Storage-VM (und dann auch noch als Raid) Perlen vor die Säue und 2.) eine Mischung von Gast-OS und Daten auf diesen NVMe's für eine bessere Nutzung auch "pfui" - Datenpools gehören für mich von den System-Disks (ob virtuell oder physisch) getrennt (schon wegen anderen Raid-Leveln, Performance usw.). Ich würde daher die NVMe's dann lieber "unbefleckt vom Gast-OS" lassen und der Storage-VM lieber ZUSÄTZLICH zu den oben beschriebenen beiden VMDKs mitgeben (darauf dann einen eigenes "Raid" o.ä., auf dem dann z.B. die weiteren VMs oder sonstige Daten liegen).

Aber wie gesagt: viele Wege führen nach Rom. Soll aber alles, was ESXi selbst angeht (inkl. Konfigurationsdateien der VMs), auf einem RAID liegen, kommst Du aber um einen Raidcontroller wohl eher nicht herum.
 
Danke für die Tipps!
Gegen einen Raid Controller habe ich nichts, nur wenn der NVMe können soll, wird es eben richtig teuer. Es gibt ja durchaus einige günstige Modelle, die supported sind und für den Zweck ausreichen - dann aber eben „nur“ SAS/SATA.
 
SATA reicht m.E. halt völlig für fast alles.
 
Kussler schrieb:
Hi zusammen, ich habe aktuell folgende Situation und komme einfach nicht weiter:

Mein altes Q1900DC-ITX mit baremetal XPEnology hat die Grätsche gemacht (on-board Stromversorgung kaputt).

Jetzt habe ich mir ein ASRock J4105-ITX geholt, weil das VT-d kann und ich endlich den eingebauten HDMI Port nutzen wollte.
Also ESXi 6.7u3 mit Realtek Treibern (für Realtek RTL8111H NIC) auf dem J4105 installiert und XPEnology als erstes virtualisiert.
Die XPEnology VM mit durchgereichtem ASMedia SATA Controller funktioniert absolut perfekt (baremetal modus, also die VM ist nur der bootloader, damit ich im Notfall auch einfach mit XPEnology Bootstick an die Platten komme).

Jetzt wollte ich eine Linux VM mit durchgereichter Intel UHD 605 iGPU (+ Audio) betreiben die einfach zum surfen/streamen am TV per HDMI gedacht ist.
Ich kriege ein HDMI Bild und Ton, aber die Video-Performance (ich tippe auf fehlende HW-acceleration) ist unterirdisch.
Die Linux VM scheint die Intel GPU zu erkennen, ich hab schon tausende Variationen von Parametern (VM Parameter in ESXI, i915 grub-Parameter, Xorg Parameter, Berechtigungen geprüft, etc.) getestet, aber es will einfach nicht so wie es soll. Entweder ist der Bildschirm nach dem Start von Xorg komplett schwarz, mal mit starken Artefakten (i915.modesetting=1), oder es ist alles glasklar aber mit Software-Renderer...
Versucht hatte ich zuerst Xubuntu, dann Ubuntu, dann Debian, dann LibreELEC, etc.

Ich muss dazu sagen, dass ich kein wirklicher Linux-Experte bin, deshalb kann ich absolut nich sagen, ob die VM dioe iGPU korrekt durchgereicht bekommt, aber ich hab ungefähr jeden Tweak aus dem Internet mit dem Thema GPU Passthrough/ESXi/i915 erfolglos versucht.

Kann ESXi technisch überhaupt die onboard iGPU korrekt durchreichen? Die XPEnology VM funzt so gut, dass ich fast am liebsten auf ESXi bleiben würde
Zum Vergrößern anklicken....

Ich hab mittlerweile noch ein paar Mal verschiedene Linux distros bzw. Kernel getestet und auch verschiedene ESXi Einstellungen und es funktioniert endlich!

Die VM wurde jetzt auf BIOS statt EFI installiert (mit EFI krieg ich einfach keine HW-accel hin) und der (Debian-)Kernel (uname -r) ist aktuell auf 4.19.0-17-amd64.
Außerdem hab ich noch die folgenden Pakete nachinstalliert: firmware-linux firmware-linux-nonfree firmware-misc-nonfree mesa-va-drivers intel-media-va-driver-non-free i965-va-driver intel-microcode libdrm-intel1 libintellij-annotations-java
(Vorher noch die sources list anpassen!)

Wenn mir jetzt noch jemand sagen kann, warum ESXi so viel RAM für sich beansprucht, wäre ich glücklich. Meine XPEnology VM hat 1 GB (2 GB wären mir lieber) zugewiesen und meine Debian VM krieg ich nicht auf 4 GB, obwohl der Host insgesamt 7,5 GB zur Verfügung hat (0,5 GB gehen für die iGPU drauf). ESXi meckert immer es wär zu wenig da...
 
VMware hat beim 7er den minimalen RAM-Bedarf von 2 auf 4GB erhöht und empfiehlt mindestens 8GB zum Starten von VMs in Produktiven Umgebungen.
 
Gibt's eigentlich irgendwas, was die 7er Version für uns Home-Frickler besser macht als 6.7U3? :d
 
Keine Ahnung, ich frickel relativ wenig. Daher ists mir wumpe ob 6.7 oder 7.x :d
 
Kann keine Samsung 980 o. 980 pro NVMe m.2 SSD per passthrough für VMs weitergeben. ESXI: 6.5.0 Update 3, MB: ASRockRack X470D4U2-2T m akt BIOS. :(
Passthrough für Intel, Crucial MP400 o. auch Samsung 970 NVMe m.2 SSDs geht.
Kenn jemand das Problem u. einen Fix?
Danke
 
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