ESX / ESXi - Hilfethread

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
:eek: Bildungslücke.

"D'oh" ist Homer Simpsons Stoßseufzer in der Originalsprache Englisch.
Im Deutschen leider mit dem Imperativ "Nein!" übersetzt...

Hab gerade alle VMs angehalten und die Betriebssystemversion neu gesetzt.
Danke dir. =)
Und auch danke dafür, dass ich nach 79 Tagen die VMs neustarten durfte... :haha:
 
Hallo Zusammen,

hab grade versucht die aktuellen Updates an meinem esxi (siehe Signatur) einzuspielen. Nach infos von folgendem Link:
[URL="https://esxi-patches.v-front.de/ESXi-6.7.0.html"]https://esxi-patches.v-front.de/ESXi-6.7.0.html[/URL]

In der ESXi config ist die Auslagerung wie folgt aktiv:

2019-12-10 20_35_16-ESXI – VMware ESXi.png

Folgendes habe ich über die SSH Konsole ausgeführt:

Code: 
esxcli network firewall ruleset set -e true -r httpClient
esxcli software profile update -p ESXi-6.7.0-20191204001-standard \
-d [url="https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml"]https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml[/url]
esxcli network firewall ruleset set -e false -r httpClient


Leider erhalte ich aber folgenden Fehler:

Code: 
[root@ESXI:~] esxcli software profile update -p ESXi-6.7.0-20191204001-standard \
> -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
 [InstallationError]
 [Errno 28] No space left on device
       vibs = VMware_locker_tools-light_11.0.1.14773994-15160134
 Please refer to the log file for more details.


Über den vSphere Client ist ein update leider nicht erfolgreich, da dies wenn ich es richtig verstehe auf Grund des HBA Passthrough nicht erfogreich ist.

Jemand ne idee oder Tipp für mich wie ich das Update angewendet bekomme?
Das vorige Update hatte Problemlos auf diesem wege funktioniert.

Danke.
Grüße
Elektromat

- - - Updated - - -

Hab es hinbekommen. Installation wie folgt:

Code: 
esxcli software profile update -p ESXi-6.7.0-20191204001-no-tools \
-d https://hostupdate.vmware.com/softwa...epot-index.xml

Code: 
Update Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed: VMW_bootbank_net-vmxnet3_1.1.3.0-3vmw.670.3.89.15160138, VMW_bootbank_vmkusb_0.1-1vmw.670.3.89.15160138, VMware_bootbank_elx-esx-libelxima.so_11.4.1184.2-3.89.15160138, VMware_bootbank_esx-base_6.7.0-3.89.15160138, VMware_bootbank_esx-update_6.7.0-3.89.15160138, VMware_bootbank_native-misc-drivers_6.7.0-3.89.15160138, VMware_bootbank_vsan_6.7.0-3.89.14840357, VMware_bootbank_vsanhealth_6.7.0-3.89.14840358
   VIBs Removed: VMW_bootbank_net-vmxnet3_1.1.3.0-3vmw.670.2.48.13006603, VMW_bootbank_vmkusb_0.1-1vmw.670.2.48.13006603, VMware_bootbank_elx-esx-libelxima.so_11.4.1184.1-2.48.13006603, VMware_bootbank_esx-base_6.7.0-3.77.15018017, VMware_bootbank_esx-update_6.7.0-3.77.15018017, VMware_bootbank_native-misc-drivers_6.7.0-2.48.13006603, VMware_bootbank_vsan_6.7.0-3.77.14914424, VMware_bootbank_vsanhealth_6.7.0-3.77.14914425
   VIBs Skipped: VMW_bootbank_ata-libata-92_3.00.9.2-16vmw.670.0.0.8169922, VMW_bootbank_ata-pata-amd_0.3.10-3vmw.670.0.0.8169922, VMW_bootbank_ata-pata-atiixp_0.4.6-4vmw.670.0.0.8169922, VMW_bootbank_ata-pata-cmd64x_0.2.5-3vmw.670.0.0.8169922, VMW_bootbank_ata-pata-hpt3x2n_0.3.4-3vmw.670.0.0.8169922, VMW_bootbank_ata-pata-pdc2027x_1.0-3vmw.670.0.0.8169922, VMW_bootbank_ata-pata-serverworks_0.4.3-3vmw.670.0.0.8169922, VMW_bootbank_ata-pata-sil680_0.4.8-3vmw.670.0.0.8169922, VMW_bootbank_ata-pata-via_0.3.3-2vmw.670.0.0.8169922, VMW_bootbank_block-cciss_3.6.14-10vmw.670.0.0.8169922, VMW_bootbank_bnxtnet_20.6.101.7-24vmw.670.3.73.14320388, VMW_bootbank_bnxtroce_20.6.101.0-20vmw.670.1.28.10302608, VMW_bootbank_brcmfcoe_11.4.1078.25-14vmw.670.3.73.14320388, VMW_bootbank_char-random_1.0-3vmw.670.0.0.8169922, VMW_bootbank_ehci-ehci-hcd_1.0-4vmw.670.0.0.8169922, VMW_bootbank_elxiscsi_11.4.1174.0-2vmw.670.0.0.8169922, VMW_bootbank_elxnet_11.4.1097.0-5vmw.670.3.73.14320388, VMW_bootbank_hid-hid_1.0-3vmw.670.0.0.8169922, VMW_bootbank_i40en_1.8.1.9-2vmw.670.3.73.14320388, VMW_bootbank_iavmd_1.2.0.1011-2vmw.670.0.0.8169922, VMW_bootbank_igbn_0.1.1.0-5vmw.670.3.73.14320388, VMW_bootbank_ima-qla4xxx_2.02.18-1vmw.670.0.0.8169922, VMW_bootbank_ipmi-ipmi-devintf_39.1-5vmw.670.1.28.10302608, VMW_bootbank_ipmi-ipmi-msghandler_39.1-5vmw.670.1.28.10302608, VMW_bootbank_ipmi-ipmi-si-drv_39.1-5vmw.670.1.28.10302608, VMW_bootbank_iser_1.0.0.0-1vmw.670.1.28.10302608, VMW_bootbank_ixgben_1.7.1.16-1vmw.670.3.73.14320388, VMW_bootbank_lpfc_11.4.33.25-14vmw.670.3.73.14320388, VMW_bootbank_lpnic_11.4.59.0-1vmw.670.0.0.8169922, VMW_bootbank_lsi-mr3_7.708.07.00-3vmw.670.3.73.14320388, VMW_bootbank_lsi-msgpt2_20.00.06.00-2vmw.670.3.73.14320388, VMW_bootbank_lsi-msgpt35_09.00.00.00-5vmw.670.3.73.14320388, VMW_bootbank_lsi-msgpt3_17.00.02.00-1vmw.670.3.73.14320388, VMW_bootbank_misc-cnic-register_1.78.75.v60.7-1vmw.670.0.0.8169922, VMW_bootbank_misc-drivers_6.7.0-2.48.13006603, VMW_bootbank_mtip32xx-native_3.9.8-1vmw.670.1.28.10302608, VMW_bootbank_ne1000_0.8.4-2vmw.670.2.48.13006603, VMW_bootbank_nenic_1.0.29.0-1vmw.670.3.73.14320388, VMW_bootbank_net-bnx2_2.2.4f.v60.10-2vmw.670.0.0.8169922, VMW_bootbank_net-bnx2x_1.78.80.v60.12-2vmw.670.0.0.8169922, VMW_bootbank_net-cdc-ether_1.0-3vmw.670.0.0.8169922, VMW_bootbank_net-cnic_1.78.76.v60.13-2vmw.670.0.0.8169922, VMW_bootbank_net-e1000_8.0.3.1-5vmw.670.0.0.8169922, VMW_bootbank_net-e1000e_3.2.2.1-2vmw.670.0.0.8169922, VMW_bootbank_net-enic_2.1.2.38-2vmw.670.0.0.8169922, VMW_bootbank_net-fcoe_1.0.29.9.3-7vmw.670.0.0.8169922, VMW_bootbank_net-forcedeth_0.61-2vmw.670.0.0.8169922, VMW_bootbank_net-igb_5.0.5.1.1-5vmw.670.0.0.8169922, VMW_bootbank_net-ixgbe_3.7.13.7.14iov-20vmw.670.0.0.8169922, VMW_bootbank_net-libfcoe-92_1.0.24.9.4-8vmw.670.0.0.8169922, VMW_bootbank_net-mlx4-core_1.9.7.0-1vmw.670.0.0.8169922, VMW_bootbank_net-mlx4-en_1.9.7.0-1vmw.670.0.0.8169922, VMW_bootbank_net-nx-nic_5.0.621-5vmw.670.0.0.8169922, VMW_bootbank_net-tg3_3.131d.v60.4-2vmw.670.0.0.8169922, VMW_bootbank_net-usbnet_1.0-3vmw.670.0.0.8169922, VMW_bootbank_nfnic_4.0.0.29-0vmw.670.3.73.14320388, VMW_bootbank_nhpsa_2.0.22-3vmw.670.1.28.10302608, VMW_bootbank_nmlx4-core_3.17.13.1-1vmw.670.2.48.13006603, VMW_bootbank_nmlx4-en_3.17.13.1-1vmw.670.2.48.13006603, VMW_bootbank_nmlx4-rdma_3.17.13.1-1vmw.670.2.48.13006603, VMW_bootbank_nmlx5-core_4.17.13.1-1vmw.670.3.73.14320388, VMW_bootbank_nmlx5-rdma_4.17.13.1-1vmw.670.2.48.13006603, VMW_bootbank_ntg3_4.1.3.2-1vmw.670.1.28.10302608, VMW_bootbank_nvme_1.2.2.28-1vmw.670.3.73.14320388, VMW_bootbank_nvmxnet3-ens_2.0.0.21-1vmw.670.0.0.8169922, VMW_bootbank_nvmxnet3_2.0.0.29-1vmw.670.1.28.10302608, VMW_bootbank_ohci-usb-ohci_1.0-3vmw.670.0.0.8169922, VMW_bootbank_pvscsi_0.1-2vmw.670.0.0.8169922, VMW_bootbank_qcnic_1.0.2.0.4-1vmw.670.0.0.8169922, VMW_bootbank_qedentv_2.0.6.4-10vmw.670.1.28.10302608, VMW_bootbank_qfle3_1.0.50.11-9vmw.670.0.0.8169922, VMW_bootbank_qfle3f_1.0.25.0.2-14vmw.670.0.0.8169922, VMW_bootbank_qfle3i_1.0.2.3.9-3vmw.670.0.0.8169922, VMW_bootbank_qflge_1.1.0.11-1vmw.670.0.0.8169922, VMW_bootbank_sata-ahci_3.0-26vmw.670.0.0.8169922, VMW_bootbank_sata-ata-piix_2.12-10vmw.670.0.0.8169922, VMW_bootbank_sata-sata-nv_3.5-4vmw.670.0.0.8169922, VMW_bootbank_sata-sata-promise_2.12-3vmw.670.0.0.8169922, VMW_bootbank_sata-sata-sil24_1.1-1vmw.670.0.0.8169922, VMW_bootbank_sata-sata-sil_2.3-4vmw.670.0.0.8169922, VMW_bootbank_sata-sata-svw_2.3-3vmw.670.0.0.8169922, VMW_bootbank_scsi-aacraid_1.1.5.1-9vmw.670.0.0.8169922, VMW_bootbank_scsi-adp94xx_1.0.8.12-6vmw.670.0.0.8169922, VMW_bootbank_scsi-aic79xx_3.1-6vmw.670.0.0.8169922, VMW_bootbank_scsi-bnx2fc_1.78.78.v60.8-1vmw.670.0.0.8169922, VMW_bootbank_scsi-bnx2i_2.78.76.v60.8-1vmw.670.0.0.8169922, VMW_bootbank_scsi-fnic_1.5.0.45-3vmw.670.0.0.8169922, VMW_bootbank_scsi-hpsa_6.0.0.84-3vmw.670.0.0.8169922, VMW_bootbank_scsi-ips_7.12.05-4vmw.670.0.0.8169922, VMW_bootbank_scsi-iscsi-linux-92_1.0.0.2-3vmw.670.0.0.8169922, VMW_bootbank_scsi-libfc-92_1.0.40.9.3-5vmw.670.0.0.8169922, VMW_bootbank_scsi-megaraid-mbox_2.20.5.1-6vmw.670.0.0.8169922, VMW_bootbank_scsi-megaraid-sas_6.603.55.00-2vmw.670.0.0.8169922, VMW_bootbank_scsi-megaraid2_2.00.4-9vmw.670.0.0.8169922, VMW_bootbank_scsi-mpt2sas_19.00.00.00-2vmw.670.0.0.8169922, VMW_bootbank_scsi-mptsas_4.23.01.00-10vmw.670.0.0.8169922, VMW_bootbank_scsi-mptspi_4.23.01.00-10vmw.670.0.0.8169922, VMW_bootbank_scsi-qla4xxx_5.01.03.2-7vmw.670.0.0.8169922, VMW_bootbank_sfvmk_1.0.0.1003-6vmw.670.3.73.14320388, VMW_bootbank_shim-iscsi-linux-9-2-1-0_6.7.0-0.0.8169922, VMW_bootbank_shim-iscsi-linux-9-2-2-0_6.7.0-0.0.8169922, VMW_bootbank_shim-libata-9-2-1-0_6.7.0-0.0.8169922, VMW_bootbank_shim-libata-9-2-2-0_6.7.0-0.0.8169922, VMW_bootbank_shim-libfc-9-2-1-0_6.7.0-0.0.8169922, VMW_bootbank_shim-libfc-9-2-2-0_6.7.0-0.0.8169922, VMW_bootbank_shim-libfcoe-9-2-1-0_6.7.0-0.0.8169922, VMW_bootbank_shim-libfcoe-9-2-2-0_6.7.0-0.0.8169922, VMW_bootbank_shim-vmklinux-9-2-1-0_6.7.0-0.0.8169922, VMW_bootbank_shim-vmklinux-9-2-2-0_6.7.0-0.0.8169922, VMW_bootbank_shim-vmklinux-9-2-3-0_6.7.0-0.0.8169922, VMW_bootbank_smartpqi_1.0.1.553-28vmw.670.3.73.14320388, VMW_bootbank_uhci-usb-uhci_1.0-3vmw.670.0.0.8169922, VMW_bootbank_usb-storage-usb-storage_1.0-3vmw.670.0.0.8169922, VMW_bootbank_usbcore-usb_1.0-3vmw.670.0.0.8169922, VMW_bootbank_vmkata_0.1-1vmw.670.0.0.8169922, VMW_bootbank_vmkfcoe_1.0.0.1-1vmw.670.1.28.10302608, VMW_bootbank_vmkplexer-vmkplexer_6.7.0-0.0.8169922, VMW_bootbank_vmw-ahci_1.2.8-1vmw.670.3.73.14320388, VMW_bootbank_xhci-xhci_1.0-3vmw.670.0.0.8169922, VMware_bootbank_cpu-microcode_6.7.0-3.77.15018017, VMware_bootbank_esx-dvfilter-generic-fastpath_6.7.0-0.0.8169922, VMware_bootbank_esx-ui_1.33.4-14093553, VMware_bootbank_esx-xserver_6.7.0-3.73.14320388, VMware_bootbank_lsu-hp-hpsa-plugin_2.0.0-16vmw.670.1.28.10302608, VMware_bootbank_lsu-intel-vmd-plugin_1.0.0-2vmw.670.1.28.10302608, VMware_bootbank_lsu-lsi-drivers-plugin_1.0.0-1vmw.670.2.48.13006603, VMware_bootbank_lsu-lsi-lsi-mr3-plugin_1.0.0-13vmw.670.1.28.10302608, VMware_bootbank_lsu-lsi-lsi-msgpt3-plugin_1.0.0-9vmw.670.2.48.13006603, VMware_bootbank_lsu-lsi-megaraid-sas-plugin_1.0.0-9vmw.670.0.0.8169922, VMware_bootbank_lsu-lsi-mpt2sas-plugin_2.0.0-7vmw.670.0.0.8169922, VMware_bootbank_lsu-smartpqi-plugin_1.0.0-3vmw.670.1.28.10302608, VMware_bootbank_qlnativefc_3.1.8.0-5vmw.670.3.73.14320388, VMware_bootbank_rste_2.0.2.0088-7vmw.670.0.0.8169922, VMware_bootbank_vmware-esx-esxcli-nvme-plugin_1.2.0.36-2.48.13006603


Danach mit das Fehlende .vib installiert.

Code: 
esxcli software vib install -v https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/tools-light/VMware_locker_tools-light_11.0.1.14773994-15160134.vib

Code: 
Installation Result
   Message: Operation finished successfully.
   Reboot Required: false
   VIBs Installed: VMware_locker_tools-light_11.0.1.14773994-15160134
   VIBs Removed: VMware_locker_tools-light_10.3.10.12406962-14141615
   VIBs Skipped:


Jemand ne idee wie ich generell dieses [Errno 28] No space left on device beim nächsten Update umgehen kann?
Bzw. warum funktionierts einzeln aber nicht zusammen?

Grüße
Elektromat
 
Ich plage mich auch schon länger mit diesem Fehler rum. Hatte mein ESXi 6.7U3 frisch installiert und die Auslagerungsdatei eingestellt, aber schon beim ersten Update direkt die gleichen Probleme "[Errno 28] No space left on device". Der ESXi ist auf einer 120GB SSD installiert, auf der auch die Auslagerungsdatei liegt. Freier Speicherplatz ist auf der SSD eigentlich ausreichend vorhanden.
 
Aus welchem grunde auch immer, wird die Partitionierung wohl mit der Installation nur recht knapp bemessen vorgenommen.
Auf meinem 16 GB Stick wird der vorhandene Platz auch nicht vollständig verwendet wie ich es in Erinnerung habe.
 
Weiss irgendjemand hier evtl. etwas dazu, ob die TRX40-Plattform von ESXi supported wird?

...ich bekomm' nämlich GPU-Passthrough einer 2080Ti auf einem TRX40 Taichi nicht ans Laufen... :motz:
 
Zuletzt bearbeitet:
besterino schrieb:
Weiss irgendjemand hier evtl. etwas dazu, ob die TRX40-Plattform von ESXi supported wird?

...ich bekomm' nämlich GPU-Passthrough einer 2080Ti auf einem TRX40 Taichi nicht ans Laufen... :motz:
Zum Vergrößern anklicken....



- IOMMU-Gruppen?
- Da es eine nvidia ist - die advanced VM Settings angepasst?
- Funktioniert der Passtrough nicht?
- Erscheint die GraKa nicht in der VM?
- Startet die VM mit der GraKa?
- Schmiert der ESXi beim Start der VM ab?
 
- IOMMU-Gruppen?
Was genau meinst Du / willst Du wissen?

- Da es eine nvidia ist - die advanced VM Settings angepasst?
Ja:
hypervisor.cpuid.v0=FALSE
pciPassthru[0].MSIEnabled=FALSE (für alle außer USB-Controller der Ti, hab aber auch mit mal mit ausprobiert --> kein Unterschied)
pciPassthru.64bitMMIOSizeGB=64
pciPassthru.use64bitMMIO=TRUE


- Funktioniert der Passtrough nicht?
Doch, aber die VM crashed beim Booten --> Boot loop in Windows Recovery.

- Erscheint die GraKa nicht in der VM?
Doch, aber entweder mit Error 43 oder VM crashed beim Booten --> Boot loop in Windows Recovery

- Startet die VM mit der GraKa?
Nur wenn die Graka wg. Error 43 nicht funktioniert. :d

- Schmiert der ESXi beim Start der VM ab?
Nein. Übrigens ESXi 6.7U3.

Außerdem bereits in der passthru.map experimentiert: settings für Nvidia (10de) generell auf d3d0 / link, ganz auskommentiert oder für einzelne devices außer GPU selbst auf d3d0.

Mit einem X399-Brett (X399D8A-2T) hab ich es mit der Graka ja mal hinbekommen. Auf dem läuft auch aktuell eine TitanXP im Passthrough, da muss ich in der passthru.map die Graka-Devices (Audio + GPU) auf "link" setzen.

Windows funktioniert übrigens auch problemlos mit der Hardware.
 
Hi,

jemand Erfahrung mit GPU-Passtrough und AMD Karten? Muss da auch,wie bei den NVIDIA, was an den Advanced VM Settings bzw. Passthru.map gemacht werden?

Danke schonmal
 
Roger2k schrieb:
Ich plage mich auch schon länger mit diesem Fehler rum. Hatte mein ESXi 6.7U3 frisch installiert und die Auslagerungsdatei eingestellt, aber schon beim ersten Update direkt die gleichen Probleme "[Errno 28] No space left on device". Der ESXi ist auf einer 120GB SSD installiert, auf der auch die Auslagerungsdatei liegt. Freier Speicherplatz ist auf der SSD eigentlich ausreichend vorhanden.
Zum Vergrößern anklicken....

Es ist am einfachsten, das jeweilige Update als ZIP File auf einen Datastore zu legen. Von dort kann man dann z.B. einfach das Update mittels

Code: 
esxcli software vib update -d /vmfs/volumes/BackupNAS/ESXi670-201912001.zip

starten. Dabei muss dann das Archiv nicht erst heruntergeladen werden. Irgendwie scheint das mit dem automatischen Auslagern auf den Datastore nicht zu funktionieren.
 
Roger2k schrieb:
Ich plage mich auch schon länger mit diesem Fehler rum. Hatte mein ESXi 6.7U3 frisch installiert und die Auslagerungsdatei eingestellt, aber schon beim ersten Update direkt die gleichen Probleme "[Errno 28] No space left on device". Der ESXi ist auf einer 120GB SSD installiert, auf der auch die Auslagerungsdatei liegt. Freier Speicherplatz ist auf der SSD eigentlich ausreichend vorhanden.
Zum Vergrößern anklicken....

Es gibt diverse Einträge in diversen Foren zu der Meldung. Das kann verschiedene Gründe haben. Einerseits gibts nen KB Artikel bei VMware zum Thema INodes, wenn voll, dann kommt wohl die gleiche Meldung. Andererseits soll ein weiterer Ansatzpunkt das Setzen des Swap Bereichs auf einen Datastore sein. Per default ist das nicht der Fall, sondern es wird das Root Volume genutzt?
Wie es scheint kommt es hier einfach nur dazu, dass wahlweise die INodes nicht ausreichen/voll sind oder eben kein Platz im besagten Speicherbereich zum Auspacken des gesamten Archivinhalts ist. Die VMware Tools sind ja noch recht "groß". Das in zwei Schritten zu machen umgeht das Thema. Deswegen gehts imho einzeln.
Der Platz auf der SSD ist übrigens dabei nicht wirklich das Thema, das Ding ist mehrfach partitioniert. Von deinen 120GB stehen dem Host also nichtmal ansatzweise so viel zur Verfügung.
 
fdsonne schrieb:
Der Platz auf der SSD ist übrigens dabei nicht wirklich das Thema, das Ding ist mehrfach partitioniert. Von deinen 120GB stehen dem Host also nichtmal ansatzweise so viel zur Verfügung.
Zum Vergrößern anklicken....

Das ist richtig, aber wieso wird Seitens VMWare dann nicht die Partitionsgröße in zukünftigen Installationen erweitert (sofern verfügbar)? Speicher kostet ja heutzutage nicht mehr wirklich was, gerade auf MicroSD, wo die meisten Server das drauf haben.
XEN Server handhabt das aber übrigens leider auch sehr ähnlich. Da durfte ich damals ewig die Logs aufräumen, damit die Kiste noch lief.
 
Weil das rumfingern an gemounteten Partitionen nicht so ganz ohne ist. Sicher könnte man da was bauen, wenn man will oder weis was getan werden muss. Aber das ist halt kein Klicki Bunti Windows oder Linux. Sondern soll ein Hypervisor sein, der für sodde Spielerei halt einfach nicht gemacht ist.
Ich wäre mir nichtmal sicher ob das überhaupt Punkte bringt die Partition zu vergrößern - denn je nachdem was da nun genau das Problem ist könnte das halt wieder voll laufen.

In der VCSA gibts bspw. ne Partition mit irgend so nem DB Log Kram, die ist 50GB in der 100 Hosts/1000 VMs "Size" -> und ist voll, randvoll. 100% usage. Known "issue". Kein wirkliches Problem im Betrieb, weil er vorn rausputzt, wenn er hinten rein schreibt. Aber so ziemlich jegliche SNMP based Disküberwachung schlägt halt Alarm. Würde das mit der Partition, wer der Host die Files abkippt, ähnlich laufen, würde groß machen nur bedingt was bringen.

Btw. ich für meinen Teil habe mir angewöhnt, eh nur noch ohne VMware Tools zu installieren. Warum? Weil die Dinger eh alle Nase lang geupdatet werden. Sprich ich muss das an die VMs eh zyklisch verteilen. Bei mir geschieht das im allmonatlichen Rhythmus der Microsoft Patches. Kommt da noch ein neues Paket, fliegts direkt mit drauf. Je nachdem muss die VM dann eh gebootet werden. Auch wenn das aktuell nicht mehr so schlimm ist wie früher.
 
Zuletzt bearbeitet:
tekken321 schrieb:
Hi,

jemand Erfahrung mit GPU-Passtrough und AMD Karten? Muss da auch,wie bei den NVIDIA, was an den Advanced VM Settings bzw. Passthru.map gemacht werden?

Danke schonmal
Zum Vergrößern anklicken....

Jo, funzt reibungslos :wink:
Rein mit der GraKa, IOMMU aktivieren und dann durchreichen.
Nur integrierte GPUs wollen nicht.

Aber - unter AM4 gibts wohl einen Reset Bug was einen Neustart des gesamten Hosts von nöten hat.
Wobei ich das auf meinem B450m Steel Legend jetzt seit 2 Monaten nicht mehr hatte und VM-Reboots mit der GraKa laufen einwandfrei.

GPU ist ne PowerColor Radeon RX480 Red Devil.

- - - Updated - - -

besterino schrieb:
- IOMMU-Gruppen?
Was genau meinst Du / willst Du wissen?

- Da es eine nvidia ist - die advanced VM Settings angepasst?
Ja:
hypervisor.cpuid.v0=FALSE
pciPassthru[0].MSIEnabled=FALSE (für alle außer USB-Controller der Ti, hab aber auch mit mal mit ausprobiert --> kein Unterschied)
pciPassthru.64bitMMIOSizeGB=64
pciPassthru.use64bitMMIO=TRUE


- Funktioniert der Passtrough nicht?
Doch, aber die VM crashed beim Booten --> Boot loop in Windows Recovery.

- Erscheint die GraKa nicht in der VM?
Doch, aber entweder mit Error 43 oder VM crashed beim Booten --> Boot loop in Windows Recovery

- Startet die VM mit der GraKa?
Nur wenn die Graka wg. Error 43 nicht funktioniert. :d

- Schmiert der ESXi beim Start der VM ab?
Nein. Übrigens ESXi 6.7U3.

Außerdem bereits in der passthru.map experimentiert: settings für Nvidia (10de) generell auf d3d0 / link, ganz auskommentiert oder für einzelne devices außer GPU selbst auf d3d0.

Mit einem X399-Brett (X399D8A-2T) hab ich es mit der Graka ja mal hinbekommen. Auf dem läuft auch aktuell eine TitanXP im Passthrough, da muss ich in der passthru.map die Graka-Devices (Audio + GPU) auf "link" setzen.

Windows funktioniert übrigens auch problemlos mit der Hardware.
Zum Vergrößern anklicken....

Hmmm.... Mir würde noch einfallen, dass du den ACS override in den erweiterten Einstellungen vom ESXi von false auf true stellst.

Die VM schmiert ab sobald der Treiber installiert wird, richtig? Könnte es sein das nvidia den Treiber dahingehend angepasst hat?



PS: Bin ich froh, dass es den automatischen Merge beim Doppelpost gibt ^^
 
Zuletzt bearbeitet:
Hmm... die ACS-Einstellungen in ESXi kann ich noch probieren.

Am Treiber sollte es eigentlich nicht liegen: TitanXp funzt mit dem Treiber im Passthrough (auf X399 Plattform).

Weiter Ausprobieren geht leider erst nächste Woche... jetzt erst mal mit ganz anderen Brettern spielen und Geschwindigkeit ohne BIOS oder OC am Hang steigern. ;)
 
Ihr Lieben, gibt es eigentlich eine Möglichkeit für Normalsterbliche, kostenlos an die aktuelle 6.7U3b zu kommen? Meine einmalige Test-Phase ist leider schon vor einigen Jahren abgelaufen... :d
 
Du hast Post
 
Hab’s hinbekommen. :d

Zur Erinnerung: 3960X auf ASRock TRX40 Taichi mit ESXi 6.7U3b, 2 VMs für GPU-Passthrough (1x 2080Ti, 1x TitanXp) mit Win10 Pro 1909. Beide VMs je 8 Kerne und 16GB RAM.

Mit der VM mit der 2080Ti kann man lokal am „Server“ zocken, die VM mit der Titan streamt parallel und unabhängig davon über GeForce Game Streaming an entfernte Geräte mit moonlight als client.

Als Proof of concept funzt das wirklich gut. Müsste jetzt mir nur echt mal überlegen, ob ich das dauerhaft so einsetzen will... dann wäre da noch einiges anzupassen.

Erkenntnis 1: vmxnet3 als NIC in der VM ist Käse und bekommt keinen sauberen 4K Stream hin - auch nicht mit einer 10Gbit-Leitung. Mit SR/IOV NICs geht’s dann.

Erkenntnis 2: der up2 scheint als Client zu schwach auf der Brust zu sein.
 
Inplace-Update auf 6.7U3b am X399D8A-2T erfolgreich. Entsprechende Zip-Datei auf den lokalen Datastore und mit "esxcli software vib update -d" installiert.
Btw, der Datastore ist am gleichen 128er Stick wie der ESXI. :bigok: . Muss man halt manuell partitionieren und formatieren aber das ist nicht tragisch.
 
Ich mach das bisher immer über die ISO - einfach Booten und die bietet ja auch eine Update-Funktion. Hat bis jetzt immer problemlos geklappt. Allerdings bin ich sonst da immer auf dem „Never Change a Running System“ - gerade bei VMware ändert sich da von Version zu Version ja doch zum Teil erheblich was und meine Box hängt nicht (direkt) am Internet.
 
Ich erstelle mir mim ESXi-Customizer Skript mein eigenes ISO, dann habe ich die aktuelle Variante. Notwendige VIBs kann ich einpflegen lassen und ich muss mich nicht bei VMware für den ISO-Download anmelden :bigok:

Wenns ist, kann ich dann mit dem ISO via Update-Manager auch gleich updaten, kann mich nicht beschweren ^^

@besterino was hat es letztendlich zum laufen gebracht?
 
Seelbreaker: weiß ich nicht genau, das ist das Problem, wenn man an verschiedenen Schrauben gleichzeitig dreht. :d Kann z.B. eine BIOS-Einstellung, die neue ESXi-Version (6.7U3B statt 6.7U3) eine erweiterte VM-Einstellung (kein msiEnabled = FALSE) oder auch das Entfernen der Einstellungen aus der passthru.map gewesen sein. Oder eine Kombination davon. ;)
 
Ich hoffe jemand kann mir hier weiterhelfen, den ich Verzweifle grad ein bisschen:

Habe meinen Server (ML310e) inkl. einer Dual Port GBit NIC (HP Branded, aber eig. die normale Intel Dual Port NIC) nun frisch mit ESXi 6.5 U3 (Neuestes Dezember HP Image) installiert. Nun habe ich aber Probleme mit einer VM, die PCI Geräte nutzt
Es handelt sich hier um eine Firewall fürs Testnetzwerk (Sophos UTM 9.6). Per Passthrough wurde die Dual Port GBit NIC übergeben. Starte ich die Maschine, hängt sie sich nach dem Hochfahren auf und geht einfach Instant aus (In den Logs konnte ich Grob nichts finden, außer, dass das Ding halt ein Power Off hatte).

Gleiches gilt, wenn ich Versuche, die Firewall komplett neu zu installieren. Beim Setup (HW Detect) geht die VM einfach aus - In der Weboberfläche gibt es aber kein Hinweis auf einen Fehler.
Mit 6.0 U3 ging Passthrough problemlos. Im BIOS etc. nix geändert. Hat hier jemand einen Tipp? Stochere seit Stunden im Dunkeln

Was ich bisher auch rausgefunden hab:
Es handelt sich um eine HP NC360T Dual Port GBit Netzwerkkarte --> Wird laut VMware HCL nur bis 6.5 U2 unterstützt
Erkannt wird eine Intel Corporation 82571EB Gigabit Ethernet Controller im Web UI --> Wird laut VMware HCL für 6.5 U2 und wieder 6.7 (U1) unterstützt

Urm... Ok - Kann man machen. Kann mir einer sagen, wo ich die Treiber am besten herkriege? Soll ich hier die HP Treiber oder Intel Treiber nehmen? Komisch ist jedoch, dass die NIC problemlos erkannt wird und funktioniert, scheinbar will das Ding bloß nicht im Passthrough genutzt werden, lässt sich aber Konfigurieren und als PCI-Gerät zuweisen.

Edit2: Getestet habe ich jetzt auch Passthrough mit einer Windows VM. Hier kommt es beim Booten zu einem Bluescreen, während eben die Linux VMs einfach PowerOff machen nach dem Starten bzw. beim Setup auch einfach aus gehen...
 
Zuletzt bearbeitet:
Schau' mal bitte, wie die Karte genau in ESXi erkannt wird, konkret welche Anbieter ID und Geräte ID die hat.

Damit bewaffnet kannst Du mal in der passthru.map schauen: wenn (zufällig) einer der Einträge der Intel passt, ggf. mal auskommentieren. Falls für Deine NIC kein Eintrag vorhanden ist, mal einen der Intel Einträge ausprobieren, z.B. 8086 [BZW. DEINE ANBIETER-ID (ohne "0x")] [DEINE DEVICE ID (ohne "0x")] d3d0 default - ggf. statt default auch mal false. Tut das nicht, kannst Du auch noch statt d3d0 mal "link" und "bridge" versuchen.

Ansonsten Workaround: NIC bei ESXi lassen, den NICs exklusive vSwitches zuweisen und in diese vSwitches nur die Sophos-VM mit virtuellen Adaptern hängen. Meine Sophos-VM hat z.B. 4 solche virtuellen NICs und routet u.a. auch zwischen den entsprechenden Netzen; kann übrigens auch VMXNET3.
 
Das mit den NICs normal anhängen und vSwitche usw. kenne ich alles - Da das aber auch meine Testmaschine ist, will ich auch wirklich "echte" NICs dran haben.

Folgendermaßen wird das Ding erkannt:
1578333929002.png

Ich habe jetzt auch mal eine Ersatz NC360T reingeklemmt (Der Server lief seit Dezember 2018 ohne Reboot :fresse: Nicht, dass die Reboots heute das Ding gekillt haben. Karte hat schon einige Jahre aufm Buckel).
Gleiches Phenomen.

Die Treiber sind auf dem (HP) ESXi 6.5 U3 Image aber eins neuer, als in den HCL Listen für 6.5 U2 angegeben:
1578334126281.png


Muss mal schauen, wie ich herausfinden kann, was für ein Treiber die Intel Karte genau nutzt (Es können wohl einer von 2 aus dem Bild sein). Bei 6.0 U3 war nämlich nur der net-e1000e in der 3.2.2.1-2 enthalten (Wie jetzt auch im 6.5 U3), jedoch zusätzlich der ne1000 aus der HCL (Gab es nicht in 6.0 scheinbar?). Evtl. kann ich den anzuziehenden Treiber anpassen?

Das gleiche war beim B120i Treiber. Downgrade auf 88er Version durchgeführt, danach zog er aber den Default VMware Treiber (Bei 6.0 U3 kein Problem). Musste ich dann den default VMware (SCSI) Treiber auch disablen (Passthrough ging davor auch schon nicht, also hat das keine Auswirkungen auf den Rest gehabt)
Am schlimmsten ist aber die sch*** WebUI, die total Lahmarschig, träge und zum Teil buggy ist :( Vermisse jetzt schon den vSphere Client :(
 
ESXi Treiber sollten doch bei aktiviertem Passthrough völlig egal sein... der Hypervisor macht ja nix mit dem Ding und außerdem funzt Passthrough ja auch mit Geräten, für die ESXi überhaupt keine Treiber hat. Treiber spielen doch nur dann eine Rolle, wenn Du Passthrough deaktivierst um z.B. wie von mir oben beschrieben mit vSwitches zu arbeiten.

Willst Du passthrough, kommst Du daher mit Treibereien m.E. nicht weiter, sondern musst eben bei der passthru.map bzw. Sonderparametern in der VM ansetzen.
 
Ja - Das denke ich mir auch. Aber aktuell kann ich mir nicht erklären, warum mit 6.0 U3 die VM ging, in 6.5 U3 die VM nicht mehr geht bzw. nichtmal eine komplett nagelneue. Beides ohne dem PCI Gerät geht tadellos.
Was soll ich da bei der passthru.map den Prüfen? Eig. sollte er das doch bei einer neuen VM sauber einrichten können... :/

Edit: Das größte Problem ist aktuell, dass ich gar nichts bei Google finde. Wenn ich was mit Passthrough suche, komme ich zu 90% auf irgendwelche GPU Passthrough spielereien (Auch dein Thread im HWLUXX :fresse:) oder, dass der ganze Host freezed. Gibt es irgendwo "versteckte" Logs (Die ich nicht kenne), wo ich nachschauen kann, was genau passiert? Interessant ist der Zeitpunkt, wenn die VM kurz einfriert und halt Instant einfach ein "Power off" macht (Sich abschaltet). Ich habe das Gefühl, das liegt eher am ESXi, dass er etwas abschaltet, bevor der Host Probleme kriegt, als die VM selber.
Nach einigem hin und her kann ich jetzt folgendes noch sagen: Windows VMs kacken nach dem BIOS Post (Also wenn Windows hochgefahren werden soll) instant ab und gehen in Power Off, kein Bluescreen.
 
Zuletzt bearbeitet:
Ich hab da bei den GPUs schon allerlei erlebt. Unter 6.5 funzt es mit GPU1 mit Settings ABC, unter 6.7(U1/2/3(b)) dann aber nur mit Settings 123 oder wieder ganz anders. Mit GPU2 werden die Karten dann wieder neu gemischt, je nach ESXi-Version.... ein System hab ich dahinter noch nicht erkannt. :d

Disclaimer: Bin selbst kein ESXi-Experte, hab alles auch nur mal selbst angelesen / ausprobiert, z.B. hier.

Würde an Deiner Stelle als erstes (weil schnell gemacht) mal testweise in den advanced settings der VM für die NIC mal folgenden Parameter setzen:

Code: 
pciPassthru0.msiEnabled = "FALSE"

...wobei du bei mehreren Passthrough-Devices in der VM ggf. die Nummer "0" anpassen musst, je nachdem welches Device deine NIC genau ist. Und falls deine NICs als zwei Geräte auftauchen, eben zwei Einträge setzen, wenn es die einzigen sind eben:
pciPassthru0.msiEnabled = "FALSE"
pciPassthru1.msiEnabled = "FALSE"

Wenn das nicht hilft, würde ich für deine NIC in der passthru.map einen Eintrag anlegen und als erstes testen:

8086 8c1c d3d0 default

Da man nach Änderungen in der passthru.map besser immer einen Reboot macht, kannst Du danach dann auch jeweils einmal mit und ohne msiEnabled=FALSE testen.

Das Ganze kannst Du dann jeweils für die verschiedenen Möglichkeiten durchprobieren, also:

8086 8c1c d3d0 false
8086 8c1c link default
8086 8c1c link false
8086 8c1c bridge default
8086 8c1c bridge false

Bringt das alles nix, weiss ich auch nicht weiter, außer auf neue ESXi-Version hoffen...
 
Ich kriege grad so dermaßen die Kotze.
Bei Windows kann ich zwischen 8 und 10 unterscheiden:
- Windows 10 kriegt ein Bluescreen mit zugewiesener NIC während Boot
- Bei Windows 8.1 funktioniert die VM tadellos, bis er in Windows drin ist und die 2 Fenster kommen mit "Treiber werden installiert". Kurz darauf geht einfach die ganze VM direkt aus. Gleiches Verhalten wie mit der Linux Maschine, sobald diese durchgestartet ist bzw. das Setup die HW scant

Das, was ich zuvor geposted hab mit "Startet gar nicht mehr" lag an etwas anderem...

@ besterino
Danke - Teste ich gleich mal. Kann doch echt nicht sein - Früher war alles besser. Die neuen ESXi auch total komisch
 
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