MTU 9000 vs 9216

On the host side, you should always use an MTU of 9000 for jumbo frames and not try to match the 9216 value you're seeing on your switch. On the other hand, you see 9216 on a network switch because it's allowing overhead of different encapsulations.

ESXi NIC driver update procedure - esxcli

List NIC adapters ...

esxcli network nic list

[root@esx21:~] esxcli network nic list

Name    PCI Device    Driver  Admin Status  Link Status  Speed  Duplex  MAC Address         MTU  Description

------  ------------  ------  ------------  -----------  -----  ------  -----------------  ----  -------------------------------------------------------

vmnic0  0000:01:00.0  ntg3    Up            Up            1000  Full    90:b1:1c:13:fc:14  9000  Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet

vmnic1  0000:01:00.1  ntg3    Up            Up            1000  Full    90:b1:1c:13:fc:15  9000  Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet

vmnic2  0000:02:00.0  ntg3    Up            Down             0  Half    90:b1:1c:13:fc:16  1500  Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet

vmnic3  0000:02:00.1  ntg3    Up            Down             0  Half    90:b1:1c:13:fc:17  1500  Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet

List of drivers

esxcli software vib list | grep ntg3

[root@esx21:~] esxcli software vib list | grep ntg3

ntg3                           4.1.3.2-1vmw.670.1.28.10302608        VMW     VMwareCertified   2018-12-15

Driver details

vmkload_mod -s ntg3

[root@esx21:~] vmkload_mod -s ntg3

vmkload_mod module information

 input file: /usr/lib/vmware/vmkmod/ntg3

 Version: 4.1.3.2-1vmw.670.1.28.10302608

 Build Type: release

 License: BSD

 Required name-spaces:

  com.vmware.vmkapi#v2_5_0_0

 Parameters:

  initRingSzRxJmb: ushort

    RX Jumbo Ring Size

  initRingSzRxStd: ushort

    RX Standard Ring Size

  intrMode: ushort

    Interrupt mode: 0=IntX, 1=MSI(Default)

Update driver version

esxcli software vib update -d. file.vib

Reboot server

vCenter http request rate

PR: https://bugzilla.eng.vmware.com/show_bug.cgi?id=2088939

Resil jsem dneska limitaci vCentra pro spousteni API (ansible/powercli) prikazu. Reseni je relativne jednoduche - navysit v souboru: /etc/vmware-vapi/endpoint.properties hodnotu http.request.rate.count=360 na treba 1000 a restartovat  vmware-vapi-endpoint sluzbu

Number of vCenter API requests
Pocet API volani do vCentra

vLCM versus VxRAIL

Q: with the introduction of vLCM with readynodes, what would the value out of selling VxRail ?

A: Though vLCM provides firmware support, it doesn’t provide pre-validated and pre-integrated bundles, which VxRail does. Our customers have told us that this is a big pain point. VxRail images are getting customer from one valid image/driver/firmware state to another valid state.

VxRail provides other value such as enhanced phone home support and additional automation such as auto-buildout of clusters.

vSAN/DRS awareness to be introduced in vSAN/vSphere 7.0! (NOT RELEASE in 7.0)

Originally piblished here ... 

http://www.yellow-bricks.com/2020/03/19/vsan-drs-awareness-to-be-introduced-in-vsan-vsphere-7-0/

It was briefly mentioned here, but I figured I would elaborate on this new cool feature for vSAN Stretched Clusters which is DRS Awareness of vSAN Stretched Clusters. So what does this mean? Well, it is fairly straight forward. DRS will take vSAN resync traffic into consideration when the DRS algorithm runs. I can probably explain best by talking through a scenario:

• vSAN Stretched Cluster environment with 4 hosts and a witness
• VMs running in Preferred and in Secondary
• VMs configured with "should rules" to stay within their fault domain
• ISL between "data locations" is impacted
• HA has restarted the VMs of the secondary site in the preferred site
• ISL is now restored

What would happen without DRS awareness of vSAN stretched clusters is that DRS would automatically migrate VMs back to the Secondary site as soon as it becomes available. DRS runs every minute in vSphere 7.0 so it is very likely that vSAN is still resyncing data. The problem with this is two-fold:

1. The vMotion process will slow down the resync of data temporarily
2. Blocks which have not been resynced and are being read by the VM will need to be fetched from the remote location

As you can imagine this is an undesired situation. As such in vSphere / vSAN 7.0 a whole new level of integration is introduced between DRS and vSAN. Now DRS will be aware of what is happening on the vSAN layer. If vSAN is syncing a particular component of a virtual machine, then DRS will not move the VM back! It will wait until the resync has completed and then move the VM back. This ensures that the migration won't conflict with the resync, and of course that when the VM is migrated that it will have "site read locality".

It is a feature our team had been asking for and which was tested within VMware Cloud on AWS, and I am happy to see it made it into the "regular" vSphere release.

vSphere Support for Intel Optane Persistent Memory

VMware and Intel are working closely to develop the market and use-cases for Intel’s Optane Persistent Memory (PMEM).

This technology is available in two modes: 

• App-direct mode (AD in short, also known as Persistent Memory): vSphere 6.7 U3 enables Intel®Optane™ DC Persistent Memory in “App-Direct” mode. You can take advantage of the large capacity, affordability and persistence benefits offered in this mode and deploy in production any supported 3rd party application without any restriction with full VMware support. VMware encourages its customers to leverage this technology in “App-Direct” mode. For more information on the App-Direct mode performance benefits in virtualization environment, please refer to PMEM App-Direct WP.
• Memory-Mode (MM): vSphere 6.7 Update 3 enable Intel® Optane™ DC Persistent Memory in“Memory” mode. vSphere usage of Intel® Optane™ DC Persistent Memory in “Memory mode”can offer increased memory capacity and TCO improvements for relevant workloads. Initially, VMware will support “Memory” mode for appropriate use-cases in production deployments (refer toPMEM memory-mode WP); such a deployment should go through RPQ process to secure VMware support.

Specific vSphere and VSAN support statement for this technology is available in this KB articlevSphere Support for Intel's Optane DC Persistent Memory (PMEM) (67645). Please note the recommended version to use is vSphere is 6.7u3.

If customers are using this technology in App-Direct Mode, there is no explicit approval needed. VMware support this technology on certified hardware. You can find the list of certified hardwarehere.

If customers are using this technology in Memory-Mode, customer need to procure an RPQ approval from VMware. 

• It is important to highlight that VMware is supporting the Intel Optane Persistent Memory in memory mode and committed to develop the use-cases and market in close collaboration with Intel
• As this technology is new and runs at slower speed than DDR memory, we want to educate the market and develop the right use-cases and expectation. Due to this reason, VMware wants to work closely with early customers and help them succeed
• To address the above requirement, VMware is leveraging the existing RPQ process for early customers, VMware representative need to file the RPQ for interested customers. VMware request specific information from the customer environment. You can find the detailed information about filing the customer RPQ for Intel Optane Persistent Memory-mode here
• It is important to note that RPQ process is only for early customers. Once we develop the early success stories and use-case, VMware has all the intent to remove the RPQ requirements and make this technology as generally supported. 

Please note, VMware is committed to support Intel Optane Persistent Memory in both modes “App-Direct” and “Memory-mode”. If you have any question, please feel free to reach out to @Sudhanshu Jain

Sudhanshu (Suds) Jain

Product Management – Cloud Infrastructure

3401 Hillview Avenue, Palo Alto, CA 94304

Office: 650.427.7672 | Mobile: 408.393.7668

MobaXterm Xserver with SSH, telnet, RDP, VNC and X11 - Features

https://mobaxterm.mobatek.net/features.html