Balanced Memory Configuration for ESXi Servers

Background

ESXi servers are fundamental infrastructure. The underly hardware performance has a butterfly effect on the upper layer virtual machines and applications. Since there is less than 10% performance overhead on the virtualization layer. So it’s valuable to get full performance on the hardware layer. Memory is a big player in hardware performance tuning. Balanced memory configuration is very important. I wrote an article “LRDIMM or RDIMM on ESXi hosts?” a long time ago. It was the understanding in 2016. I did some research recently. I hope the following study help with your hardware decisions. This study is based on Intel Xeon 2nd Generation Scalable Processors.

1. Basic Concepts

Before we talk about balanced memory and optimized memory. Let’s take a look at some basic concepts which will be used in the article.

1.1 Memory Channel

The memory channels control reading and writing bandwidth operations between the CPU and memory modules. Think about it like the lanes on a highway connect CPU and memory. There are 6 memory channels on Intel Xeon 2nd generation Scalable processors. This is different from Intel Xeon E7. E7 only has 4 memory channels. If you are an E7 user and transform to Scalable. You should notice that the balanced memory size on E7 doesn’t balance on Scalable processors.

1.2 DIMM

The full name of DIMM is Dual In-line Memory Module. It’s the small chip-set mounted on a printed circuit board. There are multiple DIMMs on the board. We usually call the whole stuff DIMM in life. DIMM should be installed on the DIMM slot on the server’s motherboard. Each memory channel has two DIMM slots for Intel Xeon 2nd Generation Scalable Processors.

1.3 DIMM Type

The major two types are RDIMM and LRDIMM. The main difference between the two types is that LRDIMM has a buffer in the DIMM. That means LRDIMM is slower than DIMM. LRDMM supports a larger size per DIMM. Such as 128 GB, or higher. RDIMM usually is 16 GB, 32 GB, or 64 GB.

1.4 Rank

It’s one set of memory chips that are accessed while writing to or reading from the memory. Small DIMM size needs maybe only a single rank. Larger DIMM size needs more ranks. Refer to this article to learn more about rank. Dual-rank is better performance than quad-rank according to hardware vendors.

1.5 Interleave

Memory interleaving allows a CPU to efficiently spread memory accesses across multiple DIMMs. All DIMMs should be in one interleaved set creating a single uniform memory region that is spread across as many DIMMs as possible. If there are different types of DIMM or size of DIMM, the memory subsystem interleaves multiple times to access data.

2. Balanced Memory

Memory balance refers to memory population rules on physical servers. There are 6 memory channels on an Intel Xeon 2nd Generation Scalable Processors. Each channel handles two DIMM slots. Enterprise users usually use dual processors for ESXi servers. So there are 24 DIMM slots totally in the server. Each processor handles 12 DIMM slots. The DIMM population should be in pairs and even numbers. For example. You have 12 DIMMs. 6 of 12 should be assigned to the first processor and the other 6 are assigned to the second processor’s DIMM slots. And the 6 DIMMs should be populated on the same slot on each processor. This is called a “balanced memory” population. The memory balance is also related to the NUMA balance for ESXi. The imbalanced memory population causes imbalanced NUMA nodes. This is very important in virtualization performance tuning.

DIMM size and type in the population also impact to memory balance. The DIMM type and size on both processors should be the same. Some customers may want to upgrade existing balanced memory to a higher capacity. The suggestion is to use the same type and size of DIMMs for the upgrading.

3. Memory Optimize

Balanced memory is easy. Hardware vendor’s pre-sales usually give a balanced memory configuration. But the trick is the balance doesn’t means optimized. Balanced but non-optimized server’s performance can be only 35% of the balanced and optimized servers according to Lenovo.

Fully populate the DIMM slots is the first rule. Each interleaving grabs data from all DIMM slots. Think about it like 24 lanes highway again. You can load more goods if you dispatch 24 trucks at the same time. One benefit of virtualization is hardware consolidation. We usually see high memory utilization on ESXi. So this is an important point to optimize ESXi performance.

Use the same type and size of DIMM. Do not mix different types or sizes of DIMM in the server. Since different types or size of DIMM means multiple interleaves. Use the same example. The trucks can only load one type of goods each time. If there are two types of goods. The trucks have to go twice even it’s half loaded.

Rank is another weight impact on performance. Dual-rank DIMM is the best performance. Quad-rank usually in big size DIMM. The performance is lower than dual-rank.

Different DIMM type also impacts performance. RDIMM is a better performance than LRDIMM. The reason because LRDIMM has a cache on DIMM to handle data I/O between processor and memory. It slows down the I/O.

The other things impact to ESXi performance are BIOS settings and power settings. These are out of scope of this post. Basically you need to set to high performance for BIOS and power to achieve best memory performance.

4. Reference

Lenovo: Balanced Memory Configurations with Second-Generation Intel Xeon Scalable Processors

Dell: How to Balance Memory on 2nd Generation Intel® Xeon™ Scalable Processors
Dell: Balanced Memory is Best: 2nd Generation AMD EPYC Processors for PowerEdge Servers

Cisco: Intel Xeon Scalable 2nd Generation Processor Recommendations for Cisco UCS M5 Servers (Login required)

HPE: Server Memory and Persistent Memory Population Rules for HPE Gen10 Servers With Intel Xeon Scalable Processors

VMware: A Performance Comparison of Hypervisors

MAC Address Conflict with ESXi vmkernel NIC on Cisco UCS Blades

Background

I worked on a interesting case few month back. A ESXi blade was not able to bring up due to management IP address didn’t responding to ping. We tried to reconfigure IP address, re-acknowledge blade, rebuild the network, and even replaced the motherboard. It was no lucky. Eventually we figured it out that another ESXi host’s management network somehow configured same MAC address. It caused the MAC address conflict on network.

This guide will show you some tips of how to troubleshooting MAC address conflicts on ESXi and Cisco UCS level.

Some Reference

The first article you should read is “vmk0 management network MAC address is not updated when NIC card is replaced or vmkernel has duplicate MAC address”. It helps you understand why vmkernel MAC address is not updated. The solution in the KB is change MAC address manually on ESXi. Or re-create management network.

But the reality is we usually don’t know where the conflict comes from. We only know this Cisco UCS blade installed ESXi and it doesn’t responding to ping. So you may suspect it’s a hardware issue like me.

Check MAC address conflicts on Cisco UCS

There are some ways to check MAC address conflicts on Cisco UCS.

  • Login to UCS Manager by SSH and check MAC address status.
  • Export UCS Manager log and check MAC address conflicts in fwm_trace_log file.
# Login to UCS Manager
# Run following command to show mac address status.
show platform fwm info mac <mac address> <vlan id>

# Sample
show platform fwm info mac 0025.0050.11.11 141

Login to UCS Manager GUI to generate support log.

Admins -> AllFaults, Events and Audit -> Log -> TechSupport Files

Generate a ucsm log bundle. Download and extract it. There are two major files in the log bundle: UCSM_A_TechSupport.tar.gz and UCSM_B_TechSupport.tar.gz. The files correspond to their respective Fabric Interconnect.

MAC address conflicts usually occurred on one Fabric Interconnect. So you may need to check both of them. I use A side as sample. Go to extract folder -> UCSM_A_TechSupport -> sw_trace_logs -> fwm_trace_log.current

Search keyword “REGMAC seen on border port” in the log. You need to repeat same in the log of the other FI. If you can find the entries and time is recently. Then it indicate there is conflict on the MAC address outside the UCS domain.

There maybe other reasons can cause mac address issue. I wrote in Error: No NIC found with MAC address…

Convert Virtual Machine of VirtualBox to ESXi

My coworker want to build a virtual machine on ESXi, but vendor only support virtual appliance of Oracle VirtualBox format. VMware has a KB article to show how to “Importing Virtual Machine from Oracle VirtualBox to VMware Fusion, Workstation, or Player (2053864)“. It’s working fine. But it’s not applicable for VMware ESXi.

If you follow the guide to export .ova file and import to ESXi. It will show error below on ESXi 6.0 or later:

Issues detected with selected template. Details….No supported hardware versions among….

After couple of hours’ deep dive. I figured out a way to convert VirtualBox to ESXi. You need Oracle VirtualBox, VMware Workstation or VMware Player and VMware ESXi host.

  1. Select the virtual machine -> Go to main menu -> File -> Export appliance.
  2. Choose the virtual machine.
  3. Make sure Format is “Open virtualization format 1.0“.
  4. Export to a .ova file.
  5. Open the .ova file in VMware Workstation or VMware Player.
  6. The import of the VM maybe failed with following error. Just click Retry button it will work.
    The import failed because xxxxx did not pass OVF specification conformance or virtual hardware compliance checks.
  7. Select the virtual machine and go to main menu -> File -> Export to OVF.
  8. VMware Workstation or VMware Player generates .ovf, .mf and .vmdk files.
  9. Edit .ovf file and find the line with keyword “VirtualSystemType“.
  10. Change the value “vmx-XX” to the version lower or equal to your ESXi version.
  11. Edit .mf file and remove SHA256 value of .ovf file in first line.
    SHA256(XXXXX.ovf)= xxxxxxxxxxxxxxxxx
  12. Now it’s ready to import to VMware ESXi host.

Conclusion

This procedure is not involve any code or command. There are also couple of other ways to convert VirtualBox to ESXi by ovftool command line. I tried several ways but didn’t work. Maybe I did something wrong.

In step 10, I changed VM version in .ovf file directly. I think you can also leverage VMware Workstation or VMware Player to downgrade the virtual machine’s version in GUI. It should work as long as the version is lower than your ESXi supported VM version.

Private IP Address Routes to L3 Subnet on Dual vNIC VM

It’s not easy for me to describe the issue in one line on the title. Let me give some background here. I have 2 set of VMs. Set 1 has VM A & VM B. Set 2 has VM C & VM D. Each VM has a vNIC configured with a private IP address. VM A and VM C also have another vNIC configured with an L3 (Routable) IP address. Each set’s private IP addresses are the same. To make sure no confusion I implemented a vRouter VM for each set. The vRouter is same as VM A or VM C, it has two vNICs. One is connected to L3 network, another is connected to the private network. This way can keep the private network traffic not going outside of the set. So the both set no disturb each other when I set same private IP addresses.

Diagram

Following are IP addresses I set for each VM:

  • VM A: 192.168.0.11
  • VM B: 192.168.0.12
  • VM C: 192.168.0.11
  • VM D: 192.168.0.12

The problem is I still can get ping responding on VM A to 192.168.0.12 when I turn off VM B. I expected to see the L2 traffic goes to it own vRouter and finds VM B is offline. But tracert command shows me the traffic goes from VM A’s L3 network to vRouter of the 2nd set, and then get the answer from VM D. Looks like the L2 ping package is broadcasting on L3 network.

The issue was fixed by enabling a feature on L3 network. It called “Enforce Subnet Check for IP Learning“. Cisco changed the name to “Limit IP Learning To Subnet“. It’s a VLAN level setting. It will not allow broadcasting the private Ip traffic on an L3 network. It forces private IP traffic to go to L2 network only.

Emulex OneConnect OCe10102 on ESXi 6.0

Please refer to following post for basic troubleshooting of Emulex OneConnect.

How to Install Proper Drivers for 3rd Party Network Adapter on ESXi 5.x

I have a box uses Emulex OneConnect OCe10102 network adapters. The adapter is quite old and Emulex brand card doesn’t support ESXi 6.0. I upgraded the server to ESXi 6.0 and the Emulex adapters lost.

In the initial troubleshooting, I noticed that the adapters are still visible in BIOS. So it should be some driver level issues. I checked VMware Compatibility Guide. The model OCe10102 doesn’t support by ESXi 6.0.

If you run the following command you will still be able to see the adapters in PCI list on ESXi.

[code language="perl"]
esxcli hardware pci list
[/code]

So it indicates the adapters are not visible in ESXi since the newer Emulex driver doesn’t contain the model of the adapter in ESXi 6.0 native driver.

Then I uninstalled the native Emulex driver for ESXi 6.0 by the following command and rebooted the ESXi host.

[code language="perl"]
esxcli software vib remove -n elxnet
[/code]

The adapters still not visible after rebooting since no any drivers for Emulex adapters. Then I downloaded the Emulex drivers for ESXi 5.5 on VMware website and uploaded the “offline” package in the zip file to /tmp directory of the host. Then installed the driver by the following command:

[code language="perl"]
esxcli software vib install -d "/tmp/xxxxx.zip"
[/code]

The adapters appeared after rebooting the host.

Troubleshooting Network Performance of Virtual Machine

There are several layers of networking on the virtualization infrastructure. Guest operating system, Virtual Machine, ESXi driver, physical network adapters, RJ45/SFP and network switches…etc. Sometimes it’s hard to say where exactly caused a problem. Especially hardware layer problems. Today I worked on a very interesting case, it may give some ideas to troubleshooting network performance issue which is caused by hardware layers.

A user told me he was bothered by network performance of a virtual machine. It’s slow to copy data to NFS share. But responding to “ping” command looked good. I didn’t see any issue on virtual machine layer. VMware Tools was up to date, Windows OS was patched, virtual network adapter type was VMXNET3 and VM version was also up to date.

When I tried to copy an image file to share folder of the virtual machine, I did see sometimes speed was fast, but sometimes not. Since I have two physical uplinks, it led me to guess it could be one of the uplinks.

After a lot of swapping and cable changing, we eventually figured out there was a bad SFP on network switch end. I was able to observe the issue by using “psping.exe” of Microsoft Sysinternals. I used the following command to send the different size of ping package to the virtual machine. Network drops were increasing when I increased package size.

psping.exe -l <size of package> <Destination>
Example: psping.exe -l 4k xxxx.contoso.com

The size could be 1k, 2m or even larger. I think this is a good way to identify problem outside of ESXi. Especially SFP problem as such kind of problem didn’t give any CRC or error count on network switch level.

You can also use Windows native command “ping.exe” as following. The size unit is “bytes”. For example, you need to input 4096 if you want to send 4kb.

ping.exe -l <size> <Destination>
Example: ping.exe -l 4096 xxx.contoso.com

 

 

Cannot Complete File Creation Operation When Storage vMotion

Just quick notes. I saw following error  when do storage vMotion.

Cannot Complete File Creation Operation.

When check /var/log/hostd.log. I saw following errors:

2017-11-28T02:51:04.476Z info hostd[76A80B70] [Originator@6876 sub=Vimsvc.TaskManager opID=459515D4-000040D6-2d-cf-d4-7817 user=vpxuser:contosotestuser] Task Created : haTask--vim.host.OperationCleanup
2017-11-28T02:51:04.476Z info hostd[772C2B70] [Originator@6876 sub=Libs opID=459515D4-000040D6-2d-cf-d4-7817 user=vpxuser:contosotestuser] CopyFromEntry: Hostlog_Dump: Hostlog /vmfs/volumes/598700ee-ec
2017-11-28T02:51:04.476Z info hostd[772C2B70] [Originator@6876 sub=Libs opID=459515D4-000040D6-2d-cf-d4-7817 user=vpxuser:contosotestuser] UUID: 28dbb1b5-a9d8-e311-1061-03300000002d
2017-11-28T02:51:04.476Z info hostd[772C2B70] [Originator@6876 sub=Libs opID=459515D4-000040D6-2d-cf-d4-7817 user=vpxuser:contosotestuser] MigID: 1511837464286041
2017-11-28T02:51:04.476Z info hostd[772C2B70] [Originator@6876 sub=Libs opID=459515D4-000040D6-2d-cf-d4-7817 user=vpxuser:contosotestuser] HLState: none
2017-11-28T02:51:04.476Z info hostd[772C2B70] [Originator@6876 sub=Libs opID=459515D4-000040D6-2d-cf-d4-7817 user=vpxuser:contosotestuser] ToFrom: none
2017-11-28T02:51:04.476Z info hostd[772C2B70] [Originator@6876 sub=Libs opID=459515D4-000040D6-2d-cf-d4-7817 user=vpxuser:contosotestuser] MigType: invalid
2017-11-28T02:51:04.476Z info hostd[772C2B70] [Originator@6876 sub=Libs opID=459515D4-000040D6-2d-cf-d4-7817 user=vpxuser:contosotestuser] OpType: nfc
2017-11-28T02:51:04.476Z info hostd[772C2B70] [Originator@6876 sub=Libs opID=459515D4-000040D6-2d-cf-d4-7817 user=vpxuser:contosotestuser] WorldID: 0
2017-11-28T02:51:04.478Z warning hostd[772C2B70] [Originator@6876 sub=Libs opID=459515D4-000040D6-2d-cf-d4-7817 user=vpxuser:contosotestuser] Hostlog_Flush: Failed to open hostlog /vmfs/volumes/598700e
2017-11-28T02:51:04.478Z warning hostd[772C2B70] [Originator@6876 sub=Vcsvc.OCM opID=459515D4-000040D6-2d-cf-d4-7817 user=vpxuser:contosotestuser] PersistToDisk: failed to persist entry /vmfs/volumes/5
2017-11-28T02:51:04.478Z info hostd[772C2B70] [Originator@6876 sub=Default opID=459515D4-000040D6-2d-cf-d4-7817 user=vpxuser:contosotestuser] AdapterServer caught exception: vim.fault.CannotCreateFile
2017-11-28T02:51:04.478Z info hostd[772C2B70] [Originator@6876 sub=Vimsvc.TaskManager opID=459515D4-000040D6-2d-cf-d4-7817 user=vpxuser:contosotestuser] Task Completed : haTask--vim.host.OperationClean
2017-11-28T02:51:04.478Z info hostd[772C2B70] [Originator@6876 sub=Solo.Vmomi opID=459515D4-000040D6-2d-cf-d4-7817 user=vpxuser:contosotestuser] Activation [N5Vmomi10ActivationE:0x75395c80] : Invoke do
2017-11-28T02:51:04.478Z verbose hostd[772C2B70] [Originator@6876 sub=Solo.Vmomi opID=459515D4-000040D6-2d-cf-d4-7817 user=vpxuser:contosotestuser] Arg entry:
--> (vim.host.OperationCleanupManager.OperationEntry) {
--> hlogFile = "/vmfs/volumes/598700ee-ec0f9918-5b56-000000000000/XXX-VM-01/XXX-VM-01-375f29ae.hlog",
--> opId = 1511837464286041,
--> opState = "running",
--> opActivity = "nfc",
--> curHostUuid = "28dbb1b5-a9d8-e311-1061-03300000002d",
--> }
2017-11-28T02:51:04.478Z info hostd[772C2B70] [Originator@6876 sub=Solo.Vmomi opID=459515D4-000040D6-2d-cf-d4-7817 user=vpxuser:contosotestuser] Throw vim.fault.CannotCreateFile
2017-11-28T02:51:04.478Z info hostd[772C2B70] [Originator@6876 sub=Solo.Vmomi opID=459515D4-000040D6-2d-cf-d4-7817 user=vpxuser:contosotestuser] Result:
--> (vim.fault.CannotCreateFile) {
--> faultCause = (vmodl.MethodFault) null,
--> file = "/vmfs/volumes/598700ee-ec0f9918-5b56-000000000000/XXX-VM-01/XXX-VM-01-375f29ae.hlog",
--> msg = ""
--> }

It indicates there is a file cannot be created during migration. Further check on VM configuration file (.vmx) I noticed following parameter existing but the file doesn’t existing.

migrate.hostlog = "XXX-VM-01-375f29ae.hlog"

You cannot create the file directly. Workaround is create a .hlog file with other name then rename it to the same name.

BTW, there is a bug on ESXi 6.0 U1 for similar issue, but I saw this problem  on  U2. Just for your reference below.

Storage migration of a virtual machine with a name beginning with core fails with the error: Relocate virtual machine coreXX Cannot complete the operation because the file or folder coreXX-XXXXX.hlog already exists

Network Problems of Auto Deployed ESXi Host in LAB

I built a simple Auto Deploy environment by vSphere 6.5 on nested environment. I created virtual ESXi hosts on a physical ESXi host to do the testing. The whole configuration was smoothly, I’m impressed Auto Deploy can be implemented in few hours. One thing bothered me was networking.

New ESXi hosts cannot get IP addresses properly somehow. It’s not a single problem. The symptoms are ESXi hosts cannot get IP address, or the Configure Management Network was grayed out on console, or ESXi hosts can get IP address but no responding to ping. Just quick post my solutions here.

To fix all these problems you need to do following:

  1. Enable Promiscuous Mode on the vSwtich which is attached to nested ESXi hosts on physical ESXi hosts.
  2. (I did that on Web Client of vCenter 6.5 U1. You may see different procedure on earlier versions.) Edit the host profile of Auto DeployNetworking configurationHost port group — Highlight Management Network — The option Determine how MAC address for vmknic should be decided — Choose Use the MAC Address from which the system was PXE booted.

If you don’t do step 1, your nested ESXi hosts may not able to get DHCP IP addresses properly, or it can get IP addresses but maps to a new MAC address lead to network packages cannot be transmitted.

Nested ESXi hosts get a DHCP IP addresses when do PXE booting. The hosts get another new IP addresses when apply host profile as soon as management network is created. It could be two different IP addresses and the MAC address of management network could be a new one that not same to any of vmnics. It will be hard to trace back on network switch in real environment, so I think it’s better also to do step 2.

Update 10/25/2017 — You should choose “User must explicitly choose the policy option” in step 2 above if you have multiple NICs. The reason is DHCP IP address during PXE may be captured by random NICs. If you choose what I mentioned in step 2, you will see DHCP server may learns MAC address of a none management network NICs associated with management IP address. Please refer this article for more detail.