Creating a Single-Node VSAN

| 02/05/2016 | Tags: , ,

Creating a Single-Node VSAN


Many of us homelab enthusiasts tend to build “whitebox” systems from spare PC parts and a few internal hard drives for local storage that we’ve either ordered or had laying around in order install ESXi and run a single-node lab environment.  VMware Virtual SAN (VSAN) enables the ability to build a local SAN environment utilizing the local hard drives in the host.  The only downside/caveat is that you need a minimum of (3) ESXi hosts in a cluster to enable and configure VSAN.  Bummer!  

Well, thanks to some very smart people in the community, there is a way to create a VSAN on your single-node host!  

Keep in mind that this is not supported by VMware and is recommended for testing purposes only and should not be done in a production environment so use at your own risk.

I will mention that this topic has been covered by other bloggers (one of my favorites, William Lam, and a few others…) in the community but for my own knowledge and sharing, I decided to write this post detailing how I configured this in my environment.

Below, I will show you how to configure a hybrid and an all-flash VSAN on your ESXi host.  Again, I remind you that running a single-node VSAN is not supported by VMware and you run the risk losing all your data in the event of a disaster scenario (system crash, etc.)  Please be sure to understand the risks when deciding to use this in your own home lab.


  • (1) vCenter Server (Windows-based or VCSA)
  • (1)ESXi host in a cluster
  • (1) vmk for VSAN Traffic
  • (1) SSD for Caching Tier
  • (1) SSD for Capacity Tier (All-Flash configuration)…or…
  • (1) HDD for Capacity Tier (Hybrid Configuration)
  • SSH access to Host

For simplicity’s sake, I will be using a VCSA and ESXi VM deployed in VMware Workstation 12.1.1 Pro on Windows 10 for this demonstration.

1 2

Be sure that you have connected your ESXi host to your vCenter Server and have added it to a cluster, you do not need to enable VSAN on the cluster yet.  Add an additional vmk to your vSwitch for VSAN traffic.  Also ensure you have started the SSH service on the ESXi host.

Open an SSH session to your ESXi Host.  If you’ve added a vmk for VSAN but have not enabled it for VSAN traffic yet, enter the following command.

esxcli vsan network ipv4 add -i vmkN

(Where “N” is the number of your vmk port – ie: vmk1)

In my environment, I already created a VSAN vmk and enabled it for VSAN traffic so I was able to skip the command above.


Using the vSphere Web Client or C# client, verify the hard drive that you want to use for your VSAN datastore.  I will be using these drives, the 30GB will be my cache disk and the 120GB will be the capacity disk.

4 5

Back in your SSH session, enter the following command to determine and confirm the eligibility of the disks intended for use to create your VSAN.

vdq -q


Next, enter the following command to get the current default VSAN policy.

esxcli vsan policy getdefault


We will need to change the current policy by running the following commands.

esxcli vsan policy setdefault -c cluster -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1) (\"stripeWidth\" i1))"
esxcli vsan policy setdefault -c vdisk -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1) (\"stripeWidth\" i1))"
esxcli vsan policy setdefault -c vmnamespace -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1) (\"stripeWidth\" i1))"
esxcli vsan policy setdefault -c vmswap -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1) (\"stripeWidth\" i1))"


Run this command again to confirm that the policy has been changed.

esxcli vsan policy getdefault


Run the following command to create a new VSAN cluster

esxcli vsan cluster new


Now, since my disks are all SSD, I am creating an All-Flash VSAN configuration.  I need to run the following command to tag the capacity SSD as the data disk.  The “-d” represents the “capacity disk” and you need to specify the identifier of the disk to tag.  You can simply copy the identifier number directly from the ESXi hosts storage devices section in Web Client/C# Client, or from the SSH session where we ran the “vdq -q” command.  

Note – If you are deploying a Hybrid VSAN, this command is not needed so you can skip to the next command to add the “cache & capacity” disks to your VSAN.

esxcli vsan storage tag add -d <disk identifier> -t capacityFlash


If you’d like to confirm that the disk has been tagged for “capacityFlash” simply run the “vdq -q” command again and check the disk.


Next, run the following command to add both your disks (cache & capacity) to your VSAN storage volume.  The “-s” represents the SSD “cache disk”, and the “-d” represents the “capacity disk”.  Be sure to enter the correct identifier number for the respective disks.

esxcli vsan storage add -s <disk identifier> -d <disk identifier>


 Run the following command to show the VSAN cluster info.

esxcli vsan cluster get


Run the following command to list the VSAN storage

esxcli vsan storage list


Congratulations, if everything has been followed correctly, you should now have created a single-node VSAN datastore!

16 17

But we are not quite finished just yet.  Even though I can see the VSAN datastore, I still want to officially enable VSAN on the cluster in vCenter.  Do the following…

18 19 20

In my environment, I have an extra disk in my host, but I do not want to claim this as part of my VSAN.  So, from the drop-down menu, I selected “Do not claim” and hit Next then Finish. 

21 22

Now I can see that VSAN is “Turned On” and can see the disks that are associated with the Disk Group.

23 24

But, there’s still a bit more to be done for me to be able to provision VMs on this datastore.  I need to edit the VSAN VM Storage Policy.  Personally, I prefer to leave the default policies intact and instead create a new policy for my single-node datastore.  I will show both editings of the default policy, for those who do not want to bother with creating a new policy, as well as creating a new policy.  First, let’s check the VASA storage provider and ensure it has been synchronized so that we can edit/create our VSAN Storage policy.

25 26


Editing Virtual SAN Default Storage Policy


Here we need to simply change:

  • Number of failures to tolerate = 0 (Default is 1)
  • Force provisioning = Yes (Default is No)



Creating a new Virtual SAN Storage Policy


Give it a Name and a Description then hit Next.  


Select VSAN from the “Rules based on data services” drop-down, then add all the rules from the drop-down and configure the same settings mentioned above, then hit Next and Finish.

  • Number of failures to tolerate = 0 (Default is 1)
  • Force provisioning = Yes (Default is No)

31 32

And, there you have it!  A fully functional Single-Node VSAN to provision VMs on.  You still have to add a VSAN license, but that will not be covered here as you should already be familiar with the licensing process.



The Finishing touches

The following optimizations commands are optional but highly recommended for better performance and stability in your VSAN environment.

Since this is a homelab, the disks I used may not be on the official VMware HCL and can potentially impact the performance of the lab environment.  Corman Hogan wrote a great blog and included a tip on how to disable VSAN device monitoring.  Open an SSH session to your host again and run the following command.

esxcli system settings advanced set -o /LSOM/VSANDeviceMonitoring -i 0

To confirm that the command was successful, run the following command.  It should return a value of “0” as the default value is “1”.

esxcfg-advcfg -g /LSOM/VSANDeviceMonitoring


Cormac Hogan also wrote another great post about the new “Sparse VM Swap Object”.  ESXi 6.0 Update 2 (aka 6.2) brings a new setting in VSAN 6.2 which allows VSAN to provision a VM swap object as thin instead of thick, where thick has historically been the default.  So if you’d like to disable thick provisioning and use thin, run the following command.

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

To confirm, run the following command.  It should return a value of “1” as the default value is “0”.

esxcfg-advcfg -g /VSAN/SwapThickProvisionDisabled


And last, but definitely not least, if you intend on running any Nested ESXi VMs on your newly created VSAN, be sure to run the following command to prevent any errors when trying to create SCSI disks for your ESXi VM.  This will enable an advanced ESXi setting that will “fake” SCSI reservations.  William Lam has a nice post about this here.

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

And to confirm it took, run the following command.  It should return a value of “1” as the default value is “0”.

esxcfg-advcfg -g /VSAN/FakeSCSIReservations


That’s all folks!  I hope that you’ve found this post to be of use to you and I hope you come back for more content.  Feel free to comment, share, and subscribe!

Giving credit where it is due, shout out to William Lam and Cormac Hogan!



Create a Synology VM with XPEnology

| 30/04/2016 | Tags: , ,

Create a Synology VM with XPEnology


I’m a huge fan of Synology NAS systems, but I must say, they do often put a gaping hole in your wallet.  Well, fortunately the folks over at XPEnology have created an alternative way for us to create your own Synology devices, whether it be deployed on a bare-metal system or as a virtual machine.  I currently own a few Synology NAS devices, but I love having the ability to spin up a working VM version quickly and with ease, for use in my nested lab environments.


In this post, I am going to show you how to create your very own Synology VM on VMware ESXi, Workstation, and Fusion hypervisors.  As I mentioned previously, you can also deploy this onto a bare-metal system, but since I do not have a spare system to test this with, I will not cover that deployment.  So without any further hesitation, let’s get to it!


  • VMware ESXi
  • VMware Workstation
  • VMware Fusion
  • XPEnology files
    • DSM 5.x PAT file – (please note that DSM 6.0 remains unsupported with XPEnology at this time)
    • XPEnoboot 5.x VMDK file
    • Synology Assistant (optional but recommended)
    • NFS Plug-in for VMware VAAI (optional but recommended)
    • Open-VM-tools (optional but recommended)

The type of Synology system that XPEnology emulates is a DS3615xs 12-bay unit.  Let’s begin by heading over to the XPEnology website and grabbing what we need.  At the time of this writing, the current version of DSM is the newly released DSM 5.2-5967, but the XPEnology team has not yet created an updated bootloader (XPEnoboot) that supports this version.  The current stable version is DSM 5.2.-5644 Update 5 (and can be manually updated to Update 8 at a later time).  The current stable version of XPEnoboot is 5.2-5644.5 so I’ve downloaded the following files…


Now the fun begins, and I will start with the VMware ESXi deployment.  I will be deploying on the newest version of ESXi 6.0 Update 2 via the vSphere Web Client.  For those of you using the vSphere C# client, the directions are the same just the interface is different.


ESXi 6.0 Update 2

Part 1:

Create a new virtual machine


Give it a name and select a folder to place the VM in


Select a compute resource


Select a storage location


Select the proper Compatibility version


Select the following Guest OS settings


Customize the VM with the following settings, remove the floppy, and select the appropriate network 


Finish and let it build the “Shell” VM 



Part 2:

Now that the VM has been built, we need to add the XPEnboot VMDK that we downloaded earlier to the VM

Browse to the datastore where you created the VM and upload the XPEnoboot VMDK 


Once uploaded, we need to add the disk to the VM 

2016-04-29_22-29-15 2016-04-29_22-29-562016-04-29_22-30-58

At this point, I also like to add an additional SCSI disk which will be used as an NFS volume, or iSCSI LUN.  You can make this any size you like but for the purposes of this post, I’m just going to add a simple 50GB Thin Provisioned disk. The 16GB disk we created with the VM will be used to install application packages (i.e. – VMware Tools, etc.)

Keep in mind that this is a 12-bay device, so you can technically add 10 more disks to fill all the drive bays


Now power-on the VM and open the console window.  Keep an eye on the window for the IP address assigned to the VM.  You can connect to this IP using a web browser instead of using the Synology Assistant to detect and connect to it.


Open you favorite web browser and type in the IP address of the VM, and hit enter.  This will connect you to the VM’s Synology Web UI

Click the Set up button, then click the Manual Install link and browse for the DSM .pat file we downloaded earlier. Then click the Install Now button

2016-04-29_23-03-382016-04-29_23-04-27 2016-04-29_23-06-12

This will prompt you that it will erase all data on all disks, including the XPEnoboot disk we uploaded and attached earlier.  Note, I have experienced failures at this point and received a message that the .pat file may be corrupt.  In the even this also happens to you, please use this alternative XPEnology download link.


Once complete, the VM will be rebooted.  But since we erased all of the disks during installation, the VM will fail to boot properly and this is expected

2016-04-29_23-17-15 2016-04-29_23-17-36

Power off the VM and access the datastore that the VM is stored on.  Delete the XPEnoboot VMDK then re-upload the VMDK that we originally downloaded

2016-04-29_23-19-41 2016-04-29_22-27-40

Power on the VM and select the Install/Upgrade option


When it finishes it boot, this time you will notice that it will not display the IP address we saw the last time.  The IP should have remained the same but I’m going to use the Synology Assistant to detect it and help me connect since my web browser was not connecting to the same address

2016-04-29_23-25-50 2016-04-29_23-44-17

Now we are presented with the Web UI screen and we can login with admin and a blank password


Click next and give the Synology VM a name and change the admin user password or enter a new username and password then click Next

2016-04-29_23-48-13 2016-04-29_23-50-20

In order to prevent updates from installing automatically and possibly breaking the boot up of the Synology VM, I chose “Download DSM updates but let me choose whether to install them” and clicked next


I also chose to skip the “Set up QuickConnect”


And….You’re Done!  You now have a fully functional Synology virtual machine.  You can feel free to add additional disks or what have you.


At this point, I like to go ahead and install the Open-VM-Tools package so that I can use the VMware tools to gracefully power off the VM as needed.  To do so, you will need to have downloaded the package from the XPEnology website.

Open Package Center, then click the Settings button.


On the General tab, set the Trust Level to Any Publisher and click OK


Back in the Package Center, click Manual Install.  Browse to the package and click Next


Since we have yet to create a volume, it will prompt you to click OK to launch Storage Manager and create a volume to install the package on.


In Storage Manager, click Volume the click Create.  Keep the default of “Quick”, Next, select Disk 3, Next, OK to the warning message, Yes for disk check, Next, Apply….Done!

2016-04-30_0-08-57 2016-04-30_0-11-08 2016-04-30_0-12-02 2016-04-30_0-13-10 2016-04-30_0-14-49 2016-04-30_0-15-13

Now, repeat step 3 above, click Apply, and you will have VMware tools installed.


Wow, that seemed like an awful lot of steps, but it really wasn’t all that much.  In the next sections, I will just go over the deployment of the “Shell VMs”  and the steps to add the XPEnoboot VMDK to the VMs in VMware Workstation and VMware Fusion as the rest of the post-boot setup steps are the same.


VMware Workstation Pro 12.1.1

Part 1:

Create the Shell VM…

2016-04-30_1-07-28 2016-04-30_1-07-43 2016-04-30_1-08-01 2016-04-30_1-08-17 2016-04-30_1-10-34 2016-04-30_1-10-46 2016-04-30_1-11-05 2016-04-30_1-11-47 2016-04-30_1-12-14 2016-04-30_1-12-27 2016-04-30_1-12-39 2016-04-30_1-13-17 2016-04-30_1-13-40 2016-04-30_1-15-42

Part 2: 

Add the XPEnoboot VMDK to the VM…


2016-04-30_1-18-32 2016-04-30_1-18-46 2016-04-30_1-19-02 2016-04-30_1-19-14 2016-04-30_1-19-54 2016-04-30_1-21-00


Power on the VM and continue with same process outlined above for ESXi deployment.  Use the Synology Assistant to find and connect as the VM may not display the IP address right away.


VMware Fusion Pro 8.1.1

Part 1:

Create the Shell VM…

2016-04-30_09-21-41 2016-04-30_09-22-04 2016-04-30_09-22-36 2016-04-30_09-22-58 2016-04-30_09-24-14

Part 2:

Add the XPEnoboot VMDK to the VM…

2016-04-30_09-25-28 2016-04-30_09-26-35 2016-04-30_09-27-02 2016-04-30_09-29-08 2016-04-30_09-30-49 2016-04-30_09-31-51 2016-04-30_09-32-41 2016-04-30_09-33-14 2016-04-30_09-34-58 2016-04-30_09-36-10 2016-04-30_09-36-45 2016-04-30_09-37-39

Power on the VM and continue with same process outlined above for ESXi deployment.  Use the Synology Assistant to find and connect as the VM may not display the IP address right away.


Now you should all feel confident in creating your own Synology VM systems for whatever your use case may be and hopefully you will all love using Synology products as much as I do.  If you would like the true experience, I’d recommend purchasing a real system.  But in the interim, this will give you a way to create your own and play around with it.

Keep in mind that when updates are released, it is always wise to first check on the XPEnology site and/or forum to see if the updates break anything as sometimes they will cause the boot process to break since the XPEnoboot cannot support it yet.  Usually you are safe to update as long as the update is within the same DSM version, but consult the site/forum first as I am not responsible for any upgrade impacts.

Well, I hope that you all have enjoyed this read/guide and come back for more!

And giving credit where it is due, I’d like to give a shout out to Erik Bussink as his guide is what inspired me to write this updated guide for all of you!  



Configure OpenDNS on Ubiquiti EdgeRouter Lite

| 27/03/2016 | Tags:

I recently picked up a new router/firewall for my home, and chose the Ubiquiti EdgeRouter Lite (ERLite-3).  This device comes with a lot of bells and whistles and if you would like more information on it, please see here.

I am a huge fan of speed and security, and for this purpose I always choose to configure my home network to use OpenDNS name servers rather than my ISP’s (Internet Service Provider) name servers.  OpenDNS has some great setup guides available for users to configure their devices and you can view the setup guides here and choose the solution that best suits your needs.  Now, I prefer to configure OpenDNS right on the router so that it applies to any and all devices on my network that use the internet.  Unfortunately though, I did not find a setup guide for Ubiquiti devices…but since I was already familiar with the process, I tinkered a bit around the EdgeOS and managed to figure it out.


In this post, I am going to cover how to set up your EdgeRouter to use OpenDNS name servers.  By default, the router is configured to forward DNS queries to the name server IP addresses obtained from your ISP via DHCP.  So let’s go ahead and change that!


First, let’s head over to the following OpenDNS page to test our settings and ensure we are not already configured to use OpenDNS’s DNS name servers somehow (this is just for good measure).  On the right-hand site there is a link that reads:

“click here to test your settings”


Go ahead and click it, and it should return the following message:


Next, login to your EdgeOS dashboard WebGUI (by default it’s configured as and login using the default user credentials (ubnt/ubnt).


On the bottom left corner, click the System tab to open it up.


In the Name Server area, add the following OpenDNS name server IP addresses then scroll to the bottom and click Save before closing this window:


Great, Step 1 is done!  Now onto Step 2…this can be done via the CLI or the Config Tree.  (I chose the latter…)

Click on the Config Tree button and navigate to the following from the left-side Configuration pane:

service / dns / forwarding / system 

Click the triangle-like icon direct to the left of the word system, then click the “+” icon to the right of the word system. If done correctly you should see the following header on the top of the page and two buttons, Discard & Preview, on the bottom of the page.


Next, click the Preview button at the bottom of the page.  This will show you the command that would be used in the CLI to apply the name servers.  The great thing about this is that it also give you the option to “Apply” it now via the GUI!  I chose to hit Apply.  


Once, completed, there should be some green text at the bottom reading:

“The configuration has been applied successfully”


Now, the final step is to go back to the OpenDNS page and test the settings again.  If everything is applied correctly, you will be presented with the following:


Now your router is fully configured to use OpenDNS!  

I hope that you have found this to be informative so please be sure to comment below and share this post.

Intel NIC not detected by ESXi

| 21/03/2016 | Tags: ,

Intel NIC Not Detected by ESXi


In this post I am going to cover a random issue I encountered after installing ESXi 6.0 Update 2 on one of my new Home Lab 2016 hosts.  The actual installation of ESXi was extremely easy and painless (I may cover that in another post).  After I had completed the installation, I was attempting to configure my Management network interfaces and suddenly noticed that only 4 network interfaces were being detected!  


As I then thought to myself, “I wonder what is going on here since I didn’t get any POST issues?”, I noticed that I was getting a message during POST regarding the initialization of the Intel Boot Agent for PXE booting.  The message stated:

“…PXE-E05: The LAN adapter’s NVM configuration is corrupted or has not been initialized.  The Boot Agent cannot continue.” 



Immediately, I began to consult “Mr. Google” and see if there was anything I could find related to this particular problem.  After reading a few threads, many users had mentioned and/or suggested that the NIC’s firmware was corrupted and needed to be “re-flashed”.  I quickly got to work and researched a bit further to understand the process of flashing the NIC firmware.  I downloaded the latest version of PREBOOT (at the time of this writing, it was version 20.7)which contains the “BootUtility” needed to perform the flash.

Next, I prepared myself a DOS-bootable USB using Rufus.  I then extracted the PREBOOT.exe file using 7zip and placed the contents on the newly created USB.  This would allow me to either boot into the USB and access DOS or boot into the UEFI: Built-in Shell on Supermicro motherboards, and access the necessary files.  Once I had my drive ready, I went ahead and plugged it into my server and initiated a reboot.  During POST, I invoked the boot menu so and chose the option to boot into the Built-in Shell.


Once in the shell, I determined that my USB was mounted at fs4:


I navigated through the directories so I can see the contents of each folder until I saw the BootIMG.FLB file which is the new flash image I want to apply.  I then navigated to the location of the BootUtility.  Since I am using the built-in shell, I needed to ensure that I used the BootUtil for x64-bit EFI so I navigated to the following location:



Running the BOOTUTIL64E.EFI file will simply list your network interfaces and I could then see the current firmware version for all of my interfaces, although for some reason the ones in question are displaying “Not Present”.  Adding a “-?” suffix will bring up the help and list all the parameters to execute the commands properly.  I found a great reference article here which made it easier for me to see what parameters I needed in my command.  


To begin, I entered the following command since I wanted to enable flash on all of my NICs.  



Or, if you wanted to do each one individually, you could specify the NIC  number (referenced as X below) manually.


A reboot is required after successful completion of this command before proceeding, so I went ahead and rebooted my system and then booted back into my USB via the built-in shell.  


Afterwards, simply running the utility again showed that NIC ports 1-4 were all PXE ready.  


Now it was time to run the following flash command.  Note: Specifying the file parameter is optional.  Without it, it will assume that the BOOTIMG.FLB file is in the same location you are executing the command from.  Since I left the file in its originating location, I had to specify it manually.


You will then be prompted to create a restore image, in the event something goes awry but I chose not to create a restore image.


Upon successful completion, I can now see that my firmware version has been upgraded from version 1.3.98 and is now running version 1.5.78


Now that my firmware has been upgraded, I rebooted the host and accessed the Management Network settings screen, and to my delight, ESXi was now detecting all of my network interfaces!  Woohoo!!  


I am still trying to figure out why flash is not present on the NICs that previously were not detected, and my assumption is that it’s due to these being relatively cheap $80 network cards instead of full priced (~$300) network cards.  In any case, they still work and I am quite happy with them.  I hope you have found this information useful.  Thanks for reading!