WilliamLam.com

Intel NUC with 512GB memory

by // 11 Comments

Yes, you read that correctly. 512 gigabytes of memory on an Intel NUC. Not only is this pretty ? but this is actually possible today with an already released Intel NUC!

A few months back, I was made aware of some really cool technology from Intel called Intel Memory Drive Technology (IMDT) which leverages Intel Optane SSDs to extend memory of a system beyond its physical memory (DRAM) capacity. This technology is made possible with their IMDT software, which is a purpose built Hypervisor whose sole purpose is to just manage memory and this Hypervisor runs on top of the Intel Optane SSD. You can think of this like a Software-Defined Memory (SDM) solution. In fact, SDM was actually coined in this performance white paper evaluating IMDT with scientific-based applications back in 2018.

Note: This should not be confused with Intel Optane and its Datacenter Persistent Memory (PMEM) solution which vSphere already supports today.

The target use case for this type of technology is for memory intensive applications such as SAP HANA, Oracle, Redis, Memcache and Apache Spark to just name a few. These workloads can easily gobble up 10's of terabytes of memory that can bring a number of challenges when needing to scale up these solutions. High capacity memory DIMMS are not only expensive, but once you exhaust the number of physical DIMM slots, your only option for scale up is to add additional servers which is very costly.

Using IMDT, customers can expand their physical DRAM capacity from 8x to 15x, which can significantly improve cost, performance but also the operational overhead in managing  additional systems. Putting aside the in-memory based workloads, I think there is also huge potential for general purpose workloads that can also get the exact same benefits, especially when you think about constraints like power, cooling and location such as Edge or ROBO locations. Since this solution works on an Intel NUC, a really interesting use case for this technology that immediately came to mind was for a vSphere/NSX/vSAN homelab environment.

[Read more...]

Quick Tip - Easily identify source DHCP server using ESXi DCUI

by // 1 Comment

While installing the ESXi 7.0 Update 1 on one of my physical system, I happened to be in the "Configure Management Network" section of the ESXi Direct Console UI (DCUI) and noticed something I had never seen before. As shown in the screenshot, it now shows the IP Address of the DHCP server in which ESXi received the DHCP lease.


I had not noticed this before and after asking on Twitter, it looks like this is definitely a new enhancement that was added fairly recently. I did not see this in one of my ESXi 6.7 Update 3 deployments, but it may have came in a later patch but definitely new in ESXi 7.0 or greater. Not only is this a quick and easy way to identify the DHCP server being used but in case you need to track down an unexpected rogue DHCP server running, this will certainly come in handy as pointed out by John.

USB Network Native Driver now supports ESXi 7.0 Update 1

by // 8 Comments

I know many of you have been asking about this and today I am happy to share that the USB Network Native Driver for ESXi Fling is now supported with ESXi hosts running the latest 7.0 Update 1 release.

Note: The USB Network Native Driver is only supported with x86 ESXi and NOT with the ESXi-Arm Fling, there seems to be some confusion since these are two different CPU architectures.

In addition, there are a couple of minor enhancements (see changelog for details), but one feature that I am super excited to see incorporated into this version of the Fling is the automatic persistency of USB NIC binding, which maps physical USB NICs to either a Standard or Distributed Virtual Switch. Previously, this required users to update the local.sh script on ESXi to automatically restore the NIC bindings since the processing of these interfaces happens much later in the boot up process. These tweaks are no longer required when using this version of the Fling!

This enhancement was the direct result from Andrei Warkentin and his work on the ESXi-Arm Fling with the Raspberry Pi! Huge thanks to him for this contribution and hopefully we can repay that back one day with the integration of the USB Network Native Driver into the ESXi-Arm Fling ?