Вы находитесь на странице: 1из 71

Contact About the Author Hire Me Huur mij in!

Search by Google
Search

Kies uw NAS server iSCSI - Storage Lösungen


Stel zelf uw NAS server samen, snelle rapidSAN iSCSI Speichersysteme von
levering en scherpe prijs Einstiegs- bis zu High-End Lösunge
www.hpsindustrial.nl www.ntecgmbh.de

HOME VMWARE OTHER IT STUFF BLOG SEARCH

Home - VMware - VCP 4.0 Preperation - All in One

- VCP 4.0
Words of gratitude
Written by Matthijs van den Berg

Monday, 15 February 2010 11:32

This guide did not form itself. I would like to thank:

Resource Rent
The test environment used to test all settings and create VMs to toy around with was provided by Resource Rent. A cloud computing provider using VMware as
default (and of cause reliable) platform!
FastOne - IS
My web hosting provider.. for helping me out when the site (SEO part) was broken once again..
My Girl..
For not complaining when I was working again.. (or studying.. accepted better ;-0 )
All who have replied and contributed to this guide!

How to read / use


Written by Matthijs van den Berg

Monday, 26 October 2009 14:59

I have written this study guide based upon the VCP 4.0 blueprint released by VMware. This blueprint outlines the study objectives to master before going for the VCP exam.

In the blueprint consists of bullets with objectives. I have used those bullets and placed my answer directly below the objective. You will find that some fat text and colors
are used:

• Fat test after a bullet – This is a objective / question from the blueprint
• Orange text – this is a hyperlink to a site with more information about the subject

All other text is (supposed) to be written by me or in some cases (minimized) copy / passed from a VMware whitepaper or Internet site. If another source then mentioned
under “Tools” at the bottom of the objective is used, this is mentioned.

Hope you learn some.


Hope you learn some.

Regards,

Matthijs

VMware Certified Professional on vSphere 4 – Learning guide


Written by Matthijs van den Berg

Tuesday, 06 October 2009 10:12

Hi All! I haven’t even finished my Design Expert certification yet but couldn’t wait to start with my VCP 4.0 any longer. There is huge demand for VCP 4 professionals and
vSphere is being deployed all over.

Since I did not wanted to take the training I did my exam before the 1st of January 2010. I passed.. but for all of you out there I finished the parts of the learning guide that i
did not finish before my exam date.

As of today, valentines day 2010 the 14th of February, the guide is done!

Of cause, when comments and improvements come in, I will adjust the guide! So keep them coming, I have received many responses via the commend system as well as
e-mails. Please keep them coming! Really motivating!

If you have any comments, feel like helping me out of are just in the mood of dropping me a line, please feel free to do so.

Enjoy reading and I hope this helps you guys out there!

Regards,

Matthijs

PS Use the menu in the upper right of the page to navigate through the items of the learning guide!

PS 2 on advice of Mike I have published a preliminar version in PDF format. Download it here. Only Chapter 8 is missing (dd 23-11-2009)
Working on it...

Objective 1.1 - Install VMware ESX/ESXi on local storage


Written by Matthijs van den Berg

Tuesday, 06 October 2009 09:31

Knowledge

Identify minimum hardware requirements


The minimum hardware requirements are stated in the Installation Guide or the Best Practice Guide. In short these are for: ESX

2 x 64 bit processor
2 GB RAM

For vCenter Server the specs are:


Processor – 2 CPUs 2.0GHz or higher Intel or AMD x86 processors. Processor may be higher if the database runs on the same machine.
Memory – 3GB RAM. RAM requirements may be higher if your database runs on the same machine.
Disk storage – 2GB. Disk requirements may be higher if your database runs on the same machine.
Microsoft SQL Server 2005 Express disk requirements. The bundled database requires up to 2GB free disk space to decompress the installation archive.
Networking – 1Gbit recommended.

Download, prepare and validate installation media


You can download the ISO files from the VMware website if you have a valid log in ID and are authorized to download vSphere ISO files. To check you can use the
MD5 checksum and during installation the verification step in the wizard. The ISO files can be mounted using tools like iLO, Daemon tools of the VI Client. When
physical installation media is required the ISO file needs to be burned to a CD / DVD. Native support is available in Windows 7 and Mac OSX. Other OSes require a
third party tool.
Determine appropriate ESX/ESXi configuration in a given situation

Obtain required information for environment


Obtain information on the following aspects about your environment:

System compatibility
I/O compatibility (Network and HBA cards)
Storage compatibility
Backup software compatibility

Verify hardware against the VMware Hardware Compatibility Guide


Before purchasing hardware it is best to validate against the VMware Hardware Compatibility Guide (HCL). This ensures the correct function of the ESX OS on
the hardware and ensures VMware support. You can find the HCL here.

Perform a custom installation

Customize storage layout for given situations


ESX hosts have required and optional partitions.
/boot and vmkcore are physical partitions. /, swap, /var/log, and all the optional partitions are stored on a virtual disk called esxconsole-<system-
uuid>/esxconsole.vmdk. The virtual disk is stored in a VMFS volume.
You can read all about the required partitions here.
And all about the optional partitions here.

Configure ESXi from the direct console


You can log on to the console the manage the system (if that is what they mean here…).
Configure ESX/ESXi NTP
Both ESX and ESXi can use an NTP (Time Server) for the time sync. This ensures that the ESX clock is always up to date.

GUI
The configure a time server change this in “Time Configuration” in the tab Configuration when a ESX server is selected

CLI
Edit:

/etc/ntp.conf

and add the time servers you deem necessary. For example:

server 0.nl.pool.ntp.org

Manage ESX/ESXi licensing

Compare/Contrast VMware vSphere editions


VMware has two lines of editions. One for Small Business and one for mid-size and Enterprise. Both lines combined this leads to 7 version of the product, 3
aimed at small businesses and 4 aimed at medium and enterprise corporations. These versions differ on the amount of resources supported and the supported
functionality. You can find a schematic overview here.

Manage license keys


License reporting and management are centralized. If you upgrade all your hosts, you no longer need a license server or host-based license files. All product licenses
are encapsulated in 25-character license keys that you can manage and monitor from vCenter Server. Each host requires a license, and each vCenter Server instance
requires a license. You cannot assign multiple license keys to a host or to a vCenter Server system. You can license multiple hosts with one license key if the key has
enough capacity for more than one host. Likewise, you can license multiple vCenter Server instances with one license key if the key has a capacity greater than one.

When you apply a minor upgrade or patch the ESX/ESXi or vCenter Server software, you do not need to replace the existing license key with a new one. If you
upgrade the edition of the license (for example, from standard to enterprise), you must replace the existing license key in the inventory with a new upgraded license
key.

Tools
VMware Hardware Compatibility Guid
VMware ESX/ESXi and vCenter Server Installation Guide
Configuration Maximums Guide
Product Documentation
VMware Virtualization Toolkit

Objective 1.2 - Upgrade VMware ESX/ESXi


Written by Matthijs van den Berg

Tuesday, 06 October 2009 13:26

Knowledge

Plan a VMware vSphere upgrade

Backup/Restore ESX/ESXi host configuration


Back Up ESX Procedure

Back up the files in the /etc/passwd, /etc/groups, /etc/shadow, and /etc/gshadow directories. The /etc/shadow and /etc/gshadow files might not be present
on all installations.
Back up any custom scripts.
Back up your .vmx files.
Back up local images, such as templates, exported virtual machines, and .iso files.

Back Up ESXi procedure

Install the vSphere CLI.


In the vSphere CLI, run the vicfg-cfgbackup command with the -s flag to save the host configuration to a specified backup filename.

Example:

vicfg-cfgbackup --server <ESXi-host-ip> --portnumber <port_number> --protocol


<protocol_type> --username username --password <password> -s <backup-filename>

Understand Virtual Machine backup options


You can find more info here.
There are several options to back-up your virtual machines. While migrating the underlying ESX hyper-visor backing up you VMs is essential. If for any reason
your ESX hosts dies, cannot access the VM’s any more of cannot use them any more you need a valid roll-back scenario. Having a decent backup is an
essential step here. Some back-up options are:

Use VCB to back-up your VMs in combination with you back-up tools for

File level backup


Image level backups

Use back-up agents in you Virtual Machines


Shutdown the VM and copy the files

Determine if existing hardware meets upgrade requirements


Verify hardware against the VMware Hardware Compatibility Guide
Before upgrading ESX it is essential to validate you hardware against the VMware Hardware Compatibility List (HCL). This ensures the correct function of the
ESX OS on the hardware and ensures VMware support. You can find the HCL here: http://www.vmware.com/resources/compatibility/search.php.
Understand VMware ESX/ESXi upgrade scenarios
More info here.
There are several way’s to upgrade you existing ESX infrastructure the vSphere / ESX 4. Besides wiping the system and starting over again with a fresh
installation (what I think is not meant here) VMware provides several in place upgrade options. These options depend on the current version of ESX / vCenter
you are running. When you upgrade from ESX 3.x/ESXi 3.5 to ESX 4.0/ESXi 4.0, you can use either the vSphere Host Update Utility or vCenter Update
Manager.

Host Update Utility


This utility is intended for small deployments with fewer than 10 ESX/ESXi hosts and without vCenter Server or vCenter Update Manager. The utility
includes a wizard that guides you through upgrades. While an upgrade is in progress, the utility provides visual status.

Update Manager
With Update Manager 4.0 you can perform orchestrated upgrades of hosts and virtual machines. Orchestrated upgrades allow you to upgrade all hosts in
the inventory using host upgrade baselines. Orchestrated upgrades can be used to upgrade the virtual machine hardware and VMware Tools of virtual
machines in the inventory at once, using baseline groups containing the VM hardware and / or VMware tools that match.

Direct, in-place upgrade from ESX 2.5.5 to ESX 4.0 is not supported, even if you upgrade to ESX 3.x as an intermediary step. The default ESX 2.5.5
installation creates a /boot partition that is too small to enable upgrades to ESX 4.0. As an exception, if you have a non-default ESX 2.5.5 installation on
which at least 100MB of space is available on the /boot partition, you can upgrade ESX 2.5.5 to ESX 3.x and then to ESX 4.0. The upgrade of ESX 2.5.5
to ESX 3.x requires the use of one of the following methods:
Graphical upgrade from CD
Text-mode upgrade from CD
Tarball upgrade using the service console
Scripted upgrade from CD or PXE server using esxupdate
Scripted upgrade from CD or PXE server using kickstart commands

Perform upgrade to ESX 4.0

Upgrade VMware ESX/ESXi


Described at the previous bullet, use the tools provided to upgrade ESX, perform a fresh install, user the CD or a scripted install from a PXE server.
Upgrade virtual machine hardware
After you have upgraded the ESX server you VM’s are (probably) not automatically updates. You can update the VM’s by hand (right click the VM and select
Upgrade Hardware) of use the update manager to automate this process. Remember that before upgrading the virtual hardware you MUST UPGRADE
VMWARE TOOLS FIRST. The new VMware tools version holds new drivers for the upgraded hardware that are essential. I you fail to upgrade the VMware
Tools you might loose network connectivity. Upgrading hardware requires the VM to be down / reboot.
Upgrade VMware Tools
Upgrading VMware Tools can be done by hand (use the VI-Client of from within the VM using the existing VMware tools) or automated using the Update
Manager. Updating the VMware tools requires a restart of the server. This restart can be combined with the reboot / shutdown needed for the hardware update,
however you cannot validate if the VMware tools install was successful before upgrading the Virtual Hardware.

Verify success of upgrade


Follow best practices when you install updates on hosts.
To ensure that each update is successful, use the following strategy:

After each update, test the system to ensure that the update was completed successfully.
If the installation was unsuccessful, revert to the last good known image. See“RollBackanESXiUpdate, Patch, or Upgrade,” on page 83 and “Uninstall a Bundle
from a Host,” on page 106.

Understand upgrade roll back options


When an upgrade fails there are roughly two way to go back to the previous situation:
When an upgrade fails there are roughly two way to go back to the previous situation:

Rollback the upgrade using the provided tools (rollback-to-esx3 command of shift-r during boot for ESXi). Read the upgrade guide for detailed instructions.

Remember that if you already upgraded your VMs this upgrade is not automatically rolled back, you need a pre-upgrade snapshot. All changes to the VM are
also not rolled back.

Perform a fresh install of the ESX operating system and restore a backup you created before. You can restore this backup using this procedure for ESX
(http://www.vmware.com/pdf/esx3_backup_wp.pdf) and the procedure described in the upgrade guide for ESXi (vSphere CLI: vicfg-cfgbackup)

Tools

vSphere Host Update Utility


vCenter Update Manager
esxupdate

Objective 1.3 – Secure VMware ESX/ESXi


Written by Matthijs van den Berg

Tuesday, 06 October 2009 15:07

Knowledge

Identify default security principles

When installing ESX use security=high (default)


Do not allow root level access over SSH and use secure commands
Disable all unnecessary services in COS
Use VCenter to help you manage granular security access
Stay current with patches
Control User Level access using VCenter

Understand Service Console firewall operation


By default all incoming connections to the service console port of an ESX server are blocked. A firewall on the ESX Server checks all incoming traffic and allows only
traffic explicitly allowed in the firewall configuration. The firewall can be configured in two way’s, from the command line and from the vCenter GUI.

Service Console Security Level


The VMware firewall protecting the Service Console has three default security levels. The default in a standard install is high resulting in a fully firewalled
(incoming and outgoing) environment.

High

Incoming ports blocked by default.


Outgoing ports blocked by default.

Medium

Incoming ports blocked by default.


Outgoing ports not blocked by default.

Low

Incoming ports not blocked by default. Low


Outgoing ports not blocked by default.

More info can be found here.


Opening/Closing ports in the firewall using the vSphere Client
The vSphere client can be used to open and close ports on a ESX host. To do so:

Select you ESX host


Go to the configuration tab
Click “Properties” in the upper right corner of the screen. In the screen that opens you can select the ports to open. To open additional, non listed, ports you
need to use the command line.
Set up user/group accounts
Because the chapter is about ESX / ESXi I presume setting up users and groups on the local ESX host is meant. Another way to authenticate user locally on a ESX
host is to enable the AD authentication for local users.

Read more here to add local users and groups

Determine applications needed for accessing the service console in a given scenario
To access the service console the are roughly two option, from the local terminal (monitor, Keyboard) or remote using a SSH (Secure Shell) Client. Linux and Mac
OSX have a SSH client by default, for Windows Putty is a favored client for accessing SSH Servers.

Before you can access a VMware ESX server with a remote client you need to explicitly allow access. Also an account to login needs to be created. Remote root
access is disabled by default, but can be enabled. This however is not a best practice!!! The most secure way is to log in as a regular user and use sudo to execute
privileged commands.

Tools
vSphere Client
ESX/ESXi Configuration Guides
Product Documentation

Objective 1.4 – Install VMware ESX/ESXi on SAN Storage


Written by Matthijs van den Berg

Wednesday, 07 October 2009 21:04

Knowledge

Configure LUN Masking


LUN Masking is used to hide certain LUNs for the ESX hyper-visor. All LUNs presented to the OS are under normal circumstances visible (assuming the LUNs are
presented on the storage array). When installing ESX on a LUN you want to be sure you only see the partition you want to install ESX on, otherwise you risk
overwriting valuable VMFS partition with VM’s. Hiding LUNs during installation is typically done on you storage array. To hide LUNs on ESX (not applicable during
install):

LUN masking has been changed since the ESX 3.x version. A new command is used:

esxcli corestorage claimrules convert

This new command allows you to (un)hide luns and the convert the previous LUN masking used in pre ESX 4 servers to the new format. To add a new LUN masking
to need to hide the LUN on every available path to the storage controller! This means that the underlying command line needs to be executed for every path. The
command to add a LUN is:

esxcli corestorage claimrule add -r <claimrule_ID> -t <type> <required_option> -P <MASK_PATH>

This and more examples can be found here.

More information on how to migrate you existing pre ESX 4 LUN masking configuration to the new format can be found here on page 94.
Prepare SAN
To prepare the FC SAN:

Connect the FC and Ethernet cables, referring to any cabling guide that applies to your setup. Check the FC switch wiring, if there is any.
Configure the storage array.

From the SAN storage array, make the ESX host visible to the SAN. (This is often referred to as creating an object.)
From the SAN storage array, set up the ESX host to have the WWPNs of the host’s FC adapters as port names or node names.
Create LUNs.
Assign LUNs.
Record the IP addresses of the FC switches and storage arrays.
Record the WWPN for each SP and host adapter involved.

Caution! If you use scripted installation to install ESX in boot from SAN mode, you need to take special steps to avoid unintended data loss. See the Hide
LUN section above!

Configure the HBA BIOS for boot from SAN.


Boot your ESX system from the ESX installation CD.

To prepare the iSCSI SAN:

Caution If you use scripted installation to install ESX when booting from a SAN, you must take special steps to avoid unintended data loss. See VMware
knowledge base article 1540.

Connect network cables, referring to any cabling guide that applies to your setup.
Ensure IP connectivity between your storage system and server. This includes proper configuration of any routers or switches on your storage network. Storage
systems must be able to ping the iSCSI HBAs in your ESX hosts.
Configure the storage system.

Create a volume (or LUN) on the storage system for ESX to boot from.
Configure the storage system so that the ESX system has access to the assigned LUN. This could involve updating ACLs with the IP addresses, iSCSI
names, and the CHAP authentication parameter you use on the ESX system. On some storage systems, in addition to providing access information for the
ESX host, you must also explicitly associate the assigned LUN with the host.
Ensure that the LUN is presented to the ESX system as LUN 0. The host can also boot from LUN 255. On storage systems that present volumes as
multiple targets rather than multiple LUNs, the volumes are always presented as LUN 0.
Ensure that no other system has access to the configured LUN.
Record the iSCSI name and IP addresses of the targets assigned to the ESX host.
You must have this information to configure your iSCSI HBA.

Configure FC or iSCSI HBA BIOS


To boot from SAN you need fibre channel adaptors that support this option. When you presented a LUN you need to enter the BIOS of the adaptor during boot time of
the server and configure the LUN you wish to boot from. During the installation of ESX this LUN is visible to install ESX onto. Specific instructions for a qLogic adaptor
can be found here. Instruction for the Emulex adaptor can be found here.
Enable BIOS
Instructions on how to enable the BIOS for Qlogic and Bootbios:
Select Boot LUN
If you are using an active/passive storage array, the selected SP must be on the preferred (active) path to the boot LUN. If you are not sure which SP is on the active
path, use your storage array management software to find out. The target IDs are created by the BIOS and might change with each reboot.

Use the cursor keys to select the first entry in the list of storage processors.
Press Enter to open the Select Fibre Channel Device page.
Use the cursor keys to select the chosen SP and press Enter.

If the SP has only one LUN attached, it is selected as the boot LUN.
If the SP has more than one LUN attached, the Select LUN page opens. Use the arrow keys to position to the selected LUN and press Enter. If any
remaining storage processors show in the list, position to those entries and press C to clear the data.

Press Esc twice to exit.


Press Enter to save the setting.

Install VMware ESX/ESXi


A detailed installation procedure can be found here.
Determine boot LUN size in a given situation
VMware recommends a partition of minimal 8 GB in size for the optional partitions. Best practice is to set the /var/log to a separate partition. More info on the best
practices: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009080
FC or iSCSI HBA BIOS
On dedicated Fibre channel and iSCSI cards a BIOS is available. Depending on the vendor of the card they function of the BIOS may vary, but mostly this BIOS is
used to allow a server to boot from a SAN / NAS. More info in the VMware Storage guide.

Tools

FC SAN Configuration Guide


iSCSI SAN Configuration Guide
Product Documentation

Objective 1.5 – Identify vSphere Architecture and Solutions


Written by Matthijs van den Berg
Wednesday, 07 October 2009 22:28

Knowledge

Differentiate VMware platform products and editions


VMware differentiated it’s product in roughly two categories with per category several area’s of attention and products. In a hierarchy this looks like:

Datacenter products

VMware Infrastructure 3
VMware vSphere 4
VMware Server
VMware ESXi (Free)
Management products in the vCenter lineup

VMware vCenter Server (formerly VMware VirtualCenter)


VMware vCenter Server Heartbeat
VMware vCenter Site Recovery Manager
VMware vCenter Lab Manager
VMware vCenter Chargeback
VMware Data Recovery
VMware vCenter Lifecycle Manager
VMware vCenter Converter
VMware vCenter AppSpeed (formerly B-hive Conductor)

Desktop products

Enterprise Desktop

VMware View
VMware ThinApp
VMware MVP
VMware ACE

Consumer Desktop

VMware Workstation
VMware Fusion
VMware Player (free)

Understand the various data-center solutions (View, SRM, Lab Manager, etc.)
VMware has developed more and more products that add functionality or help providing more up-time to you infrastructure. These additional software product can
help you solve complex business cases, add functionality of ensure your business is always on. For some of these additional products I have written a short
description:

Site Recovery Manager


This products helps you to get your virtual machines up and running really fast after a site failure. Your infrastructure has to be separated over two sites with a
network and SAN replication in place. When your production site fails this product can start a script to mount the replicated SAN volumes, change network
addresses if needed and start the VMs in a predefined order. Remember this product is for large implementations only and requires selected hardware and a
carefully planned fail-over script.
VMware Server Heartbeat
The VMware server heartbeat product helps you to make your vCenter Server implementation completely redundant. The products make a fully redundant setup
including the database, licences etc. Because the VMware vCenter Server is an important part of the vSphere infrastructure (takes care of DRS, manages the
VM’s, etc.) making this part redundant can be beneficial in certain environment. Again, mainly targeted at large infrastructures that demand high availability.
VMware Lab Manager
This product allows administrators in you organization to rapidly deploy test environments. A predefined set of VM’s can be cloned to make a dedicated and
clean environment used for development, testing etc. These VMs can be based upon the production Virtual Machines. Since Lab Manager 4 Stage Manager is
fully integrated, and is no longer available as a separate product.
Life Cycle Manager
This product allows you to deploy VM’s based upon a catalog to ensure consistency in VM deployment. You can make sure these VMs are compliant with your IT
policy and retire VMs when necessary.
VMware Converter
VMware Converter allows you to migrate virtual and / or physical machines to you virtual infrastructure. The product can import a OS on a physical host to a VM
including the installation of VMware Tools. Also VM’s from consumer products or from products of other vendors can be migrated to work on you infrastructure.
VMware View
Not quite sure wheter this belongs into this list as VMware officially stated it as a Desktop product. This product allows you to use you virtual infrastructure to
host desktops: Virtual Desktop Infrastructure or VDI. You can provide users with a per user virtual machine that they can work in. View allows for easy
management, thin provisioning etc.

Explain ESX/ESXi architecture


VMware ESX(i) is based upon the virtualization concept of separating the operating system (OS) and the underlying hardware by placing a hyper-visor in between.
This hyper-visor allows the installation of multiple OS’s on the same hardware platform. Resources are managed by the hyper-visor and divided over the guest. You
can find more info here.
Compare and contrast bare metal vs. hosted architecture
New definition per 4 February 2010 thanks to mvaughn.

We can separate 3 type of installation of an OS:

Directly on the hardware, no virtualization


Speaks for itself, no virtualization, 100% of the resources for the OS. This combination gives us the best performance (native) but when the OS has nothing to
do, the server is not utilized. In most cases when the servers is under load the hardware is still not being utilized over 10%. This is the reason why virtualization is
hot, you can run multiple OSes and utilize more resources!
Bare Metal or Type 1 Hypervisor (according the the definition of Brian Madden, explains here for workstations)
Virtualization allows you to run more operating systems on the same physical hardware resulting in a better utilized system. This virtualization layer is a thin and
dedicated layer (ESX) that does nothing else then supporting VMs with resources. When possible a VM will be given direct access to hardware resources (CPU,
MEM, NIC, etc.)
Hosted or Type 2
When using this method the virtualization layer runs on top of a OS. It uses the OS to access resources like processor and memory. The VM layer is usually not
aware of the underlying hardware; this is handled by the OS. Usually this type of virtualization has a larger performance penalty due to the extra OS layer.

Remember a lot is said about virtualization, the benefits, downsides etc. Google on Internet to find out so much more you never thought it would fit on the net. My estimation
is that if you understand the basics of virtualization and can point out the differences between bare metal and virtualization this will do for the VCP exam. If you disagree,
please use the comment system and let’s get talking!

Tools
Introduction to VMware vSphere Guide
Product Documentation
VMware vSphere Editions Comparison Chart

Objective 2.1 – Configure Virtual Switches


Written by Matthijs van den Berg

Thursday, 08 October 2009 23:06

Note: Though all / most of the commands in this section can be performed by as well the Grafical User Interface as the Command Line I will only work out the GUI part
unless especially stated. This is based upon the “Tools” section below every Objective stating the GUI much more often than the CLI. If you need CLI command to perform
you configuration please take a look at the Enterprise Administrator exam prep I have written. This guide holds much more information in regards to the CLI.

Knowledge
Understand Virtual Switch and ESX/ESXi NIC and port maximums
A Virtual Switch (vSwitch) is a switch that lives on a single ESX host. This Virtual switch is connected to the physical network as well as to other Virtual Switches via
physical ethernet connections.

A vSwitch allows for many servers (via port groups) and uplinks to be connected. Port groups are the virtual extension of VLANs. Whitin a vSwitch you can create a
portgroup with a VLAN ID allowing only the traffic between that portgroup and the “physical” VLAN. In regards to the vSwitch there are some configuration maximums:

Physical hardware

The maximum number of physical adaptors depends on the brand / model of adaptor you use. Please see the configuration maximums guide on page 5 for
more information.

Virtual Switch Maximums

Total virtual network switch ports per host (vDS and vSS ports): 4096
Virtual network switch ports per standard switch: 4088
Port groups per standard switch: 512
Standard switches per host: 248
More information about the networking introduction can be found here, and basic understanding (really helpful if you are a newbie) can be found here. All
configuration maximums can be found here.

Determine the vSwitch NIC teaming policy in a given situation


NIC teaming sets the NIC teaming policies for a vSwitch or an individual port group to share traffic load or provide failover in case of hardware failure. There are
NIC teaming sets the NIC teaming policies for a vSwitch or an individual port group to share traffic load or provide failover in case of hardware failure. There are
several ways to configure multiple NIC’s. The best configuration depends on the situation you are in. In the following bullets is described per teaming configuration in
what situation it can be used:

Load Balancing
In a load balanced configuration multiple NICs are used to handle the traffic from a vSwitch. Based upon a distribution logic (like port based, MAC based or IP
based (the last one requires a port channel on a physical switch, the others do not require switch configuration)) all traffic is distributed across the uploads
resulting in more usable bandwidth. When a NIC or uplink fails in a load balanced setup the remaining NIC handles all the traffic (after some detection and MAC
address learning downtime)
Failover 

Used with multiple NICs where only one NIC is active at a given time. When a network error occurs on the active NIC the secondary NIC can take over. This is
used when there I no need for large bandwidth or the underlying network is not redundant or capable to support redundant uplinks.

Determine the appropriate vSwitch security policies in a given situation


For the VCDX exam I have written some security riscs and defined how to combat those. Please read here (second half).
Create/Delete Virtual Switches
A virtual switch can be added using the vCenter Client. Login and follow the next steps:

Select a ESX host


Select the tab “Configuration”
Select “networking” under hardware
Click “Add Networking” in the upper right corner of the screen. The next screen shows:

Select “Virtual Machine” and click next

Select the NIC (non available in the example, but there should be) you would like to use and click next.
Add a name and VLAN for a portgroup (or no VLAN of non are configured on you physical network). (Normally you would still see the physical NICs on the right
side in the preview pane)
Click Next, check the config, and click finish.

Create Ports/Port Groups

Besides adding Port Groups during the creation of a new vSwitch (like above) you can add them later. To do so:
Select a ESX host
Select the tab “Configuration”
Select “networking” under hardware
Click “Properties” next to an existing vSwitch

Click on the “Add” button to add a portgroup


Select “Virtial Machine” to add a portgroup for VMs, next

Name the new port group, optionally set the VLAN ID, next and Finish. The new port group is now added.

Assign Physical Adapters

Select a ESX host


Select the tab “Configuration
Select “networking” under hardware
Click “Properties” next to an existing vSwitch
Select the tab “Network Adaptors”
Click “Add”
Follow the wizard to add a NIC to a vSwitch (you need a available NIC; a NIC currently not in use by another vSwitch)

Modify vSwitch NIC Teaming and failover policies

Select a ESX host


Select the tab “Configuration”
Select “networking” under hardware
Click “Properties” next to an existing vSwitch
Select the “vSwitch”
Click “Edit”
Goto the tab “NIC Teaming”

Adjust the load balancing and / or failover setting to your needs.

Modify vSwitch security policy and VLAN settings

Select a ESX host


Select the tab “Configuration”
Select “networking” under hardware
Click “Properties” next to an existing vSwitch
Select the “vSwitch”
Click “Edit”
Goto the tab “Security”

Set the security policies to your needs.

Configure VMotion
To configure VMotion you need to add a “VMkerel Portgroup” to one of you vSwitches (a dedicated vSwitch of a vSwitch with VLANs in where you VMotion network
has it’s own VLAN). To add a “VMkernel Port” you can use the Add a Port Group wizard described earlier. When you already add a portgroup you may need to enable
VMotion support on the portgroup. To do so:

Select a ESX host


Select the tab “Configuration”
Select “networking” under hardware
Click “Properties” next to an existing vSwitch
Select your VMotion Port Group and click “Edit”

Make sure the the “VMotion” checkbox is checked.

Tools
ESX/ESXi Configuration Guides
Product Documentation
VMware vSphere Client

Objective 2.2 – Configure vNetwork Distributed Switches


Written by Matthijs van den Berg

Friday, 09 October 2009 23:45

Note: I do not have a dvSwitch environment to make screenshots / test what I am writing here. So what you read is from the manuals or from my brain…. When a manual is
used you will find a link to it.

Knowledge

Understand ESX Host and port maximums for dvSwitches


A vNetwork Distributed Switch (further dvSwitch) is a virtual switch that spans multiple ESX hosts.

Unlike the previously covered vSwitch, a to an ESX host local switch, this dvSwitch has one configuration for all ESX hosts and allows for new features like network
statistics that VMotion along with the host. You need to have an Enterprise Plus license to be able to use the dvSwitch (the most expensive and feature rich version of
ESX).

However, just like the old fashioned per ESX host vSwitches a vNetwork Distributed Switch has it’s limits. Lets see:
Total virtual network switch ports per host (vDS and vSS ports): 4096
Distributed virtual network switch ports per vCenter: 6000
Distributed port groups per vCenter: 512
Distributed switches per vCenter: 16
Hosts per distributed switch: 64

Take a good look at these figures. This means that PER vCenter there can be no more than 16 switches and no more than 512 port groups! If we compare this to the
regular vSwitch we see that this allows for 248 switches PER HOST and 512 port groups PER SWITCH! Thus allowing for many more networks than a standard
switch. When being realistic no “normal” implementation will exceed 512 portgroups per virtual Center, but when implementing this for example for a hosting provider
you need to take this into account.

I think it is possible to mix vNetwork Distributed Switches with regular vSwitches, but I was unable to test this due to the lack of the right license
and the fact that I think it is too much work (sorry ;-) ) to create a virtual ESX environment for this with temporary keys. If someone know this /
is able to test this, please fill me in!

Update 15-dec-2009: Steve Desrosier left me a message about this You can have dvswitches and regular vswitches on the same server, but
you do need seperate uplinks. Thanks for the info Steve!

Determine the virtual port group NIC teaming and fail-over policy in a given situation
Can’t seem to find what I need on the net, so this one is done by head. I think that the NIC teaming and failover policy is done just like when handling a vSwitch. You
link the NIC’s to a vSwitch, and on the vSwitch you configure the failover policy. You need to link physical NICs to a dvSwitch on each ESX server that is using this
dvSwitch.

A dvSwitch allows for a more granular loadbalancing policy allowing you to team all physical adaptors into one big trunk to the ESX host. On the host you can specify
on a per Distributed Port Group basis what port group uses what NIC. For example you can assign a dedicated NIC for the Service Console needing only one NIC,
because on a failure of the network connection a different NIC temporary will be used (take the performance penealty into account!).
Determine the appropriate virtual port group security policies in a given situation
This is about promiscuous mode, MAC address changes, Forged Transmits. These techniques allow you to make your infrastructure more secure. Read more here
(second half). http://b3rg.nl/vcdx/section-2-networking/objective-2.2-install-and-configure-a-virtual-networking-infrastructure-to-meet-set-security-design-
requirements.html
Create/Modify a vNetwork Distributed Switch
Please read here on page 16. http://vmware.com/files/pdf/vsphere-vnetwork-ds-migration-configuration-wp.pdf
Create/Modify Uplink Group settings
DV Port Groups on vDS are configuration templates for a group of ports and have a similar function and purpose to Port Groups on a vSS. DV Port Groups span all
the hosts covered by a vDS, so any configuration change to a DV Port Group is reflected on all hosts covered by that vDS. To configure read here on page 17.
Create/Modify dvPort Group settings
To configure read here on page 18.
Add an ESX/ESXi Host to a vNetwork Distributed Switch
To configure read here on page 11.
Add/Delete a VMkernel dvPort
To configure read here on page 18.
Migrate Virtual Machines to a vNetwork Distributed Switch
The dvNetwork Migration and Configuration manual describes two separate methods of migrating to a dvSwitch

vDS UI only
This offers more per host control over migration, but is a longer process. Hosts do not need to be in maintenance mode so VMs can be powered up during
migration.
vDS UI and Host Profiles
This uses a reference host template and is the recommended method for bulk vDS migration and deployment on hosts with inactive VMs. Host Profiles requires
the target hosts to be in maintenance mode (i.e. VMs powered down).

Tools

ESX/ESXi Configuration Guides


Product Documentation
VMware vSphere Client

Additional Links bij Matthijs

vNetwork Distributed Switch Migration and Configuration


The Greath vSwitch debate
vSwitch architecture Disagram - HyperVizor

Objective 2.3 – Configure VMware ESX/ESXi Management Network


Written by Matthijs van den Berg

Monday, 12 October 2009 23:04

Knowledge
Modify Service Console IP Settings
The Service Console (SC) is a essential part of an ESX host to manage the system. When installing the ESX host you need to configure a SC with IP addresses, and
later on you can add additional SCs, change a SC or delete an SC. A Service Console usually is a port group within a vSwitch. This same vSwitch can be used for
other networking issues as well, but best is to limit the amount of traffic that this vSwitch has to handle, for example no IP storage traffic if possible.

To add a Service Console Interface


To change the IP settings of an existing Service Console

You can change the addres and subnet of an existing service console. Remember that when doing so you network connection will be terminated! Best is to do
so from the console.
For ESX you can type the command:


esxcfg-vswif vswif0 -i 192.168.1.2 -n 255.255.255.0

For ESXi you best use the GUI:

Select a ESX host


Select the tab “Configuration”
Select “networking” under hardware
Click “Properties” next to an existing vSwitch
Select your VMotion Port Group and click “Edit”

Select “Continue modifying this connection…”


Select the tab “IP Settings”

Change the IP settings to you needs. Remember network connectivity will probably be lost.

Configure Service Console availability


Service Console Availability can be configured in two way’s:

You can assign multiple NIC’s to the vSwitch where the Service Console is running on. When wired adequately to different switches this will provide a level of
high availability to you Service Console. It will protect you agains NIC, wire and switch failure.
The Second option is to create a second Service Console, preferable on virtual and physical different network segments. This option has some more
configuration as for the second SC a gateway has to be configured via the advanced network settings. There are many good walkthroughs out there who can
help you to configure this. Read more here. http://communities.vmware.com/thread/227140 This will protect you againt all the failures a second NIC will, and also
helps to combat configuration issues you might have on the service console / service console IP settings.

Configure DNS and Routing settings for an ESX Host
To make you Service Console work adequately and reachable setting up you IP settings, including DNS
resolvers and IP gateway, is essential. The DNS will be used for resolving hostname, and Is required for a decent operation of techniques as HA and DRS. A correct
resolvers and IP gateway, is essential. The DNS will be used for resolving hostname, and Is required for a decent operation of techniques as HA and DRS. A correct
IP routing / IP gateway is needed for you SC to be reachable from other IP subnets. 
Both those settings can be configured from the GUI and the CLI.

DNS – GUI
To configure DNS settings via the GUI:

Select a ESX host


Select the tab “Configuration”
Select “DNS and Routing” under “Software”
Select “Properties” in the upper right corner

Adjust the DNS servers and domain name(s) to your needs.

DNS – Command line
To change the DNS settings from the commandline:
Edit the file /etc/resolv.conf

This file holds the DNS servers for name resolution and the local domain name. Example:


nameserver 192.168.1.1
nameserver 195.241.77.55

search b3rg.local

More info and advance settings can be found here under “Configure Hostname Resolution”.

Routing – GUI
To configure DNS settings via the GUI:

Select a ESX host


Select the tab “Configuration”
Select “DNS and Routing” under “Software”
Select “Properties” in the upper right corner
Select the tab “Routing”
The SC default gateway is used for your service console, the VMkernel default gateway is used for you storage IP settings. Adjust to your needs.

Routing – CLI
VMware allows a default gateway for iSCSI, VMkernel and VMotion (when separated on different networks) but does not require one. You can set the VMkernel
default gateway / gateway of last resort with the command:

esxcfg-route <DefaultGatewayIP>

You can add additional or specific routes with the following command:

esxcfg-route -a default <Subnet> <GatewayIP>

During some surfing on the web I found this forum posting on the VMware website. Apparently it is not possible to have a separate gateway for you Service
Console and for IP based storage on ESXi (ESX should work). This means that if you would like to use IP based storage on ESXi you need an interface in the
same subnet as you SC is. Read more here.

Tools
ESX/ESXi Configuration Guides
Product Documentation
VMware vSphere Client

Objective 3.1 – Configure FC SAN Storage


Written by Matthijs van den Berg

Wednesday, 14 October 2009 23:56

Knowledge
Identify FC SAN hardware components
When you decide to use a SAN with you VMware environment first make sure that this particular SAN is on the Hardware Compatibility List (HCL). A SAN is build up
out of several components:

SAN Controller
This is the controller that controls disk, creates LUN and presents these LUNs to your ESX hosts. The controller is managed from a web based console or by
using a software suite. This of course depends on you SAN vendor.
SAN Switches
The SAN controller and the ESX hosts are connected by means of SAN switches. You can think of SAN switches like Ethernet switches, but they cannot be
mixed, SAN switches only switch the FC protocol. Usually zoning is in place a SAN switch. Zoning creates separate segments (like VLANs when compared to
Ethernet switches) the separate the devices in the fabric (a fabric is a collection of a SAN controller, SAN Switch and HBA on a single path. When using a
redundant setup you usually have two fabrics, read more here.
Host Bus Adaptor
Within the ESX host a Host Bus Adaptor (HBA) is used to connect to the SAN switch. Again, also the HBA has to be supported by VMware and be listed on the
HCL. Configuration of SAN LUNS is done from the Virtual Center or from the command line of the ESX host.

Identify how ESX Server connections are made to FC SAN storage


When you have a SAN connection over two fabric and you SAN controller has two active controllers you have four paths to your storage. To combine those four to
one usable path you need Multi Pathing (standard installed on ESX). This is default behaviour of many SANs including most HP EVA storage arrays. In vSphere
enterprise plus you can use storage plugins from you vendor that will optimize multipathing for you. In the other editions you can do this manually. Using multipathing
can improve you SAN bandwidth with factor 4 (or more / less depending on the number of path to a storage array you have).
Describe ESX Server FC SAN storage addressing
Storage on a FC SAN is presented to a ESX host as a LUN (Logical Unit Number). A storage array usually can present up to 256 LUNs per storage controller. When
a LUN is presented to an ESX host it will be given a unique identifier existing of 4 digits separated by :. Example; 1:0:0:2. In order these digits represent: Adapter,
Channel, Target, LUN.
To find this

GUI

Select a ESX host


Select the tab “Configuration”
Select “Storage Adaptors”
Select you HBA
Look at the “Runtime Name”

CLI

Open a Command line to you ESX server


Type:

esxcfg-mpath –l

A large list of LUN details appear. Look at:

Adapter: vmhba1 Channel: 0 Target: 0 LUN: 2

Describe the concepts of zoning and LUN masking


To hide certain LUNs from the ESX hypervisor you can use two techniques; zoning and LUN Masking

Zoning
Zoning is a technique typically implemented on your SAN switches. Zoning makes segments on SAN switch that separate traffic and allows only hosts configured
in that zone to see each other. Zoning is quite straight forward and allows a host based segmentation. When a host can see a storage controller it can see all
LUNs presented on that storage controller to the host. No LUN based granularity is possible.
LUN Masking
LUN Masking u typically implemented on the ESX server. This technique allows LUNs to be hided fromthe ESX host.

Configure LUN masking


LUN Masking is used to hide certain LUNs for the ESX hypervisor. All LUNs presented to the OS are under normal circumstances visible (assuming the LUNs are
presented on the storage array). When installing ESX on a LUN you want to be sure you only see the partition you want to install ESX on, otherwise you risk
overwriting valuable VMFS partition with VM’s. Hiding LUNs during installation is typically done on you storage array. To hide LUNs on ESX (not applicable during
install):

LUN masking has been changed since the ESX 3.x version. A new command is used: “esxcli corestorage claimrules convert”. This new command allows you to
(un)hide luns and the convert the previous LUN maksing used in pre ESX 4 servers to the new format. To add a new LUN masking to need to hide the LUN on every
available path to the storage controller! This means that the underlaying command line needs to be executed for every path. The command to add a LUN is:

esxcli corestorage claimrule add -r <claimrule_ID> -t <type> <required_option> -P <MASK_PATH>

This and more examples can be found here.

More information on how to migrate you existing pre ESX 4 LUN masking configuration to the new format can be found here on page 94.

Scan for new LUNs


When new LUNs are presented from the storage controller to ESX hosts the ESX host needs to scan for LUNs before they are visible on the system. Do to so we use
the GUI:

Select a ESX host


Select the tab “Configuration”
Select “Storage Adaptors”
Select the HBA to where the new LUNs are presented
Click “Rescan” in the upper right corner

Optionally adjust where to scan for


Click OK to start scanning. This process van take a few minutes depending on you configuration.
On ESXi, it is not possible to rescan a single storage adapter. If you rescan a single adapter, all adapters are rescanned.

Determine and configure the appropriate multi-pathing policy


Multipathing is a technique to optimize the usage of all paths to a storage controller. To manage storage multipathing, ESX uses a special VMkernel layer, Pluggable
Storage Architecture (PSA). The PSA is an open modular framework that coordinates the simultaneous operation of multiple multipathing plugins (MPPs). You can
choose to use the default build in Native Multipathing Plugin, or use a vendor procides policy. The native pathing policies that can be used with ESX 4 are:

Most Recently Used (MRU)


Selects the first working path discovered at system boot time. If this path becomes unavailable, the ESX host switches to an alternative path and continues to
use the new path while it is available. This is the default policy for LUNs presented from an Active/Passive array.
Fixed (Fixed)
Uses the designated preferred path, if it has been configured. Otherwise, it uses the first working path discovered at system boot time. If the ESX host cannot use
the preferred path, it selects a random alternative available path. The ESX host automatically reverts back to the preferred path as soon as the path becomes
available. This is the default policy for LUNs presented from an Active/Active array.
Round Robin (RR)
Uses an automatic path selection rotating through all available paths and enabling the distribution of the load across the paths. For Active/Passive arrays, only
the paths to the active controller will used in the round robin. For Active/Active arrays, all paths will used in the round robin. This policy is not currently supported
for LUNs that are part of a Microsoft Cluster Service (MSCS) virtual machine.

These only apply to VMware's Native Multipathing (NMP) Path Selection Plugins (PSP). Third party PSPs have their own restrictions.

VMware does not recommend changing the LUN policy from Fixed to MRU as this policy is based on the array that has been detected by the NMP PSP.

Switching to Round Robin is safe and supported for all arrays.

Differentiate between NMP and third-party MPP


The VMkernel multipathing plugin that ESX provides by default is the VMware Native Multipathing Plugin (NMP). The NMP is an extensible module that manages
subplugins. There are two types of NMP subplugins

Storage Array Type Plugins (SATPs)


Selection Plugins (PSPs).

SATPs and PSPs can be built-in and provided by VMware, or can be provided by a third party.
If more multipathing functionality is required, a third party can also provide an Mulitple Multipathing Plugin (MPP) to run in addition to, or as a replacement for, the
default NMP. A MPP is provided especially for one type of storage array by you vendor and can contain specific multipathing configurations the further improve
performance.
The multipathing modules perform the following operations:

Manage physical path claiming and unclaiming.


Manage creation, registration, and deregistration of logical devices.
Associate physical paths with logical devices.
Process I/O requests to logical devices:
Select an optimal physical path for the request.
Depending on a storage device, perform specific actions necessary to handle path failures and I/O command retries.
Support management tasks, such as abort or reset of logical devices.

Tools
FC SAN Configuration Guide
Product Documentation
VMware vSphere Client

Objective 3.2 – Configure iSCSI SAN Storage


Written by Matthijs van den Berg

Wednesday, 14 October 2009 22:28

Knowledge
Identify iSCSI SAN hardware components
Like a Fibre channel SAN a iSCSI SAN is build up out of three components (normal setup). We find:

iSCSI Target
This is the controller of the disk and the device that converts the undelaying disk technology (for example SCSI) to iSCSI traffic on a network.
Switch
The iSCSI target is connected to the network. The iSCSI initiators talk to the iSCSI target over this network layer. A regular ethenet switch can be used, but a
dedicated VLAN, or even better, a dedicated switch with jumbo frame support is recommended. Minimum speed must be gigabit.
iSCSI initiator
The iSCSI initiator is the ESX host. On this host a software of hardware iSCSI initiator can be installed. Read further down for a comparison between the soft-
and hardware initiators.

Determine use cases for hardware vs. software iSCSI initiators


You can use both a hardware as well as a software iSCSI initiator within VMware. Both will do the job, but there are some differences:
Software iSCSI initiator
The software iSCSI initiator uses code from the vmkernel and requires only regular NIC’s in you ESX host. Best is to use a dedicated NIC, but using a VLAN is
possible as well. The main benefits of an iSCSI software initiator is the low cost (regular NIC of VLAN) that provides most of the functionality needed for most of
the environments.
Hardware iSCSI initiator
The hardware initiator allows for some extra functionality and less of a performance penalty on the system processor than the software initiator. Because the
handling of IP packets is not done on the system processor, but on the iSCSI hardware initiator. Also hardware initiators allow a boot from iSCSI SAN setup.
Generally only the most demanding setups require a hardware initiator but in those environments a fibre channel SAN is another way to go.

Configure the iSCSI Software Initiator


When you need a iSCSI software initiator you need to:

Create a VMkernel port for physical network adapters

Select a ESX host


Select the tab “Configuration”
Select “Networking”
Select “Add Networking”
Select “VMkernel”
Select “Create a virtual switch”
Select “Select the NICs
Go to “Port Group Properties” and enter a friendly name under Network label
Enter the IP settings
Finish

Enable the software iSCSI initiator

Select a ESX host


Select the tab “Configuration”
Select “Storage Adaptors”
Select the iSCSI Initiator
Select properties
Click “Enabled”

If you use multiple network adapters, activate multipathing on your host using the port binding technique. You can find all about multipathing here op page 33.
If needed, enable Jumbo Frames
Jumbo Frames must be enabled for each vSwitch through the vSphere CLI. Also, if you use an ESX host, you must create a VMkernel network interface enabled
with Jumbo Frames. This can only be done from the Command Line.

To set the MTU size for the vSwitch

vicfg-vswitch -m <MTU> <vSwitch>

To check if the creation succeded successfully you can use the command:

vicfg-vswitch -l

To create a Jumbo frames enabled VMkernel interface:

esxcfg-vmknic -a -I <ip address> -n <netmask> -m <MTU> <port group name>

Make sure that you use the Jumbo frames enable vSwitch to create the VMkernel interface in. To check if the VMkernel interface is jumbo frames enabled:

esxcfg-vmknic -l

Configure Dynamic/Static Discovery

Dynamic Discovery
With Dynamic Discovery, each time the initiator contacts a specified iSCSI server, it sends the Send Targets request to the server. The server responds by
supplying a list of available targets to the initiator.
Static Discevery
With iSCSI initiators, in addition to the dynamic discovery method, you can use static discovery and manually enter information for the targets.
To set-up the discovery:

Select a ESX host


Select the tab “Configuration”
Select “Storage Adaptors”
Select the iSCSI Initiator, properties
Click the tab “Dynamic Discovery” or “Static Discovery” and add a server or target.

Configure CHAP Authentication


CHAP uses a three-way handshake algorithm to verify the identity of your host and, if applicable, of the iSCSI target when the host and target establish a connection.
The verification is based on a predefined private value, or CHAP secret, that the initiator and target share.

ESX/ESXi supports CHAP authentication at the adapter level. In this case, all targets receive the same CHAP name and secret from the iSCSI initiator. For software
iSCSI, ESX/ESXi also supports per-target CHAP authentication, which allows you to configure different credentials for each target to achieve greater level of security.

Before setting up CHAP parameters for software iSCSI, determine whether to configure one-way or mutual CHAP. Hardware iSCSI does not support mutual CHAP.

In one-way CHAP, the target authenticates the initiator.


In mutual CHAP, both the target and initiator authenticate each other. Make sure to use different secrets
for CHAP and mutual CHAP.
for CHAP and mutual CHAP.

Configure VMkernel port binding for iSCSI Software multi-pathing


When there are two or more NICs available for iSCSI you can configure multipathing for redundancy and performance purposes. To do so please read here on page
32 and 33.

Important: when you would like to configure multipathing for iSCSI you must connect the iSCSI software initiator to the VMkernel ports. This can be done only by hand
via the ESXCLI.
Discover LUNs
When you have added the iSCSI initiator and added an iSCSI target you can start discovering targets:

Select a ESX host


Select the tab “Configuration”
Select “Storage Adaptors”
Click “Rescan” in the upprt right corner of the screen.

Identify iSCSI addressing in the context of the host


Not really sure if they mean IP addressing or iSCSI naming here. IN regards to IP addressing, make sure that the iSCSI initiator can reach the iSCSI target. For iSCSI
naming iSCSI qualified names take the form

iqn.yyyy-mm.naming-authority:unique name

yyyy-mm is the year and month when the naming authority was established.
naming-authority is usually reverse syntax of the Internet domain name of the naming authority. For example, the iscsi.vmware.com naming authority could have
the iSCSI qualified name form of iqn. 1998-01.com.vmware.iscsi. The name indicates that the vmware.com domain name was registered in January of 1998, and
iscsi is a subdomain, maintained by vmware.com.
unique name is any name you want to use, for example, the name of your host. The naming authority must make sure that any names assigned following the
colon are unique, such as:

iqn.1998-01.com.vmware.iscsi:name1
iqn.1998-01.com.vmware.iscsi:name2
iqn.1998-01.com.vmware.iscsi:name999

Tools
iSCSI SAN Configuration Guide
Product Documentation
VMware vSphere Client
esxcli

Objective 3.3 – Configure NFS Datastores


Written by Matthijs van den Berg

Thursday, 15 October 2009 15:41

Knowledge
Identify the NFS hardware components
To be able to add NFS datastores to your configuration you need an infrastructure that supports NFS. The following componets must be in place:

NFS Share / server


Switch
VMkernel interface for NFS support

Explain ESX exclusivity for NFS mounts


Added via commend system by Carole (THNX!): Concerning "Explain ESX exclusivity for NFS mounts", I have found this on ESX Configurate Guide - p.99 :

CAUTION When your host accesses a virtual machine disk file on an NFS-based datastore, a .lck-XXX lock file
is generated in the same directory where the disk file resides to prevent other hosts from accessing this virtual
disk file. Do not remove the .lck-XXX lock file, because without it, the running virtual machine cannot access
its virtual disk file.
Configure ESX/ESXi network connectivity to the NAS device
For the connectivity to a NFS device you need the same network configuration as you would for iSCSI, a VMkernel interface. To do so:

Create a VMkernel port for physical network adapters

Select a ESX host


Select the tab “Configuration”
Select “Networking”
Select “Add Networking”
Select “VMkernel”
Select “Create a virtual switch”
Select “Select the NICs
Go to “Port Group Properties” and enter a friendly name under Network label
Enter the IP settings
Finish

Create an NFS Datastore

Select a ESX host


Select the tab “Configuration”
Select “Storage”
Click “Add storage” in the upper right corner
Select the bullet “Network File System”, next

Fill in the required fields and finish the wizard.

Some more by Matthijs

You cannot run MSCS on NFS, this needs an block I/O device (iSCSI / FC)

Tools
ESX/ESXi Configuration Guides
Product Documentation
VMware vSphere Client

Matthijs' Links
Some people are very enthusiastic about running VMs on NFS.

Objective 3.4 – Configure and Manage VMFS Datastores


Written by Matthijs van den Berg

Thursday, 15 October 2009 15:43

Knowledge
Identify VMFS file system attributes
You can lookup the VMFS file system attributes from the command line.

vmkfstools -P -h <VMDK FILE NAME>

for example:

vmkfstools -P -h /vmfs/volumes/AOPSY001/TST001/TST001.vmdk

and a example output:

VMFS-3.33 file system spanning 1 partitions.


File system label (if any): AOPSY001
Mode: public
Capacity 931.2 GB, 359.4 GB available, file block size 4 MB
UUID: 4a6f26bb-33aca892-7b43-0024817ebe6b
Partitions spanned (on "lvm"):
naa.600508b300906430a44f208f2ba60007:1
Determine the appropriate Datastore location/configuration for given virtual machines
When you create a Virtual machine there are a couple of consideration to make when creating the vDisk. In no particular order:

Thick or thin
When you create a disk or clone a VM from template you can choose if you would like the disk you will be creating to be thick or thin provisioned. Think means
that the complete size of the disk will be reserved on the storage array. Thin will use only the size that is actually use within the Virtual Machine.
SCSI Controller Type
You can change the SCSI controller type in the properties of the VM. In vSphere there are four types of controllers you can choose from:

BUSLogic Parallel
LSI Logic Parallel
LSI Logic SAS
VMware Paravirtual

What controller you choose depends on you OS and performance needs. In general the VMware Paravirtual is the fastesed controller you can choose, but also
the controller that has the least number of operating systems that it is supported on.
Spread the disks If you have a VM with multiple disks you can spread those disk over multiple VMFS volumes. Especially when these volumes are separate
RAID sets and even better, accessed over different paths to the storage controller (or even on different storage controllers!) this can improve the performance of
a VM.
SCSI Bus Sharing
This defines if is disk can be used by one VM or by more than one VM the options are:

None
Disk is for one VM only
Virtual
Disk can be shared by VMs on the same ESX host
Physical
Disk can be shared by VMs on different ESX hosts

Determine use cases for multiple VMFS Datastores


Oops, just told you guys. But because Copy Past is really fast….: If you have a VM with multiple disks you can spread those disk over multiple VMFS volumes.
Especially when these volumes are separate RAID sets and even better, accessed over different paths to the storage controller (or even on different storage
controllers!) this can improve the performance of a VM.
Create/Configure VMFS Datastores
Before you try to add storage according to the following procedure, first check:

Are the LUNs / targets presented on the storage controller?


Is the zoning / LUN Masking configured correctly
Are the HBA’s / VMkernel interfaces configured correctly
Did you scan for new LUNs / targets after they where presented?

To create a VMFS Datastore using the vSphere client:

Select a ESX host


Select the tab “Configuration”
Select “Storage”
Click “Add storage” in the upper right corner

Follow the wizard for your type of storage

Attach existing Datastore to new ESX host


If an existing datastore (formatted etc.) is present and visible to the ESX host you can add it to the “Storage” view by:

Select a ESX host


Select the tab “Configuration”
Select “Storage”
Click “Refresh” in the upper right corner
After de refresh the disk should appear.
Manage VMFS Datastores

Group/Unmount/Delete Datastores
When a datastore is decommissioned you can delete a datastore from the storage view.

Select a ESX host


Select the tab “Configuration”
Select “Storage”
Right Click the datastore you would like to delete and confirm.

Grow VMFS volumes


To increase the size of a VMFS datastore:

Select a ESX host


Select the tab “Configuration”
Select “Storage”
Right click the datastore that you need to encrease

Click on the “Increase” button and follow the wizard.

Tools
ESX/ESXi Configuration Guides
Product Documentation
VMware vSphere Client

Objective 4.1 – Install vCenter Server


Written by Matthijs van den Berg

Thursday, 15 October 2009 22:13

Knowledge
Identify hardware requirements
The hardware requirements for a vCenter Server depend on the number of ESX hosts and Virtual Machines you plan to deploy in that environment. VMware has
made some estimation on the hardware requirements based on the number of VMs and ESX host:

Up to 200 ESX hosts a 32 bit can be sufficient, however a 64 bit server is always recommended. Above 200 ESX hosts a 64 bit server is required.
The MINIMUM requirements (thank you ITTamer!) are (can be more when the DB is on the same machine):

2 x 2Ghz CPU
3 GB RAM
2 GB Disk

The recommended setting for up to 50 ESX hosts and 250 VMs are:

2 CPUs
4 GB RAM
3GB Disk Space

The recommended setting for up to 200 hosts and 2000 VMs are:

4 CPUs
4 GB RAM
3GB Disk Space

The recommended setting for up to 300 hosts and 3000 VMs are:

4 CPUs
8 GB RAM
3GB Disk Space

Understand configuration maximums


As most of you know the vSphere environment can handle a lot, but there are maximums. VMware stated those maximums in a document that you can find here.
This document states all the configuration maximums in regards to ESX hosts, VMs, resource pools, etc. Because the is the vCenter chapter I have summarized some
of the vCenter maximums:

Item Max.

ESX hosts on 32 bit vSphere 200

VMs on 32 bit vSphere (powered on / registered) 2000 / 3000

ESX hosts on 64 bit vSphere 300

VMs on 64 bit vSphere (powered on / registered) 3000 / 4500

Linked vCenters 10

Concurrent vSphere Clients (32 / 64 bit) 15 / 30

ESX hosts / datacenter 100

Concurrent (storage) VMotions (Host / Datastore) 2/4

Concurrent operations per vCenter 96

Read more about the configuration maximums of vCenter here on page 6.

Determine availability requirements for a vCenter server in a given situation


VMware vCenter is the hard of the Virtual infrastructure. Despite the fact that you infrastructure can run without a VC for a while it is best for management and
features like DRS to have a vCenter. I have thought about this for a number of scenario’s:

One site, limited number of hosts


When you run vCenter on one host with a limited number of ESX hosts and limited up-time demands you can install the vCenter Server in a VM. Enabling HA on
you cluster will increase the availability of the vCenter Server in case of a ESX host crash.
One site, more host and high available demands
When the demands for availability are higher of DRS must almost always work you can increase the availability of a vCenter by running it:

In a MSCS environment (not officially supported?)


In vCenter Linked mode
By enabling “Fault Tolerance” for the VM

vCenter on more than one site


When you have more than one site you best run vCenter in linked mode. This ensures not only that the service is running on two sites but also that the
configuration is replicated.

Determine appropriate vCenter Server edition


vCenter comes in different flavors.

VMware vCenter Server Standard.


Provides large scale management of vSphere deployments for rapid provisioning, monitoring, orchestration and control of virtual machines.
VMware vCenter Server Foundation.
Provides powerful management tools for smaller environments (up to three vSphere hosts) looking to rapidly provision, monitor and control virtual machines.
VMware vCenter Server for Essentials.
Integrated into the vSphere Essentials and Essentials Plus editions for small office deployments.

Determine database size requirements


The size of the vCenter database is mainly determined by the amount of performance statistics collected. This is a settings that you can set. In the past VMware
delivered a excel sheet to calculate the estimated MS SQL Server database size but in the new vSphere version this is being calculated in realtime in the GUI. To
change this setting and see the DB size estimate:

Goto the menu item “Administration”, “vCenter Server Settings”


Click “Statistics”
Choose a interval duration and click “Edit”
When the interval in selected the DB size is shown. When you click edit you can change the level. There are four levels in where level 1 is the lowest level and
level 4 is the highest level logging nearly anything on the system. When is change the five minute interval from log level 1 to four the DB size estimate goes from
15 GB to roughly 44 GB! Wow! And I did not even change the save period from the default of one day.

Prepare/Configure vCenter Server database


How to prepare your database highly depends on your installation. VMware recommends a separate database for the vCenter Server and for the vCenter Update
Manager. Each vCenter Server must have it own database, however those database can be on the same SQL Server (if that is the best approach…I don’t know, but
don’t think so). Read here, chapter 10, to see what database you would like to use etc.
Install vCenter Server using downloaded installer
VMware allows you to download the vCenter installation media as a EXE file of as an ISO file. The ISO file can be mounted or burned to DVD, the EXE file can run
directly on a OS but has to be copied there. Read more here on page 83.
Install additional modules
VMware allows fro plug-ins into the vCenter client. These are both VMware as third party supplied and add extra functionality. To install plug-ins:

Select “Plug-ins”, “Manage Plug-ins..” from the vCenter client menu


Install plug-ins to your needs

vCenter Guided Consolidation


The Guided Consolidation plug-in is the P2V plug-in. It allows you to select physical servers and convert them using a wizard to a virtual machine. This plug-ins
has to be installed explicitly. The installer is in the Virtual Center installation media and you can select this during the installation wizard. Read more here on
page 103.
vCenter Update Manager
The Update Manager allows you to update you infrastructure, including updates to third party guest operating systems. The plug-in is available if the Update
Manager is installed.
vCenter Converter
The Converter allows you to convert existing VM Backups, VMs and physical machines to a virtual server. You have to download and install the converter.

Determine use case for vCenter Linked Mode Groups


VMware vCenter linked mode allows you to link vCenter installations. Reasons to do so can be:

Availability
When you link vCenter servers those servers can manage the entire infrastructure. When one server fails, for example on site A, you can connect to the linked
server on site B to continue working.
Configuration maximums
The number of ESX hosts, VMs and users per vCenter server is limited. When running into those limits adding additional vCenter servers can increase those
configuration maximums. The number of ESX hosts can grow up to a 1000 and the number of powered on VM can be 10.000! You can link a maximum of 10
vCenter servers.

Tools
ESX/ESXi and vCenter Server Installation Guides
Product Documentation
Database Sizing Tool/Calculators

Objective 4.2 – Manage vSphere Client plug-ins


Written by Matthijs van den Berg

Friday, 16 October 2009 12:25

Knowledge
Identify available plug-ins
The number of plug-ins can very with the exact release of vSphere. During the initial release the plug-ins worth mentioning are:

vCenter Guided Consolidation


vCenter Update Manager
vCenter Converter
vCenter Storage Monitor (default)
vCenter Hardware status (default)
vCenter Service Status (default)

Determine required plug-ins for a given application


Not really quite sure what is meant here (again ;-) ). I think it is quite obvious that when you install the Update Manager that that Update Manager plug-in is the
associated plug-in to install.
Ensure permissions to install plug-ins
This was a really pain in the ass. I cannot find any User Access Control method of denying users access to plug-ins, the plug in menu etc. It is not an option in de
roles menu. So I think the best way to deny access is not to install the plug-in on the host system. To disable this I think the best way is to use Windows user
permissions.

Update 1 dec 2009: I have received a mail from Peter. He point me to 'Table a-6 - extension priveleges' of vsphere basic system administration. This should allow
control over registering/unregistering/
updating and extension (plug-in). Unfortunately after testing this with a user, and leaving this option unchecked, it does not do the trick. I am not sure whether this is a
bug and should work (cannot find anything else this setting should do) or that we are on the wrong track here.. if you know more... please help.

If anybody knows a better way, please contact me or leave a message in the commend system!

Enable plug-ins after installation


When I plug-in is installed you need to enable it. To do so:

open the Plug-in Manager


Right click a installed plug-in

Click “Enable” to enable the plug-in.

Tools
ESX/ESXi and vCenter Server Installation Guides
Product Documentation
vSphere Client

Objective 4.3 – Configure vCenter Server


Written by Matthijs van den Berg

Sunday, 18 October 2009 21:43

Knowledge
Identify the vCenter Server managed ESX Hosts and Virtual Machine maximums
Here we go again, another list of figures that made the VCP 3 exam so famous.

Item Max.

ESX hosts on 32 bit vSphere 200

VMs on 32 bit vSphere (powered on / registered) 2000 / 3000

ESX hosts on 64 bit vSphere 300


VMs on 64 bit vSphere (powered on / registered) 3000 / 4500

Linked vCenters 10

Concurrent vSphere Clients (32 / 64 bit) 15 / 30

ESX hosts / datacenter 100

Concurrent (storage) VMotions (Host / Datastore) 2/4

Concurrent operations per vCenter 96

Read more about the configuration maximums of vCenter here on page 6.

Join ESX/ESXi Hosts to vCenter Server


When you have installed an ESX host you can add this to the vSphere environment by adding it to the vCenter Server. To do so:

Go to the vSphere client and right click on your cluster

In the menu that pop’s up click “Add Cluster”

Follow the wizard to add a ESX host.

Configure Guest OS Customization


When deploying OSes from a template you can use a Customization file to quickly deploy VMs in the same way. Remember that you need the MS sysprep files for
Windows Server 2003 / XP /2000 customization. In general there are two ways to start the wizard:

Deploy from template


When you right click a template en choose “Deploy Virtual Machine from this template…” you automatically start a wizard to deploy a VM from template. A part of
this wizard is a separate wizard to start the customization of the OS.
this wizard is a separate wizard to start the customization of the OS.

Customization Specifications Manager


After you have created a VM specification and saved this you can view and edit those, and create complete new ones, using the Customization Specifications
Manager. To open the Customization Specifications Manager select the menu as displayed below.

Here you can create new specifications, manage existing ones and import specifications.

Use datacenters and folders to organize the environment


In vCenter there are quite some possibilities to organize your environment. In the “Hosts and Clusters” and the “VMs and Templates” view you can create data-
centers. These can represent physical data-centers in your IT environment. Please note that you cannot use VMotion to live migrate VMs from onw DC to another You
must use Clusters or a smaller instance to separate VMs if you need VMotion.
Folders are visible only in the “VMs and Templates” view. You can create nested folder structures you separate VMs. Folders are created within Data-centers.
For both folders and datacenters it is possible to set user rights to allow of disallow certain users certain actions.
Configure/Use Scheduled Tasks
You can create scheduled tasks to automate certain tasks in you vSphere environment. To do so:

Goto “Management”, “Scheduled Tasks” to open the Scheduled tasks


Right click “New” in the upper left corner of the window

Choose a task that fits your needs.


Follow the per task wizard that pops up.

Configure/Use Resource Maps


A resource map shows how different resources are connected to each other. To open Maps choose:

“Management”
“Maps”
Example output:
Use Storage Reports/Storage Maps
To open storage information including Maps choose:

“Inventory”
“Datastores”
goto the tab Maps to see the connections between ESX hosts, VM and storage
goto the tab datastores to see the datastores on the ESX hosts and the amount of storage that is used.

View/Manage Events
In the event log all events are logged including the person who initiated the event (another reason for decent delegation of control!). To open the events:

“Management”
“Events”

Configure vCenter Server settings


vCenter Server settings can be viewed and edited via the vSphere client. Go to:

“Administration” in the menu bar


Select “vCenter Server Settings…”
Configure vSphere Client settings
vCenter Client settings can be viewed and edited via the vSphere client. Go to:

“Edit” in the menu bar


Select “Client Settings…”

Tools
vSphere Basic System Administration Guide
Product Documentation
vSphere Client

Objective 4.4 – Configure Access Control


Written by Matthijs van den Berg

Wednesday, 21 October 2009 00:32


Knowledge
Create/Modify user permissions in vCenter
VMware vCenter has quite a advanced Delegation of Control system. It allows for users to be created and a per user or per group delegation of access rights. When
you manage a host using vCenter Server, only the privileges and roles assigned through the vCenter Server system are available. If you connect directly to the host
using the vSphere Client, only the privileges and roles assigned directly on the host are available. Also you can use your active directory users in VC. To create /
modify user permissions, called Roles in vCenter, you can:

Open the vCenter client

In the navigation bar choose “Administration”, and “Roles”

Right Click in the left “Name” pane and select “Add” or “Edit” to add or edit user roles.

You can edit the user permissions to your needs.


Read more here on page 213.

Create/Modify user permissions in ESX Server


The privileges and roles assigned on an ESX/ESXi host are separate from the privileges and roles assigned on a vCenter Server system. When you manage a host
using vCenter Server, only the privileges and roles assigned through the vCenter Server system are available. If you connect directly to the host using the vSphere
Client, only the privileges and roles assigned directly on the host are available.
To edit local users and groups on a ESX host connect you vCenter client directly to the ESX host instead of connecting to the vCenter server (type the ESX hostname
in the vCenter client connection box and use root or a later created user to log-in). Then:

Select the ESX host


Select the tab “Users and Groups”
Right click to add or edit users
Read more here on page 213.

Restrict access to vCenter inventory objects


The users, groups, roles and rights policy in vCenter is quite advanced. You can create a role that specifies what users / groups in that role are allowed to do, add a
user group to this role and connect that user group to an inventory object in vCenter.
For example if you would like your R&D department to access only VMs in the Folder R&D you attach the R&D user group (that can be the same user group that you
use in your active directory!) to that folder. By applying a Role for the users you can control what users are allow to do within that folder. This allows for a granular
user and object access. To attach a
Define vCenter predefined roles and their privileges
vSphere comes standard with a number of preconfigured security roles. Users can be added to these standard roles to quickly give them predefined privileges. The
standard roles within vCenter are:

Select the object you would like to apply the user rights on
Goto the tab Permissions
Right click and select “Add”

Select the role you would like to assign in the right pane
Select the local or AD user / user group you would like to assign
Optionally; deselect the “Propagate to Child Objects” check box if you need user rights only on the object and not on underlying objects.

Create/Clone Edit roles


The roles we have been talking about earlier can be modified and new roles can be added. To do so:
Use the navigation bar to go to “Administration”, “Roles”
Right click a role to edit or add

Assign roles to users and groups


To assign users to a role an object where the users and roles are assigned to is needed. If you would like to add users with certain permission to the whole
infrastructure select the highest level in the vCenter hierarchy. To add users and roles:

Select the tab “Permission”


Right click and select “Add Permission…”
Add a user of group and select the appropriate Role.

Describe how privileges propagate


When a Role and user are assigned to an object these Users and Roles propagate to underlying objects. Example; you have a resource pool. Within this resource
pool multiple VMs and other resource pools are present. When you create a privilege all those VMs and resource pools inherit the same policy. This is default
behavior. To disable this propagation disable the check box “Propagate to Child Objects” in the assign permissions screen.
Understand permissions as applied to user and group combinations
You can assign the same permissions to groups and individual users. Those users and groups can have different roles on different objects within you vSphere
environment. So one user can sometimes be part of a group and sometimes have permission assigned to the individual user. This can make the permissions part
VERY COMPLEX! So be conservative with user rights. Personally I never assign individual users rights, but always use groups, preferably groups that also exist in the
Active Directory (if one is present).

Tools
vSphere Basic System Administration Guide
Product Documentation
vSphere Client

Objective 5.1 – Create and Deploy Virtual Machines


Written by Matthijs van den Berg

Monday, 26 October 2009 14:22

Knowledge
Understand virtual machine hardware maximums
A virtual machines can handle the values as described in the following table. Please note that these maximums can depend on the VMware version you are using.

Item Max.

Max. CPUs 8

Max. RAM 255 GB

SCSI adaptors 4

SCSI Targets per adaptor / VM 15 / 60

Disk Size / VM 2 TB min. 512


bytes

IDE Controller / Devices 1/4

Virtual NICs 10

Parallel ports 3

Serial Ports 4

VMDirectPath PCI / PCIe Devices 2

VMDirectPath SCSI targets 60

Number of remote console connections 40

Create a virtual machine


Determine appropriate SCSI adapter
When creating or editing a VM you can choose from several types of SCSI adaptors. Those are:

Buslogic Parallel
Older guest operating systems default to the BusLogic adapter.
LSI Logic Parallel
This is the default adaptor when a VM is created (for most OSes).
LSI Logic SAS
LSI Logic SAS is available only for virtual machines with hardware version 7. Disks with snapshots might not experience performance gains when used on
LSI Logic SAS and LSI Logic Parallel adapters.
Paravirtual SCSI adaptor
Paravirtual SCSI (PVSCSI) adapters are high-performance storage adapters that can result in greater throughput and lower CPU utilization. Paravirtual
SCSI adapters are best suited for high performance storage environments. Paravirtual SCSI adapters are not suited for DAS environments. VMware
recommends that you create a primary adapter (LSI Logic by default) for use with a disk that will host the system software (boot disk) and a separate
PVSCSI adapter for the disk that will store user data, such as a database.

Determine Virtual Disk type


When creating a Virtual Machine there are the following options in regard to disk types:

Create a Virtual Disk


The standard option is to create a new vDisk that you can use in the VM. When you have created
Use an existing Virtual Disk
This option allows you to attach a previously created virtual disk to the VM.
Create a RAW Device Mapping
This allows you to directly connect to a SAN / NAS LUN. The format of the disk in not VMFS but OS specific and allows for clustering across boxes (both a
physical and virtual node participate in a OS level cluster).
Do not create a disk

Install/Upgrade/Configure VMware Tools


When you have a running VM best practice is to install the VMware tools. These tools provide you with the optimal driver set for the virtualized hardware. The
most recent virtual hardware, for example the VMXnet 3 adaptor needs those tools to be installed before it is usable in the OS (driver). To install VMware tools:

Right click a VM in the vCenter client


Choose “Guest”, “Install/Upgrade VMware Tools”

Another option is to use the Update Manager to upgrade VMware tools

Create/Convert templates
It is possible to create template from VMs. Those templates can be used to VMs from. To create a template:

Create a VM like you normally would but use general settings (no specific hardware etc.)
When you have installed the OS and the VMware tools and other general software shutdown the VM
Right click the VM and choose “Template”, “Clone to Template” (can be done when VM is powered on, source VM stays as a VM) or “Convert to Template” (only
available when VM is off, VM will be converted to template.).

Customize Windows/Linux virtual machines


When using supported MS Windows or Linux guest OSes you can use a wizard to create a VM from a template. This wizard assists you in some basic configuration
steps like assigning a IP, changing the name of the VM, changing the SID, etc.

Before you can use those tools some OSes (like 2003) need the sysprep tools installed on the vCenter server.

To start the customization wizard:

Right click a template and select “Deploy a Virtual Machine from the template”
Follow the wizard that appears.
One of the last steps of the wizard allows you to save the customization specification you have just created. Those saved specifications allow you to reuse those
settings when deploying other VMs later on.

Manage Customization Specifications


After you have created a VM specification and saved this you can view and edit those, and create complete new ones, using the Customization Specifications
Manager. To open the Customization Specifications Manager select the menu as displayed below.

Here you can create new specifications, manage existing ones and import
specifications.
Deploy a virtual machine from a template
Explained two bullets above.
Deploy a virtual machine using VMware vCenter Converter Enterprise
VMware Converter is available in two editions; VMware Converter Standalone and VMware Converter Integrated (I could not find a “Enterprise” version for vSphere…
So let’s presume that the Integrated version is meant here). The Standalone version is free, the integrated version is free only when you have valid vSphere licences.

Perform a Hot Clone


Perform a Cold Clone
Perform System Reconfiguration

Deploy a virtual machine using Guided Consolidation


a module within vCenter Server, walks you step by step through the consolidation process including automatic discovery of up to 500 servers, performance analysis,
conversion and intelligent placement on the right host

Perform Discovery
Analyze discovered virtual machines
Consolidate selected virtual machines

Clone a virtual machine


To clone a VM:

Right click a VM in the vSphere client


Select “Clone”
Follow the wizard to create a clone of the selected VM

Import a virtual machine from a file/folder


You can import VMs that all ready exist on a datastore:

Select an ESX host


Select the tab “Configuration”
Select the Hardware option “Storage”
Right click a datastore and select “Browse Datastore…”
Select a VMX file to import a VM
Follow the wizard

Tools
vSphere Basic System Administration Guide
Product Documentation
vSphere Client

Objective 5.2 – Manage Virtual Machines


Written by Matthijs van den Berg

Sunday, 25 October 2009 01:23

Knowledge
Configure/Modify virtual machines

Add/Hot Add virtual machine hardware


You can add and remove hardware for Virtual Machines via the GUI and the CLI. We will be discussing the GUI only here. Depending of the state of the VM (on
or off) you can add certain hardware. When a VM is off all types of hardware can be added / modified / deleted.
To edit the hardware properties of a VM:

Right click a VM is the vSphere Client


Click “Edit Settings…”
Click the Add button to add additional hardware
Select existing hardware to modify or delete
Follow the instructions on screen to execute your selected operation

It is possible to add / modify certain aspects / remove some types of hardware while the VM is running. This is called “Hot Add”. This might depend of the type of
guest OS you are using. You can Hot Add the following types of hardware:

USB Controller (new device type in wizard)


Ethernet Adaptor (Hot Add / Remove new in ESX 4.x)
Hard Drive
SCSI Controller

Grow virtual machine disks


You can grow a virtual disk both when a server is turned on and off. To grow a virtual disk:

Right click a VM is the vSphere Client


Click “Edit Settings…”
Select the disk you would like to grow and click increase the size of the disk on the right side of the screen
Click OK to apply and close the screen.
The “Recent Tasks” screen show a progress indicator that the disk is being increased.

Determine appropriate disk format


The are some options to choose when creating a Virtual Disk. I think that the difference between thin and thick provisioned disk is meant here. You can choose
this during the creation of a Disk and during a VMotion of a VM. Also you can browse to the .vmdk file using the GUI and choose to inflate the disk.

A Thin provisioned disk is a disk that is assigned a predefined amount of disk space, but the disk space is not being used on the VMFS volume until the VM
actually needs the space. Because many VMs will never fully use the assigned disk space this can potentially save much space. The downside is that you
can over-commit you VMFS volumes with the danger of quickly filling the volumes when many VM start to allocate space at the same time (virus, large
updates, etc.).
A Thick Provisioned file system is a file-system that works a little bit more the old fashioned way. When you assign a VM a 20 GB partition a 20 GB file is
created on the VMFS file system whether the VM uses it or not. This is a little bit more save, but way more inefficient use of disk space.

Connect virtual machines to devices


I Presume PCI devices are meant here. vSphere allows you to connect a physical device directly to a VM. This allows a VM to directly access this device for optimal
performance and compatibility. The PCI Device has to be on the HCL. You can assign a PCI Device to either the VMkernel or as a pass through device, but not both.
So dual of quad port card has to be either one.
Read more here and here about restrictions and how to configure.
Configure virtual machine options

General Options
To open the general options of a VM:

Right click a VM in the vSphere client


Select “Edit Settings…”
Select the tab “Options” in the new window
In the left pane “General Options” is selected by default
Edit the VM Name of Guest OS type here

Advanced Options

Right click a VM in the vSphere client


Select “Edit Settings…”
Select the tab “Options” in the new window
In the left pane select “Advanced”

There are several field you can change. As stated on the Advanced window you can leave those to the default most of the time. Consider this a warning
from VMware ;-). I won’t go through all the option but you can enable mem and CPU hot plug and NPIV (SAN WWN to a VM) here.

Power Management Options


Can oly be changed when the VM is off

Right click a VM in the vSphere client


Select “Edit Settings…”
Select the tab “Options” in the new window
In the left pane select “Power Management”
Change the way how a VM responds to the standby mode here, and allow “Wake on LAN” (WOL) Support here.

VMware Tools Options


When the VMware tools are installed in the guest OS this allows for a more controller Guest OS. You can control the VM with the play, pause and stop buttons.
Those buttons, unlike in VMware ESX 3.5, perform a soft pause of shutdown (guest shutdown) of the OS by default. You can change these settings here. To go
to the panel:

Right click a VM in the vSphere client


Select “Edit Settings…”
Select the tab “Options” in the new window
In the left pane select “VMware Tools”

Configure appropriate virtual machine resource settings


You can change the reservation, shares and limit of VM resources on a per VM level. Also the way the VM handles hyper threading can be configured. To do so:

Right click a VM in the vSphere client


Select “Edit Settings…”
Select the tab “Resources”
Tools
vSphere Basic System Administration Guide
Product Documentation
vSphere Client

Objective 5.3 – Deploy vApps


Written by Matthijs van den Berg

Sunday, 25 October 2009 01:29

Knowledge
Determine whether a vApp is appropriate for a given situation
A vApp is a logical group of VMs that have a dependency on each other. When you are not using a vApp starting or stopping an application that exists out of multiple
VMs means you need to start / stop the VMs in a particular order by hand. When the fist VM is started (let’s say a domain controller) you need to check is it is up
(Tools report back, or see the CTRL-ALT-DEL screen) and then start the next server. This is exactly what a vApp automates for you in combination with a Resource
Pool. A vApp allows you to:

Determine a start-up oder including dependencies (start only when.. ) and define groups of VMs to start / stop when a criteria is met.
Configures resources like you would using a resource pool
Configure vApp properties and version numbers
Configure vApp IP allocation
Nest other vApps within a vApp. You can manage a vApp within a vApp as a single server. This makes using vApps really powerful.

Define Open Virtual Machine Format (OVF)


The Open Virtual Machine Format (OVF) is a format the allows for VMs to be migrated between different platforms of virtualization. In short you can migrate a OVF VM
easily between VMware ESX and Hyper-V / Xen. (assuming those support the OVF as well). Another benefit of the OVF is that the VMs are compressed by default
make to size of the file smaller. In the “File” menu you can choose to deploy or export OVF templates. You can use the OVF tool to import / export VMs from and to
the OVF format. Read more here. http://www.vmware.com/go/ovf_guide
Import/Export a Virtual Appliance
You can import a Virtual Appliance by using the VA Marketplace. This is a part of the VMware website where VMs are offered by vendors of software that you can use
for preview of production purposes depending on the type of software offered. To access the VA Marketplace choose:

File
“VA Martketplace…”
Select a VM in the screen that pop’s up to download and follow the wizard to install this in you VI.

Build a vApp
To build a new vApp:

Right click you cluster and select “New vApp…”


Follow the wizard that appears
To add VM to the vApp drag and drop the VM into the vApp

Create/Add virtual machines to a vApp


Oops, just told you… ;-). To add a VM to a vApp drag and drop the VM on to the vApp.
Edit vApp Properties
To edit a vApp:

Right click a vApp


Select “Edit Settings”
Adjust the settings as needed. The settings that can be edited are explained earlier in this chapter.

Export vApps
To export a vApp:

Click “File” in the vCente client


Choose “Export”, “Export OVF Template”

Clone a vApp
To clone a vApp:

Right click the vApp (the vApp has to be shut down for this option to be selectable)
Choose “Clone” from the menu (the vApp has to be shut down for this option to be selectable)

Tools
vSphere Basic System Administration Guide
Product Documentation
vSphere Client
OVF Tool

Objective 6.1 – Install, Configure and Manage VMware vCenter Update


Manager
Written by Matthijs van den Berg

Monday, 02 November 2009 01:03

Knowledge
Determine installation requirements and database sizing
When installing vCenter you can choose to install the Vmware Update Manager (VUM). The update manager allows you to centrally download, distribute and install
updates in a controlled way. The VUM supports the ESX Operating Systems as well as some mainstream guest OSes.
To distribute these updates VUM downloads and stores the updates locally and the signatures are stored in a Database that can be local or on a central Database
To distribute these updates VUM downloads and stores the updates locally and the signatures are stored in a Database that can be local or on a central Database
server. The size that the update store and database needs can be calculated with the Sizing Estimator VMware distributes here.
The installation requirements are:

Hardware

2 Ghz processor
2 GB RAM. When VUM is installer on the same server as vCente Server (fully supported) a minimum of 4 GB of RAM is needed.
Preferable a Gigabit connection, but 10/100 can suffy

Software

Windows XP SP2, Sever 2003 or Server 2008 (dedicated DB recommended)


MS SQL serve or Oracle as a local or remote database.

Install Update Manager Server and Client components


To install the update manager. This can be done on the vCenter Server or on a separate machine. Make sure you have sufficient disk space and a database (or no DB
if you choose to install the MS SQL Server locally). Recommendations for large environments are to use a separate Update Manager Server and a separate database
server. To start the install run the wizard from the vCenter Server install CD.
Read more here on page 27. http://www.vmware.com/pdf/vsp_vum_40_admin_guide.pdf
Configure update manager settings
To be able to manage the VUM settings you first need to download, install and enable the VUM plug-in. Read more here on how to. When you have the plug-in
enabled in the vSphere Client select “Home” from the navigation pane and then click “Update Manager” from the “Solutions and Applications” section.

From this view you can select and configure multiple option from the VUM like when and how to download what patches, see events and create baselines to attach to
ESX hosts for scanning etc.
Configure patch download options
Under the tab “Configuration” you can select the “Patch Download Settings” and the “Patch Download Schedule”. Here you can configure the settings like: for wat OS
to download patches, use a shared repository, use a proxy server and create download schedules for updates.
Create baselines
A baseline holds specific updates or update groups / criteria for OS’s. You can create a baseline for example to hold all ESX(i) updates. When scanning for updates a
host will be checked whether those updates defined in the baseline are installed. A base line can be static, containing only specific updates, of dynamic, containing all
available updates with certain urgency for a specific OS.
Attach baselines to vCenter inventory objects
When you have created a baseline you need to attach this baseline to objects in the vSphere environment. This allows you to select single or multiple entities in one
baseline to create a granular update policy. A baseline can be applied to:

vCEnter Server environment (the top level)


Datacenters
Clusters
Hosts
vApps
ESX hosts
VMs

Scan ESX hosts and virtual machines


To scan ESX hosts you need to:

Go to the “Hosts and Clusters” view


Select an ESX host
Select the tab “Update Manager”
Click “Scan” in the upper right corner
Click OK on the pop-up screen that appears.

Remediate ESX hosts and virtual machines


When the scan completed successfully you can choose to apply those updates to the OS / Applications.

Go to the “Hosts and Clusters” view


Select an ESX host
Select the tab “Update Manager”
Select the button “Remediate” in the lower right corner

Follow the wizard that appears on screen.

Stage ESX/ESXi Host updates

Go to the “Hosts and Clusters” view


Select an ESX host
Select the tab “Update Manager”
Select the button “Stage” in the lower right corner

Followw the wizard to upload (stage) the updates for a OS or application.

Analyze compliance information from a scan


When you have performed a scan of a ESX host or VM you can see whether the host has all the latest updates installed or not. When you select a host and the select
the tab “Update Manager” you are in the “Compliance View”. This Shows how many updates are not installed on a host. When you click on updates the need to be
installed (the red figure) you see the Following window that indicated what applicable updates are installed and that are not.
Tools
VMware vCenter Upgrade Manager Administration Guide
Product Documentation
Update Manager Database Sizing Tools

Objective 6.2 – Establish and Apply ESX Host Profiles


Written by Matthijs van den Berg

Monday, 02 November 2009 23:05

Knowledge
Create/Delete Host Profiles
Host profiles can be used to capture a configuration of an ESX host. This configuration can be used to be applied on other ESX hosts or as a baseline to check
whether an ESX host complies to the standard defined.

To create a host profile:

Select the “Host profiles View” from the menu.


Click “Create Profile” in the upper left corner.

Follow the wizard that appears


Or right click an ESX host and select “Create Profile”
Import/Export Host Profiles
To import Host Profiles:

Use the same procedure as described above

To export

I think right click a profile and export, but since I do not have the correct licence I cannot test this.

Edit Host Profile Policies


I think right click a profile and edit, but since I do not have the correct licence I cannot test this.
Associate an ESX host with a host profile
I think right click a profile and link, but since I do not have the correct licence I cannot test this.
Check for Compliance
To Check for host compliance af an ESX host:

Right click the ESX host


Select “Host Profile”
Select “Check Compliance…”

Apply Host Profiles


To apply a host profile to an ESX host:

Right click the ESX host


Select “Host Profile”
Select “Apply Profile…”

Analyze configuration compliance information from a scan


I really need another version..

Tools
vSphere Basic System Administration Guide
Product Documentation
vSphere Client

Matthijs’ links
http://communities.vmware.com/docs/DOC-10850

Objective 7.1 – Create and Configure VMware Clusters


Written by Matthijs van den Berg
Tuesday, 10 November 2009 00:27

Knowledge
Create new cluster
A cluster is an entity that exists within a Data center. You can create multiple clusters to segment ESX hosts due to version, proc type, etc. or to to counter cluster
configuration maximums. To create a cluster:

Open the vCenter client


Go to the view “Hosts and Clusters”
Right click you Data Center in the left pane, en select “New Cluster”
Follow the wizard that appears to create a new cluster. In the above example we enabled HA and DRS. Those are only available with the correct licenses.

Add ESX/ESXi hosts to a cluster


When you have created a cluster you need to add ESX(i) hosts.

Right click on you cluster and select “Add Host…”

Fill in the FQDN hostname, user name and password of the local ESX host user (password created during setup)
Follow the rest of th wizard to add the host to the cluster.

Configure High Availability basic/advanced settings


High Availability is technique that automatically start VMs that crashed. This can be due to failures of an ESX host or failures within the VM (VM Tools heartbeat
monitoring). To configure this:

Edit the settings of you cluster (right click, “Edit Settings…”)


Click “VMware HA”. The following screen appears
Edit the settings to your needs.

Host Monitoring Status


This should be enabled for default operation of HA. When you expect network downtime you can temporary disable this. Be aware that when disabled HA
will not work.
Admission Control
This controls whether VMs can be powered on when there are not enough resources available. It reserved the capacity of the number of resources
reserved for HA. For example when set to prevent; when you have three VMs you have 300% of resources. When you specify that HA tolerates 1 host
failure (equal to 100%) this means that admission control reserves 100% of 300% (1/3th) of the resources for just in case. When you try to power on a VM
that would take the number of resources over 200% this VM will fail to power on.
Admission Control Policy
This controls how many (or what percentage) of host failures capacity is reserved for.

Idea, but not officially meant for this purpose: You can increase the number that the cluster tolerates if you have a second site that is being replicated to the
first and would like to make sure that you have sufficient capacity for the VMs on the second site.

Click Advanced to change advanced settings. Advanced Settings can only be added manually.

Enable/Configure VM Monitoring
VM Monitoring allows you to monitor the availability of the VMware Tools within a VM. When the VMware Tools heart beat is not received for a certain period of time
the VM will be reset. You can specify a default value for the monitoring times of specify this by hand:

Failure Interval
This value determines the period of time that no heart beats are received and the VM will be reset.
Minimum Up-time
Number of seconds that a VM is not being monitors after it’s power on.
Maximum per VM resets
The maximum number of times a VM is reset during a certain time frame. By setting this you can prevent infinite reboots, but it most likely will reboot multiple
times every time frame. Pay attention!
Maximum resets time windows
The time frame to what the “Maximum per VM Resets” setting apply.

Configure Distributed Resource Scheduler basic/advanced settings


Distributed Resource Scheduler or DRS is the technique VMware uses to level the load of all VMs across the ESX hosts. When creating a cluster this is disables by
default and you need the right licenses before you can use this. There are three basic levels:

Manual
VMware DRS make the load level recommendation only; you need to apply the recommendations manually.
Partially Automated
This will start a VM when being powered on the host with the most resources available. You still need to apply the recommendations to VMotion a VM to level the
load manually
Fully Automated
This will place VMs when being powered on and migrate VMs to level the load fully automated. You can select how aggressive this is being handled.

Advanced option van be entered manually. VMware recommends this only to use in conjunction with their support desk. I could not find a complete comprehensive list
of all the DRS advanced options on the Internet.

Configure Distributed Power Management


This is where VMware continues on their Green IT promise. DPM allows you to consolidate all VMs on the minimum number of hosts required. All other hosts are
being shutdown until their resources are needed within the cluster. A host is than turned on fully automatic by the vCenter Server. To configure DPM:

Right Click you cluster


Click “Edit Settings…”
Click “Power Management”

Change the settings to your needs


Click “Host Options” to change per ESX host DPM settings when you would like those to be different from the cluster settings.

Configure Enhanced VMotion Compatibility


Enhanced VMotion Compatibility allows hosts with CPU’s from different families to be used in the same Cluster for VMotion. From ESX 4.0 this allows an easier use of
ESX hosts: you can mix older and newer CPU families (from one vendor!) with each other. To do so you must select an EVC mode that supports the oldest CPU in
the cluster. To configure:

Right Click you cluster


Click “Edit Settings…”
Click “VMware EVC”
Click the button “Change…”
Choose Enable for your CPU vendor
Click the “VMware EVC mode” for you servers.

Note: to enable none of you VMs must use technology from a newer processor type. For example, when you build a cluster from ESX hosts with Core i7
processors, create VMs and add a Core 2 due processor host later on you VMs are using Core i7 functionality. You cannot enable the EVC mode for anything
less that Core i7 mode. You have to change the VM CPU details to allow this.

Configure swap file location


Each VM comes with a default created swap file. These swap files are stored with the VM files on the VMFS data store. You can change this default behaviour to
another location, for example the local disk of the ESX host. To to so:
another location, for example the local disk of the ESX host. To to so:

Select an ESX host


Select the tab “Configuration”
Select “Virtual Machines Swapfile Location” in the menubox “Software”
Click “Edit” in the upper right corner
Select a local or remote VMFS data store that this ESX host will use as default

You can also change this per VM

Edit the settings of a VM


Select the tab “Options”
Select the item “Swapfile Location”
Change the settings to your needs.

Analyze HA host failure capacity requirements


You can calculate the amount of CPU and memory resources that are needed for a host failure. When doing so you need to take the following into account:

Resources in use
Total amount of resources available
Amount of CPU resources available on the host with the largest amount of Mhz
Amount of CPU resources available on the host with the most RAM

When you account for 1 host failure this can be the host with the most RAM, CPU etc. So you need to make sure that you always have the largest amount
of RAM and the largest mount of CPU resources available in the cluster to accommodate for a host failure. This can be calculated bu using the total
amount of resources minus the amount of resources in use. Read more here on page 13 – 19.

Analyze HA admission control


Admission control checks if there are sufficient resources within:

Host (checks to ensure reservations, shares and limits)


Resource Pool (checks to ensure reservations, shares and limits)
VMware HA (checks to ensure VM recovery as specifies in the HA settings)

Those settings can prevent a VM from starting up or can prevent settings new reservations, limits or shares on a VM. Only HA admission control can be
disabled. You can choose your HA admission control policy based on your needs. You can account for fragmentation (the total amount of resources in the
cluster can be sufficient for one large VM but it might not fit on any of the hosts) and flexibility. Read more here on page 19.

Important: In addition to the user-specified memory reservation, for each virtual machine there is also an amount of overhead memory. This extra memory
commitment is included in the admission control calculation and can provide readings that you might not anticipate. It can even prevent you from powering on a
VM that, when calculated on paper before, should fit!

Determine use cases for DRS automation levels and migration thresholds
DRS is a very powerful technology that automatically distributes resources. This is typically used in environments where resources used by VMs vary and can lead to
performance bottlenecks or uneven distributed ESX hosts. When turning on DRS the resources are load balanced automatically giving you the best performance. How
aggressive you set your DRM depends on the type of VMs. When you have VMs that have a very volatile CPU / MEM usage setting it to conservative might prevent
many VMotions that need to be undone some minutes later. When you need the best performance asap you mijght set this to aggressive. Be aware that VMotion uses
system resources.
Determine use cases for DPM policies
I my opinion this should be “allways-on”. It consolidates you VMs on the least amount of ESX hosts needed to accommodate the resources needed savinf energy. If
however you expect that VMs need CPU of memory in large amounts faster that you ESX hosts can power on you might disable this. Also HA can be a reason the be
conservative on those settings. And last but not least, you hardware must support the shutting down / powering on of the ESX hosts. Technologies like HP iLO can
help you make sure you can turn your hosts back on.

Tools

vSphere Availability Guide


vSphere Resource Management Guide
Product Documentation
vSphere Client

Objective 7.2 – Enable a Fault Tolerant Virtual Machine


Written by Matthijs van den Berg
Tuesday, 10 November 2009 01:31

Knowledge

Identify FT restrictions
There are ‘some’ restrictions to the use of VMware Fault Tolorance. Those are for the ESX host system

You can only apply it to VMs with one processor


You need a working cluster (HA and DRS with shared storage) as a FT VM only resides on 1 data store
You need a HV-Compatible CPU
You need exactly the same CPU on both ESX hosts
All hosts must use the same version of ESX
It does not prevent you from a faulty storage array (or a filled up VMFS)
You need a dedicated NIC for FT logging (Gbit or better)
Advanced or higher license
5% to 20% overhead!

And for the VM you would like to apply FT to:

No thin provisioned disk (auto upgraded to thick disk)


No Storage VMotion
A small performance penalty (keeping the VM in lockstep) See here
No non-replayable devices (USB, Sound, Physical CD-ROM, etc.)
No Para Virtualisation enabled
No Para Virtualized SCSI (PVSCSI)
Will use their full memory reservation!
No VMXNET 3 NIC support
VM OS must be supported (Operating system support may very based on the processor your ESX host uses )
No support for Snapshots
No MSCS support (remove before enabling FT)
No support for CPU / Mem hot plug
Extended Page Tables (EPT)/Rapid Virtualization Indexing (RVI) is automatically disabled

Read these and more limitations in a blog posting here.

Evaluate FT use cases


Despite the large number of restrictions FT is a strong feature of ESX / vSphere to protect you VM against unplanned ESX host failure. But remember that this is the
only thing this feature protects you from; ESX failures like network, server, disk I/O etc. When the central storage or Guest OS failes FT is not going to help you! A
Cluster like MSCS would be a better solution to counter a guest OS failure but is a expensive solution that cannot be used for all applications. And it are those
applications that are best suited for FT when they do fit between the restrictions FT has.
Set up an FT network
A FT VM uses the vLockstep technique to keep the VMs on both ESX hosts in sync.
FT generates two types of network traffic:

Migration traffic to create the secondary virtual machine


FT logging traffic

Migration traffic happens over the NIC designated for VMotion and it causes network bandwidth usage to spike for a short time. Separate and dedicated NICs are
recommended for FT logging traffic and VMotion traffic, especially when multiple FT virtual machines reside on the same host. Sharing the same NIC for both FT
logging and VMotion can affect the performance of FT virtual machines whenever a secondary is created for another FT pair or a VMotion operation is performed for
any other reason.

VMware vSwitch networking allows you to send VMotion and FT traffic to separate NICs while also using them as redundant links for NIC failover.

Adding multiple uplinks to the virtual switch does not automatically result in distribution of FT logging traffic. If there are multiple FT pairs, then traffic could be
distributed with IP-hash based load balancing policy, and by spreading the secondary virtual machines to different hosts. Remember that IP hashed based load
balancing require switch configuration.

To calculate the required bandwidth use the formula:

FT logging bandwidth ~= [ (Average disk read throughput in Mbytes/sec * 8) +


Average network receives (Mbits/sec) ] * 1.2

To setup a network for FT logging

Select an ESX host


Click tha tab “Configuration”
Select “Networking” from the right menu
Select an existing vSwitch with sufficient free bandwidth or create a new vSwitch with dedicated NICs
Click “Add” on the “Ports” tab
Select the VM Kernel Bullet

Enter a name and optionally a VLAN


Check the box “Use this portgroup for Fault Tolerant logging”
Finish the network

Verify requirements of operating environment


There are some requirements and recommendations to the guest OS of a FT VM:

The guest OS must be supported by VMware for FT


Make sure that the guest OS uses an NTP server for time sync
FT does not perform well when used on a VM with a large amount of I/O

Enable FT for a virtual machine


There are two types of FT operations that can be performed on a virtual machine: Turning FT on or off, and enabling or disabling FT. The performance implications of
these operations are as follows:

“Turn On FT” prepares the virtual machine for FT.

Non Supported devices are removed


Balooning is being disabled
The SWAP file is deleted
Hardware MMU is being disabled (shutdown required)

“enable FT” operation enables Fault Tolerance by live-migrating the virtual machine to another host to create a secondary virtual machine.
When “Turn on FT” operation succeeds for a virtual machine that is already powered on, it automatically creates a new secondary virtual machine. So it has the
same effect as “Enabling FT”. This uses a substantial amount of resources. Keep turning on / off to a minimum. When not enough resources are available to
process is terminated.

Test an FT configuration
Thank you Henrique: There are two build in methods to test FT. Right-click the VM and there'll be a Fault Tolerance option.

Test Failover: Primary and Secondary VMs switch roles


Test Restart Secondary: After restarting it, you can check its consistency compared to the original

Upgrade ESX hosts containing FT virtual machines


This sound easy but must be handled with care! VMware FT requires two ESX hosts to have the exact same patch level! So when updating you need to make sure
this is either the case or not necessary. VMware recommends the following two update scanario’s:

Disable FT (longer downtime)


The first scenario is easy, disable (not turning off, this takes longer!) FT, upgrade and enable again. Disabling only takes seconds, enabling can take several
minutes.
Disable FT with multiple hosts (shorter downtime)
The second scenario requires at least four hosts. In short:

Update the two hosts not in use by FT VMs and check the levels are exactly the same
Disable FT (turning off would take longer)
VMotion the FT machine to an updates ESX host
Enable FT. A replica is automatically created on the ESX host with the same patch level.

Tools

vSphere Availability Guide


Product Documentation
vSphere Client

Matthijs’ Links

FT Archtecture and performance


VMware Fault Tolerance Recommendations and Considerations

Objective 7.3 – Create and Configure Resource Pools


Written by Matthijs van den Berg

Wednesday, 18 November 2009 23:40

Knowledge
Determine Resource Pool requirements for a given situation
…for a given situation. But no situation is given, so a general explanation here. VMware resource pools can be used for delegation of control and, the main purpose
meant to use them for, resource compartmentalization. You can use resource pools to:

Segment you organization


Isolate VMs from certain users
Access control and delegation
Separate resources

Evaluate appropriate shares, reservations, and limits in a given situation


…for a given situation. But no situation is given, so a general explanation here. Resource pools consist of multiple resources that can be guaranteed or limited. Those
resources are:
Shares
The number of CPU or Memory shares a VM has in respect to the Resource Pool or ESX hosts total.
Reservation
The guaranteed CPU or Memory allocation for a resource pool. Those resources are extracted from the parent ESX host of resource pool. Indicates whether
expandable reservations are considered during admission control. If you power on a virtual machine in this resource pool, and the reservations of the virtual
machines combined are larger than the reservation of the resource pool, the resource pool can use resources from its parent or ancestors if this check box is
selected (the default).
Limit
Upper limit for the amount of CPU or memory the host makes available to this resource pool. Default is Unlimited. To specify a limit, deselect the Unlimited check
box.

Evaluate virtual machines for a given Resource Pool


When you select a resource pool and go to the tab “Resource Allocation” you can see the VMs in a resource pool. This shows you the view as shown below including
the Resource Pool main items like Reservation, Limit and Shares.

Create Resource Pools


To create a resource pool you can

Select the object you would like to create a resource pool in (ESX host, other resource pool or vApp)
Right click, and select “Create Resource Pool…”

Set CPU resource shares/reservations/limits


To set CPU Shares, reservations and / or limits on a existing resource pool:

Right click the resource pool


Click “Edit Settings…”
Adjust the CPU settings to your needs.

Set memory resource shares/reservations/limits


To set Memory Shares, reservations and / or limits on a existing resource pool:

Right click the resource pool


Click “Edit Settings…”
Adjust the Memory settings to your needs.

Define Expandable Reservation


Indicates whether expandable reservations are considered during admission control. If you power on a virtual machine in this resource pool, and the reservations of
the virtual machines combined are larger than the reservation of the resource pool, the resource pool can use resources from its parent or ancestors if this check box is
the virtual machines combined are larger than the reservation of the resource pool, the resource pool can use resources from its parent or ancestors if this check box is
selected (the default).
Add virtual machines to pool
In Dutch we have a nice phrase for this; “Sleur en Pleur”. This means something like drag and drop, and that’s just is, drag and drop the VMs into the correct resource
pool. Another option is to select the correct resource pool during a VMotion.
Describe resource pool hierarchy
You can cascade resource pools. This means that you can place resource pools within resource pools. Remember that a second level resource pool (pool in pool)
cannot have more resources then the resource pool on a higher level. When you use more than one resource pool on the second level those resource pools together
cannot use more resources than the resource pool on the above level.

Tools
vSphere Resource Management Guide
Product Documentation
vSphere Client

Objective 7.4 – Migrate Virtual Machines


Written by Matthijs van den Berg
Wednesday, 18 November 2009 23:44

Knowledge
Identify compatibility requirements
For a VMotion to work some requirements need to be met. Those requirements depend on the specific environment you are using. Some factors are:

What type of migration are you performing (cold, hot, storage)


What type of licenses do you have (need enterprise for VMotion!)
Is your hardware suited for VMotion / Storage VMotion

Cite the three methods of virtual machine migration

Cold Migration
a cold migration is a migration of a VM when it is powered off. The benefits of a cold migration are:

You can move the VM files, also when those are not on shared storage
The Host you move the VM to does not need to have the same CPU

The downside is, obvious, that you need to power down the VM. I think that VMotion of a suspended VM is also a cold migration. Almost the same benefits
apply here, with the exception of the host CPU. Those must be of the same proc family for the migration of a suspended VM to work.

VMotion
Migration with VMotion allows virtual machine working processes to continue throughout a migration. The entire state of the virtual machine, as well as its
configuration file, if necessary, is moved to the new host, while the associated virtual disk remains in the same location on storage that is shared between the two
hosts. After the virtual machine state is migrated to the alternate host, the virtual machine runs on the new host. The state information includes the current
memory content and all the information that defines and identifies the virtual machine. The memory content includes transaction data and whatever bits of the
operating system and applications are in the memory. The defining and identification information stored in the state includes all the data that maps to the virtual
machine hardware elements, such as BIOS, devices, CPU, MAC addresses for the Ethernet cards, chip set states, registers, and so forth. When you migrate a
virtual machine with VMotion, the new host for the virtual machine must meet compatibility requirements in order for the migration to proceed.
The benefits of a VMotion are that there is no host downtime. The downsides are:

Need shared storage


Need a (preferably dedicated) Gigabit network connection
The ESX hosts need to be configured in exactly the same manner (like network names, storage etc.)
You need processors from the same family or use Enhanced VMotion to broaden the compatibility of the processors.
You cannot move the storage of the VM, you need ….

Storage VMotion
Use migration with Storage VMotion to relocate a virtual machine’s configuration file and virtual disks while the virtual machine is powered on.

You cannot change the virtual machine’s execution host during a migration with Storage VMotion. You can use storage VMotion while the VM keeps on running.
This allows you to free up space in storage array’s without downtime.

Understand/Apply
Migration with VMotion allows virtual machine working processes to continue throughout a migration. The entire state of the virtual machine as well as its configuration
file, if necessary, is moved to the new host, while the associated virtual disk remains in the same location on storage that is shared between the two hosts. After the
virtual machine state is migrated to the alternate host, the virtual machine runs on the new host. The state information includes the current memory content and all the
information that defines and identifies the virtual machine. The memory content includes transaction data and whatever bits of the operating system and applications
are in the memory. The defining and identification information stored in the state includes all the data that maps to the virtual machine hardware elements, such as
BIOS, devices, CPU, MAC addresses for the Ethernet cards, chip set states, registers, and so forth. When you migrate a virtual machine with VMotion, the new host
for the virtual machine must meet compatibility requirements in order for the migration to proceed.
Migration with VMotion happens in three stages:
When the migration with VMotion is requested, vCenter Server verifies that the existing virtual machine is in a stable state with its current host.
The virtual machine state information (memory, registers, and network connections) is copied to the target host.
The virtual machine resumes its activities on the new host. If any error occurs during migration, the virtual machines revert to their original states and locations.

Migration of a suspended virtual machine and migration with VMotion can be referred to as hot migration, because they allow migration of a virtual machine
without powering it off.

Determine migration use cases


There can be several reasons why to migrate a VM from one hosts to another. Some scenarios are:

Migrate VMs to perform hard- and or software maintenance of the host or underlying layers as network / storage
Migrate VMs for migration purposes
Migrate VMs for balancing the use of resources (automated with DRS)
Migrate VMs to separate certain servers onto different hosts
Migrate VMs to automatically shut down remaining hosts for power savings (DPM)
Migrate VMs for disaster recovery reasons

Compare and contrast migration technologies


You can migrate VMs for several reasons as described above. To be able to know how to migrate you need to now about several migration options:

VMotion
For the live migration of a VM from one ESX hosts to another. No downtime
Storage VMotion
With storage VMotion techniques you can migrate the files the VM uses from one VMFS to another storage array. No downtime for the VM.
VMware converter
you can use the VMware converter to migrate VMs of physical machines to a VM. Usually this requires downtime and the old machine is not removed (default).

Migrate a virtual machine using VMotion


To migrate a VM using the vSphere Client GUI:

Right click the VM


Select “Migrate…” from the menu
The following wizard appears

Select “Change host”


On the “Select Destination” select the Cluster to migrate to
On the “Select Resource Pool” select the resource pool to migrate to
On the VMotion priority select with what priority a VM will be Motioned:
High Priority migration (the recommended and first option in vSphere called: Reserve CPU …) will VMotion the VM and reserve the resources this VM needs on
both the source and destination hosts. If those CPU resources cannot be allocated the VMotion will fail!
Low Priority migration: Resources are not reserved on the source / destination hosts. The migration will take longer and the VM might become unavailable for
some time!
Finish to start the VMotion (remember that there is a maximum to the number of concurrent VMotion.

Migrate a virtual machine using Storage VMotion


This method used the same start as the normal VMotion but has a few different steps. Since I have Copy Past:

Right click the VM


Select “Migrate…” from the menu
The following wizard appears
Select “Change datastore”
On the “Select Resource Pool” select the resource pool to migrate to
On the Select Datastore screen select the data store you would like to move to. If you would like to separate several files of a VM (configuration files, different
disks, etc) you can select the “Advanced” option that allows you to pick a data store from per disk or for the configuration files.

Select the format you would like to disk to use. Here you can change a thin disk to a thick disk or visa versa.
Finish to start the VMotion (remember that there is a maximum to the number of concurrent VMotions.

Cold migrate a virtual machine


And the last option of the Migrate wizard only applies to VMs that are turned off or are in “Suspended” state. You can perform a migration of the ESX host and the
datastore in one migration.
Since this option uses a combination of the options you’ll find in the wizards described above I will not go into detail. The only change is the select host you need to
specifically select and ESX host to migrate to.

Tools
vSphere Basic System Administration Guide
Product Documentation
vSphere Client

Objective 7.5 – Backup and Restore Virtual Machines


Written by Matthijs van den Berg
Wednesday, 18 November 2009 23:48

Knowledge
Describe different back-up/restore procedures and strategies
Wow, what a question. There are quite a lot way’s to backup VMs. In general there are two types of backups with per type several implementations. Let’s sun some of
them:

File level backup


with this I mean backing up and restoring on a file level in a VM. Some ways to go to achieve this:

Install you old-fashioned decent backup agent as an application in you OS. This agent is not aware of the fact that this OS is virtualized.
Use a backup proxy to backup you data. With backup proxy I usually mean VCB; VMware Consolidated Backup. This allows a file level backup for some
supported guest OSes

Image Backup
an image back up is a copy of the VM files. Those files can be transferred and restored on other location and ESX hosts. Usually this backup method is used for
disaster recovery of VMs. A few ways to go:

Manually using VMware converter or coping the files from the ESX host (downtime!)
Automatically using VMware VCB.
Using the new VMware “Backup and Recovery Appliance”
Using several thirty party products that are out there.

Create/Delete/Restore Snapshots
The new “Backup and Recovery Appliance” VMware provides as a downloadable appliance from there website uses snapshots to create backups. Snapshots are
differentials between two points in time. Using this principle VMware can create easy backups. To manually create / delete or restore snapshots you can use the
vSphere Client. When right clicking a VM you can use the “Snapshot” menu to create, remove re restore snapshots. There is the Snapshot manager that allows you to
revert of delete snapshots and gives an overview of all the snapshot available.
Install Backup and Recovery Appliance
First make sure that you pass all the requirements that this solution requires. Please read here on page 11 and further to check. The appliance can be downloaded
from the VMware site. To install you can choose:

File
“Deploy OVF template…”. This will give you a wizard to install a VM into you environment.
Follow all the steps in the wizard to get the VM running

Install vCenter Data Recovery plug-in


To manage the appliance you need to install the Data Recovery Plug-in into you vSphere client. This plug-in connect to the Backup and Recovery Appliance over port
22024.

Run the plug-in installer VMwareDataRecoveryPlugin.msi


Follow the wizard
Enable the plug-in in the vSphere client

Create a backup job with vCenter Data Recovery


Before you create a back-up job make sure that you have add storage to backup to. Also you need your business input like frequency, Retention time etc. To create a
backup job:

Open the “VMware Data recovery” option on the vSphere client


Click “New Backup Job…”
Follow the steps in the wizard.

Remember that backups are only performed when the CPU usage of the host is below 90% and that no more that 8 back-up jobs can run at the same time.

Perform test and actual restores using vCenter Data Recovery


Install and play around.

Tools
VMware Data Recovery Administration Guide
Product Documentation
vSphere Client
Backup and Recovery Appliance
To download you need a VMware vSpere Enterprise (plus), advanced or essential plus edition or buy it separately in advance to the standard edition.

Objective 8.1 – Perform Basic Troubleshooting for ESX/ESXi Hosts


Written by Matthijs van den Berg
Sunday, 29 November 2009 12:53

Knowledge
Understand general ESX Server troubleshooting guidelines
VMware maintains some documentation and Self Service guides to troubleshoot issues wih VMware ESX / vSphere. I searched the Internet and the VMware website
but there is no chapter ”Trouble shoot” or what so ever. So I put something together myself:

Is the problem reproducible?


Can you find anything in the log files
Are you using the latest version / patches?
Are there other people who have the same problem / symptoms and do they have a solution?
Familiar with the VMware community forums? Post your problem.
If all else fails: Contact VMware Support and send the the generated support log files.

Troubleshoot common installation issues


When installing there can be several installation issues. Troubleshooting might be difficult, but I have written down some things that go wrong quite often.

After installation your ESX server does not boot

You have installed ESX on to a LUN instead of the local hard drive (possibly over writing VMFS partitions). Solve by reinstalling and before starting the
installation hide the LUNs presented to the server
You intentionally installed ESX to a LUN (boot from SAN) but ESX does not boot. Solve by adjusting the HBA BIOS to boot from LUN and by selecting the
correct LUN.
You have selected the wrong boot device in the BIOS of the server

After installation you cannot reach the server via the network

The VLAN configuration on your Switch or Service Console is misconfigured


Routing is not configured
There is no Default Gateway defined for the Service Console Network
The Firewall on ESX does not allow you to connect you the protocol you intent

Monitor ESX Server system health


You can use the vCenter Hardware Status plug-in to monitor you server hardware. This default plug-in shows you CIM hardware sensor information like temperature,
fan rotation speed etc.
Understand how to export diagnostic data
You can download log files of ESX hosts via the vSphere client. To do so:

Goto File in the vSphere Client


Select Export
Select “Export System logs…”

Select the ESX host you would like to export log files from, optionally you can download them to a specified location.

Tools
ESX/ESXi and vCenter Server Installation Guides
Product Documentation
vSphere Client

Additionel Links
Performance and Troubleshooting Guide - Thanks to Milopez using the comment system

Objective 8.2 – Perform Basic Troubleshooting for VMware FT and Third-


Party Clusters
Written by Matthijs van den Berg

Monday, 07 December 2009 22:02

Knowledge
Analyze and evaluate VM population for maintenance mode considerations
As explained before in chapter 7.2 you need to take special care before placing a host in maintenance mode when using FT. Because a FT VM requires two instead of
one active host you need to make sure that you have at least two hosts supporting FT and having exactly the same configuration and version number. If you cannot
meet these criteria you disable FT (remember that disabling is faster than turing it off).
Understand manual Third-Party failover/failback processes
When using other fail-over techniques VMware provides you with nothing more or less than hardware virtualization (assuming that FT is not used). There are many 3th
When using other fail-over techniques VMware provides you with nothing more or less than hardware virtualization (assuming that FT is not used). There are many 3th
party techniques to provide fail-over scenarios on the guest (VM) level. Every tool has its own requirements and procedures to fail-over.

A small piece of extra info:


Prehaps this question is about the fail-over of ESX hosts from one site to another. There is a possibility to create scripts to seach the replicated LUNs and import the
VM found into you vCenter / vSphere environment. This includes the manual action:

Replicates LUNs with VMs


Make sure there is enough capacity to start all VMs on one site
Create a shell script to search LUNs / VMFS volumes and import the VMs
Create a script to start the VMs in a particular order with pauses between the start-up.

Troubleshoot Fault Tolerance partial or unexpected fail-overs


You can use the information provided in the appendix Fault Tolerance Error Messages to help you troubleshoot Fault Tolerance. The topic contains a list of error
messages that you might encounter when you attempt to use the feature and, where applicable, advice on how to resolve each error.

Storage Related Errors


When you loose / partial loose / have slow storage you VM might experience errors. For those errors te solve first solve the underlying storage errors.
Network related errors
When the logging NIC is not functioning the FT VM might fail-over. To solve this dedicate a separate NIC for fail-over and vMotion.
Network related errors – bandwidth issues
When there is not enough bandwidth to send all transactions to fail-over hosts you FT VM fail. To solve this reduce the number of FT VMs, increase the
bandwidth of, the easiest solution, distribute the FT VMs and their copies more evenly over all hosts.
vMotion failure
When you vMotion a VM that is busy the vMotion might fail. This might cause a FT VM to failover. To avoid this VMware recommends only to vMotion VMs when
the VM is not that busy… so night work ;-)
File system – too much IO
When a file system is handling too much IO this might cause a FT VM to fail-over. Since the failed over VM will use the same storage array this is not going to
help, so to solve this the only way is to reduce the number of IOs on a VMFS volume. To see is a VMFS volume is over utilized check for warnings about SCSI
reservations in the VMkernel log.

Tools
vSphere Availability Guide
Product Documentation
vSphere Client

Objective 8.3 – Perform Basic Troubleshooting for Networking


Written by Matthijs van den Berg

Monday, 07 December 2009 23:04

Knowledge
Verify VM is connected to the correct port group
To check if a VM is connected to the correct port group you can check if the Vm is connected to the correct port group. Changing the name of a port group when virtual
machines are already connected to that port group causes an invalid network configuration for the virtual machines configured to connect to that port group. The
connection from virtual network adapters to port groups is made by name, and the name is what is stored in the virtual machine configuration. Changing the name of a
port group does not cause a mass reconfiguration of all the virtual machines connected to that port group. Virtual machines that are already powered on continue to
function until they are powered off, because their connections to the network are already established. Avoid renaming networks after they are in use. After you rename
a port group, you must reconfigure each associated virtual machine by using the service console to reflect the new port group name. To look up the port group name:

Select the VM
Right Click and select “Edit Settings”
Select the network adaptor of your choosing
Check if the drop down box shows the correct network adaptor

Verify port group settings are correct


To check to port group settings, for example what physical NIC and / or VLAN are being used you need to check the port group settings. To do so (assuming you have
a default vSwitch, not a distributed one):

Select “Hosts and Clusters” view (Home > Inventory > Hosts and Clusters)
Select an ESX host
Select the “Configuration” tab
Select “Networking”
Select the vSwitch that the port group belongs to

Check the Upload Adaptors and check speed, duplex and VLAN trunk on the switch

Click “Properties” on that port group

Select the port group in the pop-up screen that appears and click “Edit”
Check if the VLAN mentioned is the correct one.

Verify that the network adaptor is connected within the VM


To check is the NIC is connected (virtually connected) check the VM properties:

Select the VM
Right Click and select “Edit Settings”
Select the network adaptor

Check if the box “Connected” is ticked under “Device Status”


Check if the box “Connected at power on” is ticked (optional)

Verify VM network adaptor settings


The Virtual NIC has some settings on its own. To check:

Select the VM
Right Click and select “Edit Settings”
Select the network adaptor

Check if the adaptor is of the correct type (e1000, enhanched VMXNET3 etc.)
Check if the adaptor has the correct MAC address (or better; auto)

Verify physical network adaptor settings


All virtual NICs are connected through physical adaptors. Those adaptors, again, have specific settings on their own. To check those:

Select “Hosts and Custer's” view (Home > Inventory > Hosts and Custer's)
Select an ESX host
Select the “Configuration” tab
Select “Networking”
Select the tab “Network Adaptors”
Check “Edit” to change the speed and duplex

Verify vSphere network management settings


Network Management of management network??? If you know the answer? Drop my a line or use the comment system please.

Tools
ESX/ESXi Configuration Guides
Product Documentation
vSphere Client
ping, vmkping, tcpdump, nslookup

Objective 8.4 – Perform Basic Troubleshooting for Storage


Written by Matthijs van den Berg
Thursday, 10 December 2009 23:02

Knowledge
Identify storage contention issues
The first thing here is; what is storage contention. Storage contention is the battle of several, in our case, VMs for storage performance. A SAN is limited in
performance, mostly limited by write I/Os of sometimes in bandwidth. This can cause a higher than usual latency before a write to disk is committed. This latency
depends on many things like the performance of the array (duh), the network, the disks, synchronous replication to a second site, the amount used, etc.

To effectively find the one issue that is causing delay in your SAN / NAS network might be quite a quest. Usually I p think SAN / NAS tooling is used to find the delays.
It all starts with finding the cause of the contention. For this reason VMware a build Performance section in vSphere. To look at disk latency:

Select and ESX host


Select the tab “performance”
Find the chart that says “Disk (ms)” It shows a chart like this one:

Look at the milliseconds to see if your SAN has structural latency (congestion) issues.

You can also use ESXTOP on the command line to find latency information. Read more on ESXTOP here and look for davg / gavg / kavg. Also read my blof on
how to log to a remote share for a longer period of time.
VMware recommends smaller LUNs to reduce the contention of storage.

Identify storage over-commitment issues


I could not find any official documentation. To look for overcommitted storage arrays look at:

Latency
Number of I/Os verses you storage array’s maximum
The Queue depth used
Etc.

Identify storage connectivity issues


The way to troubleshoot this depends on your type of storage; IP based or Fibre Channel based. When you use an IP based storage solution, for example an iSCSI
solution, you can use ping, esxping, trace route etc. to check the network layer. Do not forget to ping with a larger packet size when using jumbo frames to check if all
the components in the network between you ESX host and the storage array (and including those two) support jumbo frame size (9000).

To troubleshoot fibre channel you need to take a look at:

LUN presentation at the storage array (presented to the correct ESX host (WWN Name))
Zoning of the Fibre Channel Switches
LUN masking on the ESX host, configuration of the HBA, are you using boot from SAN? Check the HBA BIOS, etc.

Identify iSCSI software initiator configuration issues


In the previous step we checked the network layer of the iSCSI / NAS based storage layer. The problem might also be the (virtual) iSCSI adaptor it self. Some of the
things you need to check:

IP address
Jumbo Frames
Subnets configures for iSCSI
VLAN ID
Etc.

Interpret Storage Reports and Storage Maps


The VMware vSphere interface produces many graphs and topology layout images for your convenience. These images can give you a good insight into the VMware
performance and layout. To find thore reports:

Select and ESX host or Virtual Machine


Select the tab “Performance”
Look at the graphs you find interesting.
To interpret those graphs

Look at the Disk (ms), more latency might indicate contention


Look at the Disk (KBps) to see how busy you SAN is and relate this to the maximum performance of you SAN.

Tools
FC SAN Configuration Guide
iSCSI SAN Configuration Guide
Product Documentation
vSphere Client

Objective 8.5 – Perform Basic Troubleshooting for HA/DRS and VMotion


Written by Matthijs van den Berg
Wednesday, 20 January 2010 21:51

Knowledge
Explain the requirements of HA/DRS and VMotion
VMotion, the technique used for DRS and in some extend HA have certain requirements to work. I have tried to put most of them in a list:

Compatible CPUs
Depending on your VMotion type (Enhanced VMotion of the previous regular stuff) you need matching CPUs. For regular VMotion these must come from the
same family, with enhanced vMotion this requirement is stretched to “vendor”.
Advanced CPU Features
All hosts must have AMD-V or Intel-VT and AMD-NX or Intel XD.
A Gigabit network interface
At least a gigabit NIC is required for vMotion to transferr the state of the VM to another host.
Jumbo Frames
Jumbo Frames are recommended for the best vMotion performance
All hosts must be connected to a vCenter server
The hosts must be part of a vCenter environment and have the correct licences applied.
Shared Storage
All hosts must be able to access shared storage where VMs can reside.
VM without RAW disk of physically connected devices
The VM must not have a RAW device for clustering purposes or any physically devices, like local CD-ROM players from a host or managemnt station, connected.
Verify VMotion functionality
vMotion uses a dedicated interface to transfer data. Usually this interface in designed to use a separate VLAN / subnet. To test if network connectivity, optionally with
jumbo frames, is working properly you can use the vmkping command

vmkping [options] [host|IP address]

Read more on vmkping ant the available options here. For the ultimate test can can manually vMotion a VM from one host to another.
Verify DNS settings
Adding a host to your company's DNS is essential. Without DNS things like HA will act strange. Though a hostfile can do the trick, DNS usually is more easy to
configure and maintain. Make sure that the following in regards to DNS resolving works:

Resolve your hostname


Resolve you FQDN hostname
Resolve your IP address (reversed lookup)

Verify the service console network functionality


You can use vmkping (see above under Verify vMotion Compatibility) to use vmkping to test the SC network connection
Interpret the DRS Resource Distribution Graph and Target/Current Host Load Deviation
The Tab hosts of your Cluster contains the following view:

This view shows the amount or resource (CPU / Memory) being used on each hosts. When CPU or memory are unbalanced for a longer period of time moving one or
more VMs might balance the load en let all servers on those hosts perform better.
Troubleshoot VMotion using topology maps
Topology maps are a easy way to show you the network and storage connection from an to ESX hosts and / or VMs. As stated above there are some requirements to
the use of vMotion live storage, networking etc. A first and easy check is to look at the topology maps and see if these requirements are met. Maps can be found
when selecting a server and than selecting the tab Maps.
Troubleshoot HA capacity issues
When planning for HA you need to plan for a maximum host failure; the number of hosts that can fail before you run short on resources. When VMs can no longer
start this might be due to a lack of resources (memory is quite common). You Vi will provide you with warnings like “insufficient resources to satisfy failover level” etc.
Read more here (VI doc but most info is still relevant). http://www.vmware.com/files/pdf/VMwareHA_twp.pdf
Troubleshoot HA redundancy issues
HA redundancy.. What is meant here? The number of host failures allowed? A second service console to counter network issues? If you know, help me out using the
comment system please!

Tools
vSphere Availability Guide
vSphere Resource Management Guide
Product Documentation
vSphere Client
DRS Resource Distribution Graph
Topology Maps
cpuid, ping, vmkping

Matthijs’ Links
DRS Performance Best Practice

Objective 8.6 – Create and Respond to vCenter Connectivity Alarms


Written by Matthijs van den Berg

Wednesday, 20 January 2010 22:01

Knowledge
List vCenter default connectivity alarms
Going to do this one the easy way. VMware publishes a table in their Online Library (see blow) that shows all the default. Below is a selection that excludes the
performance alarms (see 8.7 for those).

Alarm Name Description

Cannot Connect to Network Monitors network connectivity on a vSwitch.

Cannot Connect to Storage Monitors host connectivity to a storage device.

Cluster High Availability Error Monitors high availability errors on a cluster.


Datastore Usage On Disk Monitors datastore disk usage.

Exit Standby Error Monitors whether a host cannot exit standby mode.

Health Status Changed Monitors changes to service and extension health status.

Host Battery Status Monitors host batteries.

Host Connection and Power State Monitors host connection and power state.

Host Connection Failure Monitors host connection failures.

Host CPU Usage Monitors host CPU usage.

Host Error Monitors host error and warning events.

Host Hardware Fan Status Monitors host fans.

Host Hardware Power Status Monitors host power.

Host Hardware System Board Status Monitors host system boards.

Host Hardware Temperature Status Monitors host temperature.

Host Hardware Voltage Monitors host voltage.

Host Memory Status Monitors host memory.

Host Memory Usage Monitors host memory usage.

Host Processor Status Monitors host processors.

Host Service Console SwapIn Rate Monitors host service console memory swapin rate.

Host Service Console SwapOut Rate Monitors host service console memory swapout rate.

Host Status for Hardware Objects Monitors the status of host hardware objects.

Host Storage Status Monitors host connectivity to storage devices.

License Error Monitors license errors.

License Inventory Monitoring Monitors the license inventory for compliancy.

Migration Error Monitors whether a virtual machine cannot migrate or relocate,


or is orphaned.

List possible actions for connectivity alarms


Below you will find all actions that can be defind as a action for a specific alarm. (found here)

Action Description Alarm Object

Send a notification email SMTP sends an email message. datacenter, datastore, cluster, host,
The SMTP must be ready when the resource pool, virtual machine,
email message is sent. You can set network, vNetwork distributed
SMTP through vCenter Server or switch, dvPort group
through Microsoft Outlook Express.

Send a notification trap SNMP sends a notification trap. datacenter, datastore, cluster, host,
vCenter Server is the default SNMP resource pool, virtual machine
notification receiver. An SNMP trap
viewer is required to view a sent
viewer is required to view a sent
trap.

Run a command Performs the operation defined in datacenter, datastore, cluster, host,
the script you specify. It runs as resource pool, virtual machine,
separate process and does not network, vNetwork distributed
block vCenter Server processes. switch, dvPort group

Enter or exit maintenance mode Puts the host in and out of host
maintenance mode. Maintenance
mode restricts virtual machine
operations on the host. You put a
host in maintenance mode when
you need to move or service it.

Enter or exit standby Suspends or resumes the guest host


operating system on the virtual
machine.

Reboot or shut down host Reboots or shuts down the host. host

For a given alarm, analyze and evaluate the affected virtual infrastructure components
See the second column from the table above.
Create a vCenter connectivity alarm
To create a custom alarm you first need te specify the level you would like to create an alarm on. The Virtual Infrastrcture level is a good start (highest level). Do:

Select the tab “Alarms”


Select the view “Definitions”
Right click in the definitions pane and select “New Alarm…” the flowing pane opens:

Select the second bullet: “Monitor for specific events…”


Enter all values in all tabs to create the alarm. Since there is a large number of settings to be made I will not state all options. The options a quite clear as well.

Relate the alarm to the affected components


I think that this means that you can create an alarm on different levels like data-center, host or VM level. Actions that are triggered based on a event will only affect
that level and the objects that are part of that level.

For example, you can create a alarm for one VM only that monitors the VM and reboots the host when memory usage is out of control.

Another answer to this question is perhaps how to see what part of your virtual infrastructure is affected by the issue indicated by the alarm. You can see this under
“object” in the “Triggered Alarms” view.

But perhaps something different is meant here. If you think so, help me out and reply below!

Tools
vSphere Basic System Administration Guide
Product Documentation
vSphere Client
Objective 8.7 – Create and Respond to vCenter Utilization Alarms
Written by Matthijs van den Berg

Wednesday, 20 January 2010 23:11

Knowledge
List vCenter default utilization alarms

No Compatible Host For Secondary Virtual Monitors whether there are no compatible hosts available to
Machine place a secondary virtual machine.

Timed Out Starting Secondary Virtual Machine Monitors timeouts when starting a Secondary virtual machine.

Virtual Machine CPU Ready Monitors virtual machine CPU ready time.

Virtual Machine CPU Usage Monitors virtual machine CPU usage.

Virtual machine disk commands canceled Monitors the number of virtual machine disk commands that
are canceled.

Virtual machine disk reset Monitors the number of virtual machine bus resets.

Virtual Machine Error Monitors virtual machine error and warning events.

Virtual Machine Fault Tolerance Secondary Monitors changes in latency status of a fault tolerance
Latency Status Changed secondary virtual machine.

Virtual Machine Fault Tolerance State Monitors changes in the fault tolerance state of a virtual
Changed machine.

Virtual Machine High Availability Error Monitors high availability errors on a virtual machine.

Virtual Machine Memory Usage Monitors virtual machine memory usage.

Virtual Machine Total Disk Latency Monitors virtual machine total disk latency.

List possible actions for utilization alarms

Action Description Alarm Object

Suspend the virtual machine Suspends the virtual machine when virtual machine
the alarm triggers. You can use the
suspend feature to make resources
available on a short-term basis or
for other situations in which you
want to put a virtual machine on
hold without powering it down.

Power on or power off the virtual Power on starts the virtual machine virtual machine
machine and boots the guest operating
system if the guest operating
system is installed.Power off is
analogous to pulling the power
cable on a physical machine. It is
not a graceful shutdown of the guest
operating system, but is used when
a shut down might not succeed. For
example, a shut down will not work if
the guest operating system is not
responding.

Reset the virtual machine Pauses activity on the virtual virtual machine
machine. Transactions are frozen
until you issue a Resume
command.
Migrate the virtual machine Powers off the virtual machine and virtual machine
migrates it according to the settings
you define when you created the
alarm action.

Reboot or shutdown the guest Reboot shuts down and restarts the virtual machine
guest operating system without
powering off the virtual
machine.Shutdown shuts down the
guest operating system gracefully.

For a given alarm, analyze and evaluate the affected virtual infrastructure resource
See the tables above
Create a vCenter utilization alarm
To create a custom alarm you first need te specify the level you would like to create an alarm on. The Virtual Infrastructure level is a good start (highest level). Do:

Select the tab “Alarms”


Select the view “Definitions”
Right click in the definitions pane and select “New Alarm…” the flowing pane opens:

Select the second bullet: “Monitor for specific conditions of state…”


Enter all values in all tabs to create the alarm. Since there is a large number of settings to be made I will not state all options. The options a quite clear as well.

Relate the alarm to the affected resource


I think that this means that you can create an alarm on different levels like data center, host or VM level. Actions that are triggered based on a event will only affect
that level and the objects that are part of that level.

For example, you can create a alarm for one VM only that monitors the VM and reboots the host when memory usage is out of control.

Another answer to this question is perhaps how to see what part of your virtual infrastructure is affected by the issue indicated by the alarm. You can see this under
“object” in the “Triggered Alarms” view.

But perhaps something different is meant here. If you think so, help me out and reply below!

Tools
vSphere Basic System Administration Guide
Product Documentation
esxtop/resxtop
Performance Charts
vSphere Client

Objective 8.8 – Monitor vSphere ESX/ESXi and Virtual Machine


Performance
Written by Matthijs van den Berg
Saturday, 13 February 2010 10:16
Knowledge
Before we start this chapter…. I will keep it to the basics here. After taking the exam I did not find any questions that cover the subjects in the chapter in depth. I also think
that this is not the idea of the VCP exam, and that VMware will go there with the enterprise admin exam. So the basics of performance. Here we go…

Identify critical performance metrics (e.g., CPU ready, queue depth, etc.)
As you might have read before working with virtual servers kinda changes the way to think about resources and servers. Because VMware places multiple servers on
1 host those servers will, at some point, start competing for resources. This battle might result in a lack of a particular resource. To find out what resources are short
you can monitor some metrics of the ESX host.

CPU Ready time


VMware schedules the CPU requests from the VMs on the physical processor. Those multiple requests must be consolidated onto a fewer number of
processors. When the load is high, this scheduling becomes challenging. Especially with multi processor VMs (vSMP) the scheduling is difficult. VMware needs to
have to total number of vCPUs as physical cores available before this request is executed on the processor. When you have 2 VMs, a 1 proc and a 4 proc, and 4
physical cores the 4 processor request will not be scheduled until the 1 CPU requests are handled. So you have 3 CPU cores waiting.. that’s CPU ready time.
Read more here. http://www.vmware.com/pdf/esx3_ready_time.pdf

In fact, sometimes providing a server with LESS vCPUs might result in BETTER performance. This strongly depends on you specific hardware, VMs and Load. A
general rule, use the MINIMUM amount of vCPU as possible.

For those who would like to dig in to this, you do have things like less further relaxed co-scheduling. Read some here: http://www.vmware.com/files/pdf/perf-
vsphere-cpu_scheduler.pdf
Queue depth
This queue depth applies to the storage queue on your ESX system. VMware places request on the storage queue. You can use ESXTOP to monitor the queue
depth over time. I have written a blog about ESXTOP monitoring here . When the queue starts to rise, you storage array / SAN infrastructure is not able to get all
I/Os written to disk. When the queue overflows, I/Os are in fact lost.

Since queued commands are an instantaneous statistic, you will need to monitor it over a period of time to see if you are hitting the queue limit. To determine
queued commands, 'QUED' is the counter to look for in the esxtop, storage resource screen. If queueing, then try to adjust queue depths. See “Related
Publications” on page 22, KB article 1267.

Explain memory metrics (ballooning, shared, etc.)


Memory is one of the resources that you run short on some day in your environment. VMware uses a technique called ballooning to reclaim memory from VMs. The
process is in fact quite simple: When the ESX host runs short on memory it signals the ballooning driver in the VM to inflate. This inflation increases the memory
pressure within the VM causing the VM OS to start using its own memory techniques to free up memory. Since the balloon within the VM is not consuming actual
memory, but only make the guest OS belive so, the freed memory within the guest is available for ESX to use.

Unfortunately the memory techniques within the guest usually mean SWAPPING. Swapping is, as we all know, done on slower disk resulting in performance
degradation. When ballooning occurs be aware the performance might drop because your ESX host is short in memory.

More info can be found here.


Explain CPU metrics (ready/wait time, etc.)
Yep, just did two bullets above.
Explain network metrics (usage, packet drops, etc.)
You can monitor the network performance by using the “ESXTOP” command line tool or by viewing the information in the vSphere GUI. Since I prefer the ESXTOP tool
because it really shows a lot of information…: To use it and let it show network charastics use:
esxtop –a
Then press the letter “n” to let it show network charastics. The “-a” option defines that esxtop will be showing ALL fields (widen you screen to show all). To change
this, and show only fields that interest you use the “f” key. There are quite a large number of columns, I picked a few to explain:

PORT-ID
The virtual network device port id.
UPLINK
Y implies the corresponding port is an up-link. N implies it is not.
UP
Y implies the corresponding link is up. N implies it is not.
%USED
The amount of total network capacity used. My ESX host shows 800% here when having 4 NICs in the system. So I think this shows 200% per physical NIC,
100% for up and 100% for down.
PKTTX/s
The number of packets transmitted per second.
PKTRX/s
The number of packets received per second.
MbTX/s
The Megabits transmitted per second.
MbRX/s The MegaBits received per second.
%DRPTX The percentage of transmit packets dropped.
%DRPRX
The percentage of receive packets dropped.

You an find all items explained bu reading the MAN pages of esxtop. You can also find them on the internet.

Explain storage metrics (latency, queuing, etc.)


You can use ESXTOP and select the “d” (disk) key to show disk I/O performance metrics. Those metrics can give you some insight in the performance of you storage
device. Some columns of the disk portion of ESXTOP are:

NLUNS
The number of LUN’s that are behind the specific adaptor. You can check wheter you have distributed your LUN’s evenly across you HBA’s. Be aware the when
using multiple storage processors you have more paths to you SAN / NAS than HBA’s. This means this figure will not provide you with a complete picture of all
using multiple storage processors you have more paths to you SAN / NAS than HBA’s. This means this figure will not provide you with a complete picture of all
your storage paths!
READS/s and WRITES/S
This show the number of reads and writes per second per HBA. This gives you an insight in the amount of I/Os you esx host and storage device are processing.
MBREAD/s and MBWRTN/s
The amount of Megabytes read and written per second. This gives you an insight into the amount of data your ESX hosts and storage device are processing.
When using the GUI you can view the latency. This latency figure shows you the round trip time from you ESX host to you storage device. This can be important
as long latency is killing for a good overall performance. Latency can increase due to heavy load, long distances to the storage device (second site for example)
of a bad of over committed network / storage infrastructure.
AQLEN
The storage adapter queue depth. This is the maximum number of ESX VMKernel active commands that the adapter driver is configured to support.
LQLEN
The LUN queue depth. This is the maximum number of ESX VMKernel active commands that the LUN is allowed to have.

Compare and contrast Overview and Advanced Charts


You can view performance characters in the vCenter client. To do so:

Select and object, for example a ESX host


Select the tab “Performance”
There are two different default levels:

Overview
Give you an overview of some of the most important counts of an object. This is a clean overview
Advanced
Gives you some more advance charts and the ability to create you own charts. This can help you make charts for a specific VM or ESX host when running
into issues.

Create an Advanced Chart


You can create / customize performance charts in vCenter. To do so:

Select and object, for example a ESX host


Select the tab “Performance”
Click the button “Advanced” in the upper left corner
Click “Chart Option”, the following screen appears:

Select a Chart option area you would like to create a custom chart for
Select all counters you would like to include
Click “Save Chart Settings…” in the lower right corner, give a name and save.
You can select you custom chart settings under “Switch To…” in the top of the screen.

Determine host performance using guest Perfmon


You can generate log files with ESX top and export them to be used within Perfmon. I have write a blog on how to do so here.

Tools
vSphere Resource Management Guide
Product Documentation
esxtop/resxtop
Performance Charts
vSphere Client

Matthijs’s Links
Comparison between VMXNET and VMXNET3 Ethernet adaptors
Performance Monitoring and Analysis on the VMware site

Practice Exams
Written by Matthijs van den Berg

Sunday, 29 November 2009 20:12

There are some exam practice sites and tools out there that can help you prep for the actual exam and give you an insight of the type of questions that will be asked.

I would recommend that you first learn (for example by using my learning guide) and then use the practice exam to test if you are ready to go for it.

Warning: Those practice exams might but also MIGHT NOT represent actual exam questions!
Simon Longs Practice Exams
Exam Collection.com (You need a special tool ($) to take this test exam!)

And you have those payed exam questions.... for example:

Testking
Pass4Sure
....

If you have more resources, please let me know!

VCP4 STUDIE GUIDE - FAST FIND


- Quick navigation -

Copyright © 2010 B3RG. All Rights Reserved.


Joomla! is Free Software released under the GNU/GPL License.

Вам также может понравиться