Apple – Page 17

Home Labs made easier with VSAN 6.0 + USB Disks

03.04.2015 by William Lam // 23 Comments

VSAN 6.0 includes a large number of new enhancements and capabilities that I am sure many of you are excited to try out in your lab. One of the challenges with running VSAN in a home lab environment (non-Nested ESXi) is trying to find a platform that is both functional and cost effective. Some of the most popular platforms that I have seen customers use for running VSAN in their home labs are the Intel NUC and the Apple Mac Mini. Putting aside the memory constraints in these platforms, the number of internal disk slots for a disk drive is usually limited to two. This would give you just enough to meet the minimal requirement for VSAN by having at least a single SSD and MD.

If you wanted to scale up and add additional drives for either capacity purposes or testing out a new configurations, you are pretty much out of luck, right? Well, not necessary. During the development of VSAN 6.0, I came across a cool little nugget from one of the VSAN Engineers where USB-based disks could be claimed by VSAN which could be quite helpful for testing in a lab environment, especially using the hardware platforms that I mentioned earlier.

For a VSAN home lab, using cheap consumer USB-based disks which you can purchase several TB's for less than a hundred dollars or so and along with USB 3.0 connectivity is a pretty cost effective way to enhance hardware platforms like the Apple Mac Mini and Intel NUCs.

Disclaimer: This is not officially supported by VMware and should not be used in Production or evaluation of VSAN, especially when it comes to performance or expected behavior as this is now how the product works. Please use supported hardware found on the VMware VSAN HCL for official testing or evaluations.

Below are the instructions on how to enable USB-based disks to be claimable by VSAN.

Step 1 - Disable the USB Arbitrator service so that USB devices can been seen by the ESXi host by running the following two commands in the ESXi Shell:

/etc/init.d/usbarbitrator stop
chkconfig usbarbitrator off

Step 2 - Enable the following ESXi Advanced Setting (/VSAN/AllowUsbDisks) to allow USB disks to be claimed by VSAN by running the following command in the ESXi Shell:

esxcli system settings advanced set -o /VSAN/AllowUsbDisks -i 1

Step 3 - Connect your USB-based disks to your ESXi host (this can actually be done prior) and you can verify that they are seen by running the following command in the ESXi Shell:

vdq -q

Step 4 - If you are bootstrapping vCenter Server onto the VSAN Datastore, then you can create a VSAN Cluster by running "esxcli vsan cluster new" and then contribute the storage by adding the SSD device and the respective USB-based disks using the information from the previous step in the ESXi Shell:

esxcli vsan storage add -s t10.ATA_____Corsair_Force_GT________________________12136500000013420576 -d mpx.vmhba32:C0:T0:L0 -d mpx.vmhba33:C0:T0:L0 -d mpx.vmhba34:C0:T0:L0 -d mpx.vmhba40:C0:T0:L0

If we take a look a the VSAN configurations in the vSphere Web Client, we can see that we now have 4 USB-based disks contributing storage to the VSAN Disk Group. In this particular configuration, I was using my Mac Mini which has 4 x USB 3.0 devices that are connected and providing the "MD" disks and one of the internal drives that has an SSD. Ideally, you would probably want to boot ESXi from a USB device and then claim one of the internal drives along with 3 other USB devices for the most optimal configuration.

As a bonus, there is one other nugget that I discovered while testing out the USB-based disks for VSAN 6.0 which is another hidden option to support iSCSI based disks with VSAN. You will need to enable the option called /VSAN/AllowISCSIDisks using the same method as enabling USB-based disk option. This is not something I have personally tested, so YMMV but I suspect it will allow VSAN to claim an iSCSI device that has been connected to an ESXi host and allow it to contribute to a VSAN Disk Group as another way of providing additional capacity to VSAN with platforms that have restricted number of disk slots. Remember, neither of these solutions should be used beyond home labs and they are not officially supported by VMware, so do not bother trying to do anything fancy or running performance tests, you are just going to let your self down and not see the full potential of VSAN 🙂

Quick Tip - How to enable memory overcommitment in VMware Fusion?

02.14.2015 by William Lam // 20 Comments

There was an interesting internal thread that I came across yesterday where someone was asking if VMware Fusion supported memory overcommitment like VMware Workstation? In VMware Workstation, memory overcommitment can be adjusted by going to Edit->Preferences->Memory which provides three different options as shown in the screenshot below. This setting specifies the percentage of memory that would be reserved from the physical host memory for each Virtual Machine.

These options map to the following % of host memory reservation:

Option	% of Host Memory Reserved Per VM
Fit all virtual machine memory into reserved host RAM	100
Allow some virtual memory to be swapped	50
Allow most virtual memory to be swapped	25

Disclaimer: Be aware, that default safe guards have been put in place to ensure optimal VM performance. If you decide to change these settings and allow memory overcommitment, it can potentially degrade performance of both your VMs as well as host system. Make sure you understand the changes before applying them.

You can also specify a custom value by editing the VMware Workstation configuration file located in: C:\ProgramData\VMware\VMware Workstation\config.ini and modifying or adding the following property:

prefvmx.minVmMemPct = P

where P is the percentage of configured VM memory that should fit into the host memory. The smallest value that P can be is 1. Below is a screenshot of a 32GB VM running on a Macbook Air with latest version of Fusion (8.5.3) which only has 8GB of physical memory and the value that I had used for this demonstration is 1.

Going back to VMware Fusion, memory overcommitment is also possible but the option to configure it is not available in the VMware Fusion UI. You will need to add the above setting into the VMware Fusion configuration file located in /Library/Preferences/VMware\ Fusion/config which does not exist by default. You will need to restart Fusion/Workstation for the change to go into effect.

In addition to the change, if you do decide to overcommit your memory, it was also mentioned that you may also want to disable Hard Disk buffering for optimal performance. You can make this change in the Advanced Settings of the the VM as seen in the screenshot below.

You can also just add the following property to the Virtual Machine's VMX configuration file:

hard-disk.hostBuffer = "disabled"

Memory commitment can be a wonderful tool, especially for lab environments. If you combine this with SSD storage and if swapping does occur, the impact may be acceptable so that you can run a few more VMs. Thanks to Regis Duchesne & Jesse Pool for sharing this handy tidbit!

ESXi 6.0 works OOTB for Apple Mac Mini & Mac Pro

02.06.2015 by William Lam // 146 Comments

Over the years, there have been various Apple issues that have required different hacks/tweaks to get a stock ESXi image to install on an Apple Mac Mini. Even though the only officially supported Apple platform for ESXi is the Apple Mac Pro, VMware Engineering, CPD and Hardware QE have been working hard to back porting as many of these "fixes/tweaks" to provide the best user experience possible for installing ESXi on non-supported Apple hardware. As you can imagine, the amount of work required to manage hardware on the official VMware HCL is no small task and then trying to back port non-supported platforms is even more challenging from a support standpoint.

The release of ESXi 6.0 is a significant release in my opinion as it contains the final few fixes that have plagued earlier version of the Mac Mini platform, especially starting with the Mac Mini 6,2 and greater models. I am please to announce that the stock ESXi 6.0 image now works on all Mac Mini platforms starting from 5,1 and newer as well as Mac Pro 6,1 platform and newer. There are no additional tweaks or custom ISOs that will be required for a fully functional ESXi installation with proper networking enabled. In fact, if you have a Thunderbolt Ethernet Adapter connected to either a Mac Mini or Mac Pro, you will also notice that it is automatically recognized without any additional driver or tweaks to the driver map files.

Disclaimer: Running ESXi on an Apple Mac Mini is not officially supported by VMware, please use at your own risk

One caveat that I would like to highlight is for the recent 2014 Mac Mini 7,1 or newer models where the SATA HDD is not automatically detected due to a change in the disk model made by Apple. Unfortunately, due to the late release of the 2014 Mac Mini, the required PCI ID to recognize the drive could not be added to the stock image of ESXi 6.0. Luckily, the resolution is quite easy and you can download and apply this custom VIB to get the SATA HDD recognized. I have been told that the plan is to get this fix in the next update/patch release so hopefully in the near future, no additional tweaks are required ... unless Apple decides to change something on us again 🙂

Here are screenshots of running ESXi 6.0 on both the Apple Mac Mini and Mac Pro: