Building a Modern SOHO Virtualization Lab – Part 4

iSCSI NETWORK BOOT

With the NUC Skull Canyon it is possible to boot an operating system from an iSCSI LUN. Whereas with other operating systems (e.g. Windows), certain steps are required to install a software iSCSI initiator inside the operating system and then configure the iSCSI initiator to boot the operating system from an iSCSI LUN, VMware ESXi is automatically enabled for booting from an iSCSI LUN as long as the iSCSI LUN is mounted before ESXi installer is loaded. If the iSCSI LUN is mounted properly, the ESXi installer will detect the mounted iSCSI LUN and will offer it as one of the available targets for installing ESXi. Therefore, to boot ESXi from an iSCSI LUN, nothing needs to be configured in ESXi itself besides selecting the iSCSI LUN as the destination to which ESXi should be installed (not unlike selecting any other drive visible by the ESXi installer).

Advertisement

Building a Modern SOHO Virtualization Lab – Part 3

SECONDARY NIC WITH 2016 NUC SKULL CANYON

When I first discovered the 2016 NUC Skull Canyon, my primary hesitation was that this NUC had only one Gigabit Ethernet Network Interface Card (NIC). In my ESXi lab, I have been using several Late 2012 Mac Minis with two GigabitEthernet NICs each. I used the primary (on-board) NIC for management and VM traffic and the secondary (Thunderbolt-based) NIC for iSCSI traffic to the iSCSI SAN. Unfortunately, the NUC Skull Canyon has only one on-board NIC, which in my opinion is a significant oversight on Intel’s part. Granted, the Late 2012 Mac Mini also comes with one on-board NIC, so it has the same “design flaw” as the 2016 Skull Canyon NUC.

Building a Modern SOHO Virtualization Lab – Part 2

GOING BEYOND SIX-VM-PER-HOST LIMIT

In the first blog post of this series, I described the progression of my VMware ESXi virtualization lab, as I was able to scale the number of concurrently running VMs from four to 12 VMs running on two 2012 2.6 GHz quad-core Mac Minis.

In early of 2016, I thought that I had solved the VM scaling problem in my lab by having purchased an iSCSI NAS capable of read-write SSD caching, but just a few days later I learned that I was wrong again. As I attempted to add even more VMs to my lab, I realized that I had a new bottleneck of 12 VMs. It turned out that I could not run more than 6 VMs on each Mac Mini, as powering up a 7th VM on either Mac Mini resulted in the same old issue manifesting itself in all VMs on the Mac Mini becoming unresponsive and eventually crashing. To my chagrin, I realized that I had not yet found the final solution to my problem.

Building a Modern SOHO Virtualization Lab – Part 1

BACKGROUND

Being a Cisco Unified Communications (aka Collaboration) engineer, I have a SOHO lab where I stage various Cisco application servers and practice scenarios that I deploy for my clients. I started delving into virtualization back in 2009 – several years before Cisco decided to virtualize Unified Communications applications. Back then, Cisco Unified Communications applications ran directly on bare metal, but with a few tweaks, it was possible to install them as virtual machines for lab purposes. Initially, I used VMware Server and VMware Workstation as my hypervisors and ran the VMs on my laptop, but in 2010 I bought my first lab server to be used as an ESXi host.