VMware vSphere 6 Part 1 - Getting Started w. Virtualization

Learn VMware's free ESXi 6 Hyperisor, Virtual Networking, NFS Shares and Virtual Machines. Learn how with Video Demos.
4.5 (251 ratings) Instead of using a simple lifetime average, Udemy calculates a
course's star rating by considering a number of different factors
such as the number of ratings, the age of ratings, and the
likelihood of fraudulent ratings.
1,398 students enrolled Bestselling in VMware
24% off
Take This Course
  • Lectures 168
  • Length 8.5 hours
  • Skill Level All Levels
  • Languages English
  • Includes Lifetime access
    30 day money back guarantee!
    Available on iOS and Android
    Certificate of Completion
Wishlisted Wishlist

How taking a course works


Find online courses made by experts from around the world.


Take your courses with you and learn anywhere, anytime.


Learn and practice real-world skills and achieve your goals.

About This Course

Published 1/2016 English

Course Description


VMware vSphere 6.0 is the platform businesses depend on to deploy and manage their virtualized Windows and Linux workloads. In this course you will learn the concepts, skills and mechanics you need to get you started as a VMware vSphere 6.0 administrator.

Why Take This Course? (Please click blue Full details link just below)

Here are some great reasons why you should consider enrolling in this course:

  • Our courses are the highest rated of all vSphere courses on Udemy. We consistently earn scores of 4.5 to 4.8 stars out of 5!
  • Most feedback of any vSphere course on Udemy. Over 200 people have rated this course. Please check out our feedback
  • Fastest growing vSphere course on Udemy! We add more new students per day than any other vSphere course. People sign up because of our content, quality and price
  • One of the lowest cost vSphere courses on Udemy! We give you 8.5 hrs of detailed lectures for $20 or less. Other vSphere courses charge $70 or more for much less content
  • We have the newest vSphere courses on Udemy. Our courses were developed in late 2015 and published in 2016. Others go back to 2013 or earlier
  • The only courses teaching vSphere 6. Why learn older technology? vSphere 6 is the latest and greatest version of vSphere
  • We have the most complete set of vSphere courses on Udemy. Combined, our Part 1 through 6 courses give you 31+hours of vSphere 6 training. Nobody else offers anything close to the breadth and depth of vSphere training that you will get here
  • We offer lots of free preview content. Check the course out for yourself before you buy
  • Video demonstrations that show you how to complete all tasks discussed in your course

Check us out. Try any of the free preview lessons to see if this course is for you.

About This Course - Learn VMware vSphere 6.0 from the ground up

This is an in-depth introductory course on virtualization with VMware vSphere 6. This course covers four major topics that all vSphere 6 administrators must know:

  • First, we start by learning how to install and configure the ESXi 6.0 hypervisor. From there, we configure ESXi host management networking, join our host to a Windows AD domain, set up time services and much more
  • Next, we explore virtual and physical networking. Virtual networking is used to provide Ethernet and TCP/IP networking to VMs. Physical networking is used by both ESXi and VMs to communicate to physical network peers. You will learn to build NIC teams for fast, reliable networking, and how to enable Cisco Discovery Protocol on your virtual Switches
  • ESXi can use file shares for Virtual Machines, for backups and as a repository for install media images or to hold VM clones or templates. We will see the file choices ESXi supports, how to connect and disconnect from file shares and best practices for achieving both high performance and redundancy
  • We will learn how to build virtual machines. You will learn about the features and capabilities of the virtual hardware layer, how to install a guest OS into your new VM, the purpose and benefits of VMware Tools and how to optimize your VMs for best performance and lowest resource overhead.
  • Included at the end of each chapter is a series of one or more video demonstrations that show you exactly how to use your new vSphere skills in a live vSphere 6 environment!

Get in-depth lectures, insights, concepts, how-tos and more. Start learning vSphere 6 now - here on Udemy.

What are the requirements?

  • Have a basic knowledge of Ethernet and TCP/IP
  • You should understand and know how to use file shares (e.g.: SMB / CIFS shares)
  • Prior experience installing Windows desktop or server operating systems

What am I going to get from this course?

  • Install and configure VMware's ESXi hypervisor according to best practices
  • Understand and configure virtual and physical networking
  • Connect ESXi to NFS shares
  • Create, edit, power on and run Virtual Machines

What is the target audience?

  • System administrators who need to work with vSphere virtualization
  • Programmers who need to learn how to create vSphere Virtual Machines
  • Existing vSphere administrators who want to improve their knowledge of vSphere 6.0
  • Anyone who wants to get more work from their servers by virtualizing workloads

What you get with this course?

Not for you? No problem.
30 day money back guarantee.

Forever yours.
Lifetime access.

Learn on the go.
Desktop, iOS and Android.

Get rewarded.
Certificate of completion.


Section 1: Introduction
VMware vSphere Training From ESXLab
VMware vSphere 6.0
Get ESXi 6.0 for Free!
Course Goals
Course Goals continued
Presented By
Should You Take This Course?
Let's Get Started!
Section 2: Install and Configure ESXi 6.0 Hypervisor

Our first step in this class is to install ESXi onto stand alone PC servers and then connect to those newly installed ESXi hosts using the vSphere Client and SSH. In future chapters we will add to our original implementation. Our ultimate objective is a scalable, highly redundant, load balanced Virtual Infrastructure implementation that supports a large community of Windows 2003 / 2008 / 2012, desktop, Linux and other VMs.


VMware ESXi is a bare-metal virtualization hypervisor solution. As such, it must install on an industry standard PC server. Please check VMware's Hardware Compatibility Guide (portal on www.VMware.com web site) for the most up to date list of supported PC servers.
Because it owns the hardware, ESXi is in full control of resource assignments to running VMs. The VMkernel, allocates hardware resources on an as-needed basis. In this way, the VMkernel can prevent idling VMs from wasting CPU cycles that could otherwise be used by busy VMs. Likewise, the VMkernel keeps track of needed RAM, not just requested or allocated RAM. It can dynamically re-assign RAM to memory starved VMs, thereby ensuring that VMs get the memory they need to run.


As your ESXi deployment matures (technically) you will want to introduce:
● Different LAN (virtual or physical) segments to isolate network traffic to improve both security and performance. You could use different LAN segments for things like IP Storage, Management and production systems

● Shared storage solutions including iSCSI, Fibre SAN and NFS shares

● Hardware redundancy in the form of multipath storage solutions and teamed NIC configurations

● You may even wish to consider a Boot From SAN or boot from USB/SD card solution so you don't need to provision and configure local storage.
Boot from SAN is available on supported Fibre SAN controllers and also with iSCSI SAN controllers (using iSCSI hardware initiators).


ESXi is capable of using the largest PC server hardware platforms. Apart from what is stated above, ESXi is limited to:
● No more than 320 CPU cores (includes Hyperthreaded logical processors) for CPU scheduling purposes

● All available RAM up to 4TB
Furthermore the following implementation limitations need to be considered:
● ESXi supports a modest selection of 10Gb and 40Gb Ethernet controllers

● Jumbo Frames supported, which may improve software iSCSI I/O performance.

Notes about Local Storage

● ESXi requires enterprise class storage controllers. This means that it usually doesn't work with embedded SATA controllers found on desktop motherboards

● ESXi has support for controllers from LSI Logic, Adaptec and many others. Most vendor branded controllers (Dell PERC, HP Smart Array, IBM ServeRAID, etc.) are made by (i.e.: rebranded from) either LSI Logic or Adaptec HP Smart Array controllers and have significant limitations you should know about:

1. They may refuse to boot off a local storage volume that is >2TB in size

2. They may refuse to use disk that do not carry HP's brand even if HP OEM's the drive. This means that generic Seagate, Western Digital, Hitachi, etc. enterprise drives (that work fine) may be rejected by HP controllers and/or storage shelves


JBOD – Just a Bunch of Disk. Physical disks in a non-RAID configuration.
ESXi comes in two forms – Embedded and Installable. Embedded is baked into firmware on the motherboard of select PC servers. This lets you boot your server without any local storage.
ESXi Installable is a version of ESXi that can be installed onto local storage, USB memory keys or SAN storage. It is installed from CD media that you can download from www.vmware.com.
ESXi does away with the Service Console found in ESX 4.1 and older. This provides a smaller, leaner hypervisor than full ESX. It is also more secure because there is less software (to exploit) and fewer services running on ESXi than there is on ESX.


DCUI - Direct Console User Interface This is the Yellow & Grey screen on the console of your ESXi host once it is fully booted.


ESXi is installed in text mode – so your PC server doesn't need to have graphics capability.
VMware makes it possible to set up an install server for ESXi so you can perform network based installs.

Accept the VMware EULA

In the above screen shot, the ESXi 6.0 installer detected a local SATA based Intel SSD and a 4.09 TB local RAID array on an LSI Logic hardware RAID controller. Since our intent is to use the SSD as a hardware based Read cache (see Performance chapter), we'll select the RAID set as the install target for ESXi

Performing an In-Place Upgrade

VMware has no supported password reset tool for ESXi. Officially, the only way to reset the root password is to re-install the entire operating system.
However, there are community developed procedures that appear to work. If you need to recover the root password for ESXi and have some Linux administrator and command line skill, please visit
The procedures in this blog have been tested on ESXi 3, 4 and 5.x and *should* work in vSphere 6.0. Note that these procedures appear to work for ESXi.


Virtualization abstracts the physical hardware to the VM. The VM guest operating system normally expects to own all hardware and also expect to be able to execute privileged CPU instructions that are not available to applications. If ESXi allowed guest operating systems full access to these privileged instructions, then the guest OS could manipulate hardware directly, possibly interfere with virtual memory page translation tables and perform other operations that could compromise the ESXi host. To avoid this problem, VMware blocked guest OS' from privileged/dangerous instructions and CPU features – and provides this capability through software that emulates (and controlled) what the guest OS could do. This worked but adds overhead to some operations.

Intel and AMD have virtualization hardware assist technology in their CPUs, offering sophisticated memory management capabilities, better hardware emulation features and other improvements that dramatically reduced the overhead of virtualization while maintaining compatibility with Guest OS'.

ESXi probes physical CPUs for Intel VT or AMD-V technology and will not install or run if the feature is not present or enabled, so please be sure to turn on this feature in your machine's BIOS.
For more information see: http://en.wikipedia.org/wiki/X86_virtualization

Hardware Virtualization Assist Part 2

The installer will now install ESXi onto your selected storage volume. To do this, the installer:
- Wipes all partitions on the selected target storage volume - Creates partitions as needed (normally 8 partitions are created)
Useful information about the installation disk:

- ESXi consumes about 4GB of disk space in overhead. The rest is for VM use

- partition 4 is the boot partition and is located at the front of the disk (behind the Master Boot Record and partition table)

- partitions 2 and 4, 5, 6 & 8 are for ESXi use and occupy the front of the disk

- partition 7 is a vmkcore partition (partition code 0xfc) and is a ESXi partition used to hold crash dumps

- partition 3 consumes all remaining disk space and is partitioned and formatted as a VMware File System (VMFS)

Note: ESXi 6.0 can install on > 2TB volumes. ESX(i) 4.1 and earlier cannot. Be aware that some vendor supplied RAID controllers (e.g.: older HP gear) cannot use a greater than 2TB volume as a boot volume.


It only takes about 5-10 minutes to install ESXi 6.0 onto your PC server. The install proceeds non-interactively. A status indicator updates a percent completed horizontal bar


ESXi has a simple, BIOS-like interface called the Direct Console User Interface (DCUI). The DCUI makes it very easy to configure. To configure your ESX host... simply hit F2 at the greeter screen and update your host configuration.


The ESXi administrator account is root (the traditional Linux administrator account). When you install ESXi, the system defaults to:
- The root password is set during installation

- IP properties set via DHCP

- No command line access (either locally or remotely)

In the next few slides, we will discuss how to change these values.


The ESXi configuration menu is a simple text interface where you complete your server's customizations.
Use the up/down arrows to move to a function. When a function is highlighted, its properties and the command keys used to modify that function are displayed on the right.


You must set the IP properties of your ESXi host before you can manage it. Select Configure Management Network to set the:
- Fully Qualified Domain Name (FQDN)

- IP address

- Netmask

- Default Gateway

and other properties.

You can set these values statically or dynamically using DHCP. If you use DHCP, you must configure your DHCP servers to send static properties to a host. To do this, configure your DHCP server with the MAC address of your ESXi host management NIC and then set the static properties to server whenever that NIC broadcasts for a DHCP lease.


It is a best practice to use static network settings for your ESXi host. To complete this task, you must:
1. Select the correct NIC for management networking 2. Set a static IP address and Netmask and Default Gateway values 3. Identify your local DNS server(s) and the default DNS search domains


You manage your ESXi host through your network. To communicate with your ESXi host (using either the vSphere Client directly or vCenter indirectly), you must have network connectivity to it.
Since modern PC servers may have many NICs and these NICs may be connected into different physical and/or virtual LAN segments, you may have to select the correct physical NIC (rather than the default NIC) before you can manage your machine.
NIC Teams The Network Adapters screen lets you review and select the NIC or NICs you wish to use to carry network traffic. If you select more than one physical NIC, you automatically create a NIC team. NIC teams afford better speed and redundancy.
Tip It can be difficult (or impossible) to tell which RJ45 jack is associated with which MAC address. A simple way of selecting the correct physical NIC(s) is to unplug all NICs from their switch except for the NICs you wish to use for management. Then use the Status column (Connected means the NIC has a link to the switch) to determine which NICs you should for management.


ESXi 6.0 makes it easier to identify onboard NICs from add-on NICs. In previous versions of ESXi, all NICs were reported in the order they were discovered during a boot up PCI bus scan. Normally, onboard NICs were discovered first – but this was not guaranteed. This could lead to problems trying to identify how vmnic# (alias for physical nic #) mapped to physical NICs.
With ESXi 6.0, VMware now identifies NICs as follows:
- If the Hardware Label values starts with N/A, then the NIC is on the motherboard

- If the Hardware label value starts Chassis slot... then the NIC is an add on NIC
For NICs on the motherboard, the NIC labeled NIC 1 will show up first, then NIC 2 and so on.
For add-on NICs, port 1 will show up first and then ports 2-4 (if the card is a dual/quad NIC)


Complete this form to set your ESXi host management NIC IP properties.
vCenter cannot manage an ESXi host whose IP address changes. For this reason it is best to give all of your ESXi, ESXi hosts fixed IP properties.
You must select Set static IP addresses... and complete all three fields to complete your static IP address properties assignment.


ESXi 6.0 supports IP V6. You can assign IP V6 addresses:
- Via DHCP

- Self generated via ICMP stateless configuration
You can assign up to 3 static IPV6 addresses to your ESXi host.


ESXi and vCenter require DNS services to function properly. So it is critical that you have DNS name servers set up and accessible from your local LAN segment.
It is a best practice to have both primary and secondary DNS servers available... but ESXi will function with just primary DNS.


DNS Suffixes are used to enable DNS to look up the IP address of a host specified only by it's host name (and not qualified with a domain name). An example might be a look up request for a host called esxi5.
DNS needs a full domain name. Custom Suffixes will append domain names from the list set on this screen to simple host names and then perform a DNS query. This continues until either:
- a matching FQDN is found and it's IP address is returned

- no matching FQDN is found and all suffix Domain names have been tried
It is a good practice to add at lest one domain name (the primary domain name for your organization) to this list!


All network changes are applied at one time when you leave the Configure Management Network sub-menu. First the new settings are applied to the appropriate configuration files and then the ESXi hosts' management network is brought down and back up again. For this reason it is best to be at the physical server's console when updating management networking properties.
You should be brought back to the System Customization menu. Your network changes should be visible.

Test Management Network

Tech Support Mode enables functions used by support providers who are comfortable working on the ESXi command line. By default, all local and remote command line access to your ESXi host is disabled – so you can only access your ESXi host through:
- the vSphere client pointed directly at your ESXi host

- vCenter if vCenter has management control over your ESXi host

- The VMware Management Assistant service (VMA), if installed

Enabling Local Tech Support allows physical console command line access. Support personnel who have access to the physical console directly or via remote console services such as Dell DRAC (Dell Remote Access Controller), HP ILO (Integrated Lights Out) or IBM Integrated Management Module (MM) would be able to log in to your server.
Enabling Remote Tech Support enables the Secure Shell Daemon (sshd) and supports network based administrator access to your box without the need for remote console services.
Warning Enabling Remote tech support enables direct root access to your ESXi host through a TCP/IP connection. This is a potential security threat. Turn on this feature only if needed. If this feature is turned on, set a strong root password.

Never expose your machine to an untrusted network like the Internet - especially if Remote Tech Support is turned on!


It may happen that the management agents (services) on your ESXi host become unstable or crash. If this occurs, your ESXi host will not respond to vCenter or the vSphere client. In vCenter your host will grey out and report as disconnected.
You could reboot the ESXi host but that would bring down all running VMs. A more acceptable option is to simply restart the management agents on your ESXi host.
This function can be done at any time. Any connected vSphere Client sessions will be closed. Once this function completes, your host should become active in vCenter and should accept direct vSphere Client login requests.


Once ESXi has rebooted, it is managed via VMware's vSphere Client. You can download the vSphere Client from www.vmware.com/download.
There are additional hot keys active on the ESXi console:
Alt-F1 – first command line log in screen

Alt-F2 – the ESXi greeter screen (screen shot above)

Alt-F3 to Alt-F10 – no function

Alt-F11 – Grey status screen/greeter screen with no F-key prompts

Alt-F12 – VMkernel log dump


ESXi supports both local and remote command line access (must be enabled using the DCUI Troubleshooting). These services are off by default.
Allowing direct console or network Secure Shell (SSH) command line logins enables direct ESXi host administration without the need for vSphere Client or Web Client. The environment is similar to a Linux style machine.
One thing to note is that ESXi will allow direct root logins both on the console and via SSH. This is a security concern because it means that anyone in possession of (or who can guess) the root password can take control of your machine.
It is best to leave these services disabled – so they cannot be abused. You can turn these services on (as needed) through the DCUI.
Please note that ESXi will do exactly what you tell it (via the command line) without the normal 'are you sure?' prompts. This tool is suitable for those who are comfortable administering Linux servers from the command line and who also have knowledge and experience with ESXi added tools and commands.


The VMkernel records detailed log entries into a file called /var/log/messages. You can view this file by logging into the Local/Remote tech support prompts (as root) and issuing the command: # less /var/log/messages

You can see the most recent entries by hitting the Alt-F12 keys on your machine's console. This display shows one screen full of the most current additions to the VMkernel log file. You should check this file if you are troubleshooting problems and need more information than is available in the vSphere client.

Hit Alt-F2 to go back to the ESXi greeter screen when done.


All command line commands entered using Local or Remote tech support are logged to /var/log messages. In this way, it is possible to reproduce the activities of prior command line sessions.


VMware makes log files and configuration files available for review in a number of different ways. The approach (above) is to use a web browser to log in to and view ESXi host configuration/web files.
VMware has a good knowledge base article on the files available using this approach here - http://kb.vmware.com/kb/2004201


You manage your ESXi host directly with the vSphere Client. This is a separate download and install available from VMware (http://www.vmware.com/download). Alternatively, you can just point your web browser over to your ESXi host and follow the vSphere Client download link found there.
All VMware client to server connections are encrypted using strong encryption. The encrypted link is set up before any data is exchanged between the client and the back end server.


ESXi uses self-signed digital certificates to support end-to-end encryption. All communications between VMware client and VMware server software is encrypted using strong encryption.

Since self-signed digital certificates cannot be independently verified by a 3rd party Certificate Granting Authority (CA), a warning is issued. It is (usually) safe to permanently disregard this warning.

It is possible to acquire an SSL certificate from a Certificate Authority (CA) and then install that certificate onto your ESXi host. This would eliminate the warning messages because a trusted certificate can be used to verify that the host is who it says it is.

Normally trusted certificates are used on Internet facing hosts to ensure the integrity of web requests (e.g.: for secure banking/payment systems, etc.). Since your ESXi hosts won't be directly on the Internet, there is no need (and no benefit) to purchasing a trusted certificate for your machine.

CA generated certificates are also a good idea (and may be mandatory) in organizations where security is critical. Such organizations will run their own Certificate Authority and will have policies that all servers on their internal network must use digital certificates created by and verifiable from the central CA.

vSphere Client > ESXi Host

By default, the vSphere Client warns you whenever any command line service is enabled. To avoid the distraction, we have manually turned off these warnings. Since granting command line access is normally not a good idea, presenting these warnings makes sense.
There are some situations where you want to enable command line access and don't want to be bothered about the fact that these service(s) are turned on. To disable command line warning sin the vSphere Client, please check out the following Knowledge Base article:


You can create local ESXi user accounts with passwords to allow for local authentication (for both the vSphere client and Local/Remote Troubleshooting – if enabled). To do this click on the Local Users & Groups tab and then right-click the back ground and select Add.... You can make new groups by clicking the Groups button and then right-clicking the background.

Best Practice

You would create local accounts only if you do not have an Active Directory service available. Otherwise, it is a best practice to join an AD domain and use domain accounts.


To command line log into ESXi over the network (from Windows, ESXi Remote Troubleshooting Mode must be enabled) download the putty Secure Shell terminal emulator at http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

ESXi Host Roles

ESXi 6.0 can join an Active Directory domain. AD authentication allows you to set up access rules for ESXi login without having to create local user accounts on ESXi. To join an ESXi host to an AD domain, you must have a domain account with Add Host to Domain privileges set.


Joining an AD domain is the first step to allowing AD defined users to access ESXi directly. The second step is to select inventory items (your ESXi host, folders, VMs, Resource Pools) and assign these users rights on these items. Without specific permission assignments, AD based users will not be able to interact with ESXi – as the default permission for all AD users is No Access.


ESXi reports on the properties of the CPUs found in your server, including:
- The make/model of the machine

- Make/model and speed of the CPUs

- Number of populated sockets

- Number of cores in the CPU

- Number of Logical Processors (sockets * cores * HT logical processors)

- Presence/Absence of Hyperthreading (Intel CPUs only)

- Presence/Absence of power management capabilities (newer CPUs only)
If you have Intel CPUs and Hyperthreading is reporting N/A you should check to see if Hyperthreading is active. To do this, click:

Properties > Hyperthreading > Enabled

This will turn on Hyperthreading support even if the machine's BIOS is set to disable it. You will need to reboot ESXi for this change to take effect.


Note: Hyperthreading is not supported on virtual ESXi hosts.
Hyperthreading is a feature baked into Intel CPUs that allows a single CPU Core to work on two tasks in lock step. The idea is to keep the CPU core busy by giving it a 2nd task when the Core would otherwise be idle waiting on a physical memory fetch (after a local Cache miss)
Hyperthreading provides a modest increase in performance under typical workloads (usually 5% to 20% increase over the same workloads on the same CPUs with Hyperthreading turned off).
Hyperthreading is especially useful when the VMkernel uses it to provide some CPU service to low priority VMs or VMs that would otherwise just run their Idle task (because they have nothing better to do).
If you use PC Servers powered with Intel CPUs, you should:
- Verify that Hyperthreading is available on your CPU

- Verify that Hyperthreading is turned on in your physical machine's BIOS

- Verify that ESXi recognizes that Hyperthreading is available and that ESXi will use Hyperthreading


ESXi uses memory in 2 ways:
1. For the VMkernel hypervisor (approximately 40MB), and

2. For virtual machines (all remaining RAM).

ESXi needs a minimum of 2GB of RAM or it will refuse to run. Adding more RAM means more room for VMs to run which should result in good performance as your VM population and RAM requirements grow.
ESXi is very frugal and hands out memory to VMs only when needed and only for as long as needed. We will explore ESXi memory scavenging techniques later in this class.


ESXi uses Network Time Protocol to ensure that it's clock remains accurate. This is important because the ESXi host provides clock services to all VMs it runs. So, any clock drift in the ESXi host will result in clock drift in VMs. If VM clocks drift by more than 5 minutes they may not be able to join or remain members of Active Directory domains.

Click the Properties... link to review and configure NTP.

Best Practice

Always set your server's BIOS clock to UTC. That way, VMs will get a UTC clock and can then set their local time zone to any region they like.
If you set the hardware clock to your local time, then VMs must all operate in your local time zone only (because they cannot calculate time zone offsets from any time zone other than UTC).


ESXi installs with an unrestricted use 60-day evaluation license. This eliminates the need to contact VMware for temporary evaluation licenses.
ESXi can be activated using a stand alone host license. A host license is issued on a host by host basis and unlocks access to feature entitlements purchased for that host. Alternatively, ESXi can draw a license entitlement for needed features from vCenter.


The vSphere Client can report on most aspects of your system's hardware health including:
- CPU sockets, cores and cache size

- Power supply, motherboard, CPU and add-on card temperatures

- Fan location, health and speed

- Hardware firmware and driver health including chipset, NIC, storage controller, BIOS functionality

- Power supply count and health (connected, disconnected, missing, etc.) and

- System boards.

Use this view to get a quick assessment of your server's physical health.


Observed IP Ranges This value displays the IP address range observed by ESXi as frames flow through each physical NIC. Here's what it's used for.
In most corporate networks, different physical LAN segments are used to isolate different types of traffic such as Production traffic, storage traffic, management traffic, back up traffic, etc. It is a common practice to use different sub-net address blocks for each physical segment.
For example, your company may subnet its network traffic as follows: – Production traffic including servers 10.

2.0.0/16 – Desktop PCs and printers – Management LAN segment for direct PC server management – Back Up LAN – IP Storage LAN (for iSCSI servers)

In the above scheme, if a physical NIC reported Observed IPs in the 10.1/16 range, you would know it was physically connected to the management LAN. If another physical NIC reported Observed IPs in the 192.168.100/24 range, then it should be used to carry back up traffic.


It is important that your management network settings are correct. After installation, it is a good idea to review these settings and fix any errors you find.
Click Properties... to edit network settings for the management network. You may need to reboot your ESXi host before these changes take effect.

ESXi System Logs
Sizing ESXi CPU, Memory
Sizing ESXi Storage, NICs
RDP, Web Remote Lab Access
Lab – Install ESXi 6.0

In this video I show you how to easily download the correct version of vSphere client for any ESXi host or vCenter Server. We'll use vSphere Client 5.x to reach out to the enterprise class PC server (running ESXi 5.5) that we will use to access our virtual lab environment.


In this video, I take you through the install steps to power on your ESXi host, boot from the ESXi 6 installer and complete a fresh install of ESXi 6. Once the install is complete we reboot our ESXi host and allow ESXi 6.0 to boot, initialize and get ready for service.


In this video, we will use the Direct Console User Interface to set base ESXi host properties.


The next step is to log back into the DCUI to confirm that our network settings are correct and that they work as expected. We will do that by using the Test Management Networking feature to ping the local gateway, the local DNS server(s) and by doing a Name-to-Address DNS lookup.

Next, we will review Troubleshooting options such as ESXi Shell (local command line console) and SSH (encrypted network command line sessions). These services can be used to administer and troubleshoot your ESXi host.


In this video we take a brief tour of the ESXi host via vSphere Client. We check out the Configuration tab and use the Hardware and Software box to review the ESXi hosts' processors, memory, network adapters, storage controllers, storage volumes and available licensed features.


In this video we see how to create and test ESXi local user accounts, how to add ESXi to an Active Directory domain so that we can set domain account privileges, how to synchronize ESXi hardware clocks to a Network Time Protocol (NTP) time source to achieve accurate VM times and how to review and update the ESXi host CPU Power Policy.


A short video on how to navigate to the system logs function, how to review the three ESXi system logs (hostd.log, vmkernel.log and vpxa.log) and how to create and download a log bundle


ESXi Shell (host console command line access) and Secure Shell (network command line access) can be used to provide support and perform administration on an ESXi host. VMware recommends these services be disabled by default. If you decide to enable them, you will receive yellow warning banners in vSphere Client. In this video, I'll show you how to suppress these warnings while leaving ESXi Shell and SSH enabled.


In this video I show you how to upload ESXi Host Client to an ESXi host, how to install it using esxcli, how to access an ESXi host using a web browser and how to navigate the host with Host Client.

Host Client is important because VMware is retiring vSphere Client - there will be no vSphere Client software for vSphere 6.5 (expected late 2016). So it is a good idea to install Host Client now so that you have the time to become familiar with it.

Review & Questions
Section 3: Virtual and Physical Networking
Introduction to Virtual Networking
The next step in our virtual infrastructure build out is to look at virtual and physical networking. In this chapter we will examine the role virtual switches play and see how they are created, configured and up-linked to physical LAN segments.
Chapter Outline

Standard vSwitches

Standard network virtual switches are configured within individual ESXi hosts. They provide VM – VM networking, VM – Physical networking, management traffic and VMkernel to NAS, iSCSI and VMotion networking. Standard network vSwitches are internal to each ESXi host and have no visibility to other hosts.

Distributed vSwitches

Distributed vSwitches are a new type of vSwitch that spans multiple ESXi hosts. Distributed vSwitches create the illusion of a single large, flat LAN segment that can be used for direct VM to VM networking regardless of the host on which each VM resides. In this manner, Distributed vSwitches greatly simplify network design and deployment.

Distributed vSwitches support vLAN's. So, a single Distributed vSwitch can have multiple VLAN s, and VMs can connect to the same VLAN across multiple hosts. This capability gives the virtual network administrator the ability to create isolated VLAN segments on top of a large, Distributed vSwitch.


The above example shows a single ESXi host with multiple, independent standard vSwitches. Each vSwitch can be configured to carry any of Management, VMotion, iSCSI, NAS or VM network traffic. For a VM connected to one vSwitch to talk to a VM connected to a different vSwitch, network traffic would have to flow through a physical switch.


Distributed vSwitches are software objects that emulate a standard layer 2 network switch – that is, they forward Ethernet frames by destination MAC address and switch port number (which is maintained by a MAC/Port table on the switch). Distributed vSwitches span multiple ESXi hosts and provide consistent network functionality across all VMs, etc. that are plugged into the distributed vSwitch.
A distributed vSwitch has a single common MAC table. It has a unified set of performance counters. It's configuration spans all ESXi hosts. This last property is especially helpful for VMotion because the VM will find exactly the same Port Group (configured exactly the same way) on any ESXi host that shares the distributed vSwitch.
Distributed vSwitches are created and managed with the vSphere Client. You must have vCenter to create and use a distributed vSwitch.


The VMkernel owns all hardware resources including NICs. The VMkernel has native NIC drivers for a limited number of physical NICs including the Intel EtherPro series and also the Broadcom NetXtreme family of NICs and others. Note that consumer NICs (Realtek, Via, SIS, etc. are not supported by ESXi)
ESXi 6.0 supports for Jumbo Frames (up to 9,000 byte MTUs rather than the standard 1,500 byte MTU). If your physical network switches and physical peer devices (iSCSI SAN, File Sharing appliances, routers, etc.) also support Jumbo Frames, you should see a substantial performance gain from this feature. The author has experienced iSCSI SAN performance increases of 5-40% with Jumbo frames over standard (1500 byte MTU) frames. (Yes, sometimes the performance improvement is negligible – so you have to test your environment to find out if it will benefit you.)
In vSphere 5.5, VMware introduced support for Mellanox ConnectX 40 Gigabit Ethernet NICs. VMware 6.0 supports up to 4 Mellanox Technologies InfiniBand HCA devices with the nmlx4_en driver provided directly from Mellanox. See http://www.mellanox.com


Virtual machine hardware can include up to 10 virtual NICs. Virtual NICs are implemented in software that faithfully emulates hardware. VMware supports the Intel EtherPro MT GB NIC. This NIC is a native Gb NIC that is supported by most modern OS' and the vmxnet3 virtual NIC


Virtual NICs plug into Virtual Switches. Virtual Switches are software objects that emulate physical NICs. They work by mapping NIC MAC addresses to switch ports. Like a physical switch, a virtual switch will, upon receipt of a frame, look up the port associated with that MAC address and forward the frame to that port.
For now, it is best to think of Virtual Switches as 'dumb', unmanaged switches. In reality they are anything but dumb and, as we will see later on, virtual switches contain security and redundancy capabilities that even the best physical switches lack.
vSphere 5.0 and higher also supports the Cisco Nexus v1000 software distributed vSwitch. This is a for-cost add-on distributed virtual switch that behaves like a standard Cisco managed switch. Organizations that have standardized on Cisco managed switches will appreciate the ability to manage Cisco Nexus virtual switches with the same tools used to manage Cisco physical switches.
Configuration maximums from VMware's vsphere-60-configuration-maximums.pdf document. Search VMware.com for this document.


Virtual switches can be configured in three modes:

Internal Only

Internal only virtual switches inter connect virtual machines and create isolated VM to VM LAN segments. Use internal virtual switches whenever you need to create a DMZ, want to create a truly private test segment or whenever you want two or more VMs to network together at the fastest possible speed.


Like physical switches, virtual switches can be up linked – but only to a physical switch. When you uplink a virtual switch to a physical switch, you create a larger common LAN segment across the switches. When you assign a physical NIC to a virtual switch, that NIC acts to uplink the virtual switch with the physical switch to which the physical NIC is connected.
The result is a larger LAN segment that contains both physical nodes (the physical switch and devices plugged into the physical switch) and virtual nodes (VMs plugged into the Virtual Switch). The result is a heterogeneous network of both virtual and physical devices all operating at Network Layer 2.

Teamed Virtual Switches

When a NIC is used to uplink a Virtual Switch to a physical switch, all virtual-physical network traffic must flow through that one NIC. This may limit performance and it creates a single point of failure. By adding more NICs to the virtual switch a NIC team is created that provides both improved performance and redundancy.


Internal/Isolated Virtual Switches

Internal or Isolated virtual switches create internal, private network segments for the exclusive use of Virtual Machines. These software-only devices forward packets between VMs that are plugged into the virtual switch.
Because the virtual switch is 100% software, none of the undesirable attributes of physical networking are present. There are no transmission errors, no collisions and, no network signaling speed limits.
The result is that all traffic on internal virtual switches is perfect (free of collisions, errors). The rate at which packets flow through virtual switches is determined by the speed of the host CPU and RAM (as virtual switches are software entities).
The result is that internal only virtual switches should be able to forward packets at a much higher rate of speed than a corresponding physical NIC


Outbound Virtual Switches

Outbound virtual switches are virtual switches that own a physical NIC. Physical NICs assigned to a virtual switch act like an up link port because they act to connect the virtual switch to the physical switch.
On the virtual side, VMs must connect their vNIC(s) to a virtual switch in order to exchange network traffic. If the VM's peer is a physical device, the virtual switch will forward the packet to the uplinking physical NIC.
When a packet flows though the virtual switch to the physical NIC, the physical switch learns the MAC address of the VM and adds that MAC address to its MAC table. This is how the physical NIC learns that there is a VM (or many VMs) behind the port used by a physical NIC.
So, when the physical switch receives a reply packet destined for the VM, it looks up the VM's MAC address in its MAC table and then forwards the packet to the physical NIC. The virtual switch runs the physical NIC in promiscuous mode. This allows the virtual switch to receive packets destined for many VMs through one physical NIC.
You can customize the MAC address of a virtual NIC. To do this, power down your VM > Edit Settings > NIC and replace the MAC address with one that suits your needs.
All Organizationally Unique Identifiers (first 3 bytes of a MAC address) are listed here: http://standards.ieee.org/develop/regauth/oui/oui.txt


Teamed Outbound Virtual Switches

One problem with outbound virtual switches is that all network traffic that flows between virtual and physical network nodes must flow through one NIC. This creates the potential for performance problems and a single point of failure. An easy way to resolve both problems is to promote the outbound virtual switch to a teamed virtual switch. This can be done easily by adding additional physical NICs to the virtual switch.
When a virtual switch is promoted to a team, it distributes network traffic (using various policies) throughout all NICs in the team. This provides the virtual switch with more bandwidth thereby reducing the chance that network traffic will bottleneck at the virtual switch.
You can assign up to 8 physical NICs to a team. NICs can be hot added( while the switch is in use) without the risk of packet loss. When a NIC is added to a virtual switch, the switch will rebalance the NIC team to distribute network traffic across all physical NICs.
NIC Teams also provide redundancy. If a NIC in a team fails (cable pull, switch port failure, NIC failure) the virtual switch will remove the failed NIC from the team and rebalance network traffic across the surviving NICs. This is completely transparent to VMs. VMware's implementation of NIC teaming is fully 802.3AD NIC Team, and also Link Aggregation Control Protocol (LACP) standards compliant.


Virtual Switch Properties

Virtual switches have two distinct sets of properties; what happens on the virtual side of the virtual switch (where VMs connect to the virtual switch) and what happens on the physical side of the virtual switch (on the physical NIC(s) assigned to the virtual switch).

Virtual Side

The virtual side of a virtual switch is perfect... no errors, no collisions and no wirespeed limitations. Packets are forwarded at host CPU and RAM speed and performance should far exceed the capabilities of physical networking.
Because virtual networking is implemented using host CPU and RAM, packets will move more quickly through your virtual switches if host CPU and RAM are not over committed. Also, faster host CPUs including larger caches may contribute to improved virtual networking performance.

Physical Side

Network traffic flowing between the virtual switch and uplinked physical switches, through assigned physical NICs, is limited by the realities of Ethernet networking. This includes the possibility of errors and collisions (on busy segments) as well as speed set by the negotiated (or assigned) signaling speed (10/100, GB or 10GB).


Multi-homed VMs

You can plug up to10 virtual NICs into a VM. Because the NICs are not subject to failure or hardware speed limitations, there is no need to add virtual NICs to a VM for performance or redundancy purposes (i.e.: a virtual NIC team). The only reason to add another NIC to a VM is because you want to plug your VM into another LAN segment.
In the example above, the multi-homed VM could function like a Network Address Translation (NAT) firewall, forwarding some packets from the Production physical network to the protected (isolated) VM but filtering others. In this way, it is possible to protect VMs that run sensitive workloads from direct network access.
Because we are using a VM to protect our private LAN segment, we gain advantages that a physical firewall cannot offer. In our firewall VM, we could also run:
- Web and other proxy services to reduce the load on the protected VMs

- Intrusion detection software (IDS) to look for attempted malicious network packets

- Enhanced logging

- etc.
Furthermore, firewall VMs can be replicated easily, deployed at little to no cost and customized to meet your needs – making them useful for protecting your network from corporate backbone traffic or even the Internet. A great example of a simple virtual Firewall appliance is IPCop, available at www.ipcop.org


Virtual Switch Connection Types

Virtual switches support two distinct connection types; VMkernel Ports and VM Port Groups.

VMkernel Ports

The VMkernel uses it's own network stack to implement VMotion, IP Storage and NFS access. Before using any of these services you must have (or create) a VMkernel port on the virtual switch that will connect you to the network peer (VMotion peer, iSCSI SAN or NFS server).
VMkernel ports are also used as management ports that connect the ESXi host to physical LAN segments. You created a VMkernel management port implicitly when you installed ESXi. You can add additional VMkernel ports as needed for VMware Fault Tolerance (real time replication of a VM for hot recovery purposes), additional management ports (on different LAN segments), etc.
Port Groups

A Port Group is a named collection of virtual switch ports that share common properties. VMs plug into port groups (and inherit the port group properties) rather than plugging into virtual switch ports directly. It is sufficient to associate a VM's NIC with a port group; the port group takes care of selecting the virtual switch port and setting its properties appropriately


Ports and Port Groups

As previously mentioned, VMs plug into predefined port groups. Port Groups can be created for any purpose and generally serve to assign VMs a common set of properties (Security, Traffic Shaping, NIC teaming and VLAN properties). That way, you don't have to assign these properties on a port by port basis (like physical switches).
Properties that can be set at the Port Group level include:
● VLAN tag ID

● Security settings

● Primary and stand by physical NICs

● Traffic shaping (rate limiting outbound network bandwidth)
VMkernel Ports

The VMkernel implements its own networking service through VMkernel ports on virtual switches. Every time you define a new service for the VMkernel you must have available (or create) a VMkernel port, on the appropriate virtual switch through which the VMkernel can connect to it's network peer.
VMkernel ports are shared. That is, a VMkernel port configured for VMotion can also be used for iSCSI SAN connectivity if the VMkernel can reach both physical peers on the same network, through the same physical NIC(s).


Add Network Wizard

The Add Network Wizard is the tool for changing your current virtual network configuration. You can launch the Add Network wizard as follows:
Inventory > Click your ESXi host > Configuration Tab > Networking > Add Networking...
The first question the Wizard asks is, what type of connection do you wish to define? Once you select the type of connection you wish to add, the Wizard adjusts so that you can supply the information needed to create your new network connection.


Current Network Configuration

To view your current network configuration: Configuration > Networking
When naming your Ports and Port Groups, use only Alphabetics, Digits, and +, -, _ and blank.
Networking provides a pictorial view of your ESXi hosts current network configuration. This view is organized by virtual switches (named vSwitch#) and then by ports and/or port groups defined on each vSwitch.
You can add virtual switches with the Add Networking... link in the upper right hand corner of this view (clipped). You can review or edit the properties of any virtual switch by clicking the Properties... link beside each virtual switch.
Note the call out icons to the right of a vSwitch on this view. These icons, when clicked, pop up a window that provides Cisco Discovery Protocol (CDP) properties for the virtual switch. CDP is an industry standard protocol for querying switch properties. VMware has implemented a subset of CDP to make virtual switches more compatible with popular enterprise network management software. For this to work, it must be enabled on the ESXi command line and you must have your virtual switches uplinked to Cisco managed switches.
Clicking call outs to the left of a vSwitch Port or Port Group displays the configuration of the associated Port or Port Group.


AKA – also known as
In vSphere 5.5, VMware gives you the ability to change the MTU for Ethernet frames. The default is 1500 bytes. This is compatible with all Ethernet devices but is not optimized for storage (iSCSI) over Ethernet. If your physical networking gear (NICs and switches) support Jumbo frames, you can now increase the MTU at the vSwitch level to allow for full 4k (4096 byte) or 8k (8192 byte) block transfers in frame.

Create/Update a NIC Team

Cisco Discovery Protocol (CDP) Properties
CDP is a way for Cisco aware devices to either Advertise their properties to other devices, listen for other device property broadcasts or to perform both functions (Advertise and listen). You need to enable CDP support on the ESXi command line interface as follows:
# esxcfg-vswitch --set-cdp advertise vSwitch0

# esxcfg-vswitch --set-cdp listen vSwitch0

# esxcfg-vswitch --set-cdp both vSwitch0
Example 1 (above) enables vSwitch CDP advertising (of properties) to other CDP aware devices but won't listen. Example 2 will listen but not advertise. Example 3 will both listen and advertise CDP properties.
To get command line access, either log in to your physical machine console or ssh (perhaps using the Windows Putty application) to your ESXi host and log in as root with root's password.
Note that it may take some time before CDP information is fully updated once any of the above commands are run.


Physical NICs

You can use the vSphere Client to view the physical NICs installed in your ESXi server. To do this click the Configuration Tab > Network Adapters. What you see is a roster of NICs identified by:

- Make/Model of NIC. In the example above there are three Broadcom NICs

- Speed and Duplex setting for the NICs - Configured – NIC auto-configured or forced to a specific setting

- vSwitch – the virtual switch that is using this NIC (or none)

- Observed IP ranges – Packet headers flowing through the NIC are examined and ESXi attempts to infer the (sub)network range of IP addresses being handled by the NIC. This is useful in determining which NIC is plugged into which network segments. Note that ESXi only looks at packet headers and not payload. No attempt is made to capture data or derive any information that would not be visible to any physical switch.

Students Who Viewed This Course Also Viewed

  • Loading
  • Loading
  • Loading

Instructor Biography

Larry Karnis, VMware vSphere Consultant/Mentor, VCP vSphere 2, 3, 4 and 5

Get VMware vSphere and View trained here... on Udemy!

What do you do if you need to learn VMware but can't afford the $4,000 - $6,000 charged for authorized training? Now you can enroll in my equivalent VMware training here on Udemy!

I have created a six courses that together offer over 32 hours of VMware vSphere 6 lectures (about 8 days of instructor lead training at 4hrs lecture per day). With Udemy, I can provide more insight and detail, without the time constraints that a normal instructor led training class would impose. My goal is to give you a similar or better training experience - at about 10% of the cost of classroom training.

I am an IT consultant / trainer with over 25 years of experience. I worked for 10 years as a UNIX programmer and administrator before moving to Linux in 1995. I've been working with VMware products since 2001 and now focus exclusively on VMware. I earned my first VMware Certified Professional (VCP) designation on ESX 2.0 in 2004 (VCP #: 993). I have also earned VCP in ESX 3, and in vSphere 4 and 5.

I have been providing VMware consulting and training for more than 10 years. I have lead literally hundreds of classes and taught thousands of people how to use VMware. I teach both introductory and advanced VMware classes.

I even worked for VMware as a VMware Certified Instructor (VCI) for almost five years. After leaving VMware, I decided to launch my own training business focused on VMware virtualization. Prior to working for VMware, I worked as a contract consultant and trainer for RedHat, Global Knowledge and Learning Tree.

I hold a Bachelor of Science in Computer Science and Math from the University of Toronto. I also hold numerous industry certifications including VMware Certified Professional on VMware Infrastructure 2 & 3 and vSphere 4 & 5 (ret.), VMware Certified Instructor (ret.), RedHat Certified Engineer (RHCE), RedHat Certified Instructor (RHCI) and RedHat Certified Examiner (RHCX) as well as certifications from LPI, HP, SCO and others.

I hope to see you in one of my Udemy VMware classes... If you have questions, please contact me directly.



Larry Karnis

Ready to start learning?
Take This Course