Producent oprogramowania do wirtualizacji VMware opublikował właśnie kolejną wersję oprogramowania VMware vSphere Hypervisor (ESXi) 7.0U2. W najnowszej aktualizacji wprowadzono wiele ciekawych rozwiązań oraz naprawiono kilka większych i mniejszych błędów min. : Problemy z aktualizacją, migracją oraz instalacją wersji 7.x na hostach z wersją 6.5.x lub 6.7.x, problemy z pamięcią masową w których błąd dotyczył odzyskiwania danych z dysków klastrowanych z modułów APD lub PDL i skutkował iż dane pozostawały niedostępne, Auto Deploy które usuwało konfigurację ESXi podczas migracji do ConfigStore oraz problemy z siecią. Zachęcamy do zapoznania się z artykułem.
Nowości:
ESXi 7.0 Update 2 obsługuje vSphere Quick Boot na następujących serwerach:
Dell Inc.
PowerEdge M830
PowerEdge R830
HPE
ProLiant XL675d Gen10 Plus
Lenovo
ThinkSystem SR 635
ThinkSystem SR 655
Niektóre pliki konfiguracyjne ESXi stają się read-only: Od ESXi 7.0 Update 2, konfiguracja poprzednio przechowywane w plikach /etc/keymap, /etc/vmware/welcome, /etc/sfcb/sfcb.cfg, /etc/vmware/snmp.xml, /etc/vmware/logfilters, /etc/vmsyslog.conf, i /etc/vmsyslog.conf.d/*.conf , teraz rezyduje się je w bazie ConfigStore. Tę konfigurację można modyfikować tylko za pomocą poleceń ESXCLI, a nie edytując pliki. Aby uzyskać więcej informacji, zobacz artykuły bazy wiedzy VMware 82637 i 82638 .
Statystyki VMware vSphere Virtual Volumes dla lepszego debugowania: dzięki ESXi 7.0 Update 2 możesz śledzić statystyki wydajności dla vSphere Virtual Volumes, aby szybko identyfikować problemy, takie jak opóźnienia w odpowiedziach dostawców VASA innych firm. Korzystając z zestawu poleceń, można uzyskać statystyki dla wszystkich dostawców VASA w systemie lub dla określonej przestrzeni nazw lub jednostki w danej przestrzeni nazw lub włączyć śledzenie statystyk dla całej przestrzeni nazw. Aby uzyskać więcej informacji, zobacz Zbieranie informacji statystycznych dla vVols .
Obsługa architektury NVIDIA Ampere : vSphere 7.0 Update 2 dodaje obsługę architektury NVIDIA Ampere, która umożliwia przeprowadzanie zaawansowanych ćwiczeń AI / ML, wykorzystując przyspieszoną pojemność GPU A100. Ponadto vSphere 7.0 Update 2 poprawia współużytkowanie i wykorzystanie GPU, wspierając technologię Multi-Instance GPU (MIG). Można również zauważyć zwiększoną wydajność komunikacji urządzenie-urządzenie, opierając się na istniejącej funkcjonalności NVIDIA GPUDirect, włączając usługi Address Translation Services (ATS) i Access Control Services (ACS) w warstwie magistrali PCIe w kernel’u ESXi.
Obsługa kart sieciowych Mellanox ConnectX-6 200G : ESXi 7.0 Update 2 obsługuje karty sieciowe Mellanox Technologies z rodziny MT28908 (ConnectX-6) i Mellanox Technologies z rodziny MT2892 (ConnectX-6 Dx) 200G.
Ulepszenia wydajności procesorów AMD Zen: dzięki ESXi 7.0 Update 2 gotowe optymalizacje mogą zwiększyć wydajność procesora AMD Zen nawet o 30% w różnych testach porównawczych. Zaktualizowany harmonogram ESXi w pełni wykorzystuje architekturę AMD NUMA, aby podejmować najbardziej odpowiednie decyzje dotyczące rozmieszczenia maszyn wirtualnych i kontenerów. Optymalizacje procesorów AMD Zen pozwalają na większą liczbę maszyn wirtualnych lub wdrożeń kontenerów z lepszą wydajnością.
Zmniejszone opóźnienia obliczeniowe i I/O oraz jitter dla obciążeń wrażliwych na opóźnienia: obciążenia wrażliwe na opóźnienia, takie jak aplikacje finansowe i telekomunikacyjne, mogą dostrzec znaczące korzyści w wydajności dzięki optymalizacji opóźnień I/O i optymalizację jittera w ESXi 7.0 Update 2. Optymalizacje zmniejszają zakłócenia i źródła jittera, aby zapewnić spójne środowisko wykonawcze. Dzięki ESXi 7.0 Update 2 można również zobaczyć większą szybkość dostarczania przerwań dla urządzeń przejściowych.
Poufne vSphere Pods w klastrze Supervisor w vSphere z Tanzu: Począwszy od vSphere 7.0 Update 2, możesz uruchamiać poufne vSphere Pods, utrzymując pamięć systemu gościa w postaci zaszyfrowanej i chronionej przed dostępem z hiperwizora, w klastrze Supervisor w vSphere z Tanzu. Możesz skonfigurować poufne vSphere Pods, dodając Secure Encrypted Virtualization-Encrypted State (SEV-ES) jako dodatkowe rozszerzenie bezpieczeństwa. Aby uzyskać więcej informacji, zobacz Wdrażanie poufnego poda vSphere .
Szybkie aktualizacje programu vSphere Lifecycle Manager: Począwszy od wersji vSphere 7.0 Update 2, można znacznie skrócić czas aktualizacji i przestojów systemu oraz zminimalizować czas rozruchu systemu, zawieszając maszyny wirtualne w pamięci i korzystając z funkcji szybkiego rozruchu. Możesz skonfigurować vSphere Lifecycle Manager do zawieszania maszyn wirtualnych w pamięci zamiast ich migracji, wyłączania lub zawieszania na dysku podczas aktualizacji hosta ESXi. Aby uzyskać więcej informacji, zobacz Konfigurowanie programu vSphere Lifecycle Manager pod kątem szybkich uaktualnień.
Zaszyfrowany ruch w dzienniku funkcji Fault Tolerance: Począwszy od wersji vSphere 7.0 Update 2, można szyfrować ruch z dziennika funkcji Fault Tolerance w celu zwiększenia bezpieczeństwa. vSphere Fault Tolerance przeprowadza częste testy między podstawową i dodatkową maszyną wirtualną, aby umożliwić szybkie wznowienie od ostatniego pomyślnego punktu kontrolnego. Punkt kontrolny zawiera stan maszyny wirtualnej, który został zmodyfikowany od czasu poprzedniego punktu kontrolnego. Szyfrowanie ruchu dziennika zapobiega złośliwemu dostępowi lub atakom sieciowym.
Rozwiązane problemy:
Installation, Upgrade, and Migration Issues
- Upgrades to ESXi 7.x from 6.5.x and 6.7.0 by using ESXCLI might fail due to a space limitationUpgrades to ESXi 7.x from 6.5.x and 6.7.0 by using the esxcli software profile update or esxcli software profile install ESXCLI commands might fail, because the ESXi bootbank might be less than the size of the image profile. In the ESXi Shell or the PowerCLI shell, you see an error such as:
[InstallationError] The pending transaction requires 244 MB free space, however the maximum supported size is 239 MB. Please refer to the log file for more details.
The issue also occurs when you attempt an ESXi host upgrade by using the ESXCLI commands esxcli software vib update or esxcli software vib install.
This issue is resolved in this release.
- After recovering from APD or PDL conditions, VMFS datastore with enabled support for clustered virtual disks might remain inaccessibleYou can encounter this problem only on datastores where the clustered virtual disk support is enabled. When the datastore recovers from an All Paths Down (APD) or Permanent Device Loss (PDL) condition, it remains inaccessible. The VMkernel log might show multiple
SCSI3 reservation conflictmessages similar to the following:2020-02-18T07:41:10.273Z cpu22:1001391219)ScsiDeviceIO: vm 1001391219: SCSIDeviceCmdCompleteCB:2972: Reservation conflict retries 544 for command 0x45ba814b8340 (op: 0x89) to device „naa.624a9370b97601e346f64ba900024d53”
The problem can occur because the ESXi host participating in the cluster loses SCSI reservations for the datastore and cannot always reacquire them automatically after the datastore recovers.
This issue is resolved in this release.
- PR 2710383: If you deploy an ESXi host by using the vSphere Auto Deploy stateful install, ESXi configurations migrated to the ConfigStore database are lost during upgradeIf you deploy an ESXi host by using the Auto Deploy stateful install feature, an option indicating the stateful install boot in the boot.cfg file is not removed and conflicts with the persistent state of the ConfigStore database. As a result, ESXi configurations migrated to the ConfigStore database are lost during upgrade to ESXi 7.x.
This issue is resolved in this release.
- PR 2696435: You cannot use virtual guest tagging (VGT) by default in an SR-IOV environmentWith the i40enu driver in ESXi 7.0 Update 2, you cannot use VGT by default to avoid untrusted SR-IOV virtual functions (VF) to transmit or receive packets tagged with a VLAN ID different from the port VLAN.
You must set all VFs to trusted mode by using the following module parameter:
esxcli system module parameters set -a -m i40enu -p „trust_all_vfs=1,1,1,…This issue is resolved in this release.
Znane problemy:
Networking Issues
- Paravirtual RDMA (PVRDMA) network adapters do not support NSX networking policiesIf you configure an NSX distributed virtual port for use in PVRDMA traffic, the RDMA protocol traffic over the PVRDMA network adapters does not comply with the NSX network policies.
Workaround: Do not configure NSX distributed virtual ports for use in PVRDMA traffic.
- Solarflare x2542 and x2541 network adapters configured in 1x100G port mode achieve throughput of up to 70Gbps in a vSphere environmentvSphere 7.0 Update 2 supports Solarflare x2542 and x2541 network adapters configured in 1x100G port mode. However, you might see a hardware limitation in the devices that causes the actual throughput to be up to some 70Gbps in a vSphere environment.
Workaround: None
- VLAN traffic might fail after a NIC resetA NIC with PCI device ID 8086:1537 might stop to send and receive VLAN tagged packets after a reset, for example, with a command
vsish -e set /net/pNics/vmnic0/reset 1.Workaround: Avoid resetting the NIC. If you already face the issue, use the following commands to restore the VLAN capability, for example at vmnic0:
# esxcli network nic software set --tagging=1 -n vmnic0
# esxcli network nic software set --tagging=0 -n vmnic0 - Any change in the NetQueue balancer settings causes NetQueue to be disabled after an ESXi host rebootAny change in the NetQueue balancer settings by using the command
esxcli/localcli network nic queue loadbalancer set -n <nicname> --<lb_setting>causes NetQueue, which is enabled by default, to be disabled after an ESXi host reboot.Workaround: After a change in the NetQueue balancer settings and host reboot, use the command
configstorecli config current get -c esx -g network -k nicsto retrieve ConfigStore data to verify whether the/esx/network/nics/net_queue/load_balancer/enableis working as expected.After you run the command, you see output similar to:
{
"mac": "02:00:0e:6d:14:3e",
"name": "vmnic1",
"net_queue": {
"load_balancer": {
"dynamic_pool": true,
"enable": true
}
},
"virtual_mac": "00:50:56:5a:21:11"
}If the output is not as expected, for example
"load_balancer": "enable": false", run the following command:
esxcli/localcli network nic queue loadbalancer state set -n <nicname> -e true - Read latency of QLogic 16Gb Fibre Channel adapters supported by the ESXi 7.0 Update 2 qlnativefc driver increases in certain conditionsDue to a regression, you see increased read latency on virtual machines placed on storage devices connected to a QLogic 16Gb Fibre Channel adapter supported by the ESXi 7.0 Update 2 qlnativefc driver. If a VM is encrypted, sequential read latency increases by 8% in your ESXi 7.0 Update 2 environment, compared to the ESXi 7.0 Update 1 environment. If the VM is not encrypted, latency increases by between 15% and 23%.
Workaround: None
- Turn off the Service Location Protocol service in ESXi, slpd, to prevent potential security vulnerabilitiesSome services in ESXi that run on top of the host operating system, including slpd, the CIM object broker, sfcbd, and the related openwsmand service, have proven security vulnerabilities. VMware has addressed all known vulnerabilities in VMSA-2019-0022 and VMSA-2020-0023, and the fixes are part of the vSphere 7.0 Update 2 release. While sfcbd and openwsmand are disabled by default in ESXi, slpd is enabled by default and you must turn it off, if not necessary, to prevent exposure to a future vulnerability after an upgrade.
Workaround: To turn off the slpd service, run the following PowerCLI commands:
$ Get-VMHost | Get-VmHostService | Where-Object {$_.key -eq “slpd”} | Set-VMHostService -policy “off”
$ Get-VMHost | Get-VmHostService | Where-Object {$_.key -eq “slpd”} | Stop-VMHostService -Confirm:$falseAlternatively, you can use the command
chkconfig slpd off && /etc/init.d/slpd stop.The openwsmand service is not on the ESXi services list and you can check the service state by using the following PowerCLI commands:
$esx=(Get-EsxCli -vmhost xx.xx.xx.xx -v2)
$esx.system.process.list.invoke() | where CommandLine -like '*openwsman*' | select commandlineIn the ESXi services list, the sfcbd service appears as sfcbd-watchdog.
For more information, see VMware knowledge base articles 76372 and 1025757.
Miscellaneous Issueshttps://kb.vmware.com/s/article/1025757
- You cannot create snapshots of virtual machines due to an error that a digest operation has failedA rare race condition when an All-Paths-Down (APD) state occurs during the update of the Content Based Read Cache (CBRC) digest file might cause inconsistencies in the digest file. As a result, you cannot create virtual machine snapshots. You see an error such as
An error occurred while saving the snapshot: A digest operation has failedin the backtrace.Workaround: Power cycle the virtual machines to trigger a recompute of the CBRC hashes and clear the inconsistencies in the digest file.
- An ESXi host might fail with a purple diagnostic screen due to a rare race condition in the qedentv driverA rare race condition in the qedentv driver might cause an ESXi host to fail with a purple diagnostic screen. The issue occurs when an Rx complete interrupt arrives just after a General Services Interface (GSI) queue pair (QP) is destroyed, for example during a qedentv driver unload or a system shut down. In such a case, the qedentv driver might access an already freed QP address that leads to a PF exception. The issue might occur in ESXi hosts that are connected to a busy physical switch with heavy unsolicited GSI traffic. In the backtrace, you see messages such as:
cpu4:2107287)0x45389609bcb0:[0x42001d3e6f72]qedrntv_ll2_rx_cb@(qedrntv)#<None>+0x1be stack: 0x45b8f00a7740, 0x1e146d040, 0x432d65738d40, 0x0, 0x
2021-02-11T03:31:53.882Z cpu4:2107287)0x45389609bd50:[0x42001d421d2a]ecore_ll2_rxq_completion@(qedrntv)#<None>+0x2ab stack: 0x432bc20020ed, 0x4c1e74ef0, 0x432bc2002000,
2021-02-11T03:31:53.967Z cpu4:2107287)0x45389609bdf0:[0x42001d1296d0]ecore_int_sp_dpc@(qedentv)#<None>+0x331 stack: 0x0, 0x42001c3bfb6b, 0x76f1e5c0, 0x2000097, 0x14c2002
2021-02-11T03:31:54.039Z cpu4:2107287)0x45389609be60:[0x42001c0db867]IntrCookieBH@vmkernel#nover+0x17c stack: 0x45389609be80, 0x40992f09ba, 0x43007a436690, 0x43007a43669
2021-02-11T03:31:54.116Z cpu4:2107287)0x45389609bef0:[0x42001c0be6b0]BH_Check@vmkernel#nover+0x121 stack: 0x98ba, 0x33e72f6f6e20, 0x0, 0x8000000000000000, 0x430000000001
2021-02-11T03:31:54.187Z cpu4:2107287)0x45389609bf70:[0x42001c28370c]NetPollWorldCallback@vmkernel#nover+0x129 stack: 0x61, 0x42001d0e0000, 0x42001c283770, 0x0, 0x0
2021-02-11T03:31:54.256Z cpu4:2107287)0x45389609bfe0:[0x42001c380bad]CpuSched_StartWorld@vmkernel#nover+0x86 stack: 0x0, 0x42001c0c2b44, 0x0, 0x0, 0x0
2021-02-11T03:31:54.319Z cpu4:2107287)0x45389609c000:[0x42001c0c2b43]Debug_IsInitialized@vmkernel#nover+0xc stack: 0x0, 0x0, 0x0, 0x0, 0x0
2021-02-11T03:31:54.424Z cpu4:2107287)^[[45m^[[33;1mVMware ESXi 7.0.2 [Releasebuild-17435195 x86_64]^[[0m
#PF Exception 14 in world 2107287:vmnic7-pollW IP 0x42001d3e6f72 addr 0x1cWorkaround: None
- If an NVMe device is hot added and hot removed in a short interval, the ESXi host might fail with a purple diagnostic screenIf an NVMe device is hot added and hot removed in a short interval, the NVMe driver might fail to initialize the NVMe controller due to a command timeout. As a result, the driver might access memory that is already freed in a cleanup process. In the backtrace, you see a message such as
WARNING: NVMEDEV: NVMEInitializeController:4045: Failed to get controller identify data, status: Timeout.
Eventually, the ESXi host might fail with a purple diagnostic screen with an error similar to#PF Exception ... in world ...:vmkdevmgr.Workaround: Perform hot-plug operations on a slot only after the previous hot-plug operation on the slot is complete. For example, if you want to run a hot-remove after a hot-add operation, wait until the HBAs are created and LUNs are discovered. For the alternative scenario, hot-add after a hot-remove operation, wait until all the LUNs and HBAs are removed.
Virtual Machines Management Issues
- UEFI HTTP booting of virtual machines on ESXi hosts of version earlier than 7.0 Update 2 failsUEFI HTTP booting of virtual machines is supported only on hosts of version ESXi 7.0 Update 2 and later and VMs with HW version 19 or later.
Workaround: Use UEFI HTTP booting only in virtual machines with HW version 19 or later. Using HW version 19 ensures the virtual machines are placed only on hosts with ESXi version 7.0 Update 2 or later.
- If you change the preferred site in a VMware vSAN Stretched Cluster, some objects might incorrectly appear as compliantIf you change the preferred site in a stretched cluster, some objects might incorrectly appear as compliant, because their policy settings might not automatically change. For example, if you configure a virtual machine to keep data at the preferred site, when you change the preferred site, data might remain on the nonpreferred site.
Workaround: Before you change a preferred site, in Advanced Settings, lower the
ClomMaxCrawlCycleMinutessetting to 15 min to make sure objects policies are updated. After the change, revert theClomMaxCrawlCycleMinutesoption to the earlier value.
Installation, Upgrade and Migration Issues
- UEFI booting of ESXi hosts might stop with an error during an update to ESXi 7.0 Update 2 from an earlier version of ESXi 7.0If you attempt to update your environment to 7.0 Update 2 from an earlier version of ESXi 7.0 by using vSphere Lifecycle Manager patch baselines, UEFI booting of ESXi hosts might stop with an error such as:
Loading /boot.cfg
Failed to load crypto64.efi
Fatal error: 15 (Not found)Workaround: For more information, see VMware knowledge base articles 83063 and 83107 .
- If legacy VIBs are in use on an ESXi host, vSphere Lifecycle Manager cannot extract a desired software specification to seed to a new clusterWith vCenter Server 7.0 Update 2, you can create a new cluster by importing the desired software specification from a single reference host. However, if legacy VIBs are in use on an ESXi host, vSphere Lifecycle Manager cannot extract in the vCenter Server instance where you create the cluster a reference software specification from such a host. In the
/var/log/lifecycle.log, you see messages such as:
020-11-11T06:54:03Z lifecycle: 1000082644: HostSeeding:499 ERROR Extract depot failed: Checksum doesn't match. Calculated 5b404e28e83b1387841bb417da93c8c796ef2497c8af0f79583fd54e789d8826, expected: 0947542e30b794c721e21fb595f1851b247711d0619c55489a6a8cae6675e796 2020-11-11T06:54:04Z lifecycle: 1000082644: imagemanagerctl:366 ERROR Extract depot failed. 2020-11-11T06:54:04Z lifecycle: 1000082644: imagemanagerctl:145 ERROR [VibChecksumError]Workaround: Follow the steps described in VMware knowledge base article 83042.
- You see a short burst of log messages in the syslog.log after every ESXi bootAfter updating to ESXi 7.0 Update 2, you might see a short burst of log messages after every ESXi boot.
Such logs do not indicate any issue with ESXi and you can ignore these messages. For example:
2021-01-19T22:44:22Z watchdog-vaai-nasd: '/usr/lib/vmware/nfs/bin/vaai-nasd -f' exited after 0 seconds (quick failure 127) 1
2021-01-19T22:44:22Z watchdog-vaai-nasd: Executing '/usr/lib/vmware/nfs/bin/vaai-nasd -f'
2021-01-19T22:44:22.990Z aainasd[1000051135]: Log for VAAI-NAS Daemon for NFS version=1.0 build=build-00000 option=DEBUG
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoadFile: No entries loaded by dictionary.
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file "/usr/lib/vmware/config": No such file or directory.
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file "//.vmware/config": No such file or directory.
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file "//.vmware/preferences": No such file or directory.
2021-01-19T22:44:22.990Z vaainasd[1000051135]: Switching to VMware syslog extensions
2021-01-19T22:44:22.992Z vaainasd[1000051135]: Loading VAAI-NAS plugin(s).
2021-01-19T22:44:22.992Z vaainasd[1000051135]: DISKLIB-PLUGIN : Not loading plugin /usr/lib/vmware/nas_plugins/lib64: Not a shared library.Workaround: None
- You see warning messages for missing VIBs in vSphere Quick Boot compatibility check reportsAfter you upgrade to ESXi 7.0 Update 2, if you check vSphere Quick Boot compatibility of your environment by using the
/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.pycommand, you might see some warning messages for missing VIBs in the shell. For example:
Cannot find VIB(s) ... in the given VIB collection.
Ignoring missing reserved VIB(s) ..., they are removed from reserved VIB IDs.
Such warnings do not indicate a compatibility issue.Workaround: The missing VIB messages can be safely ignored and do not affect the reporting of vSphere Quick Boot compatibility. The final output line of the
loadESXCheckCompatcommand unambiguously indicates if the host is compatible. - Auto bootstrapping a cluster that you manage with a vSphere Lifecycle Manager image fails with an errorIf you attempt auto bootstrapping a cluster that you manage with a vSphere Lifecycle Manager image to perform a stateful install and overwrite the VMFS partitions, the operation fails with an error. In the support bundle, you see messages such as:
2021-02-11T19:37:43Z Host Profiles[265671 opID=MainThread]: ERROR: EngineModule::ApplyHostConfig. Exception: [Errno 30] Read-only file systemWorkaround: Follow vendor guidance to clean the VMFS partition in the target host and retry the operation. Alternatively, use an empty disk. For more information on the disk-partitioning utility on ESXi, see VMware knowledge base article 1036609.
Notatki producenta-KLIK
Pozdrawiamy,
Zespół B&B
Bezpieczeństwo w biznesie
