VSOS51 Lecture V1 PDF

VMware vSphere:
Optimize and Scale

Lecture Manual Volume 1
ESXi 5.1 and vCenter Server 5.1
VMware Education Services

VMware, Inc.
www.vmware.com/education
VMware vSphere:
Optimize and Scale
ESXi 5.1 and vCenter Server 5.1
Part Number EDU-EN-OS51-LECT1
Lecture Manual Volume 1
Revision A
Copyright/Trademark
Copyright 2012 VMware, Inc. All rights reserved. This manual and its accompanying
materials are protected by U.S. and international copyright and intellectual property laws.
VMware products are covered by one or more patents listed at http://www.vmware.com/go/
patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States
and/or other jurisdictions. All other marks and names mentioned herein may be trademarks
of their respective companies.
The training material is provided as is, and all express or implied conditions,
representations, and warranties, including any implied warranty of merchantability, fitness for
a particular purpose or noninfringement, are disclaimed, even if VMware, Inc., has been
advised of the possibility of such claims. This training material is designed to support an
instructor-led training course and is intended to be used for reference purposes in
conjunction with the instructor-led training course. The training material is not a standalone
training tool. Use of the training material for self-study without class attendance is not
recommended.
These materials and the computer programs to which it relates are the property of, and
embody trade secrets and confidential information proprietary to, VMware, Inc., and may not
be reproduced, copied, disclosed, transferred, adapted or modified without the express
written approval of VMware, Inc.
Course development: Mike Sutton
Technical review: Johnathan Loux, Carla Gavalakis
Technical editing: Jeffrey Gardiner
Production and publishing: Ron Morton, Regina Aboud
www.vmware.com/education
TA B L E
OF
C ONTENTS
MODULE 1
Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
Importance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
Learner Objectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
You Are Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Typographical Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
VMware Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
VMware Online Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
vSphere Production Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
MODULE 2
VMware Management Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

You Are Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
Importance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
Learner Objectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
Methods to Run Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
ESXi Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Accessing ESXi Shell Locally. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Accessing ESXi Shell Remotely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
vCLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
vMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
vMA Hardware and Software Requirements . . . . . . . . . . . . . . . . . . . . .22
Configuring vMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Connecting to the Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Deploying vMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Configuring vMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Adding a Target Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
vMA Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Joining vMA to Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Command Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
vMA Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
esxcfg Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
esxcfg Equivalent vicfg Commands Examples . . . . . . . . . . . . . . . . . . . .33
Managing Hosts with vMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Common Connection Options for vCLI Execution . . . . . . . . . . . . . . . . .35
Common Connection Options for vCLI Execution (2) . . . . . . . . . . . . . .37
vicfg Command Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Entering and Exiting Host Maintenance Mode . . . . . . . . . . . . . . . . . . . .39
vmware-cmd Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Format for Specifying Virtual Machines with vmware-cmd . . . . . . . . .41
Connection Options for vmware-cmd . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Managing Virtual Machines Using vmware-cmd . . . . . . . . . . . . . . . . . .43
Listing and Registering Virtual Machines with vmware-cmd . . . . . . . .44
Retrieving Virtual Machine Attributes with vmware-cmd . . . . . . . . . . .45
Managing Virtual Machine Snapshots with vmware-cmd . . . . . . . . . . .47
VMware vSphere: Optimize and Scale
Powering Virtual Machines On and Off with vmware-cmd . . . . . . . . . .48

Connecting Devices with vmware-cmd. . . . . . . . . . . . . . . . . . . . . . . . . .49
Working with the AnswerVM API . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
esxcli Command Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
Example esxcli command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Lab 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
Review of Learner Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Key Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
MODULE 3
ii
Performance in a Virtualized Environment . . . . . . . . . . . . . . . . . . . . . . .57

You Are Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
Importance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
Module Lessons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Lesson 1: Performance Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Virtualization Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
VMware ESXi Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
Virtualization Performance: First Dimension . . . . . . . . . . . . . . . . . . . . .65
Virtualization Performance: Second Dimension . . . . . . . . . . . . . . . . . . .66
Virtualization Performance: Third Dimension . . . . . . . . . . . . . . . . . . . .67
Performance Factors in a vSphere Environment . . . . . . . . . . . . . . . . . . .68
Traditional Best Practices for Performance . . . . . . . . . . . . . . . . . . . . . . .69
What Is a Performance Problem? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
Performance Troubleshooting Methodology . . . . . . . . . . . . . . . . . . . . . .71
Basic Troubleshooting Flow for ESXi Hosts . . . . . . . . . . . . . . . . . . . . .72
Lesson 2: Virtual Machine Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
What Is the Virtual Machine Monitor? . . . . . . . . . . . . . . . . . . . . . . . . . .76
What Is Monitor Mode? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
Challenges of x86 Hardware Virtualization . . . . . . . . . . . . . . . . . . . . . .78
CPU Software Virtualization: Binary Translation . . . . . . . . . . . . . . . . .79
CPU Hardware Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
Intel VT-x and AMD-V (First Generation) . . . . . . . . . . . . . . . . . . . . . . .81
CPU Virtualization Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
Memory Management Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
MMU Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
Software MMU: Shadow Page Tables . . . . . . . . . . . . . . . . . . . . . . . . . .85
Hardware MMU Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
Memory Virtualization Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
Choosing the Default Monitor Mode . . . . . . . . . . . . . . . . . . . . . . . . . . .88
Overriding the Default Monitor Mode . . . . . . . . . . . . . . . . . . . . . . . . . .89
Application Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
Displaying the Default Monitor Mode . . . . . . . . . . . . . . . . . . . . . . . . . .91

Lesson 3: Monitoring Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
Commonly Used Performance Monitoring Tools . . . . . . . . . . . . . . . . . .96
Overview Performance Charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
Advanced Performance Charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98
Customize Performance Charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
Chart Options: Real-Time and Historical . . . . . . . . . . . . . . . . . . . . . . .100
Chart Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102
Objects and Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104
Statistics Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
Rollup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
Saving Charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
resxtop Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
Using resxtop Interactively . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Navigating resxtop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Sample Output from resxtop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Using resxtop in Batch and Replay Modes . . . . . . . . . . . . . . . . . . . . . . 114
Analyzing Batch Mode Output with Perfmon . . . . . . . . . . . . . . . . . . . . 116
Guest Operating System-Based Performance Tools . . . . . . . . . . . . . . . 117
Perfmon DLL in VMware Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Choosing the Right Tool (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Choosing the Right Tool (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
Lab 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
Review of Learner Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123
Key Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
MODULE 4
Contents
Network Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125

You Are Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
Importance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
Module Lessons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128
Lesson 1: Introduction to vSphere Distributed Switch . . . . . . . . . . . . .129
Learner Objectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
Distributed Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
Benefits of Distributed Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132
Distributed Switch Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
Viewing Distributed Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
Managing Virtual Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
Managing Physical Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136
Enabling IPv6 on the ESXi Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
Connecting a Virtual Machine to a Distributed Port Group . . . . . . . . .138
Distributed Switch Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
iii
Editing General Distributed Switch Properties . . . . . . . . . . . . . . . . . . .141

Editing Advanced Distributed Switch Properties . . . . . . . . . . . . . . . . .142
Editing Distributed Port Group Properties . . . . . . . . . . . . . . . . . . . . . .143
Distributed Switch Configuration: .dvsData Folder . . . . . . . . . . . . . . .144
Standard Switch and Distributed Switch Feature Comparison . . . . . . .146
Lab 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147
Lesson 2: Distributed Switch Features . . . . . . . . . . . . . . . . . . . . . . . . .149
Distributed Switch Port Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151
Port-Binding Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153
VLAN Policies for Distributed Port Groups . . . . . . . . . . . . . . . . . . . . .154
What Is a Private VLAN? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155
Types of Secondary Private VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . .156
Promiscuous Private VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157
Isolated Private VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158
Community Private VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159
Private VLAN Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
Private VLANs and Physical Switches . . . . . . . . . . . . . . . . . . . . . . . . .162
Physical Switch PVLAN-Aware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
Configuring and Assigning Private VLANs . . . . . . . . . . . . . . . . . . . . .166
Discovery Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168
Configuring CDP or LLDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169
Viewing CDP Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
Viewing LLDP Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172
What Is Network I/O Control? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173
Configuring System-Defined Network Resource Pools . . . . . . . . . . . .175
User-Defined Network Resource Pools. . . . . . . . . . . . . . . . . . . . . . . . .177
Configuring a User-Defined Network Resource Pool . . . . . . . . . . . . . .178
Network Health Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180
Network Health Check - Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181
Enabling Health Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183
Health Check Results Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .184
What Is NetFlow? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185
Network Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .186
Network Flow Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188
Configuring NetFlow on a Distributed Switch . . . . . . . . . . . . . . . . . . .190
What Is Port Mirroring? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
Configuring a Port Mirror Session . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
Port Mirroring Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194
Source and Destination Selections . . . . . . . . . . . . . . . . . . . . . . . . . . . .195
Configuration Backup and Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . .196
Backup a Distributed Virtual Switch Configuration . . . . . . . . . . . . . . .197
iv
Restore a Distributed Virtual Switch Configuration . . . . . . . . . . . . . . .198

Restore a Port Group Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . .199
Rollback and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200
Rollback Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201
Automatic Rollback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202
Recovery through DCUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203
Lab 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204
Lab 5 (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205
Key Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207
MODULE 5
Contents
Network Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209

You Are Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .210
Importance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Module Lessons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212
Lesson 1: Networking Virtualization Concepts . . . . . . . . . . . . . . . . . .213
Network I/O Virtualization Overhead . . . . . . . . . . . . . . . . . . . . . . . . . .215
vmxnet Network Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217
Virtual Network Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .218
Network Performance Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220
TCP Checksum Offload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
TCP Segmentation Offload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222
Jumbo Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224
Using DMA to Access High Memory . . . . . . . . . . . . . . . . . . . . . . . . .225
10 Gigabit Ethernet (10GigE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226
NetQueue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227
vSphere DirectPath I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228
Single Root I/O Virtualization (SR-IOV) . . . . . . . . . . . . . . . . . . . . . . .230
SplitRx Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231
Lesson 2: Monitoring Networking I/O Activity . . . . . . . . . . . . . . . . . .233
Network Capacity Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235
vSphere Client Networking Statistics . . . . . . . . . . . . . . . . . . . . . . . . . .236
vSphere Client Network Performance Chart . . . . . . . . . . . . . . . . . . . . .237
resxtop Networking Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238
resxtop Network Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239
vSphere Client, vSphere Web Client, or resxtop? . . . . . . . . . . . . . . . . .240
Lab 6 Introduction: Test Cases 1 and 2 . . . . . . . . . . . . . . . . . . . . . . . . .241
Lab 6 Introduction: Test Case 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242
Lab 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243
Lab 6 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244
v

Lesson 3: Command-Line Network Management . . . . . . . . . . . . . . . .246
Command-Line Overview for Network Management . . . . . . . . . . . . .248
Using the DCUI to Configure the Management Network . . . . . . . . . . .249
Managing Virtual Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251
Retrieving Network Port Information . . . . . . . . . . . . . . . . . . . . . . . . . .252
Setting Virtual Switch Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .253
Listing, Creating, and Deleting Standard Switches . . . . . . . . . . . . . . . .254
Managing a VMkernel Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .255
Listing, Adding, and Removing Port Groups . . . . . . . . . . . . . . . . . . . .256
Configuring a Port Group with a VLAN ID . . . . . . . . . . . . . . . . . . . . .257
Linking and Unlinking Uplink Adapters . . . . . . . . . . . . . . . . . . . . . . . .258
Configuring the SNMP Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .259
Configuring DNS and Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260
Managing Uplinks in Distributed Switches . . . . . . . . . . . . . . . . . . . . . .261
Using the net-dvs Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .262
net-dvs Output (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263
net-dvs Output (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .264
Lab 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .265
Lesson 4: Troubleshooting Network Performance Problems . . . . . . . .267
Review: Basic Troubleshooting Flow for ESXi Hosts . . . . . . . . . . . . .269
Dropped Network Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .270
Dropped Receive Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .272
Dropped Transmit Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274
Random Increase in Data Transfer Rate . . . . . . . . . . . . . . . . . . . . . . . .276
Networking Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .278
Key Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280
MODULE 6
vi
Storage Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .281

You Are Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282
Importance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
Module Lessons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .284
Lesson 1: Storage APIs and Profile-Driven Storage . . . . . . . . . . . . . . .285
VMware vSphere Storage APIs - Array Integration . . . . . . . . . . . . . . .287
VMware vSphere Storage APIs - Storage Awareness . . . . . . . . . . . . .289
Benefits Provided by Storage Vendor Providers . . . . . . . . . . . . . . . . . .291
Configuring a Storage Vendor Provider . . . . . . . . . . . . . . . . . . . . . . . .292
Profile-Driven Storage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293
Storage Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .295

Virtual Machine Storage Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . .296
Overview of Steps for Configuring Profile-Driven Storage . . . . . . . . .297
Using the Virtual Machine Storage Profile . . . . . . . . . . . . . . . . . . . . . .299
Checking Virtual Machine Storage Compliance . . . . . . . . . . . . . . . . . .300
Identifying Advanced Storage Options . . . . . . . . . . . . . . . . . . . . . . . . .301
N_Port ID Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .302
N_Port ID Virtualization Requirements . . . . . . . . . . . . . . . . . . . . . . . .303
vCenter Server Storage Filters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .304
Identifying and Tagging SSD Devices . . . . . . . . . . . . . . . . . . . . . . . . .306
Configuring Software iSCSI Port Binding . . . . . . . . . . . . . . . . . . . . . .307
VMFS Resignaturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309
Pluggable Storage Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .310
VMware Default Multipathing Plug-in . . . . . . . . . . . . . . . . . . . . . . . . .312
Overview of the MPP Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .313
Path Selection Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315
Lab 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .316
Lesson 2: Storage I/O Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .318
What Is Storage I/O Control? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .320
Storage I/O Control Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . .321
Storage I/O Control Automatic Threshold Detection . . . . . . . . . . . . . .322
Storage I/O Control Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . .323
Configuring Storage I/O Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324
Lesson 3: Datastore Clusters and Storage DRS . . . . . . . . . . . . . . . . . .327
What Is a Datastore Cluster? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329
Datastore Cluster Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .330
Relationship of Host Cluster to Datastore Cluster . . . . . . . . . . . . . . . .331
Storage DRS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .332
Initial Disk Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .333
Migration Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334
Datastore Correlation Detector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .335
Configuration of Storage DRS Migration Thresholds. . . . . . . . . . . . . .336
Storage DRS Affinity Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .338
Adding Hosts to a Datastore Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . .339
Adding Datastores to the Datastore Cluster . . . . . . . . . . . . . . . . . . . . .340
Storage DRS Summary Information . . . . . . . . . . . . . . . . . . . . . . . . . . .341
Storage DRS Migration Recommendations . . . . . . . . . . . . . . . . . . . . .342
Storage DRS Maintenance Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . .343
Backups and Storage DRS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .344
Contents
vii
Storage DRS - vSphere Technology Compatibility . . . . . . . . . . . . . . .345

Storage DRS - Array Feature Compatibility . . . . . . . . . . . . . . . . . . . . .346
Storage DRS and Storage I/O Control. . . . . . . . . . . . . . . . . . . . . . . . . .347
Lab 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348
Key Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .350
viii
MODULE 1
Course Introduction
Slide 1-1
Course Introduction
Importance
Slide 1-2
Learner Objectives
Slide 1-3
Course Introduction
Module 1 Course Introduction
You Are Here

Slide 1-4
Typographical Conventions
Slide 1-5
Course Introduction
VMware Certification
Slide 1-6
Your first level of certification is VMware Certified Professional on vSphere 5 (VCP5). After you
achieve VCP5 status, you are eligible to pursue the next level of certification: VMware Certified
Advanced Professional on vSphere 5 (VCAP5). This program is available in Datacenter
Administration (DCA) or Datacenter Design (DCD) or both. This program is appropriate for VCPs
who are ready to enhance their skills with the virtual infrastructure and add industry-recognized
credentials to their list of accomplishments.
DCA is for system administrators, consultants, and technical support engineers who can demonstrate
their skills in VMware vSphere and VMware vCenter datacenter technologies. These
participants should also be able to demonstrate their knowledge of application and physicalinfrastructure services and their integration with the virtual infrastructure.
DCD is for IT architects and consulting architects who are capable of designing VMware solutions
in a large, multisite enterprise environment. These architects have a deep understanding both of
VMware core components and of the relationships of the core components to storage and
networking. They also have a deep understanding of datacenter design methodologies. They know
applications and physical infrastructure, and the relationships of applications and physical
infrastructure to the virtual infrastructure.
This course gives you most of the information that you need for the VCAP5-DCA exam, but it does
not give you everything. To best prepare for this exam, use the VCAP5-DCA exam blueprint as a
6
study guide. The blueprint includes the list of topics in the exam and references for these topics.
Hands-on experience is a key component to passing the exam.
To obtain the exam blueprint:
http://mylearn.vmware.com/portals/certification.
2. Click the Exam Blueprint link near the bottom of the page.
After you achieve DCA and DCD status, you are eligible to pursue the highest level of certification:
VMware Certified Design Expert (VCDX). This elite group includes design architects who are
highly skilled in VMware enterprise deployments. The program is designed for veteran
professionals who want to validate and demonstrate their expertise in VMware virtual infrastructure.
For more about certifications, go to the certification Web page at http://mylearn.vmware.com/
portals/certification.
Course Introduction
1. Click the VCAP5-DCA link on the VMware Certification Web page at
VMware Online Resources

Slide 1-7
Making full use of VMware technical resources saves you time and money. Go first to the extensive
VMware Web-based resources. The VMware Communities Web page provides tools and knowledge
to help users maximize their investment in VMware products. VMware Communities provides
information about virtualization technology in technical papers, documentation, a knowledge base,
discussion forums, user groups, and technical newsletters.
The VMware Support page provides a central point from which you can view support offerings,
create a support request, and download products, updates, drivers and tools, and patches.
The VMware Education page enables you to view the course catalog and the latest schedule of
courses offered worldwide. This page also provides access information about the latest advanced
courses offered worldwide.
For quick access to communities, documentation, downloads, support information, and more, install
the VMware Support Toolbar, a free download available at http://vmwaresupport.toolbar.fm.
Periodically check the VMware Education Services Web page for the current list of released
courses.
vSphere Production Documentation

Slide 1-8
Course Introduction
vSphere documentation is available on the VMware Web site at http://www.vmware.com/support/

pubs/vsphere-esxi-venter-server-pubs.html.
From this page, you have access to all the vSphere guides, including guides for optional modules or
products.
On this page, the vSphere 5.1 Documentation Center link provides access to the online version of
all vSphere documentation.
10
MODULE 2
VMware Management Resources
Slide 2-1
2
11
You Are Here

Slide 2-2
12
Importance
Slide 2-3
2
Module 2 VMware Management Resources
13
Learner Objectives
Slide 2-4
14
Methods to Run Commands

Slide 2-5
2
A few methods exist for accessing the command prompt on an VMware vSphere ESXi host.
VMware recommends that you use VMware vSphere Command-Line Interface (vCLI) or
VMware vSphere Management Assistant (vMA) to run commands against your ESXi hosts. Run
commands directly in VMware vSphere ESXi Shell only in troubleshooting situations.
15
ESXi Shell
Slide 2-6
An ESXi system includes a direct console user interface (DCUI) that enables you to start and stop
the system and perform a limited set of maintenance and troubleshooting tasks. The DCUI includes
ESXi Shell, which is disabled by default. You can enable ESXi Shell in the DCUI or by using
VMware vSphere Client.
You can enable local shell access or remote shell access:
Local shell access enables you to log in to the shell directly from the DCUI.
Secure Shell (SSH) is a remote shell that enables you to connect to the host with a shell, such as
PuTTY.
ESXi Shell includes all ESXCLI commands, a set of deprecated esxcfg- commands, and a set of
commands for troubleshooting and remediation.
16
Accessing ESXi Shell Locally

Slide 2-7
2
If you have access to the DCUI, you can enable the ESXi Shell from there.
To enable the ESXi Shell in the DCUI:
1. In the DCUI of the ESXi host, press F2 and provide credentials when prompted.
2. Scroll to Troubleshooting Options and press Enter.
3. Select Enable ESXi Shell and press Enter.
On the left, Enable ESXi Shell changes to Disable ESXi Shell. On the right, ESXi Shell is
Disabled changes to ESXi Shell is Enabled.
4. Press Esc until you return to the main DCUI screen.
Local users that are assigned to the administrator role automatically have local shell access.
Assigning local shell access to the administrator role prevents the root account from being shared by
multiple users. Sharing the root account presents security issues and makes auditing the host
difficult.
17
Accessing ESXi Shell Remotely

Slide 2-8
If you enable SSH access, do so only for a limited time. SSH should never be left open on an ESXi
host in a production environment.
If SSH is enabled for the ESXi Shell, you can run shell commands by using an SSH client, such as
SSH or PuTTY.
To enable SSH from the vSphere Client:
1. Select the host and click the Configuration tab.
2. Click Security Profile in the Software panel.
3. In Services, click Properties.
4. Select SSH and click Options.
5. Change the SSH options. To change the Startup policy across reboots, click Start and stop
with host and reboot the host.

6. Click OK.
18
To enable the local or remote ESXi Shell from the vSphere Client:
1. Select the host and click the Configuration tab.
2. Click Security Profile in the Software panel.
3. In Services, click Properties.
4. Select ESXi Shell and click Options.
stop with host and reboot the host.

6. Click OK.
The ESXi Shell timeout setting specifies how long, in minutes, you can leave an unused session
open. By default, the timeout for the ESXi Shell is 0, which means the session remains open even if
it is unused. If you change the timeout, for example, to 30 minutes, you have to log in again after the
timeout period has elapsed.
To modify the ESXi Shell Timeout:
1. In the Direct Console, follow these steps.
2. Select Modify ESXi Shell timeout and press Enter.
3. Enter the timeout value in minutes and press Enter.
In the vSphere Client, follow these steps:

1. In the Configuration tabs Software panel, click Advanced Settings.
2. In the left panel, click UserVars.
3. Find UserVars.ESXiShellTimeOut and enter the timeout value in minutes.
4. Click OK.
19
5. Change the ESXi Shell options. To change the Startup policy across reboots, click Start and
vCLI
Slide 2-9
vCLI provides a command-line interface for ESXi hosts. Multiple ESXi hosts can be managed from
a central system on which vCLI is installed.
Normally, vCLI commands require you to enter options that specify the server name, the user name,
and the password for the server that you want to run the command against. Methods exist that enable
you to bypass entering the user name and password options, and, sometimes, the server name
option. Two of these methods are described later in this module.
For details about vCLI, see Getting Started with vSphere Command-Line Interfaces and vSphere
Command-Line Interface Concepts and Examples at http://www.vmware.com/support/pubs/vsphereesxi-vcenter-server-pubs.html.
20
vMA
Slide 2-10
2
vMA is a downloadable appliance that includes several components, including vCLI. vMA enables
administrators to run scripts or agents that interact with ESXi hosts and VMware vCenter
Server systems without having to authenticate each time. vMA is easy to download, install, and
configure through the vSphere Client.
21
vMA Hardware and Software Requirements

Slide 2-11
To set up vMA, you must have an ESXi host. Because vMA runs a 64-bit Linux guest operating
system, the ESXi host on which it runs must support 64-bit virtual machines.
The 3GB virtual disk size requirement might increase, depending on the extent of centralized
logging enabled on the vMA appliance.
The recommended memory for vMA is 600MB.
22
Configuring vMA
Slide 2-12
2
You have to initialize vi-fastpass only if you want to enter vCLI commands without specifying a
user name and password for the vCenter Server system or an ESXi host.
23
Connecting to the Infrastructure

Slide 2-13
vMA commands directly targeted at the hosts are sent using the VMware vSphere SDK for Perl
API. Commands sent to the host through the vCenter Server system are first sent to the vCenter
Server system, using the vSphere SDK for Perl API. Using a private protocol that is internal to
vCenter Server, commands are sent from the vCenter Server system to the host.
24
Deploying vMA
Slide 2-14
2
vMA is deployed like any other virtual appliance. After the appliance is deployed to the
infrastructure, the user can power it on and start configuring vMA.
The vMA appliance is available from the download page on the VMware Web site.
25
Configuring vMA
Slide 2-15
After vMA is deployed, your next step is to configure the appliance. When you start the vMA
virtual machine the first time, you can configure it. The appliance can be configured either by
opening a console to the appliance or by pointing a Web browser to the appliance.
The vi-admin account is the administrative account on the vMA appliance and exists by default.
During the initial power-on, you are prompted to choose a password for this user account.
Although the vMA appliance is Linux-based, logging in as root has been disabled.
26
Adding a Target Server

Slide 2-16
2
After you configure vMA, you can add target servers that run the supported vCenter Server or ESXi
versions. The vifp interface enables administrators to add, list, and remove target servers and to
manage the vi-admin users password.
After a server is added as a vMA target, you must run the vifptarget command. This command
enables seamless authentication for remote vCLI and vSphere SDK for Perl API commands. Run
vifptarget <server> before you run vCLI commands or vSphere SDK for Perl scripts against
that system. The system remains a vMA target across vMA reboots, but running vifptarget again
is required after each logout.
You can establish multiple servers as target servers and then call vifptarget once to initialize all
servers for vi-fastpass authentication. You can then run commands against any target server without
additional authentication. You can use the --server option to specify the server on which to run
commands.
27
vMA Authentication
Slide 2-17
The vMA authentication interface enables users and applications to authenticate with the target
servers by using vi-fastpass or Active Directory (AD). While adding a server as a target, the
administrator can determine whether the target must use vi-fastpass or AD authentication. For vifastpass authentication, the credentials that a user has on the vCenter Server system or ESXi host are
stored in a local credential store. For AD authentication, the user is authenticated with an AD server.
When you add an ESXi host as a fastpass target server, vi-fastpass creates two users with obfuscated
passwords on the target server and stores the password information on vMA:
vi-admin with administrator privileges
vi-user with read-only privileges
The creation of vi-admin and vi-user does not apply for AD authentication targets. When you add a
system as an AD target, vMA does not store information about the credentials. To use the AD
authentication, the administrator must configure vMA for AD.
28
Joining vMA to Active Directory

Slide 2-18
2
Configure vMA for Active Directory authentication so that ESXi hosts and vCenter Server systems
added to Active Directory can be added to vMA. Joining the vMA to Active Directory prevents you
from having to store the passwords in the vMA credential store. This approach is a more secure way
of adding targets to vMA.
Ensure that the DNS server configured for vMA is the same as the DNS server of the domain. You
can change the DNS server by using the vMA Console to the Web UI.
Ensure that the domain is accessible from vMA. Ensure that you can ping the ESXi and vCenter
Server systems that you want to add to vMA. Ensure also that pinging resolves the IP address to the
target servers domain.
To add vMA to a domain:
1. From the vMA console, run the following command:
sudo domainjoin-cli join <domain_name> <domain_admin_user>
2. When prompted, provide the Active Directory administrators password.
3. Restart vMA.
29
Command Structure
Slide 2-19
The slide shows syntax and vCLI command examples.

The <target_option> is necessary only if you are sending the command to an ESXi host through
the vCenter Server system. In this case, the <target_option> specifies to which host the vCenter
Server system should forward the command.
The example command (vicfg-nics -l) displays information about the physical network
interface cards on an ESXi host.
30
vMA Commands
Slide 2-20
2
The vCLI command set is part of vMA. For more information about the commands included in
vMA, see Getting Started with vSphere Command-Line Interfaces and vSphere Command-Line
Interface Concepts and Examples at http://www.vmware.com/support/pubs/vsphere-esxi-vcenterserver-pubs.html.
31
esxcfg Commands
Slide 2-21
For many of the vCLI commands, you might have used scripts with corresponding service
commands with an esxcfg prefix to manage ESX 3.x hosts. To facilitate easy migration from ESX/
ESXi 3.x and later versions of ESXi, a copy of each vicfg- command that uses an esxcfg- prefix is
included in the vCLi package.
Commands with the esxcfg prefix are available mainly for compatibility reasons and might
become obsolete.
32
esxcfg Equivalent vicfg Commands Examples

Slide 2-22
2
The slide lists some examples of vicfg commands for which an esxcfg prefix is available.
33
Managing Hosts with vMA

Slide 2-23
Host management commands can stop and reboot ESXi hosts, back up configuration information,
and manage host updates. You can also use a host management command to make your host join an
AD domain or exit from a domain.
34
Common Connection Options for vCLI Execution

Slide 2-24
2
The slide lists options that are available for all vCLI commands.
--cacertsfile
Used to specify the Certificate Authority file in PEM format,

to verify the identity of the vCenter Server system or the
ESXi host to run the command on. Can be used, for example,
to prevent man in the middle attacks.
--config
Uses the configuration file at the specified location. Specify

a path that is readable for the current directory.
--credstore
Name of credential store file. Defaults to <HOME>/

.vmware/credstore/vicredentials.xml on Linux and
<APPDATA>/VMware/credstore/vicredentials.xml
on Windows. Commands for setting up the credential store
are included in the vSphere SDK for Perl.
--encoding
Specifies the encoding to be used. Use --encoding to specify

the encoding vCLI should map to when it is running on a
foreign language system.
35
--passthroughauth
This option specifies the system should use the Microsoft

Windows Security Support Provider Interface (SSPI) for
authentication. Trusted users are not prompted for a user
name and password.
--passthroughtauthpackage
Use this option with --passthroughauth to specify a

domain-level authentication protocol to be used by
Windows. By default, SSPI uses the Negotiate protocol
which means that client and server to negotiate a protocol
that both support.
--password
Uses the specified password when used with --username to

log in to the server.
--portnumber
Uses the specified port to connect to the system specified by

--server. Default port is 443.
36
Common Connection Options for vCLI Execution (2)

Slide 2-25
2
--protocol
Uses the specified protocol to connect to the system specified by

--server. Default is HTTPS.
--savesessionfile
Saves a session to the specified file. The session expires if it has been
unused for 30 minutes.
--server
Uses the specified ESXi of vCenter Server system. Default is localhost.
--sessionfile
Uses the specified session file to load a previously saved session. The
session must be unexpired.
--url
Connects to the specified vSphere Web Services SDK URL.
--username
Uses the specified user name. If you do not specify a user name and
password on the command line, the system prompts you and does not
echo your input to the screen.
--vihost
When you run a vCLI command with --server option pointing to vCenter
Server system, use --vihost to specify the ESXi host to run the command
against.
37
vicfg Command Example

Slide 2-26
An ESXi host can be shut down and restarted using the vicfg-host command options. If a host
managed by vCenter Server is shut down by this command, the host is disconnected from vCenter
Server but not removed from the inventory.
No equivalent ESXCLI command is available.
You can shut down or reboot all hosts in a cluster or datacenter by using the --cluster or
--datacenter option.
In the first and second examples, the connection options (<conn_options>) used are --server,
--username, and --password. But in the third example, the --password option is omitted. In
this case, you are prompted to enter the password when you run this command.
NOTE
vicfg- commands will be deprecated in future releases. Use esxcli commands instead where
possible.
38
Entering and Exiting Host Maintenance Mode

Slide 2-27
2
A host can be placed in maintenance mode by using the vicfg-hostops command. When the
command is run, the host does not enter maintenance mode until all of the virtual machines running
on the host are either shut down, migrated, or suspended.
vicfg-hostops does not work with VMware vSphere Distributed Resource Scheduler (DRS).
You can put all hosts in a cluster or datacenter in maintenance mode by using the --cluster or
--datacenter option.
The --operation info option can be used to check whether the host is in maintenance mode or
in the Entering Maintenance Mode state.
39
vmware-cmd Overview
Slide 2-28
vmware-cmd was included in earlier versions of the ESX Service Console. A vmware-cmd
command has been available in the vCLI package since ESXi version 3.0. vmware-cmd is a legacy
tool and supports the usage of VMware vSphere VMFS (VMFS) paths for virtual machine
configuration files. As a rule, use datastore paths to access virtual machine configuration files.
You can manage virtual machines with the vSphere Client or the vmware-cmd vCLI command.
Using vmware-cmd you can to the following:
Register and unregister virtual machines
Retrieve virtual machine information
Manage snapshots
Turn the virtual machine on and off
Add and remove virtual devices
Prompt for user input.
40
Format for Specifying Virtual Machines with vmware-cmd

Slide 2-29
2
When you run vmware-cmd, the virtual machine path is usually required. You can specify the
virtual machine using one of the following formats:
Datastore prefix style: '[ds_name] relative_path', for example:
'[myStorage1] testvms/VM1/VM1.vmx' (Linux)
"[myStorage1] testvms/VM1/VM1.vmx" (Windows)
UUID-based path: folder/subfolder/file, for example:

'/vmfs/volumes/mystorage/testvms/VM1/VM1.vmx' (Linux)
"/vmfs/volumes/mystorage/testvms/VM1/VM1.vmx" (Windows)
41
Connection Options for vmware-cmd

Slide 2-30
The vmware-cmd vCLI command supports only the following connection options. Other vCLI
connection options are not supported, for example, you cannot use variables because the
corresponding option is not supported. The connection options for vmware-cmd are different from
the connection options that are used for vicfg- commands.
-H <host> Target ESXi or vCenter Server system.
-h <target> When you run vmware-cmd with the -H option pointing to a vCenter Server
system, use -h to specify the ESXi host to run the command against.
-O <port> Alternative connection port. The default port number is 902.
-U <username> User who is authorized to log in to the host that is specified by --server or
--vihost.
-P <password> Password of the user who is specified by <username>. Required if a user is
specified.
--config <connection_config_file> Location of a configuration file that specifies
connection information.
--credstore <cred_store> Name of a credential store file.
--sessionfile <session_file> Name of a session file that was saved earlier using the
vSphere SDK for Perl session/save_session.pl script.
42
Managing Virtual Machines Using vmware-cmd

Slide 2-31
2
43
Listing and Registering Virtual Machines with vmware-cmd

Slide 2-32
Registering or unregistering a virtual machine means adding the virtual machine to the vCenter
Server or ESXi inventory or removing the virtual machine.
If you register a virtual machine with a vCenter Server system, and then remove it from the ESXi
host, an orphaned virtual machine results. Call vmware-cmd -s unregister with the vCenter
Server system as the target to resolve the issue.
To list, unregister, and register virtual machines:
1. Run vmware-cmd -l to list all registered virtual machines on a server.
vmware-cmd -H <vc_server> -U <login_user> -P <login_password>
--vihost <esx_host> -l
2. Run vmware-cmd -s unregister to remove a virtual machine from the inventory. The
system returns 0 to indicate success, 1 to indicate failure.
vmware-cmd -H <vc_server> -U <login_user> -P <login_password> --vihost
<esx_host> -s unregister /vmfs/volumes/Storage2/testvm/testvm.vmx
3. Run vmware-cmd -s register to add a virtual machine to the inventory.
vmware-cmd -H <vc_server> -U <login_user -P <login_password --vihost
<esx_host> -s register /vmfs/volumes/Storage2/testvm/testvm.vmx
44
Retrieving Virtual Machine Attributes with vmware-cmd

Slide 2-33
2
vmware-cmd includes options for retrieving information about a virtual machine. Each option
requires that you specify the virtual machine path. You must also specify connection options, which
differ from other vCLI commands.
You can use vmware-cmd options to retrieve several different virtual machine attributes:
The getuptime option retrieves the uptime of the guest operating system on the virtual
machine, in seconds.
vmware-cmd -H <vc_system> -U <user> -P <password> --vihost <esx_host>
/vmfs/volumes/Storage2/testvm/testvm.vmx getuptime
The getproductinfo product option lists the VMware product that the virtual machine runs
on.
/vmfs/volumes/Storage2/testvm/testvm.vmx getproductinfo product
The getproductinfo platform option lists the platform that the virtual machine runs on.
/vmfs/volumes/Storage2/testvm/testvm.vmx getproductinfo platform
45
The getproductinfo build, getproductinfo majorversion, or getproductinfo

minorversion options retrieve version information.
The getstate option retrieves the execution state of the virtual machine, which can be on, off,
suspended, or unknown.
/vmfs/volumes/Storage2/testvm/testvm.vmx getstate
The gettoolslastactive option indicates whether VMware Tools is installed and

whether the guest operating system is responding normally.
/vmfs/volumes/Storage2/testvm/testvm.vmx gettoolslastactive
46
Managing Virtual Machine Snapshots with vmware-cmd

Slide 2-34
2
A snapshot captures the entire state of the virtual machine at the time you take the snapshot.
Virtual machine state includes the following aspects of the virtual machine.
Memory state. Contents of the virtual machines memory.
Settings state. Virtual machine settings.
Disk state. State of all the virtual machines virtual disks.
When you revert to a snapshot, you return these items to the state they were in at the time that you
took the snapshot. If you want the virtual machine to be running or to be shut down when you start
it, make sure that it is in that state when you take the snapshot. You cannot use vmware-cmd to
revert to a named snapshot. To revert to a named snapshot, use the vSphere Client.
Use the hassnapshot option to check if a virtual machine already has a snapshot, The command
returns 1 if the virtual machine already has a snapshot. Otherwise the command will return a 0.
The removesnapshot option removes all snapshots associated with a virtual machine.
You can use snapshots as restoration points when you install update packages or during a branching
process, such as installing different versions of a program. Taking snapshots ensures that each
installation begins from an identical baseline.
47
Powering Virtual Machines On and Off with vmware-cmd

Slide 2-35
You can start, reboot, stop, and suspend virtual machines by using vmware-cmd. You must supply a
value for the powerop_mode flag, which can be soft or hard. You must have the current version
of VMware Tools installed and running in the guest operating system to use a soft power
operation.
When you specify soft as the powerop_mode value, the result of the call depends on the
operation:
Stop: vmware-cmd attempts to shut down the guest operating system and powers off the virtual
machine.
Reset: vmware-cmd attempts to shut down the guest operating system and reboots the virtual
machine.
Suspend: vmware-cmd attempts to run a script in the guest operating system before suspending
the virtual machine.
When you specify hard power operations, vmware-cmd immediately and unconditionally shuts
down, resets, or suspends the virtual machine.
48
Connecting Devices with vmware-cmd

Slide 2-36
2
You can connect and disconnect virtual devices by using the connectdevice and
disconnectdevice options. The selected guest operating system determines which of the
available devices that you can add to a given virtual machine.
The virtual hardware that you connect is displayed in the hardware list that is displayed in the
Virtual Machine Properties wizard. You can reconfigure virtual machine hardware while the virtual
machine is running, if the following conditions are met:
The virtual machine has a guest operating system that supports hot-plug functionality. See the
Operating System Installation documentation.
The virtual machine is using hardware version 7.
49
The following examples illustrate connecting and disconnecting a virtual device:

The connectdevice option connects the virtual IDE device CD/DVD Drive 2 to the specified
virtual machine.
vmware-cmd -H <vc_system> -U <user> -P <password> --vihost <esx_host> /
vmfs/volumes/Storage2/testvm/testvm.vmx connectdevice "CD/DVD Drive 2"
The disconnectdevice option disconnects the virtual device.

/vmfs/volumes/Storage2/testvm/testvm.vmx disconnectdevice "CD/DVD
Drive 2"
50
Working with the AnswerVM API

Slide 2-37
2
The AnswerVM API allows users to provide input to questions, thereby allowing blocked virtual
machine operations to complete. The vmware-cmd --answer option allows you to access the
input. You might use this option when you want to configure a virtual machine based on a userss
input. For example:
The user clones a virtual machine and provides the default virtual disk type.
When the user powers on the virtual machine, it prompts for the desired virtual disk type.
51
esxcli Command Hierarchies

Slide 2-38
You can manage many aspects of an ESXi host with the ESXCLI command set. You can run
ESXCLI commands as vCLI commands or run them in the ESXi Shell in troubleshooting situations.
possible.
The slide lists the hierarchy of name spaces and commands for each ESXCLI name space.
NOTE
possible.
52
Example esxcli command

Slide 2-39
2
With the esxcli vm command you can display all the virtual machine processes on the ESXi system.
This command lists only running virtual machines on the system.
53
Lab 1
Slide 2-40
54
Review of Learner Objectives

Slide 2-41
2
55
Key Points
Slide 2-42
56
MODULE 3
Performance in a Virtualized
Environment
Slide 3-1
3
Performance in a Virtualized Environment
57
You Are Here

Slide 3-2
58
Importance
Slide 3-3
3
Module 3 Performance in a Virtualized Environment
59
Module Lessons
Slide 3-4
60
Lesson 1: Performance Overview

Slide 3-5
3
61
Learner Objectives
Slide 3-6
62
Virtualization Architectures
Slide 3-7
3
In a hosted architecture, the virtualization layer runs as an application on top of an operating system
and supports the broadest range of hardware configurations. Examples of hosted architecture are
VMware Workstation and VMware Fusion.
In contrast, bare-metal (or hypervisor) architecture installs the virtualization layer directly on a clean
x86-based system. Because a hypervisor has direct access to the hardware resources, rather than
going through an operating system, it is more efficient than a hosted architecture. As a result, a
hypervisor delivers greater performance and scalability.
63
VMware offers two types of virtualization architectures: hosted and bare-metal.
VMware ESXi Architecture

Slide 3-8
VMware vSphere ESXi is a platform for running many virtual machines on a single physical
machine. The VMkernel does not run virtual machines directly. Instead, it runs a virtual machine
monitor (VMM) that in turn is responsible for execution of the virtual machine.
The VMM is a thin layer that provides virtual x86 hardware to the overlying operating system. It is
through the VMM that the virtual machine leverages key technologies in the VMkernel, such as
memory management, scheduling, and the network and storage stacks. Each VMM is devoted to one
virtual machine. To run multiple virtual machines, the VMkernel starts multiple VMM instances.
The VMM handles CPU and memory virtualization as well as some aspects of device virtualization.
The VMkernel storage and network stacks manage I/O requests to host devices through their device
drivers.
The VMkernel resource management component partitions the physical resources by using a
proportional share scheduler to allocate CPU and memory, network traffic shaping to allocate
network bandwidth, and a mechanism to allocate disk I/O bandwidth.
64
Virtualization Performance: First Dimension

Slide 3-9
3
A physical environment has a one-to-one correspondence between the guest operating system and
the physical hardware. The guest operating system and its applications run directly on the hardware
of the physical machine.
However, in a virtualized environment, the guest operating system and its applications do not run
directly on the physical hardware. Instead, they run in a virtual machine. Sitting between the virtual
machine and the physical machine is the hypervisor, which is where the VMM resides.
When running a single virtual machine on a physical machine, VMM overhead is the main factor
that affects performance.
65
A virtualized environment has various factors that affect performance. These factors depend on the
dimension of virtualization. The first dimension of virtualization is running a single virtual machine
on a physical machine.
Virtualization Performance: Second Dimension

Slide 3-10
Because server consolidation is a main goal of virtualization, your environment will most likely be
at the second dimension of virtualization: running multiple virtual machines on a physical machine.
At this level, virtual machines must share the resources. The hypervisor schedules virtual machines
to run and it coordinates access to memory, networks, and storage.
If the performance of your virtual machine is degraded, several factors can affect the performance at
this dimension: scheduling overhead, insufficient network bandwidth, or slow or overloaded storage.
66
Virtualization Performance: Third Dimension

Slide 3-11
3
However, a cost is associated with running virtual machines in a DRS cluster. One cost, for
example, is the amount of VMware vSphere vMotion migration that the DRS cluster performs to
balance virtual machines across hosts.
67
The third dimension of virtualization is running multiple virtual machines in a VMware vSphere
Distributed Resource Scheduler (DRS) cluster. With a DRS cluster, you can pool the CPU and
memory resources of multiple hosts, so a virtual machine is no longer tied to a single host.
Performance Factors in a vSphere Environment

Slide 3-12
ESXi and virtual machine performance tuning is complicated because virtual machines share
underlying physical resources: CPU, memory, storage, and networks.
If you overcommit any of these resources, you might see performance bottlenecks. For example, if
too many virtual machines are CPU-intensive, you might see slow performance because all of the
virtual machines must share the underlying physical CPU.
In addition, performance can suffer due to inherent imbalances in the system. For example, disks are
much slower than CPU, so if you have a disk-intensive application, you might see slower-thanexpected performance. This possible effect applies to both physical and virtual environments.
Expectations must be set appropriately.
Finally, configuration issues or inadvertent user errors might lead to poor performance. For example,
you might configure LUNs improperly so that two virtual machines are accessing different LUNs
that span the same set of underlying disk drives. In this case, you might see worse disk performance
than expected because of contention for the disks or because of abnormal access patterns. Or a user
might use a symmetric multiprocessing (SMP) virtual machine when a single-processor virtual
machine would work well. You might also see a situation where a user sets shares but then forgets
about resetting them. Doing so might result in poor performance because of the changing
characteristics of other virtual machines in the system.
68
Traditional Best Practices for Performance

Slide 3-13
3
To get the best performance out of your VMware vSphere environment, you should follow these
traditional best practices:
Understand your applications profile and workload characteristics. Ultimately, it is the
application that benefits from your performance-tuning efforts.
Optimally configure your virtual machine. Configure your virtual machine to provide the best
possible environment for your application to run.
If possible, use newer hardware to improve virtualization performance. Newer hardware
platforms have the latest features for improving system performance.
Monitor your workloads closely and periodically to discover new bottlenecks in your dynamic
vSphere environment. vSphere monitoring tools enable you to do this monitoring.
69
What Is a Performance Problem?

Slide 3-14
Ideally, a performance problem should be defined in the context of an ongoing performance

management process. Performance management refers to the process of establishing performance
requirements for applications, in the form of service-level agreements (SLAs). Performance
management then also tracks and analyzes the achieved performance to ensure that those
requirements are met. A complete performance management methodology includes collecting and
maintaining baseline performance data for applications, systems, and subsystems, for example,
storage and network.
In the context of performance management, a performance problem exists when an application fails
to meet its predetermined SLA. Depending on the specific SLA, the failure might be in the form of
excessively long response times or throughput below some defined threshold.
If no SLAs exist, then the perceived performance problem can be quantified by comparing current
performance metrics to baseline performance data. If you decide that the difference is severe
enough, troubleshoot to bring performance back within a predetermined range of baseline.
In environments where no SLAs have been established and where no baselines have been
maintained, user complaints about slow response time or poor throughput might lead to the
declaration that a performance problem exists. In this situation, you must define a clear statement of
the problem and set performance targets before undertaking performance troubleshooting.
70
Performance Troubleshooting Methodology

Slide 3-15
3
Having decided on an end goal, the next step in the process is to decide where to start looking for
observable problems. There can be many different places to start an investigation and many different
ways to proceed. The goal of the performance troubleshooting methodology presented in this course
is to select, at each step, the component that is most likely to be responsible for the observed
problems.
If a problem is identified, then it is important to determine the cause of the problem and to
understand possible solutions for resolving the problem.
After a problem has been identified and resolved, the performance of the environment should be
reevaluated in the context of the completion criteria. If the criteria are satisfied, then the
troubleshooting process is complete. Otherwise, the problem checks should be followed again to
identify additional problems. As in all performance tuning and troubleshooting, it is important to fix
only one problem at a time so that the effect of each change can be properly understood.
71
The first step of a performance troubleshooting methodology is to decide on the criteria for
successful completion. SLAs, baseline data, or an understanding of user expectations can be used.
The process of setting SLAs or selecting appropriate performance goals is beyond the scope of this
course, but it is critical to the success of the troubleshooting process. Without defined goals,
performance troubleshooting can turn into endless performance tuning.
Basic Troubleshooting Flow for ESXi Hosts

Slide 3-16
A large percentage of performance problems in a vSphere environment are caused by a few common
causes. As a result, the vSphere troubleshooting methodology is to follow a fixed-order flow
through the most common observable performance problems. For each problem, checks are
specified on specific performance metrics made available by the vSphere performance
monitoring tools.
The graphic represents the basic troubleshooting flow for an ESXi host. The problem checks in this
flow cover the most common or serious problems that cause performance issues on ESXi hosts. The
three categories of observable problems are the following:
Definite problems These are conditions that have a direct effect on observed performance, and
should be corrected.
Likely problems These are conditions that in most cases lead to performance problems, but
that in some circumstances might not require correction.
Possible problems These are conditions that might be indicators of the causes of performance
problems, but might also reflect normal operating conditions.
72

Slide 3-17
3
73
Lesson 2: Virtual Machine Monitor

Slide 3-18
74
Learner Objectives
Slide 3-19
3
75
What Is the Virtual Machine Monitor?

Slide 3-20
The VMM is a thin layer that provides virtual x86 hardware to the guest operating system in a
virtual machine. This hardware includes a virtual CPU, virtual I/O devices, and timers. The VMM
leverages key technologies in the VMkernel, such as scheduling, memory management, and the
network and storage stacks.
Each VMM is devoted to one virtual machine. To run multiple virtual machines, the VMkernel starts
multiple VMM instances. Each VMM instance partitions and shares the CPU, memory, and I/O
devices to successfully virtualize the system. The VMM can be implemented using hardware
virtualization, software virtualization, or paravirtualization techniques.
76
What Is Monitor Mode?

Slide 3-21
3
The combination of techniques used to virtualize the instruction set and memory determines a
monitor execution mode (also called a monitor mode). The VMM identifies the ESXi host hardware
platform and its available CPU features, then chooses a monitor mode for a particular guest
operating system on that hardware platform. The VMM might choose a monitor mode that uses
hardware virtualization techniques, software virtualization techniques, or a combination of hardware
and software techniques.
77
The virtual CPU consists of the virtual instruction set and the virtual memory management unit
(MMU). An instruction set is a list of instructions that a CPU executes. The MMU is the hardware
that maintains a mapping between virtual addresses and physical addresses in memory.
Challenges of x86 Hardware Virtualization

Slide 3-22
x86 operating systems are designed to run directly on the bare-metal hardware, so they assume that
they fully control the computer hardware. The x86 architecture offers four levels of privilege to
operating systems and applications to manage access to the computer hardware: ring 0, ring 1, ring
2, and ring 3. Though user-level applications typically run in ring 3, the operating system needs to
have direct access to the memory and hardware and must execute its privileged instructions in
ring 0.
To create and manage the virtual machines that deliver shared resources, virtualizing the x86
architecture requires placing a virtualization layer under the operating system (which expects to be
in the most privileged ring, ring 0). Further complicating the situation, some sensitive instructions
cannot effectively be virtualized because they have different semantics when they are not executed
in ring 0. The difficulty in trapping and translating these sensitive and privileged instruction requests
at runtime was the challenge that originally made x86 architecture virtualization look impossible.
VMware resolved the challenge in 1998 by developing a software virtualization technique called
binary translation.
78
CPU Software Virtualization: Binary Translation

Slide 3-23
3
VMware can virtualize any x86 operating system by using a combination of binary translation and
direct execution techniques. With binary translation, the VMM dynamically translates all guest
operating system instructions and caches the results for future use. The translator in the VMM does
not perform a mapping from one architecture to another. Instead, it translates from the full
unrestricted x86 instruction set to a subset that is safe to execute. In particular, the binary translator
replaces privileged instructions with sequences of instructions that perform the privileged operations
in the virtual machine rather than on the physical machine. This translation enforces encapsulation
of the virtual machine while preserving the x86 semantics as seen from the perspective of the virtual
machine.
Meanwhile, user-level code is directly executed on the processor for high-performance
virtualization. Each VMM provides each virtual machine with all the services of the physical
system, including a virtual BIOS, virtual devices, and virtualized memory management.
79
Binary translation allows the VMM to run in ring 0 for isolation and performance while moving the
guest operating system to ring 1. Ring 1 is a higher privilege level than ring 3 and a lower privilege
level than ring 0.
CPU Hardware Virtualization

Slide 3-24
In addition to software virtualization, hardware virtualization is supported. Intel has the Intel
Virtualization Technology (Intel VT-x) feature. AMD has the AMD Virtualization (AMD-V)
feature. Intel VT-x and AMD-V are similar in aim but different in detail. Both designs aim to
simplify virtualization techniques. Both designs allow a VMM to do away with binary translation
while still being able to fully control the execution of a virtual machine. This accomplishment is
realized by restricting which kinds of privileged instructions the virtual machine can execute
without intervention by the VMM.
80
Intel VT-x and AMD-V (First Generation)

Slide 3-25
3
The VMM gives the CPU to a virtual machine for direct execution (an action called a VM entry) up
until the point when the virtual machine tries to execute a privileged instruction. At that point, the
virtual machine execution is suspended and the CPU is given back to the VMM (an action called a
VM exit). The VMM then inspects the virtual machine instruction that caused the exit as well as
other information provided by the hardware in response to the exit. With the relevant information
collected, the VMM emulates the virtual machine instruction against the virtual machine state and
then resumes execution of the virtual machine with another VM entry.
81
With the first generation of Intel VT-x and AMD-V, a CPU execution mode feature was introduced
that allows the VMM to run in a root mode below ring 0. Privileged and sensitive calls are set to
automatically trap to the VMM. The guest state is stored in virtual machine control structures
(Intel VT-x) or virtual machine control blocks (AMD-V).
CPU Virtualization Overhead

Slide 3-26
The VMM incurs a CPU cost of correctly virtualizing sensitive instructions. Examples of sensitive
instructions are privileged execution, processor fault handling, I/O port access, and interrupts. The
CPU time spent by the VMM increases host CPU utilization and can also increase latency,
specifically virtual machine exit latency. However, when there are enough CPU resources,
performance is unaffected. In general, the overhead associated with the VMM is minimal and
typically does not affect the overall system performance. In addition, the amount of virtual machine
exit latency has decreased because hardware virtualization support improves with every CPU
generation.
82
Memory Management Concepts

Slide 3-27
3
The MMU translates virtual addresses to physical addresses. The TLB is a cache that the MMU uses
to speed up these translations. If the requested address is present in the TLB, then the physical
address is quickly located and accessed. This activity is called a TLB hit. If the requested address is
not in the TLB (a TLB miss), then the page table is consulted instead.
The page table walker receives the virtual address and traverses the page table tree to produce the
corresponding physical address. When the page table walk is complete, the virtual/physical address
pair is inserted into the TLB to accelerate future access to the same address.
83
Beyond CPU virtualization, the next critical component is memory virtualization. Memory
virtualization involves sharing the physical system memory and dynamically allocating it to virtual
machines. Virtual machine memory virtualization is very similar to the virtual memory support
provided by modern operating systems. Applications see a contiguous address space that is not
necessarily tied to the underlying physical memory in the system. The operating system keeps
mappings of virtual memory addresses to physical memory addresses in a page table. However, all
modern x86 CPUs include an MMU and a translation look-aside buffer (TLB) to optimize virtual
memory performance.
MMU Virtualization
Slide 3-28
To run multiple virtual machines on a single system, another level of memory virtualization is
required. This level is host physical memory (also known as machine memory). The guest operating
system continues to control the mapping of virtual addresses to its physical addresses, but the guest
operating system cannot have direct access to host physical memory. The VMM is responsible for
mapping guest physical memory to host physical memory. To accomplish this, the MMU must be
virtualized.
The software technique for virtualizing the MMU uses shadow page tables. Hardware support for
MMU virtualization is found on both the Intel and the AMD platforms. On the Intel platform, the
feature is called Extended Page Tables (EPT). On the AMD platform, the feature is called Rapid
Virtualization Indexing (RVI).
84
Software MMU: Shadow Page Tables

Slide 3-29
VA > GA Virtual memory addresses to guest physical memory addresses. This mapping is
specified by the guest operating system and is obtained from the primary page table.
GA > HA Guest physical memory addresses to host physical memory addresses. This
mapping is defined by the VMM and VMkernel.
By building shadow page tables that capture this composite mapping, the VMM can point the
hardware MMU directly at the shadow page tables. This direct pointing allows the virtual machines
accessing of memory to run at native speed while being assured that the virtual machine cannot
access host physical memory that does not belong to it.
85
The VMM is responsible for mapping the guest physical memory to host physical memory. To
virtualize the MMU in software, the VMM creates a shadow page table for each primary page table
that the virtual machine is using. The VMM populates the shadow page table with the composition
of two mappings:
Hardware MMU Virtualization

Slide 3-30
Software MMU is where the VMM maps guest physical pages to host physical pages in the shadow
page tables, which are exposed to the hardware. The VMM also synchronizes shadow page tables to
guest page tables (mapping of virtual addresses to guest physical addresses, also known as logicalto-physical mapping).
With hardware MMU, the guest operating system still does the logical-to-physical mapping. The
VMM maintains the mapping of guest physical addresses to host physical addresses (also known as
physical-to-machine mappings) in an additional level of page tables called nested page tables. The
guest page tables and nested page tables are exposed to hardware. When a virtual address is
accessed, the hardware walks the guest page tables, as in the case of native execution. But for every
guest physical page accessed during the guest page table walk, the hardware also walks the nested
page tables to determine the corresponding host physical page.
This translation eliminates the need for the VMM to synchronize shadow page tables with guest
page tables. However, the extra operation also increases the cost of a page walk, thereby affecting
the performance of applications that stress the TLB. This cost can be reduced by using large pages,
thus reducing the stress on the TLB for applications with good spatial locality. For optimal
performance, the ESXi VMM and VMkernel aggressively try to use large pages for their own
memory when hardware MMU is used.
86
Memory Virtualization Overhead

Slide 3-31
When new processes are created, the virtual machine updates a primary page table. The VMM
must trap the update and propagate the change into the corresponding shadow page table or
tables. This slows down memory mapping operations and the creation of new processes in
virtual machines.
When the virtual machine switches context from one process to another, the VMM must
intervene to switch the physical MMU to the shadow page table root of the new process.
When running a large number of processes, shadow page tables need to be maintained.
When allocating pages, and the virtual machine touches memory for the first time, the shadow
page table entry mapping this memory must be created on demand. Doing so slows down the
first access to memory. (The native equivalent is a TLB miss.)
For most workloads, hardware MMU virtualization provides an overall performance win over
shadow page tables, but there are exceptions to this rule: workloads that suffer frequent TLB misses
or that perform few context switches or page table updates.
87
With MMU software virtualization, shadow page tables are used to accelerate memory access and
thereby improve memory performance. However, shadow page tables consume additional memory
and incur CPU overhead in certain situations:
Choosing the Default Monitor Mode

Slide 3-32
The monitor mode has three valid combinations:

BT Binary translation and shadow page tables
HV AMD-V or Intel VT-x and shadow page tables
HWMMU AMD-V with RVI, or Intel VT-x with EPT (RVI is inseparable from AMD-V, and
EPT is inseparable from Intel VT-x)
BT, HV, and HWMMU are abbreviations used by the ESXi host to identify each combination.
When a virtual machine is powering on, the VMM inspects the physical CPUs features and the
guest operating system type to determine the set of possible execution modes. The VMM first finds
the set of modes allowed. Then it restricts the allowed modes by configuration file settings. Finally,
among the remaining candidates, it chooses the preferred mode.
88
Overriding the Default Monitor Mode

Slide 3-33
3
The chosen settings are honored by the VMM only if the settings are supported on the intended
hardware. For example, if you select Use software for instruction set and MMU virtualization for
a 64-bit guest operating system running on a 64-bit Intel processor, the VMM will choose Intel VT-x
for CPU virtualization instead of BT. This choice is made because BT is not supported for 64-bit
guest operating systems on this processor.
89
For the majority of workloads, the default monitor mode chosen by the VMM works best. The
default monitor mode for each guest operating system on each CPU has been carefully selected after
a performance evaluation of available choices. However, some applications have special
characteristics that can result in better performance when using a nondefault monitor mode. These
should be treated as exceptions, not the rule.
Application Examples
Slide 3-34
The table shows a sample list of applications and which memory management virtualization
technique (hardware or software) provides better performance for them. The applications are
characterized as memory-intensive or non-memory-intensive and whether or not they are sensitive
to TLB misses. To review, a TLB miss occurs when a memory address requested by the application
is not present in the TLB cache and the page table must be consulted instead.
90
Displaying the Default Monitor Mode

Slide 3-35
Allowed modes The monitor modes that can be set for the virtual machine, based on the
hosts hardware:
BT Software instruction set and software MMU
HV Hardware instruction set and software MMU
HWMMU Hardware instruction set and hardware MMU
User requested modes The monitor modes selected by the user (for example, using the
VMware vSphere Client interface).
GuestOS preferred modes The monitor modes supported by the guest operating system.
91
You can detect the monitor setting by looking at the virtual machines log file, vmware.log. If the
virtual machine is on an ESXi host, log in to the local or remote console of the host and use the
grep command to search for the keyword MONITOR in the virtual machines log file. The
search finds any line in the output that contains the word MONITOR. The -i option tells grep to
ignore case.
Filtered list The list of monitor modes that will work for this virtual machine. The first item in
the list is the monitor mode that is currently set for the virtual machine.
If the virtual machine is running on an ESXi host, you can download vmware.log to your desktop
by using, for example, the datastore browser in the vSphere Client. Use an editor to look at the log
file and search for the keyword MONITOR.
92

Slide 3-36
3
93
Lesson 3: Monitoring Tools

Slide 3-37
94
Learner Objectives
Slide 3-38
3
95
Commonly Used Performance Monitoring Tools

Slide 3-39
Several monitoring tools are available for you to use in a vSphere environment:
VMware performance charts You display performance charts in a vSphere Client connected
either to the ESXi host directly or to a VMware vCenter Server system or using the
VMware vSphere Web Client. Performance charts provide a lot of useful information, even if
they do not provide all the performance counters that you need to analyze performance. The
two types of charts are overview and advanced.
resxtop The resxtop commands are an excellent means of collecting every performance
statistic needed and making them available in a way that is useful to analysis.
Guest-based performance monitoring is an inaccurate means of evaluating performance in virtual
deployments. Because VMware products provide a virtual interface to the hardware, traditional
performance tools based on measuring hardware resources might not be accurate. As a result, tools
like Windows Perfmon or the Linux top command do not provide accurate measurements of CPU
use. Performance analysis on virtual deployments should always use host-based tools, for example,
vCenter Server performance charts or resxtop.
96
Overview Performance Charts

Slide 3-40
3
The two types of VMware performance charts are overview charts and advanced charts. The
overview performance charts show the performance statistics that VMware considers most useful
for monitoring performance and diagnosing problems.
Depending on the object that you select in the inventory, the performance charts in the Overview
panel provide a quick view of how your host or virtual machine is doing. The example in the
slide shows a partial view of the overview performance charts for an ESXi host. In the Overview
panel, you can view a total of ten different performance charts for a host, four of which are shown
in the slide.
97
Advanced Performance Charts

Slide 3-41
The advanced performance charts provide a graphical display of statistical data for an ESXi host or
objects in vCenter Server. You can examine data about clusters, datacenters, datastores, hosts,
resource pools, virtual machines, and VMware vSphere vApp(s). To easily compare different
metrics, you can view charts for an object side by side, for example, CPU usage and memory usage.
Such comparisons enable you to troubleshoot performance issues, monitor usage trends, do capacity
planning, and determine which resources to increase and decrease on your hosts and virtual
machines.
98
Customize Performance Charts

Slide 3-42
3
To help you sort and display the data in useful formats, the vSphere Client and the vSphere Web
Client allows you to customize the advanced performance charts with the following parameters:
real-time or historical statistics, chart type, objects and counters, statistics type, and rollup.
99
Chart Options: Real-Time and Historical

Slide 3-43
The vSphere Client can show both real-time information and historical information. Real-time
information is information generated for the past hour at a 20-second granularity. Historical
information is information generated for the past day, week, month, or year, at varying granularities.
By default, vCenter Server has four collection intervals: day, week, month, and year. Each interval
specifies a length of time that statistics are archived in the vCenter Server database. You can
configure which intervals are enabled and for what period of time. You can also configure the
number of data counters used during a collection interval by setting the collection level. Together,
the collection interval and the collection level determine how much statistical data is collected and
stored in your vCenter Server database. For example, using the table in the slide, past-day statistics
show one data point every 5 minutes, for a total of 288 samples. Past-year statistics show 1 data
point per day, or 365 samples.
Real-time statistics are not stored in the database. They are stored in a flat file on ESXi hosts and in
memory on vCenter Server systems. ESXi hosts collect real-time statistics for the host or the virtual
machines available on the host. Real-time statistics are collected directly on an ESXi host every 20
seconds. If you query for real-time statistics in the vSphere Client, vCenter Server queries each host
directly for the data. It does not process the data at this point. vCenter Server only passes the data to
the vSphere Client. The processing occurs in a separate operation, depending on the host type.
100
On ESXi hosts, the statistics are kept for 30 minutes, after which 90 data points have been collected.
The data points are aggregated, processed, and returned to vCenter Server. Now, vCenter Server
archives the data in the database as a data point for the day collection interval.
To ensure that performance is not impaired when collecting and writing the data to the database,
cyclical queries are used to collect data counter statistics. The queries occur for a specified
collection interval. At the end of each interval, the data calculation occurs.
3
101
Chart Types
Slide 3-44
The performance charts graphically display CPU, memory, disk, network, and storage metrics for
devices and entities that are managed by vCenter Server. Chart types include line charts, pie charts,
bar charts, and stacked charts.
You view the performance charts for an object that is selected in the inventory. From the vSphere
Client Performance tab, you can view overview charts and advanced charts for an object. Both the
overview charts and the advanced charts use the following chart types to display statistics:
Line charts Display metrics for a single inventory object. The data for each performance
counter is plotted on a separate line in the chart. For example, a network chart for a host can
contain two lines: one showing the number of packets received, and one showing the number of
packets transmitted.
102
Stacked charts Display metrics for children of the selected parent object. For example, a
hosts stacked CPU usage chart displays CPU usage metrics for each virtual machine on the
host. The metrics for the host itself are displayed in separate line charts. Stacked charts are
useful in comparing resource allocation and usage across multiple hosts or virtual machines.
Each metric group is displayed on a separate chart for a managed entity. For example, hosts
have one chart that displays CPU metrics and one that displays memory metrics. It is important
to consider that not all metrics are normalized to 100 percent, so stacked charts might exceed
the y-axis of the chart.
Pie charts Display storage metrics for a single datastore or virtual machine. Storage
information is based on file type or virtual machine. For example, a pie chart for a datastore
displays the amount of storage space occupied by the five largest virtual machines on that
datastore. A pie chart for a virtual machine displays the amount of storage space that is
occupied by virtual machine files.
Bar charts Display storage metrics for datastores in a selected datacenter. Each datastore is
represented as a bar in the chart, and each bar displays metrics based on file type (virtual disks,
snapshots, swap files, and other files).
103
Objects and Counters

Slide 3-45
vCenter Server enables the user to determine how much or how little information about a specific
device type is displayed. You can control the amount of information that a chart displays by
selecting one or more objects and counters.
An object refers to an instance for which a statistic is collected. For example, you might collect
statistics for an individual CPU (for example, vCPU0, vCPU1), all CPUs, a host, or a specific
network device.
A counter represents the actual statistic that you are collecting. For example, the amount of CPU
used or the number of network packets per second for a given device.
104
Statistics Type
Slide 3-46
The measurement is one of the following:

Rate Value over the current statistics interval
Delta Change from previous statistics interval
Absolute Absolute value (independent of the statistics interval)
For example, CPU Usage is a rate, CPU Ready is a delta, and Memory Active is an absolute value.
105
The statistics type refers to the measurement used during the statistics interval and is related to the
unit of measurement.
Rollup
Slide 3-47
When looking at different historical intervals, data is displayed at different granularities. Past-hour
statistics are shown at a 20-second granularity, and past-day statistics are shown at a 5-minute
granularity. The averaging that is done to convert from one time interval to another is called rollup.
The three different rollup types are listed below. The rollup type determines the type of statistical
values returned for the counter:
Average The data collected during the interval is aggregated and averaged.
Minimum The minimum value is rolled up.
Maximum The maximum value is rolled up.
The minimum and maximum values are collected and displayed only in collection level 4. Minimum
and maximum rollup types are used to capture peaks in data during the interval. For real-time data,
the value is the current minimum or current maximum. For historical data, the value is the average
minimum or average maximum.
106
For example, the following information for the CPU usage chart shows that the average is collected
at collection level 1 and the minimum and maximum values are collected at collection level 4.
Counter: usage
Unit: Percentage (%)
Rollup Type: Average (Minimum/Maximum)
Collection Level: 1 (4)
Summation The data collected is summed. The measurement displayed in the performance
chart represents the sum of data collected during the interval.
Latest The data collected during the interval is a set value. The value displayed in the
performance chart represents the current value.
For example, if you look at the CPU Used counter in a CPU performance chart, the rollup type is
summation. So, for a given 5-minute interval, the sum of all of the 20-second samples in that
interval is represented.
To view or modify the statistics level (or collection level), in the vSphere Client menu bar, select
Administration > vCenter Server Settings. Select Statistics in the left pane to view or modify the
statistics parameters, which includes the statistics level.
107
Saving Charts
Slide 3-48
You can save data from the advanced performance charts to a file in various graphics formats or in
Microsoft Excel format. When you save a chart, you select the file type, then save the chart to the
location of your choice.
108
resxtop Utility
Slide 3-49
3
Interactive mode (the default mode) All statistics are displayed as they are collected, showing
how the ESXi host is running in real time.
Batch mode Statistics are collected so that the output can be saved in a file and processed later.
Replay mode Data that was collected by the vm-support command is interpreted and played
back as resxtop statistics. This mode does not process the output of batch mode.
For more details on resxtop, see vSphere Resource Management Guide at
http://www.vmware.com/support/pubs.
109
The resxtop commands enable command-line monitoring and collection of data for all system
resources: CPU, memory, disk, and network. When used interactively, this data can be viewed on
different types of screens, one each for CPU statistics, memory statistics, network statistics, and disk
adapter statistics. This data includes some metrics and views that cannot be accessed using the
overview or advanced performance charts. The three modes of execution for resxtop are the
following:
Using resxtop Interactively

Slide 3-50
To run resxtop interactively, you must first log in to a system with VMware vSphere CommandLine Interface (vCLI) installed. To do this, you must either download and install a vCLI package on
a Linux host or deploy VMware vSphere Management Assistant (vMA) to your ESXi host. vMA
is a preconfigured Linux appliance. Versions of the vCLI package are available for Linux and
Windows systems. However, because resxtop is based on a Linux tool, it is only available in the
Linux version of vCLI.
After vCLI is set up and you have logged in to the vCLI system, start resxtop from the command
prompt. For remote connections, you can connect to an ESXi host either directly or through vCenter
Server.
resxtop has the following connection parameters:
--server [server] --username [username] --password [password] --vihost
[vihost]
[server] A required field that refers to the name of the remote host to connect to. If
connecting directly to the ESXi host, use the name of that host. If your connection to the ESXi
host is indirect (that is, through vCenter Server), use the name of the vCenter Server system for
this option.
110
[vihost] If connecting indirectly (through vCenter Server), this option refers to the name of
the ESXi host that you want to monitor. You must use the name of the ESXi host as shown in
the vCenter Server inventory.
If connecting directly to the ESXi host, this option is not used.
[portnumber] Port number to connect to on the remote server. The default port is 443, and
unless this is changed on the server, this option is not needed.
[username] User name to be authenticated when connecting to the remote host. The remote
server prompts you for a password.
The following command line is another example of running resxtop to monitor the ESXi
host named esxi01.vmeduc.com. However, this time the user logs directly in to the ESXi host as
user root:
# resxtop --server esxi01.vmeduc.com --username root
In both examples, you are prompted to enter the password of the user that you are logging in as, for
example, administrator or root.
111
# resxtop --server vc01.vmeduc.com

--username administrator --vihost esxi01.vmeduc.com
The following command line is an example of running resxtop to monitor the ESXi host named
esxi01.vmeduc.com. Instead of logging in to the ESXi host, the user logs in to the vCenter Server
system named vc01.vmeduc.com as user administrator to access the ESXi host:
Navigating resxtop
Slide 3-51
resxtop supports several single-key commands when run in interactive mode. Type these
characters to change the screen or behavior:

c Switch to the CPU resource utilization screen (this is the default screen).
m Switch to the memory resource utilization screen.
d Switch to the storage (disk) adapter resource utilization screen.
u Switch to the storage (disk) device resource utilization screen.
v Switch to virtual disk resource utilization screen.
n Switch to the network resource utilization screen.
f/F -- Displays a panel for adding or removing statistics columns on the current panel
V Display only virtual machines in the screen.
h Display the help screen.
q Quit interactive mode.
The single-key commands are case-sensitive. Using the wrong case can produce unexpected results.
112
Sample Output from resxtop

Slide 3-52
resxtop displays statistics based on worlds. A world is equivalent to a process in other operating
systems. A world can represent a virtual machine and a VMkernel component. The following
column headings help you understand worlds:
ID World ID. In some contexts, resource pool ID or virtual machine ID.
GID Resource pool ID of the running worlds resource pool or virtual machine.
NAME Name of running world. In some contexts, resource pool name or virtual machine
name.
To filter the output so that only virtual machines are shown, type V (uppercase V) in the resxtop
window. This command hides the system worlds so that you can concentrate on the virtual machine
worlds.
113
Here is an example of the output generated from resxtop. You can view several screens. The CPU
screen is the default. resxtop refreshes the screen every 5 seconds by default.
Using resxtop in Batch and Replay Modes

Slide 3-53
resxtop can also be run in batch mode. In batch mode, the output is stored in a file, and the data
can be read using the Windows Perfmon utility. You must prepare for running resxtop in batch
mode.
To prepare to run resxtop in batch mode
1. Run resxtop in interactive mode.
2. In each screen, select the columns you want.
3. Type W (uppercase) to save this configuration to a file (by default ~/.esxtop4rc).
To run resxtop in batch mode
1. Start resxtop to redirect the output to a file, as shown in the slide. The filename must have a
.csv extension. The utility does not enforce this, but the postprocessing tools require it.
2. Use tools like Microsoft Excel and Perfmon to process the statistics collected.
In batch mode, resxtop rejects interactive commands. In batch mode, the utility runs until it
produces the number of iterations requested (by using the -n option) or until you end the process by
pressing Ctrl+C.
114
To run resxtop in replay mode:

1. Use the vm-support command to capture sampled performance data in a file. For example, the
command vm-support -S -d 300 -l 30 runs vmsupport in snapshot mode. The -S
restricts the collection of diagnostic data, the -d 300 collects data for 300 seconds (five
minutes) and the -l 30 sets up a 30 second sampling interval.
2. Replay the file with the resxtop command. For example, resxtop -r <filename> replays
the captured performance data in an resxtop window.

vm-support can be run from a remote command line. For details see:
http://kb.vmware.com/selfservice/microsites/
search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1010705
115
http://kb.vmware.com/selfservice/microsites
search.do?cmd=displayKC&docType=kc&externalId=1967&sliceId=1&docTypeID=DT_KB_1
_1&dialogID=343976180&stateId=1%200%20343980403
Analyzing Batch Mode Output with Perfmon

Slide 3-54
Running resxtop in batch mode with all the counters enabled results in a large CSV file that
cannot easily be parsed. resxtop is constructed so that the batch output file can be readily
consumed by Perfmon. Perfmon can be used for:
Quickly analyzing results.
Generating smaller CSV files of a subset of the data that can be more easily consumed by other
analysis tools, such as Microsoft Excel.
To open and view the batch output CSV file
1. Transfer the .csv file to a Windows system and start Perfmon.
2. Right-click the graph and select Properties.
3. Click the Source tab. Under Data source, select the Log files radio button.
4. Click the Add button. Browse to and select the .csv file created by esxtop. Click OK.
5. Click the Apply button.
Click OK.
116
Guest Operating System-Based Performance Tools

Slide 3-55
3
The measurements are unaware of work being performed by the virtualization software. Guest
operating systems do not have complete information on the resources that are being used by the
virtualization software. This includes memory management, scheduling, and other support
processes.
The way in which guest operating systems keep time is different and ineffective in a virtual
machine
The measurements visibility into available CPU resources is based on the fraction of the CPU
that they have been provided by the virtualization software.
Often, counters that measure an applications performance are available only through tools running
in the guest operating system. For example, monitoring Microsoft server applications, such as SQL
Server or Exchange Server, requires using guest-based tools.
VMware Tools in vSphere includes a Perfmon DLL that provides additional counters that give the
guest visibility into host CPU and memory usage. The original Perfmon counters are inaccurate in a
guest because the counters are unaware of work that is being performed by the virtualization software.
117
Because VMware products provide a virtual interface to the hardware, traditional performance
instrumentation that is based on measuring hardware resources might not be accurate. The problems
seen as a result of usage of traditional in-guest performance measurements come from three areas:
Perfmon DLL in VMware Tools

Slide 3-56
VMware Tools includes a Perfmon DLL that lets you monitor key host statistics from inside a
virtual machine running a Windows operating system.
Perfmon is an SNMP-based performance monitoring tool for Windows operating systems. Perfmon
measures performance statistics on a regular interval and saves the statistics in a file. Administrators
choose the time interval, the file format, and which statistics are monitored. The ability to choose
which statistics to monitor is based on the available counters.
Installing VMware Tools provides the Perfmon performance counters VM Processor and VM
Memory. Using these counters in Perfmon enables you to view actual use so that you can compare it
with the statistics viewed from the vSphere Client. Third-party developers can provide instruments
for their agents to access these counters using Windows Management Instrumentation.
Because the Perfmon DLL features enable a user in a guest operating system to view sensitive ESXi
host metrics, the feature is disabled by default. To enable it, change the
tools.guestlib.enableHostInfo parameter to TRUE in the .vmx file of the virtual machine.
118
Choosing the Right Tool (1)

Slide 3-57
For information on using the vSphere Client and vSphere Web Client, see vSphere Installation and
Setup Guide at http://www.vmware.com/support/pubs/vsphere-esxi-vcenter-server-pubs.html. The
advantages of the vSphere Client and vSphere Web Client are that they are easy to use, provide
access to the most important configuration and performance information, and do not require high
levels of privilege to access the performance data.
119
Checking for observable performance problems requires looking at values of specific performance
metrics, such as CPU use or disk response time. vSphere provides three main tools for observing
and collecting performance data. The vSphere Client, when connected directly to an ESXi host, can
display real-time performance data about the host and virtual machines. When connected to a
vCenter Server system, the vSphere Client and vSphere Web Client can also display historical
performance data about all of the hosts and virtual machines managed by that server. For more
detailed performance monitoring, resxtop can be used to observe and collect additional
performance statistics.
The resxtop utility provides access to detailed performance data from a single ESXi host. In
addition to the performance metrics available through the vSphere Client, it provides access to
advanced performance metrics that are not available elsewhere. The advantages of resxtop are
the amount of available data and the speed with which the command makes it possible to observe a
large number of performance metrics. The disadvantage of resxtop is that it requires root-level
access privileges to the ESXi host. For documentation on accessing and using resxtop, see
vSphere Resource Management Guide at http://www.vmware.com/support/pubs/vsphere-esxivcenter-server-pubs.html.
120
Choosing the Right Tool (2)

Slide 3-58
121
When troubleshooting performance problems in a vSphere environment, you should use the
performance monitoring tools provided by vSphere rather than tools provided by the guest operating
system. The vSphere tools are more accurate than tools running in a guest operating system. Though
guest operating system monitoring tools are more accurate in vSphere than in previous releases of
ESXi, situations, such as when CPU resources are overcommitted, can still lead to inaccuracies in
in-guest reporting. The accuracy of in-guest tools also depends on the guest operating system and
kernel version being used. Thus, you should use the tools provided by vSphere when actively
investigating performance issues.
Lab 2
Slide 3-59
122

Slide 3-60
3
123
Key Points
Slide 3-61
124
MODULE 4
Network Scalability
Slide 4-1
4
Network Scalability
125
You Are Here

Slide 4-2
126
Importance
Slide 4-3
4
Network Scalability
Module 4 Network Scalability
127
Module Lessons
Slide 4-4
128
Lesson 1: Introduction to vSphere Distributed Switch

Slide 4-5
4
Network Scalability
129
Learner Objectives
Slide 4-6
130
Distributed Switch
Slide 4-7
Still, some configuration is specific to the host. A hosts uplinks are allocated to the distributed
switch and are managed in the hosts network configuration. Similarly, the VMkernel ports are
managed in the hosts network configuration as well.
A distributed switch supports Gigabit Ethernet and 10 Gigabit Ethernet physical network interface
cards (NICs).
131
Network Scalability
A VMware vSphere distributed switch (VDS) provides similar functionality to a vSphere standard
switch. Virtual machines connect to port groups. Virtual machine and VMkernel interfaces can be
connected to port groups. But you configure a distributed switch in VMware vCenter Server
instead of on an individual host.
Benefits of Distributed Switches

Slide 4-8
Having the network configuration at the datacenter level (distributed switches), not at the host level
(standard switches), offers several advantages:
Datacenter setup and administration are simplified by centralizing network configuration. For
example, adding a host to a cluster and making it compatible with VMware vSphere
vMotion is much easier.
Distributed switches support private VLANs. With private VLANs, you can use VLAN IDs in a
private network without having to worry about duplicating VLAN IDs across a wider network.
Distributed ports migrate with their clients. For example, when you migrate a virtual machine
with vMotion, the distributed port statistics and policies move with the virtual machine, thus
simplifying debugging and troubleshooting.
Enterprise networking vendors can provide proprietary networking interfaces to monitor,
control, and manage virtual networks. VMware vSphere Network Appliance API enables
third-party developers to create distributed switch solutions.
132
Distributed Switch Example

Slide 4-9
133
Network Scalability
On the slide, a distributed switch named vDS01 is created. A port group named Production is
defined on this switch. vmnic1 on host ESXi01 is assigned to the distributed switch as is vmnic1 on
ESXi02. When the distributed switch is created, an uplink port group is also created to include the
uplinks of the hosts.
Viewing Distributed Switches

Slide 4-10
To view a distributed switch:
Go to the Networking inventory view.

On the slide, the distributed switch vDS-01 is displayed. The Production port group is shown, as are
the two virtual machines connected to it: VM12 and VM11. The uplink port group vDS-01DVUplinks-47 is also shown. 47 is an identifier that is chosen by vCenter Server.
134
Managing Virtual Adapters

Slide 4-11
4
The Manage Virtual Adapters dialog box provides the means to add, edit, and remove the VMkernel
virtual adapters that are used by the selected host.
To add a virtual adapter:
1. Select a host in the Hosts and Clusters inventory view and click the Configuration tab.
2. In the Hardware list, select Networking and click Manage Virtual Adapters.
3. In the Manage Virtual Adapters dialog box, select Add to create a virtual adapter.
You also have the option to migrate virtual adapters to a different virtual switch.
135
Network Scalability
Virtual network adapters handle host network services over a distributed switch. You can configure
VMkernel network adapters and VMkernel ports for a VMware vSphere ESXi host. For
example, you might want to create a VMkernel network adapter for use as a vMotion interface, for
accessing IP storage, or for VMware vSphere Fault Tolerance logging.
Managing Physical Adapters

Slide 4-12
The association of physical adapters to distributed switch uplink groups must be done at the host
level, not the distributed switch level.
In the distributed switch view, click the Manage Physical Adapters link to add or remove physical
adapters from the uplink port group.
You can also team NICs in your distributed switch. The slide shows a NIC team on the host named
esxi02.vclass.local.
136
Enabling IPv6 on the ESXi Host

Slide 4-13
IPv6 support in ESXi provides the ability to use features such as NFS in an IPv6 environment. Use
the Networking Properties dialog box to enable or disable IPv6 support on the host.
To enable IPv6:
1. Click the Networking link in the Configuration tab of your ESXi host.
2. Click either vSphere Standard Switch or vSphere Distributed Switch. (Either view allows
you to set IPv6 for the entire system.)

3. Click the Properties link in the upper right corner. The Networking Properties dialog box is
displayed.
4. Select the Enable IPv6 support on this host system check box and click OK. The changes do
not take effect until the system is restarted.

137
Network Scalability
Internet Protocol version 6 (IPv6) is designated by the Internet Engineering Task Force as the
successor to IPv4. The most obvious difference is address length. IPv6 uses 128-bit addresses rather
than the 32-bit addresses used by IPv4. This increase resolves the problem of address exhaustion
and eliminates the need for network address translation. Other differences include link-local
addresses that appear as the interface is initialized, addresses that are set by router advertisements,
and the ability to have multiple IPv6 addresses on an interface.
Connecting a Virtual Machine to a Distributed Port Group

Slide 4-14
Connect virtual machines to distributed switches by connecting their associated virtual network
adapters to distributed port groups. You can make this connection for an individual virtual machine
by modifying the virtual machines network adapter configuration. You can also make this
connection for a group of virtual machines by migrating virtual machines from an existing virtual
network to a distributed switch.
To migrate virtual machines to a distributed switch:
1. In the Networking inventory view, right-click the datacenter and select Migrate Virtual
Machine Networking. The Migrate Virtual Machine Networking wizard starts.

2. Select a source network to migrate adapters from. Select a destination network to migrate
adapters to. Click Next.

3. Select the virtual machines and adapters to migrate to the destination network. Click Next.
4. Verify that the source network, destination network, and number of virtual machines to migrate
are correct. Click OK.
138
Distributed Switch Architecture

Slide 4-15
4
Network Scalability
The distributed switch components move network management to the datacenter level.
A distributed switch is a managed entity configured in vCenter Server. It abstracts a set of
distributed switches that are configured on each associated host. vCenter Server owns the
configuration of distributed switches, and the configuration is consistent across all hosts. Consider a
distributed switch as a template for the network configuration on each ESXi host.
Each distributed switch includes distributed ports. A distributed port represents a port to which you
can connect any networking entity, such as a virtual machine or a VMkernel interface.
vCenter Server stores the state of distributed ports in the vCenter Server database. So networking
statistics and policies migrate with virtual machines when the virtual machines are moved from host
to host.
A distributed port group provides a way to logically group distributed ports to simplify
configuration. A distributed port group specifies port configuration options for each member port on
a distributed switch. Distributed port groups define how a connection is made through a distributed
switch to a network. Ports can also exist without port groups.
139
An uplink is an abstraction to associate the vmnics from multiple hosts to a single distributed
switch. An uplink is to a distributed switch what a vmnic is to a standard switch. Two virtual
machines on different hosts can communicate with each other only if both virtual machines have
uplinks in the same broadcast domain.
The distributed switch architecture consists of two planes: the control plane and the I/O plane.
The control plane resides in vCenter Server. The control plane is responsible for configuring
distributed switches, distributed port groups, distributed ports, uplinks, NIC teaming, and so on. The
control plane also coordinates the migration of the ports and is responsible for the switch
configuration. For example, in the case of a conflict in the assignment of a distributed port, the
control plane is responsible for deciding what to do.
The I/O plane is implemented as a hidden virtual switch in the VMkernel of each ESXi host. The
I/O plane manages the I/O hardware on the host and is responsible for forwarding packets.
140
Editing General Distributed Switch Properties

Slide 4-16
The Settings dialog box has several tabs: Properties, Network Adapters, Private VLAN,
NetFlow, and Port Mirroring. These tabs are available only for distributed switches, not for
individual distributed ports or distributed port groups.
The Network Adapters tab is a read-only form that enables you to verify which physical adapters
are connected to the distributed switch.
The Private VLAN, NetFlow, and Port Mirroring tabs are discussed later in the module.
To display general distributed switch properties:
1. In the Networking inventory view, right-click the distributed switch.
2. Select Edit Settings. The distributed switch Settings dialog box is displayed, as shown on
the slide.
141
Network Scalability
If necessary, you can edit the properties of a distributed switch. Settings on the Properties tab are
grouped into the categories General and Advanced. In the General panel, you can name your uplink
ports. Naming uplinks is a good way to help administrators understand which uplinks to associate
with port groups for the policies settings.
Editing Advanced Distributed Switch Properties

Slide 4-17
Advanced properties on the distributed switch enable you to define the maximum transmission unit
(MTU), the discovery protocol status and operation type, and administrator contact details.
MTU determines the maximum size of frames in this distributed switch. The distributed switch
drops frames bigger than the specified size. If your environment supports jumbo frames, use this
option to enable or disable jumbo frames on the distributed switch.
To enable jumbo frames on a distributed switch:
Set the Maximum MTU field to 9000.

To use jumbo frames, the network must support it end to end. That is, jumbo frame support must be
enabled on the physical switch, on the distributed switch, and in the guest operating system of the
virtual machine.
To enable jumbo frames in the guest operating system of a virtual machine, first ensure that the
latest version of VMware Tools is installed. Then, for the virtual network adapter, use either the
vmxnet3, vmxnet2, e1000, or e1000e virtual device.
ESXi supports jumbo frames in the guest operating system and on VMkernel ports.
Distributed switches support two types of discovery protocols: Cisco Discovery Protocol (CDP) and
Link Layer Discovery Protocol (LLDP). Discovery protocols are discussed later in this module.
142
Editing Distributed Port Group Properties

Slide 4-18
Load-based teaming maps virtual NICs to physical NICs and remaps the virtual NIC-to-physical
NIC affiliation if the load exceeds specific thresholds on an uplink.
Load-based teaming uses the same initial port assignment as the originating port id load balancing
policy. The first virtual NIC is affiliated to the first physical NIC, the second virtual NIC to the
second physical NIC, and so on. After initial placement, load-based teaming examines both ingress
and egress load of each uplink in the team. Load-based teaming then adjusts the virtual NIC-tophysical NIC mapping if an uplink is congested. The NIC team load balancer flags a congestion
condition if an uplink experiences a mean use of 75% or more over a 30-second period.
143
Network Scalability
Distributed switches have a load balancing policy that is not available on standard switches. The
load balancing policy is called Route based on physical NIC load. Also known as load-based
teaming, this policy considers virtual machine network I/O load into account. This policy tries to
avoid congestion by dynamically reassigning and balancing the virtual switch port to physical NIC
mappings.
Distributed Switch Configuration: .dvsData Folder

Slide 4-19
When a virtual machine is connected to a port on a distributed switch, a folder named .dvsData is
created on the datastore on which the virtual machine resides. The .dvsData folder is only created
if you have a virtual machine that is attached to a distributed switch and that is located on that
datastore. If virtual machines are attached only to standard switches, then the .dvsData folder does
not exist. Also, the datastore that holds only the virtual machines .vmx config file has the
.dvsData folder.
In the .dvsData folder is a subfolder whose name matches the UUID of the distributed switch.
Each distributed switch has a UUID in the format 31 4c 2a 50 cf 99 c3 bf-d0 9a ba 8d ef 6f fe 71"
(as an example). In the UUID folder, you might find one or more files. Each file corresponds to the
port ID that the virtual machine is associated with. This number corresponds to the parameter
ethernet#.dvs.portId, where # is 0, 1, and so on. This parameter is located in the virtual
machines .vmx configuration file. The ESXi host periodically synchronizes the virtual machines
port state into this file. The host does this every five minutes.
144
The .dvsData folder and the subfolder is primarily used for VMware vSphere High Availability.
When a vSphere HA event occurs and the virtual machine is restarted on a different ESXi host, the
destination host reads the distributed port state from the .dvsData subfolder and starts the virtual
machine on that datastore.
As a general rule, do not delete the .dvsData folder. However, if you must delete the folder
(because you are performing VMFS maintenance for instance), ensure that no virtual machines on
the datastore are registered in vCenter Server. After determining that no virtual machines are
registered, then you can safely remove the .dvsData folder and its subfolders.
4
Network Scalability
145
Standard Switch and Distributed Switch Feature Comparison

Slide 4-20
The table provides a summary of the capabilities present in standard and distributed switches.
Distributed switches have more features than standard switches, including:
Inbound traffic shaping
Support for private VLANs
Load-based teaming
Port mirroring
Load-based teaming enables you to balance the load across the team of NICs, based on the current
loads on the physical NICs.
Network vMotion is the ability of distributed ports to migrate with their virtual machine. When you
migrate a virtual machine with vMotion, the distributed port statistics and policies move with the
virtual machine.
146
Lab 3
Slide 4-21
4
Network Scalability
147

Slide 4-22
148
Lesson 2: Distributed Switch Features

Slide 4-23
4
Network Scalability
149
Learner Objectives
Slide 4-24
150
Distributed Switch Port Binding

Slide 4-25
When you connect a virtual machine to a port group configured with static binding, a port is
immediately assigned and reserved for it, guaranteeing connectivity at all times. The port is
disconnected only when the virtual machine is removed from the port group. You can connect a
virtual machine to a static-binding port group only through vCenter Server. Static binding is the
default setting and is recommended for general use.
In a port group configured with dynamic binding, a port is assigned to a virtual machine only when
the virtual machine is powered on and its NIC is in a connected state. The port is disconnected when
the virtual machine is powered off or the virtual machine's NIC is disconnected. Virtual machines
connected to a port group configured with dynamic binding must be powered on and off through
vCenter.
Dynamic binding can be used in environments where you have more virtual machines than available
ports, but you do not plan to have a greater number of virtual machines active than you have
available ports. For example, if you have 300 virtual machines and 100 ports, but you never have
more than 90 virtual machines active at one time, dynamic binding would be appropriate for your
port group.
151
Network Scalability
Three types of port binding are available: static, dynamic, and ephemeral. All three have different
effects on network connections.
In a port group configured with ephemeral binding, a port is created and assigned to a virtual
machine when the virtual machine is powered on and its NIC is in a connected state. The port is
deleted when the virtual machine is powered off or the virtual machine's NIC is disconnected.
Ephemeral port assignments can be made through ESXi as well as vCenter Server, giving you the
flexibility to manage virtual machine connections through the host when vCenter Server is down.
Although only an ephemeral binding allows you to modify virtual machine network connections
when vCenter Server is down, network traffic is unaffected by a vCenter Server failure regardless of
port binding type.
Ephemeral port groups should be used only for recovery purposes when you want to provision ports
directly on an ESXi host, bypassing vCenter Server, not for any other case. The reasons for this
recommendation are the following:
Scalability An ESXi 5.x host can support up to 256 ephemeral port groups. Since ephemeral
port groups are always pushed to hosts, this limit is effectively also the vCenter Server limit.
Performance Every operation, including add-host and virtual machine power operations, is
slower comparatively because ports are created and destroyed in the operation code path.
Virtual machine operations are far more frequent than add-host or switch operations, so
ephemeral ports are more demanding in general.
Non-persistency Port-level permissions and controls are lost across power cycles, so historical
context is not saved.
Link Aggregation Control Protocol (LACP) is now supported in vSphere 5.1. LACP is a standardsbased method to control the bundling of several physical network links together to form a logical
channel for increased bandwidth and redundancy purposes.
152
Port-Binding Examples
Slide 4-26
4
Network Scalability
Each type of port binding (static, dynamic, or ephemeral) has different effects on network
connections.
The first example shows static port binding. Three ports exist on the distributed switch. The first
three virtual machines to connect acquire these ports. These ports are permanently bound to these
virtual machines. The fourth virtual machine cannot connect. However, Auto Expand can be
configured to automatically add ports as needed. Auto Expand is enabled by default when static
binding is selected in vSphere 5.1.
The second example shows dynamic port binding. Three ports exist on the distributed switch. But
four virtual machines are powered on. With dynamic port binding, only three of the virtual machines
can be connected.
The third example shows ephemeral port binding. As many ports as you need are available. The
power state of the virtual machine does not matter. Ports are created as virtual machines are
connected. The number of ports is limited only by the maximum values for vSphere on your
physical hardware.
153
VLAN Policies for Distributed Port Groups

Slide 4-27
The VLAN policy enables virtual networks to join physical VLANs.

The VLAN type provides the following options:
None Do not use VLAN. The distributed switch performs no tagging or untagging, and the
traffic travels untagged between virtual machines and the physical switch. Use this option for
external switch tagging or for cases where you are not using VLANs at all.
VLAN Also known as virtual switch tagging, this option enables you to specify which VLAN
to tag or untag. All traffic from the distributed switch and the physical switch is tagged to the
specified VLAN, and all traffic between the distributed switch and the virtual machines is
untagged. The accepted value is a number between 1 and 4094.
VLAN Trunking This option is used for VLAN trunking and enables you to specify which
VLANs to allow in the trunk. You can enter one or more VLAN trunk values, including a range
of values. All VLAN tagging of packets is performed by the virtual switch before leaving the
host. Host network adapters must be connected to trunk ports on the physical switch. Port
groups that are connected to the virtual switch must have an appropriate VLAN ID specified.
Private VLAN This option enables you to specify which private VLAN to use. Select this
option after you define private VLANs on the PVLAN tab for the distributed switch.
154
What Is a Private VLAN?

Slide 4-28
4
Private VLANs are useful on a DMZ where the server must be available to external connections and
possibly internal connections, but rarely must communicate with the other servers on the DMZ.
The basic concept behind private VLANs is to divide an existing VLAN, called the primary VLAN,
into one or more separate VLANs, called secondary VLANs.
Private VLANs have existed in the networking industry for several years. But now you can create
private VLANs for virtual machines within distributed switches.
155
Network Scalability
A private VLAN enables you to isolate traffic between virtual machines in the same isolated VLAN.
A private VLAN provides additional security between virtual machines on the same subnet without
exhausting VLAN number space.
Types of Secondary Private VLANs

Slide 4-29
Three types of secondary VLANs are available: promiscuous, isolated, and community.
Virtual machines in a promiscuous private VLAN are reachable by and can reach any machine
in the same primary VLAN.
Virtual machines in an isolated private VLAN can communicate with no virtual machines
except those in the promiscuous private VLAN.
Virtual machines in a community private VLAN can communicate with one another and with
the virtual machines in the promiscuous private VLAN, but not with any other virtual machine.
Traffic in both community and isolated private VLANs travels tagged as the associated secondary
private VLAN.
Consider these two observations about how vSphere implements private VLANs:
vSphere does not encapsulate traffic in private VLANs. In other words, no secondary private
VLAN is encapsulated in a primary private VLAN packet.
Traffic between virtual machines on the same private VLAN, but on different hosts, moves
through the physical switch. Thus the physical switch must be private VLANaware and
configured appropriately so that traffic in the secondary private VLANs can reach its
destination.
156
Promiscuous Private VLANs

Slide 4-30
157
Network Scalability
In the example, virtual machines VM 5 and VM 6 are attached to promiscuous PVLAN 5. VM 5 and
VM 6 can communicate with each other and they can communicate with the other virtual machines
(VM 1, VM 2, VM 3, and VM 4).
Isolated Private VLANs

Slide 4-31
In the example, virtual machines VM 1and VM 2 are attached to isolated PVLAN 155. VM 1 and
VM 2 can communicate only with VM 5 and VM 6. They cannot communicate with each other.
They also cannot communicate with VM 3and VM 4 in the community private VLAN. The only
reason that they can communicate with VM 5 and VM 6 is that both of those virtual machines are
connected to a promiscuous PVLAN.
158
Community Private VLANs

Slide 4-32
159
Network Scalability
In the example, virtual machines VM 3 and VM 4 are attached to community PVLAN 17. They can
communicate with each other because they are both in the same community. VM 3 and VM 4 can
also communicate with VM 5 and VM 6 because both of those virtual machines are connected to a
promiscuous PVLAN. They cannot communicate with VM 1 and VM 2 in the isolated PVLAN.
Private VLAN Implementation

Slide 4-33
How are private VLANs implemented in a physical switch?

There is no encapsulation of a private VLAN in a VLAN. Everything is done with one tag per
packet. Each packet has an additional field that identifies a tag.
The packets are tagged according to the switch port configuration, or they arrive already tagged if
the port is a trunk. A VLAN would behave the same way on a physical switch.
The switch internally holds a table that associates some tags to some private VLANs, defining the
behavior or field of existence of each packet.
160
A broadcast packet might enter the switch with a VLAN tag that belongs to an isolated VLAN. The
switch forwards the broadcast packet only to ports associated with the promiscuous VLAN or to
trunks that allow the promiscuous VLAN. The equivalent applies for the other types.
Promiscuous private VLANs have the same VLAN ID for both the primary VLAN and the
secondary VLAN.
Community and isolated private VLANs traffic travel tagged as the associated secondary private
VLAN.
Traffic in private VLANs is not encapsulated. That is, no secondary private VLAN is encapsulated
in a primary private VLAN packet.
Traffic between virtual machines on the same private VLAN but on different ESXi hosts must go
through the physical switch.
4
Network Scalability
161
Private VLANs and Physical Switches

Slide 4-34
The physical switch must be private VLANaware and configured appropriately to enable the
secondary private VLANs to reach their destination.
Some physical switches discover MAC addresses per VLAN. This discovery can be a problem for
private VLANs because each virtual machine appears to the physical switch to be in more than one
VLAN. The physical switch can also be confused by the fact that each MAC address is visible in
more than one VLAN tag.
For these reasons, it is a requirement that each physical switch where ESXi hosts with private
VLANs are connected must be private VLANaware. Being private VLANaware enables the
physical switch to merge the secondaries into one single broadcast domain.
Because of the private VLAN implementation, packets travel tagged with the secondary ID and each
virtual machine can receive and send to different secondary private VLANs (for example,
community and promiscuous).
162
The physical switch must trunk to the ESXi host and not be in a secondary private VLAN.
Private VLANs in the distributed switch work even with physical switches that are not private
VLANaware and are not discovering MAC addresses per VLAN because the MAC address is
associated to the single port.
Most PVLAN problems are caused by physical switches that are configured incorrectly. Compare
the PVLAN maps in the physical switch to the PVLAN configuration in the distributed switch.
All physical network switches have commands that allow the network administrator to examine the
PVLAN and VLAN configuration. If you believe a PVLAN problem is being caused by a physical
switch configuration, look at your physical PVLAN configuration. Double-check the configuration
of the physical switches that the ESXi hosts are running traffic through.
4
Network Scalability
163
Physical Switch PVLAN-Aware

Slide 4-35
In this brief animation, you can see possible problems with PVLANs and physical switches.
A virtual machine in a promiscuous PVLAN attempts to exchange ARP information with a virtual
machine in an isolated PVLAN.
This exchange is completely legal inside the PVLAN logic, so the promiscuous PVLAN sends a
broadcast ARP request that asks whose MAC address corresponds to the IP address of the isolated
virtual machine.
This packet travels through the physical switch under the promiscuous PVLAN ID (5, in this
example).
The packet reaches the destination distributed switch. There the PVLAN logic forwards the
broadcast to the isolated virtual machine, which sits in the secondary (isolated) PVLAN 155.
The virtual machine replies with the ARP reply, and this packet travels back using PVLAN ID 155.
164
Both physical switch ports in the diagram see the same MAC address through different VLAN IDs.
The incoming ARP request had the tag of PVLAN 5. The response packet has the tag PVLAN 155.
If these were VLANs and not related PVLANs, this exchange would not be allowed. This exchange
would confuse the physical switch and it would drop the packet. This exchange would also not be
allowed if these were PVLANs and both of these were isolated PVLANs.
The solution is to manually configure the physical switch. You must enter the PVLAN tables that
are being used on the connected distributed switches into the physical switch. Then the physical
switch will be aware of which PVLANs are being used. It will also be aware that PVLAN 5 is a
promiscuous PVLAN and that PVLAN 155 is an isolated secondary PVLAN that is related to
PVLAN 5. This awareness means that traffic between PVLAN 5 and PVLAN 155 is considered
legal and that the packet will be forwarded.
4
Network Scalability
165
Configuring and Assigning Private VLANs

Slide 4-36
The first step in setting up a private VLAN is to create the private VLAN primary and secondary
associations.
Three types of secondary VLANs are available: promiscuous, isolated, and community.
Virtual machines in a promiscuous private VLAN are reachable by and can reach any machine
in the same primary VLAN.
Virtual machines in an isolated private VLAN can communicate with no virtual machines
except those in the promiscuous private VLAN.
Virtual machines in a community private VLAN can communicate with one another and with
the virtual machines in the promiscuous private VLAN, but not with any other virtual machine.
166
To configure a primary VLAN and secondary VLANs:

1. Right-click the distributed switch in the networking inventory view and select Edit Settings.
2. Select the Private VLAN tab.
3. Under Primary Private VLAN ID, click Enter a Private VLAN ID here and enter the
number of the primary private VLAN.

4. Click anywhere in the dialog box and select the primary private VLAN that you added. The
primary private VLAN that you added is displayed under Secondary Private VLAN ID.
5. For each new secondary private VLAN, click Enter a Private VLAN ID here under
Secondary Private VLAN ID and enter the number of the secondary private VLAN.
6. Click anywhere in the dialog box, select the secondary private VLAN that you added, and select
either Isolated or Community for the port type.
7. Click OK.
To configure the VLAN policy for a distributed port group:

1. Right-click the distributed port group in the networking inventory view and select Edit
Settings.
2. Select Policies.
3. Select the VLAN type to use and click OK.
167
Network Scalability
After the primary and secondary private VLANs are associated for the distributed switch, use the
association to configure the VLAN policy for the distributed port group.
Discovery Protocols
Slide 4-37
Discovery protocols are available in vSphere virtual switches.

CDP was developed by Cisco Systems to broadcast information at network layer 2 about connected
devices. CDP is available for standard switches and distributed switches, both of which must be
connected to Cisco physical switches. CDP has been supported in vSphere since version 4.0.
LLDP is new in vSphere 5.0 and is available for distributed switches only. LLDP supports the
standards-based discovery protocol IEEE 802.1AB.
CDP is specific to Cisco. LLDP is vendor-neutral.
CDP or LLDP is used by network devices for advertising their identity, capabilities, and neighbors
on a network. When CDP or LLDP is enabled for a virtual switch, you can use the VMware
vSphere Client to view properties of the peer physical switch. These properties include the
device ID, the software version, and timeout.
168
Configuring CDP or LLDP

Slide 4-38
After the discovery protocol is enabled, it has three Operation options:

Listen (default) The ESXi host detects and displays information about the associated physical
switch port, but information about the virtual switch is not available to the physical switch
administrator.
Advertise The ESXi host makes information about the virtual switch available to the physical
switch administrator but does not detect and display information about the physical switch.
Both The ESXi host detects and displays information about the associated physical switch
and makes information about the virtual switch available to the physical switch administrator.
169
Network Scalability
The CDP and LLDP discovery protocols enable vCenter Server and the vSphere Client to identify
properties of a physical switch, such as switch name, port number, and port speed/duplex settings.
You can also configure CDP or LLDP so that information about physical adapters and ESXi host
names is passed to the CDP- or LLDP-compatible switches.
To enable a discovery protocol on a distributed switch:

1. Right-click a distributed switch in the Networking inventory view and select Edit Settings.
2. On the Properties tab, select Advanced.
3. Select Enabled from the Status drop-down menu.
4. Select the discovery protocol type from the Type drop-down menu.
5. Select the operation mode from the Operation drop-down menu.
170
Viewing CDP Information

Slide 4-39
171
Network Scalability
For you to view Cisco information from the vSphere Client, the CDP mode for the distributed
switch must be either Listen or Both. The information icon enables you to view the Cisco
information for the distributed switch. Because the CDP advertisements of Cisco equipment
typically occur once a minute, you might notice a delay between enabling CDP and the availability
of CDP data from the vSphere Client.
Viewing LLDP Information

Slide 4-40
When LLDP is enabled for a distributed switch, you can use the vSphere Client to view properties
of the physical switch. Information like the following is displayed:
Chassis ID
Timeout value
System name and description
VLAN ID
Peer device capabilities
LLDP must be enabled on the physical switch. Some physical switches have LLDP enabled
by default.
172
What Is Network I/O Control?

Slide 4-41
4
Network Scalability
Network resource pools determine the priority that different network traffic types are given on a
distributed switch.
Network I/O Control is disabled by default. When Network I/O Control is enabled, distributed
switch traffic is divided into the following system-defined network resource pools:
Fault Tolerance traffic
iSCSI traffic
vMotion traffic
Management traffic
NFS traffic
Virtual machine traffic
vSphere Replication traffic
173
VMware vSphere Replication (VR) is a new alternative for the replication of virtual machines. VR
is introduced in VMware vCenter Site Recovery Manager 5.0. VR is an engine that provides
replication of virtual machine disk files. VR tracks changes to virtual machines and ensures that
blocks that differ in a specified recovery point objective are replicated to a remote site.
You can also create custom, user-defined network resource pools for virtual machine traffic. You
can control the bandwidth that each network resource pool is given by setting the physical adapter
shares and host limit for each network resource pool.
174
Configuring System-Defined Network Resource Pools

Slide 4-42
Network shares and limits work in the same way as CPU, memory, and storage I/O shares and
limits. The physical adapter shares assigned to a network resource pool determine the share of the
total available bandwidth guaranteed to the traffic associated with that network resource pool. The
share of transmit bandwidth available to a network resource pool is determined by the network
resource pools shares and what other network resource pools are actively transmitting.
For example, you set your Fault Tolerance traffic and iSCSI traffic resource pools to 100 shares, and
all other resource pools to 50 shares. The Fault Tolerance traffic and iSCSI traffic resource pools
each receive 22 percent of the available bandwidth. The remaining resource pools each receive
11 percent of the available bandwidth. These reservations apply only when the physical adapter is
saturated.
Network shares and limits apply to a hosts outbound network I/O traffic only.
The iSCSI traffic resource pool shares do not apply to iSCSI traffic on a dependent hardware iSCSI
adapter.
175
Network Scalability
You can control the priority given to the traffic from each of these network resource pools by setting
the physical adapter shares and host limits for each network resource pool.
To enable Network I/O Control:

1. Select Home > Inventory > Networking.
2. Select the distributed switch in the inventory and click the Resource Allocation tab.
3. Click the Properties link and select Enable network I/O control on this vDS.
To enable network resource pool settings:
1. In the Networking inventory view, select the distributed switch.
2. On the Resource Allocation tab, right-click the network resource pool to edit and select Edit
Settings.
3. Modify the physical adapter shares value and host limit for the network resource pool.
4. (Optional) Select the QoS priority tag from the drop-down menu. The QoS priority tag specifies
an IEEE 802.1p tag, enabling quality of service at the media access control level.
5. Click OK.
176
User-Defined Network Resource Pools

Slide 4-43
4
In the example, two new network resource pools have been created: Virtual Machine Normal Traffic
and Virtual Machine Test Traffic. Virtual Machine Normal Traffic has 50 shares. Virtual Machine
Test Traffic has 25 shares. The system network resource pool named Virtual Machine Traffic has
100 shares.
So you might do the following:
Put your highly critical virtual machines in the Virtual Machine Traffic pool.
Put your less critical virtual machines in the Virtual Machine Normal Traffic pool.
Put all other virtual machines in the Virtual Machine Test Traffic pool.
To configure a network resource pool:
1. Click the New Network Resource Pool link to create the network resource pool.
2. Click the Manage Port Groups link to associate one or more port groups with a network
resource pool.
177
Network Scalability
Limits, shares, and a QoS priority tag can be assigned to each network resource pool, whether the
pool is system-defined or user-defined.
Configuring a User-Defined Network Resource Pool

Slide 4-44
To create a network resource pool:

1. Select your distributed switch in the inventory and click the Resource Allocation tab.
2. Click the New Network Resource Pool link. The Network Resource Pool Settings dialog box
is displayed.
3. Enter information about the resource pool by modifying the various fields.
With the QoS priority tag menu, you can select a priority code, from 1 to 7, or no code at all. Each
code is given a network priority and is associated with a network traffic characteristic. The QoS
priority tag gives you a way of identifying which network resource pool has a higher priority than
the others. The priority tag determines the service level that the packet receives when crossing an
802.1p-enabled network. vSphere does nothing with the priority tag. The physical switch prioritizes
packets based on the QoS tag. 802.1p priority tagging is available only with distributed switches, not
standard switches.
After the network resource pool is created, you can assign one or more distributed port groups to a
user-defined network resource pool.
178
To assign multiple port groups to the same network resource pool:

1. In the Resource Allocation tab, click the Manage Port Groups link. The Manage Port Groups
dialog box is displayed.

2. Select a network resource pool to associate with each port group. The Assign multiple button
enables you to assign multiple port groups to the same network resource pool.
4
Network Scalability
179
Network Health Check

Slide 4-45
Network Health Check is a feature that detects certain inconsistencies between the physical and
virtual networks. Key parameters such as VLAN tags, maximum transmission units (MTUs), and
NIC teaming configuration need to be configured consistently on the physical and virtual switches.
An inconsistent configuration can lead to network connectivity issues.
Network Health Check searches for configuration inconsistencies and reports them to the
administrator.
180
Network Health Check - Example

Slide 4-46
4
Network Scalability
In the example above, there are two ESXi hosts using one distributed virtual switch with two
distributed port groups. Two physical switches with their switch port configurations are also
displayed.
When comparing the green virtual port group with the settings on physical switch 2, the VLAN ID
and the MTU settings are identical. The virtual port group is configured with the Port ID teaming
selection, but since the configuration is internal to the virtual switch and requires no configuration
on the physical switch, the virtual and physical settings are consistent and should experience no
connectivity issues.
Next, we compare the orange virtual port group to the settings on physical switch 2. The VLAN IDs
and the MTU settings are different and the orange teaming setting is set to IP hash. For IP hash to
operate properly, Ether channel must be configured on the physical switch.
Network Health Check can detect and report the configuration differences between the port group
and the switch port configuration by using layer two ethernet packets. At one-minute intervals (by
default), request and acknowledge packets are sent back and forth between the virtual interface and
the switch. When packets are dropped, a configuration warning is displayed on the VMware
vSphere Web Client.
181
The requirements for Network Health Check include:

For VLAN and MTU checks, there must be at least two physical uplinks connected to the
distributed virtual switch.
For the teaming policy check, there must be at least two active uplinks in the team and at least
two ESXi hosts connected to the virtual distributed switch.
182
Enabling Health Check

Slide 4-47
4
Network Scalability
Network Health Check can only be enabled using the vSphere Web Client. To set up network
health check:
From the vSphere Web Client, click on your vCenter server, then click on Networking, then
highlight your distributed virtual switch.
Select the Manage tab, then select the Settings button. Highlight Health Check. Select the
Edit button.
You have the option of enabling or disabling either VLAN and MTU, Teaming and Failover,
or both.
183
Health Check Results Screen

Slide 4-48
After health check has run for a few minutes, you can check the status of the heath checks by:
From the vSphere Web Client, click on your vCenter server. Click on Networking and then
Select the Monitor tab, and then click the Health button. The top portion of the window shows
Overall health status, host member health status, and the member servers. Highlight a member
server.
The bottom portion of the window shows the VLAN, MTU, and the Teaming and Failover
tabs. Each tab displays the health check results for that section.
184
What Is NetFlow?
Slide 4-49
Network profiling
Intrusion detection and prevention
Networking forensics
Sarbanes-Oxley compliance
NetFlow version 5 is implemented in distributed switches. Standard switches do not support
NetFlow.
vSphere 5.1 introduces support for Netflow 10.
185
Network Scalability
NetFlow is a protocol that Cisco Systems developed for analyzing network traffic. NetFlow has
become an industry standard specification for collecting types of network data for monitoring and
reporting. The data sources are network devices, such as switches and routers. For ESXi
deployments, NetFlow enables visibility into virtual machine traffic. NetFlow can be used for:
Network Flows
Slide 4-50
Network flows give you full visibility into virtual machine traffic, which can be collected for
historical views and used for multiple purposes. NetFlow captures two types of flows: internal and
external.
Internal flows are generated from intrahost virtual machine traffic, that is, traffic between virtual
machines on the same hosts.
External flows are generated from interhost virtual machine traffic, traffic between virtual machines
located on different hosts, or virtual machines on different distributed switches. External flows are
also generated from physical machinetovirtual machine traffic.
186
A flow is a sequence of packets that share the same seven properties:

Source IP address
Destination IP address
Source port
Destination port
Input interface ID
Output interface ID
Protocol
A flow is unidirectional. Flows are processed and stored as flow records by supported network
devices, such as a distributed switch. The flow records are then sent to a NetFlow collector for
additional analysis.
187
Network Scalability
Although flow processing is an efficient method, NetFlow can put additional strain on the
distributed switch. NetFlow requires additional processing and additional storage on the host for the
flow records to be processed and exported.
Network Flow Analysis

Slide 4-51
NetFlow sends aggregated network flow data to a NetFlow collector. Third-party vendors have
NetFlow collector products.
A NetFlow collector accepts and stores the completed network flow records. NetFlow collectors
vary in functionality by vendor. Some features that a NetFlow collector might provide include:
Analysis software to mine, aggregate, and report on the collected data
A storage system to allow for long-term storage so that you can archive the network flow data
A customized user interface, often Web-based
188
The NetFlow collector reports on various kinds of networking information, including:

The current top network flows consuming the most bandwidth in a particular (virtual) switch
The IP addresses that are behaving irregularly
The number of bytes that a particular virtual machine has sent and received in the past 24 hours
With NetFlow data, you can investigate the causes of excessive use of network bandwidth,
bottlenecks, and unexpected application traffic. The historical records that you stored in long-term
storage can help you diagnose what might have caused these outages or breaches.
NetFlow data comes from NetFlow-enabled network devices, so additional network probes to
collect the flow-based data are not needed. NetFlow collectors and analyzers can provide a detailed
set of network performance data. Given enough storage on the NetFlow collector, flow data can be
archived for a long time, providing a long-term record of network behavior.
4
Network Scalability
189
Configuring NetFlow on a Distributed Switch

Slide 4-52
To configure NetFlow on a distributed switch, specify the following NetFlow settings:

Collector IP address and Port The IP address and port number used to communicate with the
NetFlow collector system. These fields must be set for NetFlow monitoring to be enabled for
the distributed switch or for any port or port group on the distributed switch.
VDS IP address An optional IP address that is used to identify the source of the network flow
to the NetFlow collector. The IP address is not associated with a network port, and it does not
have to be pingable. This IP address is used to fill the source IP field of NetFlow packets. This
IP address enables the NetFlow collector to interact with the distributed switch as a single
switch, rather than seeing a separate, unrelated switch for each associated host. If this IP
address is not configured, the hosts management IP address is used instead.
Active flow export timeout The number of seconds after which active flows (flows where
packets are being sent) are forced to be exported to the NetFlow collector. The default is 300.
The value range is 03600.
190
Idle flow export timeout The number of seconds after which idle flows (flows where no
packets have been seen for x number of seconds) are forced to be exported to the collector. The
default is 15. The value range is 0300.
Sampling rate The value that is used to determine what portion of data that NetFlow collects.
For example, if the sampling rate is 2, the data is collected from every second packet. If the
sampling rate is 5, the data is collected from every fifth packet. Although increasing the
sampling rate reduces the load on the distributed switch, a higher sampling rate also makes the
NetFlow reporting less accurate. If the value is 0, sampling is disabled. The default value is 0.
The value range is 01000.
Process internal flows only Indicates whether to limit analysis to traffic that has both the
source virtual machine and the destination virtual machine on the same host. By default, the
check box is not selected, which means that both internal and external flows are processed. You
might select this check box if you already have NetFlow deployed in your datacenter and you
want to see only the flows that cannot be seen by your existing NetFlow collector.
After configuring NetFlow on the distributed switch, you can enable NetFlow monitoring on a
distributed port group, a specific port, or an uplink.
Network Scalability
191
What Is Port Mirroring?

Slide 4-53
Port mirroring is a technology that duplicates network packets of a switch port (the source) to
another port (the destination). The sources network traffic is monitored at the destination.
Port mirroring is used to assist in troubleshooting. On physical switches, administrators are
accustomed to being able to mirror traffic to special ports to troubleshoot network-related problems.
Port mirroring is commonly used for network appliances that require monitoring of network traffic,
such as an intrusion detection system.
Many network switch vendors implement port mirroring in their products. For example, port
mirroring on a Cisco Systems switch is usually called Switched Port Analyzer (SPAN).
Port mirroring overcomes the vSphere 4.x limitations of enabling promiscuous mode on a distributed
port. If you enable promiscuous mode on a distributed port, this port sees all the network traffic
going through the distributed switch. You cannot select which traffic from a port or port group that a
particular promiscuous port is allowed to see. The promiscuous port can see all the traffic on the
same broadcast domain. Port mirroring overcomes this limitation by enabling the administrator to
control which traffic can be seen by the distributed port that is enabled for port mirroring.
Port mirroring supports Ciscos Remote Switch Port Analyzer (RSPAN) and Encapsulated Remote
Switch Port Analyzer (ERSPAN). With RSPAN, mirrored traffic can be directed to a remote
monitor. The RSPAN session can span multiple switch hops on a network. With ERSPAN, the
session can span across an IP network.
192
Configuring a Port Mirror Session

Slide 4-54
4
Network Scalability
To configure port monitoring using the vSphere Web Client:

1. From the vSphere Web Client home page, click on vCenter, then select Networking and

2. Click on the Manage tab and select the Settings button.
3. Highlight the Port Mirroring option and select New....
193
Port Mirroring Options

Slide 4-55
The Add Port Mirroring Session wizard starts:

1. Select the type of mirroring session required.
2. Edit the properties of the session.
3. Select the source and destination of the session.
194
Source and Destination Selections

Slide 4-56
4
Network Scalability
The following port mirroring sessions are available:

Distributed Port Mirroring: Port mirroring between distributed ports can only be local. If the
source and destination are on different hosts due to vMotion, mirroring between them will not
work. However, if the source and destination move to the same host, port mirroring works.
Remote Mirroring Source: When a source distributed port is moved from host A to host B,
the original mirroring path from the source port to As uplink is removed on A. Also, a new
mirroring path from the source port to Bs uplink is created on B. Which uplink is used is
determined by the uplink name specified in the session.
Remote Mirroring Destination: When a destination distributed port is moved from host A to
host B, all original mirroring paths from source VLANs to the destination port are moved from
A to B.
Encapsulated Remote Mirroring (L3) Source: When a source distributed port is moved from
host A to host B, all original mirroring paths from the source port to the destination IPs are
moved from A to B.
Distributed Port Mirroring (legacy): When a destination distributed port is moved from host
A to host B, all original mirroring paths from the source IPs to the destination port are invalid
because the port mirroring session source still sees the destination on A.
195
Configuration Backup and Restore

Slide 4-57
Configuration backup and restore enables you to back up and restore the configuration settings of a
distributed virtual switch, a distributed virtual port group, or both.
You have other available options if the switch configuration is lost (for example, a vCenter Server
database corruption, or the virtual switch or port group settings is recently misconfigured). A few
ways to restore the virtual switch include restoring the database completely or rebuilding the switch.
While both of these steps will restore they switch, they can be time-consuming.
196
Backup a Distributed Virtual Switch Configuration

Slide 4-58
4
Network Scalability
To back up a distributed virtual switch configuration:

1. From the vSphere Web Client home page, click vCenter and then Networking. Select the
distributed virtual switch to be backed up.

2. Right-click on the virtual switch. Then select All vCenter Actions > Export Configuration.
3. The Export Configuration wizard starts. Decide whether to backup the distributed switch only
or the distributed switch and all port groups. Add a description and click OK.
4. The Confirm Configuration Export window appears. If you want to save the exported file,
click Yes.
5. By Default the settings are saved to a file named Backup. Browse to the lab files folder and
click Save.
197
Restore a Distributed Virtual Switch Configuration

Slide 4-59
To restore a distributed virtual switch configuration:

1. From the vSphere Web Client home page, click vCenter and then Networking. Select the
distributed virtual switch to be restored.

2. Right-click on the virtual switch. Then select All vCenter Actions > Restore Configuration.
3. The Restore Configuration wizard starts. Click the Browse... button to go to the distributed
switch backup file. Select either Restore distributed switch and all port groups or Restore
distributed switch only and click Next. The Ready to Complete window appears.
4. Verify the import settings are correct and click Finish.
198
Restore a Port Group Configuration

Slide 4-60
4
Network Scalability
To restore a distributed virtual port group configuration:

1. From the vSphere Web Client home page, click vCenter and then select Distributed Port
Groups from the Inventory List. Select the distributed virtual port group to be restored.
2. Right-click on the virtual port group. Then select All vCenter Actions > Restore
Configuration.
3. The Restore Configuration wizard starts. You have the option of either restoring from a
previous configuration or restoring the configuration from a file. Select Restore to previous
configuration.
4. The previous configuration appears on the Ready to Complete window. Verify the settings are
correct and click Finish.
199
Rollback and Recovery

Slide 4-61
Automatic rollback and recovery is a new vSphere 5.1 feature that helps prevent management
network outages. Protecting the management network includes the following:
The automatic rollback feature automatically detects any configuration changes on the
management network. If the host cannot reach the vCenter Server, the changes are not permitted
to take effect.
You can also reconfigure the management network on the distributed virtual switch, using the
direct console user interface. (DCUI) You connect to each host using the DCUI to change the
management network parameters of the switch.
200
Rollback Details
Slide 4-62
4
Network Scalability
There are two different types of updates that can trigger a rollback:
If there is a change in the host networking configuration that causes connectivity issues between
the host and the vCenter server, a rollback occurs. Examples of misconfigurations include a
mismatch in the speed and duplexing of the physical NIC, a mismatch in the jumbo frames
configuration, or a misconfiguration in the IP settings of the management network.
Misconfiguration of the distributed virtual switch that causes connectivity issues between the
hosts and the vCenter server can also cause a rollback. Port group and distributed virtual port
misconfigurations can both cause network down time.
201
Automatic Rollback
Slide 4-63
Automatic rollback is enabled by default.

To disable automatic rollback:
1. From the vSphere Web Client, select vCenter.
2. From the Inventory Lists pull-down menu, select vCenter Servers and then select your
vCenter server.
3. Select the Manage tab, and then click on the Advanced Settings field. The vCenter Server
Settings table is displayed. Click Edit.

4. Scroll through the settings until you find config.vpxd.network.rollback. Using the pull-down
menu to the right, select false to disable automatic rollback.
202
Recovery through DCUI

Slide 4-64
4
Network Scalability
To rollback the configuration manually from the DCUI:

1. From the DCUI, press the F2 key. When prompted, log into the DCUI with the appropriate
credentials.
2. Using the down arrow key, scroll to the Network Restore Options entry and click Enter.
3. The Network Restore Options screen appears. To roll back the distributed network settings,
select the Restore vDS option. The Restore vDS screen appears.
4. From the Restore vDS screen, you have the option of either restoring the host settings to the
default blocked setting or restoring the default teaming policy of the host. Select the appropriate
option and click Enter.
203
Lab 4
Slide 4-65
204
Lab 5 (Optional)
Slide 4-66
4
Network Scalability
205

Slide 4-67
206
Key Points
Slide 4-68
4
Network Scalability
207
208
MODULE 5
Network Optimization
Slide 5-1
5
209
You Are Here

Slide 5-2
210
Importance
Slide 5-3
5
Module 5 Network Optimization
211
Module Lessons
Slide 5-4
212
Lesson 1: Networking Virtualization Concepts

Slide 5-5
5
213
Learner Objectives
Slide 5-6
214
Network I/O Virtualization Overhead

Slide 5-7
5
Emulation overhead Certain privileged instructions and some operations to access I/O devices
that are executed by the virtual machine are intercepted by the hypervisor. This activity adds
some overhead and contributes to network I/O latency as well.
Packet processing The network virtualization stack forwards a network packet from the
physical NIC to the virtual machine and the reverse. This activity requires some computation
and processing such as switching decisions at the virtual switch, inserting and stripping the
VLAN tag, and copying packets if necessary. This processing adds some latency on both the
transmit and receive paths.
215
Packets sent or received from a virtual machine experience some amount of overhead compared to a
bare-metal (native) environment. The overhead that is experienced by virtual machines is because
packets must traverse through an extra layer of virtualization stack. This overhead can also increase
network I/O latency. The additional latency due to the virtualization stack can come from several
sources. The most commons ones include the following:
Scheduling Packet transmission and reception involves multiple hypervisor threads and
virtual CPUs. The VMkernel scheduler has to schedule and then execute these threads (if they
are not already running) upon receipt and transmission of a packet. On an idle system, this
activity takes a couple of microseconds. But on a busy system, if high CPU contention exists,
this activity can take tens of microseconds and occasionally milliseconds.
Virtual interrupt coalescing Similar to physical NIC interrupt coalescing, the virtual machine
does virtual interrupt coalescing. That is, a virtual machine might not be interrupted
immediately after receiving or transmitting a packet. Instead, the VMkernel might wait to
receive or transmit more than one packet before an interrupt is posted. Also, on the transmit
path, the virtual machine might wait until a few packets are queued up before sending the
packets down to the hypervisor. Sometimes interrupt coalescing might have a noticeable impact
on average latency.
Halting (and waking up) the physical CPU Modern hardware and operating systems are
power efficient. That is, operating systems put the physical CPU in sleep mode (halt) when the
CPU is idle. Waking up the CPU from halt mode adds some latency. The amount of latency
varies from CPU to CPU. Depending on the load of the system, the CPU might go into deeper
sleep states from which it takes even longer to wake up. This overhead is generally common
between nonvirtualized and virtualized platforms. However, sometimes the side effect of this
can be worse in virtualized environments than in physical environments. For example, a CPU
might flush its cache on entering halt mode. In this case, the halt operation might affect a
virtualized system more than a physical system because the cache footprint is larger in a virtual
environment.
Halting (and waking up) the virtual CPU When the guest operating system issues a halt
instruction, the VMkernel scheduler might de-schedule the vCPU. Rescheduling the virtual
CPU (putting the virtual CPU back in the run queue) can take a couple of microseconds.
Latency introduced due to the virtual or physical CPU halt function is more prominent when the
CPU is lightly loaded, that is, when the CPU halts frequently.
216
vmxnet Network Adapter

Slide 5-8
The driver improves performance through a number of optimizations:

Shares a ring buffer between the virtual machine and the VMkernel, and uses zero-copy, which
in turn saves CPU cycles. Traditional networking uses a series of buffers to process incoming
network data and deliver it efficiently to users. However, higher-speed modern networks are
turning this approach into a performance bottleneck as the amount of data received from the
network often exceeds the size of the kernel buffers. Zero-copy improves performance by
having the virtual machines and the VMkernel share a buffer, reducing the internal copy
operations between buffers to free up CPU cycles.
Takes advantage of transmission packet coalescing to reduce address space switching.
Batches packets and issues a single interrupt, rather than issuing multiple interrupts.
Offloads TCP checksum calculation to the network hardware rather than use the CPU resources
of the virtual machine monitor.
217
vmxnet is the VMware paravirtualized device driver for virtual networking. The vmxnet driver
implements an idealized network interface that passes through network traffic from the virtual
machine to the physical cards with minimal overhead. The three versions of vmxnet are vmxnet,
vmxnet2 (Enhanced vmxnet), and vmxnet3.
Virtual Network Adapters

Slide 5-9
When you configure a virtual machine, you can add NICs and specify the adapter type. The type of
network adapters that are available depend on the following factors:
The version of the virtual machine, which depends on which host created it or most recently
updated it
Whether or not the virtual machine has been updated to the latest version for the current host
The guest operating system
The following virtual NIC types are supported:
vlance This virtual NIC is an emulated version of the AMD 79C970 PCnet32 LANCE NIC.
vlance is an older 10Mbps NIC with drivers available in most 32-bit guest operating systems
(except Windows Vista and later). A virtual machine configured with this network adapter can
use its network immediately. This type cannot be selected directly. It can only be configured
using the Flexible adapter type.
218
vmxnet The virtual NIC has no physical counterpart. vmxnet is optimized for performance in
a virtual machine. Because operating system vendors do not provide built-in drivers for this
card, you must install VMware Tools to have a driver for the vmxnet network adapter
available. This type cannot be selected directly. It can only be configured using the Flexible
adapter type.
Flexible This virtual NIC identifies itself as a vlance adapter when a virtual machine boots,
but initializes itself and functions as either a vlance or a vmxnet adapter. Whether the adapter
used is vlance or vmxnet depends on which driver initializes it. With VMware Tools installed,
the vmxnet driver changes the vlance adapter to the higher-performance vmxnet adapter.
e1000, e1000e This virtual NIC is an emulated version of the Intel 82545EM Gigabit Ethernet
NIC. This driver is available in most newer guest operating systems, including Windows XP
and later and Linux versions 2.4.19 and later.
The e1000e is an emulated version of the Intel 82574L Gigabit Ethernet NIC. This driver is
available for operating systems that use this NIC, such as the Windows 8 64-bit operating
system.
Whether the e1000 driver or the e1000e driver is loaded depends on the physical NIC adapters
that are used.
For more about choosing a network adapter, see VMware knowledge base article 1001805 at
http://kb.vmware.com/kb/1001805.
219
vmxnet3 The vmxnet3 adapter is the next generation of a paravirtualized NIC designed for
performance. It is not related to vmxnet or vmxnet2. The vmxnet3 adapter offers all the features
available in vmxnet2 and adds several features, like multiqueue support (called Receive-Side
Scaling in Windows), IPv6 off-loads, and MSI/MSI-X interrupt delivery. vmxnet3 devices
support fault tolerance and record/replay. This virtual network adapter is supported only for a
limited set of guest operating systems and is available only on virtual machines with hardware
version 7.
Enhanced vmxnet (vmxnet2) The Enhanced vmxnet adapter is based on the vmxnet adapter
but provides some high-performance features, such as jumbo frames and hardware offloads.
This virtual network adapter is supported only for a limited set of guest operating systems.
Network Performance Features

Slide 5-10
VMware vSphere includes support for many of the performance features of modern network
adapters.
The list of network adapter features that are enabled on your NIC can be found in the VMware
vSphere ESXi file named /etc/vmware/esx.conf. Look for the lines that start with
/net/vswitch.
As a general rule, do not change the default NICs driver settings unless you have a valid reason to
do so. A good practice is to follow any configuration recommendations that are specified by the
hardware vendor.
220
TCP Checksum Offload

Slide 5-11
221
Modern NIC adapters have the ability to perform checksum calculations natively. TCP checksums
are used to determine the validity of transmitted or received network packets based on error
correcting code. These calculations are traditionally performed by the hosts CPU. By offloading
these calculations to the network adapters, the CPU is freed up to perform other tasks. As a result,
the system as a whole runs better.
TCP Segmentation Offload

Slide 5-12
TCP Segmentation Offload (TSO) allows a TCP/IP stack to emit large frames (up to 64KB) even
though the maximum transmission unit (MTU) of the interface is smaller.
A TCP message must be broken down into Ethernet frames. The size of each frame is the maximum
transmission unit. The default MTU is 1,500 bytes, defined by the Ethernet specification. The
process of breaking messages into frames is called segmentation.
Historically, the operating system used the CPU to perform segmentation. Modern NICs try to
optimize this TCP segmentation by using a larger segment size as well as offloading work from the
CPU to the NIC hardware. ESXi utilizes this concept to provide a virtual NIC with TSO support,
without requiring specialized network hardware.
With TSO, instead of processing many small MTU-sized frames during transmit, the system can
send fewer, larger virtual MTU-sized frames.
TSO improves performance for TCP network traffic coming from a virtual machine and for network
traffic (such as VMware vSphere vMotion traffic) sent out of the server.
TSO is supported at the virtual machine level and in the VMkernel TCP/IP stack.
222
TSO is enabled on the VMkernel interface by default. If TSO becomes disabled for a particular
VMkernel interface, the only way to enable TSO is to delete that VMkernel interface and re-create it
with TSO enabled.
TSO is used in the guest when the vmxnet2 (or later) network adapter is installed. To enable TSO at
the virtual machine level, you must replace the existing vmxnet or flexible virtual network adapter
with a vmxnet2 (or later) adapter. This replacement might result in a change in the MAC address of
the virtual network adapter.
TSO support through the enhanced vmxnet network adapter is available for virtual machines that
run the following guest operating systems:
Microsoft Windows 2003 Enterprise Edition with Service Pack 2 (32-bit and 64-bit)
Red Hat Enterprise Linux 4 (64-bit)
Red Hat Enterprise Linux 5 (32-bit and 64-bit)
SUSE Linux Enterprise Server 10 (32-bit and 64-bit)
For details on how to enable TSO support for a virtual machine or to check whether TSO is enabled
on a VMkernel interface, see vSphere Networking Guide at https://www.vmware.com/support/pubs/
vsphere-esxi-vcenter-server-pubs.html.
223
Virtual machines that use TSO on an ESXi host show lower CPU utilization than virtual machines
that lack TSO support when performing the same network activities.
When the physical NICs provide TSO functionality, the ESXi host can leverage the specialized NIC
hardware to improve performance. TSO is used in the host when the physical NIC supports it.
However, performance improvements related to TSO need not require NIC hardware support for
TSO.
Jumbo Frames
Slide 5-13
The Ethernet MTU (packet size) is 1,500 bytes. For each packet, the system has to perform a
nontrivial amount of work to package and transmit the packet. As Ethernet speed increased, so did
the amount of work necessary, which resulted in a greater burden on the system.
A jumbo frame has an Ethernet MTU of more than 1,500 bytes. A jumbo frame can have an
Ethernet packet size up to 9,000 bytes. Jumbo frames decrease the number of packets requiring
packaging, compared to previously sized packets. That decrease results in less work for network
transactions, which frees up resources for other activities.
The network must support jumbo frames end-to-end. That is, the physical NICs at both ends and all
the intermediate hops, routers, and switches must support jumbo frames. Jumbo frames must be
enabled at the virtual switch level, at the virtual machine, and at the VMkernel interface. ESXi hosts
using jumbo frames realize a decrease in load due to network processing. Before enabling jumbo
frames, check with your hardware vendor to ensure that your network adapter supports jumbo frames.
For details on how to enable jumbo frames, see vSphere Networking Guide at
https://www.vmware.com/support/pubs/vsphere-esxi-vcenter-server-pubs.html.
224
Using DMA to Access High Memory

Slide 5-14
The ability to support many multiple scatter/gather elements in a DMA operation is standard on
many of the higher-end networking interfaces. Scatter/gather elements allow the transfer of data to
and from multiple memory areas in a single DMA transaction. Scatter/gather functionality is
equivalent to chaining together multiple simple DMA requests. This functionality is managed by a
buffer chain list that is maintained by the adapters device driver.
No vSphere configuration tasks are required to use DMA or scatter or gather functionality.
225
To facilitate the checksum calculations, the physical NIC requires access to physical memory. The
use of direct memory access (DMA) and high memory reduces the amount of conflict between the
physical NIC and the physical CPU. This reduction of conflict improves the performance of both the
NIC and the CPU. Systems that support DMA are able to transfer data to and from the NIC with less
CPU overhead than systems that do not support DMA.
10 Gigabit Ethernet (10GigE)

Slide 5-15
With high consolidation ratios combined with the high-bandwidth requirements of todays
applications, the total I/O load on a server is substantial.
Single Gigabit Ethernet adapters are becoming increasingly unable to support the demands of these
applications in large enterprise environments. And multiple NICs are often impractical because of
the number of ports used on the host and on the network switches. 10 Gigabit Ethernet adapters
offer a solution that provides much higher bandwidth while using fewer ports on the hosts and
switches.
Support for 10 Gigabit Ethernet adapters was introduced in ESXi 3.5. Since then, features such as
TSO, jumbo frames, and multiple receive queues were introduced to efficiently use these adapters.
226
NetQueue
Slide 5-16
5
NetQueue can also use multiple transmit queues to parallelize access that is normally serialized by
the device driver. Multiple transmit queues can also be used to get some sort of guaranteed isolation
from the hardware. A separate, prioritized queue can be used for different types of network traffic.
NetQueue monitors the load of the virtual machines as they are receiving packets and can assign
queues to critical virtual machines. All other virtual machines use the default queue.
NetQueue is enabled by default. Disabling or enabling NetQueue on a host is done by using the
VMware vSphere Command-Line Interface (vCLI). For details on how to disable and enable
NetQueue, see vSphere Networking Guide at https://www.vmware.com/support/pubs/vsphere-esxivcenter-server-pubs.html.
227
VMware supports NetQueue, a performance technology that improves performance in virtualized

environments that use 10GigE adapters. NetQueue takes advantage of the multiple queue capability
that newer physical network adapters have. Multiple queues allow I/O processing to be spread
across multiple CPUs in a multiprocessor system. So, while one packet is queued up on one CPU,
another packet can be queued up on another CPU at the same time.
vSphere DirectPath I/O

Slide 5-17
VMware vSphere DirectPath I/O leverages Intel VT-d and AMD-Vi hardware support to allow
guest operating systems to directly access hardware devices. In the case of networking, vSphere
DirectPath I/O allows the virtual machine to access a physical NIC directly rather than using an
emulated device or a paravirtualized device. An example of an emulated device is the e1000 virtual
NIC, and examples of paravirtualized devices are the vmxnet and vmxnet3 virtual network adapters.
vSphere DirectPath I/O provides limited increases in throughput, but it reduces the CPU cost for
networking-intensive workloads.
228
vSphere DirectPath I/O is not compatible with certain core virtualization features:
When ESXi is running on certain configurations of the Cisco Unified Computing System (UCS)
platform, vSphere DirectPath I/O for networking is compatible with the following:
vSphere vMotion
Hot adding and removing of virtual devices, Suspend and resume
VMware vSphere High Availability
VMware vSphere Distributed Resource Scheduler (DRS)
Snapshots
For server hardware other than the Cisco UCS platform, vSphere DirectPath I/O is not
compatible with hot adding and removing of virtual devices, suspend and resume, VMware
vSphere Fault Tolerance, vSphere HA, DRS, and snapshots. For DRS, limited availability is
provided. The virtual machine can be part of a cluster, but cannot migrate across hosts.
Typical virtual machines and their workloads do not require the use of vSphere DirectPath I/O.
However, for workloads that are networking intensive and do not need the core virtualization
features just mentioned, vSphere DirectPath I/O might be useful to reduce CPU usage.
229
For performance and use cases of vSphere DirectPath I/O for networking, see
http://blogs.vmware.com/performance/2010/12/performance-and-use-cases-of-vmware-directpathio-for-networking.html.
Single Root I/O Virtualization (SR-IOV)

Slide 5-18
Single Root I/O Virtualization (SR-IOV) is a standard that enables one PCI Express (PCIe) adapter
to be presented as multiple separate logical devices to virtual machines. The hypervisor manages the
physical function (PF) while the virtual functions (VFs) are exposed to the virtual machines. In the
hypervisor, SR-IOVcapable network devices offer the benefits of direct I/O, which include reduced
latency and reduced host CPU utilization. The ESXi platforms VMDirectPath passthrough
functionality provides similar benefits to the user, but it requires a physical adapter per virtual
machine. In SR-IOV, this functionality can be provided from a single adapter to multiple virtual
machines through virtual functions.
Users who are concerned about network latency can employ this feature and off-load the processing
onto the hardware of the PCIe adapter. However, they cant make use of vSphere vMotion, vSphere
Fault Tolerance, and vSphere HA features while using this functionality.
230
SplitRx Mode
Slide 5-19
SplitRx mode is an ESXi feature that uses multiple physical CPUs to process network packets
received in a single network queue. This feature provides a scalable and efficient platform for
multicast receivers. SplitRx mode typically improves throughput and CPU efficiency for multicast
traffic workloads.
SplitRx mode is supported only on vmxnet3 network adapters. This feature is disabled by default.
VMware recommends enabling splitRxMode in situations where multiple virtual machines share a
single physical NIC and receive a lot of multicast or broadcast packets.
SplitRx mode is individually configured for each virtual NIC. For information about how to enable
this feature, see Performance Best Practices for VMware vSphere 5.0 at http://www.vmware.com/
pdf/Perf_Best_Practices_vSphere5.0.pdf.
231
Multicast is an efficient way of disseminating information and communicating over the network. A
single sender can connect to multiple receivers and exchange information while conserving network
bandwidth. Financial stock exchanges, multimedia content delivery networks, and commercial
enterprises often use multicast as a communication mechanism. Multiple receivers can be enabled
on a single ESXi host. Because the receivers are on the same host, the physical network does not
have to transfer multiple copies of the same packet. Packet replication is carried out in the
hypervisor instead.

Slide 5-20
232
Lesson 2: Monitoring Networking I/O Activity

Slide 5-21
5
233
Learner Objectives
Slide 5-22
234
Network Capacity Metrics

Slide 5-23
If received packets are being dropped, adjust the virtual machine CPU shares. If packets are not
being dropped, check the size of the network packets and the data received rate and the data
transmitted rate. In general, the larger the network packets, the faster the network speed. When the
packet size is large, fewer packets are transferred, which reduces the amount of CPU required to
process the data. When network packets are small, more packets are transferred, but the network
speed is slower because more CPU is required to process the data. In some instances, large packets
can result in high latency. To rule out this issue, check network latency.
If packets are not being dropped and the data receive rate is slow, the host probably lacks the CPU
resources required to handle the load. Check the number of virtual machines assigned to each
physical NIC. If necessary, perform load balancing by moving virtual machines to different virtual
switches or by adding more NICs to the host. You can also move virtual machines to another host or
increase the CPU resources of the host or virtual machines.
235
Network performance depends on application workload and network configuration. Dropped

network packets indicate a bottleneck in the network. To determine whether packets are being
dropped, use the advanced performance charts in the VMware vSphere Client or use the
resxtop command.
vSphere Client Networking Statistics

Slide 5-24
You can use the advanced performance charts in the vSphere Client to track network statistics per
host, per virtual machine, or per NIC (virtual or physical). However, a single chart can display either
physical objects (host and vmnic#) or virtual objects (virtual machine and virtual NIC). Track these
counters to determine network performance:
Data transmit rate Average amount of data transmitted (in Kbps) per second
Data receive rate Average amount of data received (in Kbps) in the sampling interval
Packets transmitted Number of packets transmitted in the sampling interval
Packets received Number of packets received in the sampling interval
Transmit packets dropped Number of outbound packets dropped in the sampling interval
Receive packets dropped Number of inbound packets dropped in the sampling interval
236
vSphere Client Network Performance Chart

Slide 5-25
The graph has been configured to show the network statistics for all of the physical network
interfaces in the host. However, the interfaces are displayed only by the vmnic names. You must
know the specific interfaces connected to the VMkernel port groups in order to identify those
categories of traffic. To see network statistics for a specific virtual machine, select the virtual
machine in the inventory and display its advanced network performance chart.
237
This example shows the advanced network performance chart of an ESXi host. Specific details for a
point in time can be displayed by hovering the cursor over a point in the graph.
resxtop Networking Statistics

Slide 5-26
The following are the specific counters to examine in resxtop:

MbTX/s Amount of data transmitted in Mbps
MbRX/s Amount of data received in Mbps
PKTTX/s Average number of packets transmitted per second in the sampling interval
PKTRX/s Average number of packets received per second in the sampling interval
%DRPTX Percentage of outbound packets dropped in the sampling interval
%DRPRX Percentage of inbound packets dropped in the sampling interval
NOTE
The units for the statistics differ between the vSphere Client and resxtop. Make sure you
normalize the units before comparing output from these monitoring tools.
238
resxtop Network Output

Slide 5-27
Physical adapter An example is vmnic0.

vSphere network object One example is VMkernel port, such as vmk0. Another example is
virtual machines NIC, identified as 357663:TestVM01.eth0. The value 357663 is an internal
virtual machine ID, TestVM01 is the virtual machine name, and eth0 identifies the network
interface.
By default, the command shows the fields PKTTX/s, MbTX/s, PKTRX/s, MbRX/s, %DRPTX, and
%DRPRX. If you do not see all of the fields, resize the width of the window.
239
To display network statistics in resxtop, type n in the window. Configuration information about
the objects is listed first, followed by the performance metrics. The USED-BY column identifies
the network connections by:
vSphere Client, vSphere Web Client, or resxtop?

Slide 5-28
Both vSphere Client and resxtop are good ways to gather performance data for your vSphere
environment. However, in terms of networking, resxtop does have one advantage. Unlike vSphere
Client, resxtop displays both physical and virtual network users on the same screen. resxtop
allows administrators to determine, using a single screen, how much of the network load on a
physical NIC is due to a particular virtual machine.
The vSphere Client, on the other hand, has user-friendly displays, such as its performance charts and
various tab displays. For example, in the Networking view, a distributed switch has a Ports tab. This
tab provides you with port configuration information as well as performance information such as
dropped inbound and dropped outbound packets per port.
240
Lab 6 Introduction: Test Cases 1 and 2

Slide 5-29
5
You use a client-side script named nptest1.sh to generate network traffic. nptest1.sh generates
a large amount of network traffic. You are instructed to run this script on the network client virtual
machine, TestVM01.
You also use a server-side script called netserver. This script runs on the network server virtual
machine, TestVM02. netserver receives the data sent by nptest1.sh.
You perform three test cases, two of which are described here:
Test case 1 Both test virtual machines are configured with e1000 network adapters. The first
test virtual machine is connected to the Production port group on the distributed switch named
vDS-01. The second test virtual machine is connected to the port group named VM Network,
located on the standard switch, vSwitch0. Network traffic flows between two different
networks.
Test case 2 This test case is similar to test case 1, except you modify both TestVM01 and
TestVM02 to use the vmxnet3 adapter instead of the e1000 adapter.
241
In this lab, you generate network traffic and compare the network performance of different network
adapters connected to different networks or the same network.
Lab 6 Introduction: Test Case 3

Slide 5-30
Test case 3 is similar to test case 2 because both TestVM01 and TestVM02 are configured with a
vmxnet3 network adapter. However, in test case 3, both test virtual machines are connected to the
Production port group on the distributed switch, vDS-01.
242
Lab 6
Slide 5-31
5
243
Lab 6 Review
Slide 5-32
Your instructor will review the lab with you.
244

Slide 5-33
5
245
Lesson 3: Command-Line Network Management

Slide 5-34
246
Learner Objectives
Slide 5-35
5
247
Command-Line Overview for Network Management

Slide 5-36
Several command-line tools are available for you to view, configure, monitor, and troubleshoot your
virtual network configuration. Tools are available from vCLI or from the VMware vSphere
ESXi Shell.
The esxcli network namespace includes the ip, vswitch, and nic namespace. The commands in
these namespaces allow you to view and configure IP address, virtual switch, and virtual NIC
information. The esxcli command is available with the ESXi Shell and vCLI.
vicfg- commands exist to view and configure virtual NICs, routing information, Simple Network
Management Protocol (SNMP), VMkernel ports, and virtual switches. These commands are vicfgnics, vicfg-route, vicfg-snmp, vicfg-vmknic, and vicfg-vswitch. The vicfg-
commands are available with the ESXi Shell and vCLI.

The esxtop and resxtop commands are used to monitor realtime networking activity. esxtop is
available with the ESXi Shell and resxtop is available with vCLI.
VMware recommends that you use vCLI to run commands against your ESXi hosts. Run commands
directly in the ESXi Shell only in troubleshooting situations.
In addition to these tools, the direct console user interface (DCUI) can be used to manage your
hosts management network configuration.
248
Using the DCUI to Configure the Management Network

Slide 5-37
Configure Management Network This option allows you to view and modify the network
adapters that provide the default network connection to and from this host. You can also view
and modify the hosts VLAN, and whether to use a DHCP-assigned or static IP address. From
this option, you can configure the host to support IPv6. You can also configure the hosts
primary and alternate DNS server addresses and any custom DNS suffixes.
Restart Management Network This option allows you to restart the management network
interface, which might be required to restore networking or to renew a DHCP lease. Restarting
the management network results in a brief network outage that might temporarily affect running
virtual machines. If a renewed DHCP lease results in a new network identity (such as an IP
address or host name), remote management software is disconnected.
Test Management Network This option allows you to perform a brief network test. The test
attempts to ping the configured default gateway, ping the configured primary and alternate DNS
servers, and resolve the configured host name.
Restore Network Settings This option allows you to restore the management network settings
by automatically configuring the network with the system defaults. Restoring the network
settings stops all running virtual machines on the host.
249
The DCUI provides the following options from the System Customization window:
Restore Standard Switch This option is available only if your management network is
connected to a distributed switch. When you restore the standard switch, a new virtual adapter
is created. Also, the management network uplink that is connected to distributed switch is
migrated to the new virtual switch.
You might need to restore the standard switch for the following reasons:
The distributed switch is not needed or is not functioning.
The distributed switch needs to be repaired to restore connectivity to the VMware
vCenter Server system and the hosts need to remain accessible.
You do not want vCenter Server to manage the host. When the host is not connected to
vCenter Server, most distributed switch features are unavailable to the host.
The DCUI can be accessed in two ways:
Directly, from the ESXi hosts console
Remotely, from an SSH session with the command, dcui
250
Managing Virtual Networks

Slide 5-38
251
The vCLI networking commands enable you to manage the vSphere network services. You can
connect virtual machines to the physical network and to one another and configure standard
switches. Limited configuration of distributed switches is also supported. You can also set up your
vSphere environment to work with external networks like SNMP or NTP.
Retrieving Network Port Information

Slide 5-39
In the examples, the connection option contains only the --server option. In this case, you are
prompted for the user name and password when you run this command. This authentication step can
be bypassed by adding the server as a target server (vifp addserver) and initializing the server
for vi-fastpass authentication (vifptarget -s <server>).
252
Setting Virtual Switch Attributes

Slide 5-40
CDP is a Cisco technology that enables switches to broadcast and receive broadcasts. Switching
information is passed between the switches, which aids in troubleshooting network issues.
On a standard switch, CDP is supported. On distributed switches, CDP and Link Layer Discovery
Protocol are the supported protocols.
253
MTU and Cisco Discovery Protocol (CDP) settings can be viewed and configured with the esxcli
command. You usually set MTUs when you are configuring the virtual network to support jumbo
frames. Ensure that the physical network supports jumbo frames before you configure jumbo frames
on the virtual network.
Listing, Creating, and Deleting Standard Switches

Slide 5-41
By default, each ESXi host has one virtual switch, named vSwitch0. More virtual switches can be
added and managed in the vSphere Client or at the command prompt.
A virtual switch cannot be deleted if any of the ports are still in use. All virtual switch connections
must be severed before the switch can be removed.
You can also use the vicfg-vswitch command to perform similar functions.
To create a standard switch:
vicfg-vswitch --server esxi02 --add vSwitch5
To list information about all of your standard switches:

vicfg-vswitch --server esxi02 --list
To delete a standard switch:

vicfg-vswitch --server esxi02 --delete vSwitch5
254
Managing a VMkernel Port

Slide 5-42
Creating a VMkernel port involves creating the port, then configuring the port with a network
identity.
When you create the VMkernel port, you specify a VMkernel interface name. The name uses the
convention vmk<x>, where <x> is a number. You can determine the number to use from the results
of the list option. The list option shows the existing VMkernel interfaces, for example, vmk1,
vmk2, and vmk3. If vmk3 was the last VMkernel interface defined, then a new VMkernel interface
would be named vmk4.
Run the following command to get IPv4 settings for the VMkernel port:
esxcli -server esxi02 network ip interface ipv4 get i vmk6
where vmk6 is the name of the VMkernel port

These commands are used to manage VMkernel ports on standard switches only. These commands
to not apply to distributed switches.
255
VMkernel ports are used primarily for management traffic, which can include vMotion, IP storage,
and Fault Tolerance. You can also bind newly created VMkernel ports for use by software and
dependent hardware iSCSI initiators. You do the binding with the esxcli iscsi commands.
Listing, Adding, and Removing Port Groups

Slide 5-43
Network services connect to virtual switches through port groups. A port group enables you to
group traffic and specify configuration options like bandwidth limitations and VLAN tagging
policies for each port in the port group. A virtual switch must have one port group assigned to it.
You can assign additional port groups as necessary.
To list port groups on all standard switches:
vicfg-vswitch --server esxi02 --list
To add a port group to a standard switch:

vicfg-vswitch --server esxi02 --add-pg TestDev vSwitch5
To remove a port group from a standard switch:

vicfg-vswitch --server esxi02 --del-pg TestDev vSwitch5
256
Configuring a Port Group with a VLAN ID

Slide 5-44
5
You can set the port group VLAN ID on a standard switch with either the esxcli or
vicfg-vswitch command.
A VLAN ID restricts port group traffic to a logical Ethernet segment in the physical network.
Set the VLAN ID to 0 to disable the VLAN for this port group:
esxcli --server esxi02 network vswitch standard portgroup
set -p <port_group_name> --vlan-id 0
To set the VLAN ID on the port group named Production (located on vSwitch2):
vicfg-vswitch --server esxi02 --vlan 49 --pg Production vSwitch2
To disable VLAN for the port group named Production:

vicfg-vswitch --server esxi02 --vlan 0 --pg Production vSwitch2
257
Linking and Unlinking Uplink Adapters

Slide 5-45
A virtual switch that is not connected to the network can be very useful. You can use such virtual
switches to group virtual machines that want to communicate with one another but not with virtual
machines on other hosts. In most cases, you set up the virtual switch to transfer data to external
networks by attaching one or more uplink adapters to the virtual switch.
258
Configuring the SNMP Agent

Slide 5-46
To configure the agent to send traps, you must specify a target (receiver) address, the community,
and an optional port. If you do not specify a port, the SNMP agent sends traps to User Datagram
Protocol (UDP) port 162 on the target management system by default.
Two additional uses of the vicfg-snmp command are the following:
To enable the SNMP agent:
vicfg-snmp --server esxi01 --enable
To send a test trap to verify that the agent is configured correctly:

vicfg-snmp --server esxi01 --test
An SNMP agent is also included with vCenter Server. This agent can send traps when the vCenter
Server system is started or when an alarm is triggered on vCenter Server. You can manage the
vCenter Server agent with the vSphere Client, but not with the vicfg-snmp command.
259
SNMP allows management programs to monitor and control networked devices. You can use the
SNMP agent embedded in ESXi to send virtual machine and environmental traps to management
systems. This host-based embedded SNMP agent is disabled by default. You can configure and
enable this agent with the vicfg-snmp command.
Configuring DNS and Routing

Slide 5-47
The vicfg-dns command lists and specifies the DNS configuration of your ESXi host. Call the
command without command-specific options to list the existing DNS configuration. You can also
use esxcli network ip dns for DNS management.
If you move your ESXi host to a new physical location, you might have to change the default IP
gateway. You can use the vicfg-route command to manage the default gateway for the VMkernel
IP stack. vicfg-route supports a subset of the options available with the Linux route command.
No esxcli command exists to manage the default gateway.
260
Managing Uplinks in Distributed Switches

Slide 5-48
261
You can use the vSphere Client to create distributed switches. After you have created a distributed
switch, you can use the vSphere Client to add hosts to the distributed switch as well as to create
distributed port groups. You can also use the vSphere Client to edit distributed switch properties and
policies. You can add and remove uplink ports by using the vicfg-vswitch command.
Using the net-dvs Command

Slide 5-49
net-dvs is a command, available in the ESXi Shell, that can provide detailed information about
your distributed switch configuration, which can be useful when troubleshooting problems. netdvs is only available in the ESXi Shell. To run net-dvs, log in to the ESXi Shell as user root.
Distributed switch information is cached in a file named /etc/vmware/dvsdata.db. The ESXi

host updates this file every five minutes. This file can be collected by the vm-support command if
necessary. The file is binary, but you can view its contents by running the net-dvs command with
the -f option and the filename.
The slide shows sections of the net-dvs output which might be of interest to you. The net-dvs
output includes all the distributed switches. Each distributed switch has a switch identifier. The
switch identifier allows you to associate a given distributed switch with a particular virtual machine.
The virtual machines .vmx file references the switch identifier. The output also displays the name
of the distributed switch, which you defined when you created the switch.
The list of uplinks uses the uplink names as specified in vCenter Server. If private VLANs are
defined, you are able to see this information in the PVLAN map section.
CAUTION
Using the net-dvs command with options other than listing information is not supported.
262
net-dvs Output (1)

Slide 5-50
5
The command output reports on specific uplinks and specific port groups. Load balancing, link
speed, link selection, security policy, and VLAN tagging also are displayed in this part of the output.
263
The slide shows more sections from the net-dvs output. You can view MTU information. You can
also identify which discovery protocol has been enabled, CDP or LLDP.
net-dvs Output (2)

Slide 5-51
This section of the net-dvs output lists statistics for a specific port. This information can be
extremely useful in troubleshooting. Pay careful attention to fields like pktsInDropped and
pktsOutDropped. These fields can be used to indicate some type of hardware problem or physical
network overload.
This section of the output also reports on inbound and outbound traffic. In general, high outbound
traffic might indicate that the virtual machines on this port are good candidates for outbound traffic
shaping. High inbound traffic levels might reveal a system that needs special treatment to give it
high bandwidth or more resources in general (CPU, RAM, and so on).
264
Lab 7
Slide 5-52
5
265

Slide 5-53
266
Lesson 4: Troubleshooting Network Performance Problems

Slide 5-54
5
267
Learner Objectives
Slide 5-55
The network performance that can be achieved by an application depends on many factors. These
factors can affect network-related performance metrics, such as bandwidth or end-to-end latency.
These factors can also affect metrics such as CPU overhead and the achieved performance of
applications. Among these factors are the network protocol, the guest operating system network
stack, NIC capabilities and offload features, CPU resources, and link bandwidth. In addition, less
obvious factors, such as congestion due to other network traffic and buffering along the sourcedestination route, can lead to network-related performance problems. These factors are identical in
virtualized and nonvirtualized environments.
Networking in a virtualized environment does add factors that must be considered when
troubleshooting performance problems. Virtual switches are used to combine the network traffic of
multiple virtual machines onto a shared set of physical uplinks. As a result, virtual switches place
greater demands on a hosts physical NICs and the associated network infrastructure than in most
nonvirtualized environments.
For network-related problems, the best indicator of problems will be dropped packets.
268
Review: Basic Troubleshooting Flow for ESXi Hosts

Slide 5-56
5
TCP/IP networks use congestion-control algorithms that limit, but do not eliminate, dropped packets.
When a packet is dropped, TCP/IPs recovery mechanisms work to maintain in-order delivery of
packets to applications. However, these mechanisms operate at a cost to both networking performance
and CPU overhead, a penalty that becomes more severe as the physical network speed increases.
vSphere presents virtual NICs, such as the vmxnet or virtual e1000 devices, to the guest operating
system running in a virtual machine. For received packets, the virtual NIC buffers packet data
coming from a virtual switch until it is retrieved by the device driver running in the guest operating
system. The virtual switch contains queues for packets sent to the virtual NIC.
If the guest operating system does not retrieve packets from the virtual NIC rapidly enough, the
queues in the virtual NIC device can fill up. This condition can in turn cause the queues in the
corresponding virtual switch port to fill up. If a virtual switch port receives a packet bound for a
virtual machine when its packet queue is full, the port must drop the packet.
269
Network packets might get stored (buffered) in queues at multiple points along their route from the
source to the destination. Network switches, physical NICs, device drivers, and network stacks all
contain queues where packet data or headers might get buffered. Packet data might have to be
buffered before being passed to the next step in the delivery process. These queues are finite in size.
When these queues fill up, no more packets can be received at that point on the route, causing
additional arriving packets to be dropped.
Dropped Network Packets

Slide 5-57
If a guest operating system fails to retrieve packets quickly enough from the virtual NIC, a network
throughput issue might exist.
Two possible causes of this issue are:
High CPU use When the applications and guest operating system are driving the virtual
machine to high CPU utilizations, there might be extended delays. These delays occur from the
time the guest operating system receives notification that packets are available until those
packets are retrieved from the virtual NIC. Sometimes, the high CPU use might in fact be
caused by high network traffic. The reason is because the processing of network packets can
place a significant demand on CPU resources.
Improper guest operating system driver configuration Device drivers for networking devices
often have parameters that are tunable from within the guest operating system. These
parameters control such behavior as whether to use interrupts or perform polling. These
parameters also define the number of packets retrieved on each interrupt and the number of
packets that a device should buffer before interrupting the operating system. Improper
configuration of these parameters can cause poor network performance and dropped packets in
the networking infrastructure.
270
To resolve high CPU use:

Increase the CPU resources provided to the virtual machine. When the virtual machine is
dropping receive packets due to high CPU use, it might be necessary to add vCPUs in order to
provide sufficient CPU resources. If the high CPU use is due to network processing, ensure that
the guest operating system can use multiple CPUs when processing network traffic. See the
operating system documentation for the appropriate CPU requirements.
Increase the efficiency with which the virtual machine uses CPU resources. Applications that
have high CPU use can often be tuned to improve their use of CPU resources.
To resolve improper guest operating system driver configuration:
Tune the network stack in the guest operating system. It might be possible to tune the
networking stack within the guest operating system to improve the speed and efficiency with
which it handles network packets. See the documentation for the operating system.
Add virtual NICs to the virtual machine and spread network load across them. In some guest
operating systems, all of the interrupts for each NIC are directed to a single processor core. As a
result, the single processor can become a bottleneck, leading to dropped receive packets.
Adding more virtual NICs to these virtual machines allows the processing of network interrupts
to be spread across multiple processor cores.
5
271
Dropped Receive Packets

Slide 5-58
When a virtual machine transmits packets on a virtual NIC, those packets are buffered in the
associated virtual switch port until being transmitted on the physical uplink devices. The traffic from
a virtual machine, or set of virtual machines sharing the virtual switch, might exceed the physical
capabilities of the uplink NICs or the networking infrastructure. In this case, the virtual switch
buffers can fill up and additional transmit packets arriving from the virtual machine are dropped.
272
To prevent transmit packets from being dropped, take one of the following steps:
Add uplink capacity to the virtual switch. Adding more physical uplink NICs to the virtual
switch might alleviate the conditions that are causing transmit packets to be dropped. However,
traffic should be monitored to ensure that the NIC teaming policies selected for the virtual
switch lead to proper load distribution over the available uplinks.
Move some virtual machines with high network demand to a different virtual switch. If the
virtual switch uplinks are overloaded, moving some of the virtual machines to different virtual
switches can help to rebalance the load.
Enhance the networking infrastructure. Sometimes the bottleneck might be in the networking
infrastructure (for example, the network switches or interswitch links). You might have to add
additional capacity in the network to handle the load.
Reduce network traffic. Reducing the network traffic generated by a virtual machine can help to
alleviate bottlenecks in the networking infrastructure. The implementation of this solution
depends on the application and guest operating system being used. Techniques such as using
caches for network data or tuning the network stack to use larger packets (for example, jumbo
frames) might reduce the load on the network.
5
273
Dropped Transmit Packets

Slide 5-59
High speed Ethernet solutions (such as 10 Gigabit Ethernet) provide a consolidated networking
infrastructure to support different traffic flows through a single physical link. Examples of these
traffic flows are flows from applications running in a virtual machine, vMotion, and Fault Tolerance.
All these traffic flows can coexist and share a single link. Each application can use the full
bandwidth in the absence of contention for the shared network link. However, a situation might arise
when the traffic flows contend for the shared network bandwidth. This situation might affect the
performance of the application.
274
Two possible causes of this issue are the following:

Resource contention It is possible for the total demand from all the users of the network can
exceed the total capacity of the network link. In this case, users of the network resources might
experience an unexpected impact on performance. These instances, though infrequent, can still
cause fluctuating performance behavior which might be rather frustrating.
Few users dominating the resource usage vMotion or VMware vSphere Storage vMotion,
when triggered, can hog the network bandwidth. In this case, the performance of virtual
machines that share network resources with these traffic flows can be affected. The
performance impact might be more significant if the applications running in these virtual
machines were latency-sensitive or business-critical.
To overcome the problems listed here, use a resource-control mechanism. Resource control allows
applications to freely use shared network resources when the resources are underused. Access to
resources can be controlled when the network is congested.
Network I/O Control addresses these issues by distributing the network bandwidth among the
different types of network traffic flows.
Network bandwidth can be distributed among different traffic flows using shares. Shares provide
greater flexibility for redistributing unused bandwidth capacity. When the underlying shared
network link is not saturated, applications are allowed to freely use the shared link. When the
network is congested, Network I/O Control restricts the traffic flows of different applications
according to their shares.
Traffic flows can be restricted to use only a certain amount of bandwidth when limits are set on
these flows. However, a limit should be used with caution. A limit imposes a hard limit on the
bandwidth that a traffic flow is allowed to use, irrespective of the traffic conditions on the link.
Bandwidth is restricted even when the link is underused.
275
Random Increase in Data Transfer Rate

Slide 5-60
When configuring your network, consider the best practices mentioned in the slide.
The default virtual network adapter emulated in a virtual machine is either an AMD PCnet32 device
(vlance) or an Intel E1000 device (e1000). The vmxnet family of paravirtualized network adapters,
however, provides better performance than these default adapters. vmxnet adapters should be used
for optimal performance in any guest operating system for which they are available.
For the best networking performance, use network adapters that support the following hardware
features:
TCP checksum offload
TCP segmentation offload
Ability to handle high-memory DMA
Ability to handle multiple scatter gather elements per transmission frame
Jumbo frames
276
Multiple physical network adapters between a single virtual switch and the physical network
constitute a NIC team. NIC teams can provide passive failover in the event of hardware failure or
network outage. In some configurations, NIC teaming can increase performance by distributing the
traffic across those physical network adapters.
Use separate virtual switches, each connected to its own physical network adapter, to avoid
contention between the VMkernel and virtual machines. This guideline applies especially to virtual
machines running heavy networking workloads.
To establish a network connection between two virtual machines that reside on the same ESXi host,
connect both virtual machines to the same virtual switch. If the virtual machines are connected to
different virtual switches, traffic goes through the wire and incurs unnecessary CPU and network
overhead. Virtual machines that communicate with each other on the same ESXi host can also use
the VMCI device.
For networks, such as 10 Gigabit Ethernet networks, that support different types of traffic flow, use
Network I/O Control to allocate and control network bandwidth. Network I/O Control can guarantee
bandwidth for specific needs and can prevent any one resource pool from impacting the others.
In a native environment, CPU use plays a significant role in network throughput. To process higher
levels of throughput, more CPU resources are needed. The effect of CPU resource availability on the
network throughput of virtualized applications is even more significant. Because insufficient CPU
resources limit maximum throughput, monitoring the CPU use of high-throughput workloads is
essential.
277
Networking Best Practices

Slide 5-61
278

Slide 5-62
5
279
Key Points
Slide 5-63
280
MODULE 6
Storage Scalability
Slide 6-1
6
Storage Scalability
281
You Are Here

Slide 6-2
282
Importance
Slide 6-3
6
Storage Scalability
Module 6 Storage Scalability
283
Module Lessons
Slide 6-4
284
Lesson 1: Storage APIs and Profile-Driven Storage

Slide 6-5
6
Storage Scalability
285
Learner Objectives
Slide 6-6
286
VMware vSphere Storage APIs - Array Integration

Slide 6-7
287
Storage Scalability
VMware vSphere Storage APIs Array Integration (VAAI) is a set of protocol interfaces and
VMkernel APIs between VMware vSphere ESXi and storage arrays. In a virtualized
environment, virtual disks are files located on a VMware vSphere VMFS datastore. Disk arrays
cannot interpret the VMFS datastores on-disk data layout, so the VMFS datastore cannot leverage
hardware functions per virtual machine or per virtual disk file. The goal of VAAI is to help storage
vendors provide hardware assistance to accelerate VMware I/O operations that are more efficiently
accomplished in the storage hardware. VAAI plug-ins can improve data transfer performance and
are transparent to the end user.
Storage APIs is a family of APIs used by third-party hardware, software, and storage providers to
develop components that enhance several vSphere features and solutions. This module describes
two sets of Storage APIs: Array Integration and Storage Awareness. For a description of other APIs
from this family, see http://www.vmware.com/technical-resources/virtualization-topics/virtualstorage/storage-apis.html.
Storage vendors can take advantage of the following features:

Hardware Acceleration for NAS This plug-in enables NAS arrays to integrate with VMware
vSphere to transparently offload certain storage operations to the array, such as offline cloning
(cold migrations, cloning from templates). This integration reduces CPU overhead on the host.
Hardware Acceleration for NAS is deployed as a plug-in that is not shipped with ESXi. This
plug-in is developed and distributed by the storage vendor but signed by the VMware
certification program. Array/device firmware enabled for Hardware Acceleration for NAS must
use the Hardware Acceleration for NAS features. The storage vendor is responsible for the
support of the plug-in.
Array Thin Provisioning This extension assists in monitoring disk space usage on thinprovisioned storage arrays. Monitoring this usage helps prevent the condition where the disk is
out of space. Monitoring usage also helps when reclaiming disk space.
No installation steps are required for the Array Thin Provisioning extensions. Array Thin
Provisioning works on all VMFS-3 and VMFS-5 volumes. Device firmware enabled for this
API is required to take advantage of the Array Thin Provisioning features. ESXi continuously
checks for firmware that is compatible with Array Thin Provisioning. After the firmware is
upgraded, ESXi starts using the Array Thin Provisioning features.
288
VMware vSphere Storage APIs - Storage Awareness

Slide 6-8
vCenter Server gets the information from a storage array by using a software component called a
VASA provider. A VASA provider is written by the storage array vendor. The VASA provider can
exist on either the storage array processor or on a standalone host. This decision is made by the
storage vendor. Storage devices are identified to vCenter Server with a T10 identifier or an NAA ID.
VMware recommends that vendors use these types of identifiers so that devices can be matched
between the VASA provider and vCenter Server.
289
Storage Scalability
VMware vSphere Storage APIs Storage Awareness (VASA) is a set of software APIs that a
storage vendor can use to provide information about their storage array to vCenter Server.
Information includes storage topology, capabilities, and the state of the physical storage devices.
Administrators now have visibility into the storage on which their virtual machines are located
because storage vendors can make this information available.
Today, vSphere administrators do not have visibility in VMware vCenter Server into the storage
capabilities of the storage array on which their virtual machines are stored. Virtual machines are
provisioned to a storage black box. All the vSphere administrator sees of the storage is a logical unit
number (LUN) identifier, such as a Network Address Authority ID (NAA ID) or a T10 identifier.
The VASA provider acts as a server in the vSphere environment. vCenter Server connects to the
VASA provider to obtain information about available storage topology, capabilities, and state. The
information is viewed in the VMware vSphere Client. A VASA provider can report information
about one or more storage devices. A VASA provider can support connections to a single or multiple
vCenter Server instances.
For information about the concepts of VASA and developing a VASA provider, see VASA
Programming Guide at http://www.vmware.com/support/pubs.
290
Benefits Provided by Storage Vendor Providers

Slide 6-9
A VASA provider supplies capability information in the form of descriptions of specific storage
attributes.
Storage Scalability
Types of capability information include the following:

Performance capabilities, such as the number and type of spindles for a volume or the I/O
operations or megabytes/second
Disaster recovery information, such as recovery point objective and recovery time objective
metrics for disaster recovery
Space efficiency, such as type of compression used or if thick-provisioned format is used
This information allows vSphere administrators:
To be more aware of the topology, capabilities, and state of the physical storage devices on
which their virtual machines are located.
To monitor the health and usage of their physical storage devices.
To choose the right storage in terms of space, performance, and service-level agreement
requirements. Storage capabilities can be displayed in the vSphere Client. Virtual machine storage
profiles can be created to make sure that the storage being used for virtual machines complies with
the required levels of service.
291
Configuring a Storage Vendor Provider

Slide 6-10
If your storage supports a VASA provider, use the vSphere Client to register and manage the VASA
provider. The Storage Providers icon on the vSphere Client Home page allows you to configure the
VASA provider. All system storage capabilities that are presented by the VASA provider are
displayed in the vSphere Client. The new Storage Capabilities panel appears in a datastores
Summary tab.
To register a VASA provider, the storage vendor provides a URL, a login account, and a password.
Users log in to the VASA provider to get array information. vCenter Server must trust the VASA
provider host. So a security certificate from the VASA provider must be installed on the vCenter
Server system. For procedures, see the VASA provider documentation.
292
Profile-Driven Storage
Slide 6-11
Profile-driven storage can be used during the provisioning of a virtual machine to ensure that a
virtual machines disks are placed on the storage that is best for its situation. For example, profiledriven storage can help you ensure that the virtual machine running a critical I/O-intensive database
is placed in the gold tier. Ideally, the administrator wants to create the best match of predefined
virtual machine storage requirements with available physical storage properties.
293
Storage Scalability
Profile-driven storage minimizes the amount of storage planning that the administrator must do for
each virtual machine. For example, the administrator can use profile-driven storage to create basic
storage tiers. Datastores with similar capabilities are tagged to form a gold, silver, and bronze tier.
Redundant, high-performance storage might be tagged as the gold tier, Nonredundant, mediumperformance storage might be tagged as the bronze tier.
Profile-driven storage enables the creation of datastores that provide varying levels of service. With
profile-driven storage, you can use storage capabilities and virtual machine storage profiles to
ensure that virtual machines use storage that provides a certain level of capacity, performance,
availability, redundancy, and so on.
Finally, profile-driven storage can be used during the ongoing management of the virtual machines.
An administrator can periodically check whether a virtual machine has been migrated to or created
on inappropriate storage, potentially making it noncompliant. Storage information can also be used
to monitor the health and usage of the storage and report to the administrator if the virtual machines
storage is not compliant.
294
Storage Capabilities
Slide 6-12
Profile-driven storage is achieved by using two key components: storage capabilities and virtual
machine storage profiles.
A system-defined storage capability is one that comes from a storage system that uses a VASA
vendor provider. The vendor provider informs vCenter Server that it can guarantee a specific set of
storage features by presenting them as a storage capability. vCenter Server recognizes the capability
and adds it to the list of storage capabilities for that storage vendor. vCenter Server assigns the
system-defined storage capability to each datastore that you create from that storage system.
A user-defined storage capability is one that you can define and associate with datastores. Examples
of user-defined capabilities are:
Storage array type
Replication status
Storage tiers, such as gold, silver and bronze datastores
A user-defined capability can be associated with multiple datastores. You can associate a userdefined capability with a datastore that already has a system-defined capability.
295
Storage Scalability
A storage capability outlines the quality of service that a storage system can deliver. It is a guarantee
that the storage system can provide a specific set of characteristics. The two types of storage
capabilities are system-defined and user-defined.
Virtual Machine Storage Profiles

Slide 6-13
Storage capabilities are used to define a virtual machine storage profile. A virtual machine storage
profile lists the storage capabilities that virtual machine home files and virtual disks require to run
the applications in the virtual machine. A virtual machine storage profile is created by an
administrator, who can create different storage profiles to define different levels of storage
requirements. The virtual machine home files (.vmx, .vmsd, .nvram, .log, and so on) and the
virtual disks (.vmdk) can have separate virtual machine storage profiles.
With a virtual machine storage profile, a virtual machine can be checked for storage compliance. If
the virtual machine is placed on storage that has the same capabilities as those defined in the virtual
machine storage profile, the virtual machine is storage-compliant.
296
Overview of Steps for Configuring Profile-Driven Storage

Slide 6-14
An overview of the steps to configure profile-driven storage:

1. Before you add your own user-defined storage capabilities, view the system-defined storage
2. Create necessary user-defined storage capabilities based on the storage requirements of your
virtual machines.
3. After you create user-defined storage capabilities, associate these capabilities with datastores.
Whether or not a datastore has a system-defined storage capability, you can assign a userdefined storage capability to it. A datastore can have only one user-defined and only one
system-defined storage capability at a time.
4. Virtual machine storage profiles are disabled by default. Before you can use virtual machine
storage profiles, you must enable them on a host or a cluster.
297
Storage Scalability
capabilities that your storage system defines. You are checking to see whether any of the
system-defined storage capabilities match your virtual machines storage requirements. For you
to view system-defined storage capabilities, your storage system must use a VASA provider.
5. Create a virtual machine storage profile to define storage requirements for a virtual machine
and its virtual disks. Assign user-defined or system-defined storage capabilities or both to the
virtual machine storage profile.
Associate a virtual machine storage profile with a virtual machine to define the storage capabilities
that are required by the applications running on the virtual machine. You can associate a virtual
machine storage profile with a powered-off or powered-on virtual machine.
298
Using the Virtual Machine Storage Profile

Slide 6-15
By using virtual machine storage profiles, you can easily see which storage is compatible and
incompatible. You can eliminate the need to ask the SAN administrator, or refer to a spreadsheet of
NAA IDs, each time that you deploy a virtual machine.
299
Storage Scalability
When a virtual machine storage profile is selected, datastores are now divided into two categories:
compatible and incompatible. You can still choose other datastores outside of the virtual machine
storage profile, but these datastores put the virtual machine into a noncompliant state.
When you create, clone, or migrate a virtual machine, you can associate the virtual machine with a
virtual machine storage profile. When you select a virtual machine storage profile, the vSphere
Client displays the datastores that are compatible with the capabilities of the profile. You can then
select a datastore or a datastore cluster. If you select a datastore that does not match the virtual
machine storage profile, the vSphere Client shows that the virtual machine is using noncompliant
storage.
Checking Virtual Machine Storage Compliance

Slide 6-16
You can associate a virtual machine storage profile with a virtual machine or individual virtual
disks. When you select the datastore on which a virtual machine should be located, you can check
whether the selected datastore is compliant with the virtual machine storage profile.
To check the storage compliance of a virtual machine:
In the Virtual Machines tab of the virtual machine storage profile, click the Check
Compliance Now link.
If you check the compliance of a virtual machine whose host or cluster has virtual machine storage
profiles disabled, the virtual machine will be noncompliant because the feature is disabled.
Virtual machine storage compliance can also be viewed from the virtual machines Summary tab.
300
Identifying Advanced Storage Options

Slide 6-17
6
Storage Scalability
301
N_Port ID Virtualization
Slide 6-18
In normal ESXi operation, only the Fibre Channel HBA has a World Wide Name (WWN) and
N_Port ID. N_Port ID Virtualization (NPIV) is used to assign a virtual WWN and virtual N_Port ID
to a virtual machine. NPIV is most useful in two situations:
Configure NPIV if there is a management requirement to be able to monitor SAN LUN usage
down to the virtual machine level. Because a WWN is assigned to an individual virtual
machine, the virtual machines LUN usage can be tracked by SAN management software.
NPIV is also useful for access control. Because Fibre Channel zoning and array-based
LUN masking use WWNs, access control can be configured down to the individual virtual
machine level.
302
N_Port ID Virtualization Requirements

Slide 6-19
The requirements to configure NPIV are listed on the slide. For more about NPIV, see vSphere
Storage Guide at http://www.vmware.com/support/pubs/vsphere-esxi-vcenter-server-pubs.html.
Storage Scalability
303
vCenter Server Storage Filters

Slide 6-20
vCenter Server provides storage filters to help you avoid storage device corruption or performance
degradation that can be caused by an unsupported use of storage devices. The filters below are
available by default:
VMFS Filter - Filters out storage devices, or LUNs, that are already used by a VMFS datastore
on any host managed by vCenter Server. The LUNs do not show up as candidates to be
formatted with another VMFS datastore or to be used as an RDM.
RDM Filter - Filters out LUNs that are already referenced by an RDM on any host managed by
vCenter Server. The LUNs do not show up as candidates to be formatted with VMFS or to be
used by a different RDM. If you need virtual machines to access the same LUN, the virtual
machines must share the same RDM mapping file. For information about this type of
configuration, see the vSphere Resource Management documentation.
304
Same Host and Transports Filter - Filters out LUNs ineligible for use as VMFS datastore
extents because of host or storage type incompatibility. Prevents you from adding the following
LUNs as extents:
LUNs not exposed to all hosts that share the original VMFS datastore.
LUNs that use a storage type different from the one the original VMFS datastore uses. For
example, you cannot add a Fibre Channel extent to a VMFS datastore on a local storage
device.
Host Rescan Filter - Automatically rescans and updates VMFS datastores after you perform
datastore management operations. The filter helps provide a consistent view of all VMFS
datastores on all hosts managed by vCenter Server.
To change the filter behavior:
1. In the vSphere Client, select Administration > vCenter Server Settings.
2. In the settings list, select Advanced Settings.
3. In the Key text box, type the key you want to change.
4. To disable the setting, type False for the key.
5. Click Add.
6. Click OK.
Before making any changes to the device filters, consult with the VMware support team.
6
Storage Scalability
305
Identifying and Tagging SSD Devices

Slide 6-21
The VMkernel can now automatically detect, tag, and enable an SSD. ESXi detects SSD devices
through an inquiry mechanism based on the T10 standard. This mechanism allows ESXi to discover
SSD devices on many storage arrays. Devices that cannot be autodetected (that is, arrays that are not
T10-compliant) can be tagged as SSD by setting up new Pluggable Storage Architecture Storage
Array Type Plug-in claim rules.
You can use the vSphere Client to identify your SSD storage. The storage section in the ESXi hosts
Summary tab identifies the drive type. The drive type shows you whether a storage device is SSD.
The benefits to using SSD include:
Quicker VMware vSphere Storage vMotion migrations can occur among hosts that share
the same SSD.
SSD can be used as swap space for improved system performance when under memory
contention.
306
Configuring Software iSCSI Port Binding

Slide 6-22
To bind a iSCSI adapter to a VMkernel port, create a virtual VMkernel adapter for each physical
network adapter on your host. If you use multiple VMkernel adapters, set up the correct network
policy:
1. Click the Configuration tab, and click Storage Adapters in the Hardware panel.
2. The list of available storage adapters appears.
3. Select the software or dependent iSCSI adapter to configure and click Properties.
4. In the iSCSI Initiator Properties dialog box, click the Network Configuration tab.
307
Storage Scalability
By default, all network adapters appear as active. If you are using multiple VMkernel ports on a
single switch, you must override this setup, so that each VMkernel interface maps to only one
corresponding active NIC. For example, vmk1 maps to vmnic1 and vmk2 maps to vmnic2.
iSCSI port binding enables a software or a hardware dependent iSCSI initiator to be bound to a
specific VMkernel adapter. If you are using dependent hardware iSCSI adapters, then you must bind
the adapter to a VMkernel port to function properly.
5. Click Add and select a VMkernel adapter to bind with the iSCSI adapter.You can bind the
software iSCSI adapter to one or more VMkernel adapters. For a dependent hardware iSCSI
adapter, only one VMkernel interface associated with the correct physical NIC is available.
6. Click OK.
7. The network connection appears on the list of VMkernel port bindings for the iSCSI adapter.
8. Verify that the network policy for the connection is compliant with the binding requirements.
308
VMFS Resignaturing
Slide 6-23
Datastore resignaturing is irreversible because it overwrites the original VMFS UUID.

The LUN copy that contains the VMFS datastore that you resignature is no longer treated as a
LUN copy. Instead it appears as an independent datastore with no relation to the source of the
copy.
A spanned datastore can be resignatured only if all its extents are online.
The resignaturing process is crash-and-fault tolerant. If the process is interrupted, you can
resume it later.
The default format of the new label assigned to the datastore is snap-snapID-oldLabel (where
snapID is an integer and oldLabel is the label of the original datastore).
309
Storage Scalability
The LUN copy must be resignatured before it is mounted. When a datastore resignature is
performed, consider the following points:
When a LUN is replicated or a copy is made, the resulting LUN copy is identical, byte-for-byte,
with the original LUN. As a result, the original LUN contains a VMFS datastore with UUID X, and
the LUN copy appears to contain an identical copy of a VMFS datastore (a VMFS datastore with the
same UUID). ESXi can determine whether a LUN contains the VMFS datastore copy and does not
mount it automatically.
Pluggable Storage Architecture

Slide 6-24
The Pluggable Storage Architecture (PSA) sits in the SCSI middle layer of the VMkernel I/O stack.
The VMware Native Multipathing Plug-in (NMP) supports all storage arrays on the VMware
storage hardware compatibility list. The NMP also manages sub-plug-ins for handling multipathing
and load balancing.
The PSA discovers available storage paths and, based on a set of predefined rules, determines which
multipathing plug-in (MPP) should be given ownership of the path. The MPP associates a set of
physical paths with a specific storage device or LUN. The details of handling path failover for a
given storage array are delegated to a sub-plug-in called the Storage Array Type Plug-in (SATP).
The SATP is associated with paths. The details for determining which physical path is used to issue
an I/O request (load balancing) to a storage device are handled by a sub-plug-in called the Path
Selection Plug-in (PSP). The PSP is associated with logical devices.
310
PSA tasks:
Load and unload multipathing plug-ins
Handle physical path discovery and removal (through scanning)
Route I/O requests for a specific logical device to an appropriate multipathing plug-in
Handle I/O queuing to the physical storage HBAs and to the logical devices
Implement logical device bandwidth sharing between virtual machines
Provide logical device and physical path I/O statistics
NMP tasks:
Manage physical path claiming and unclaiming
Create, register, and deregister logical devices
Associate physical paths with logical devices
Process I/O requests to logical devices
Select an optimal physical path for the request (load balancing)
Perform actions necessary to handle failures and requests retries
Support management tasks like abort or reset of logical devices
6
Storage Scalability
311
VMware Default Multipathing Plug-in

Slide 6-25
The PSA uses plug-ins to manage and access storage.

The top-level plug-in is the MPP. All storage is accessed through an MPP. MPPs can be supplied by
storage vendors or by VMware.
The VMware default MPP is the NMP. The NMP includes SATPs and PSPs.
312
Overview of the MPP Tasks

Slide 6-26
Within each MPP there are two sub-plug-in types. These are SATPs and PSPs.
The SATP is associated with physical paths and controlling path failover. SATPs are covered in
detail later.
313
Storage Scalability
Each device should be claimed by only one claim rule. Claim rules come from and are used by MPPs.
So when a device is claimed by a rule, it is being claimed by the MPP associated with that rule. The
MPP is actually claiming a physical path to a storage device. Once the path has been claimed, the
MPP exports a logical device. Only an MPP can associate a physical path with a logical device.
The PSA has two major tasks. The first task is to discover what storage devices are available on a
system. Once storage is detected, the second task is to assign predefined claim rules to control the
storage device.
The PSP handles which physical path is used to issue an I/O request. This activity is load balancing.
PSPs are associated with logical devices. PSPs are covered in detail later.
A single MPP can support multiple SATPs and PSPs. The modular nature of the PSA allows for the
possibility of SATPs and PSPs from different third-party vendors. For example, a storage device
could be configured to be managed by the MPP written by the same vendor, while using a VMware
SATP and a PSP from some other vendor.
If the storage vendor has not supplied an MPP, SATP, or PSP, a VMware MPP, SATP, or PSP is
assigned by default.
This modularity can also cause problems. An MPP, SATP, or PSP might be assigned to a storage
device incorrectly. The physical hardware might not support correctly the feature set that has been
assigned. Troubleshooting might involve switching a device to a different MPP, SATP, or PSP.
314
Path Selection Example

Slide 6-27
When a virtual machine issues an I/O request to a logical device managed by the NMP, the
following takes place:
2. The PSP selects an appropriate physical path to send the I/O, load-balancing the I/O if
necessary.
3. If the I/O operation is successful, the NMP reports its completion. If the I/O operation reports
an error, the NMP calls an appropriate SATP.

4. The SATP interprets the error codes and, when appropriate, activates inactive paths and fails
over to the new active path.

5. The PSP is then called to select a new active path from the available paths to send the I/O.
315
Storage Scalability
1. The NMP calls the PSP assigned to this logical device.
Lab 8
Slide 6-28
316

Slide 6-29
6
Storage Scalability
317
Lesson 2: Storage I/O Control

Slide 6-30
318
Learner Objectives
Slide 6-31
6
Storage Scalability
319
What Is Storage I/O Control?

Slide 6-32
VMware vSphere Storage I/O Control extends the constructs of shares and limits to handle storage
I/O resources. Storage I/O Control is a proportional-share IOPS scheduler that, under contention,
throttles IOPS. You can control the amount of storage I/O that is allocated to virtual machines
during periods of I/O congestion. Controlling storage I/O ensures that more important virtual
machines get preference over less important virtual machines for I/O resource allocation.
You can use Storage I/O Control with or without VMware vSphere Storage DRS. There are two
thresholds: one for standalone Storage I/O Control and one for Storage DRS. For Storage DRS,
latency statistics are gathered by Storage I/O Control for an ESXi host and sent to vCenter Server
and stored in the vCenter Server database. With these statistics, Storage DRS can make the decision
on whether a virtual machine should be migrated to another datastore.
320
Storage I/O Control Configuration

Slide 6-33
Storage I/O Control is set to stats only mode by default. Stats only mode collects and stores statistics
but does not perform throttling on the storage device. Storage DRS can use the stored statistics
immediately after initial configuration or when new datastores are added.
321
Storage Scalability
Storage I/O Control can automatically determine an optimal latency threshold by using injector
based models to determine the latency setting. The injector determines and sets the latency threshold
when 90% of the throughput is reached.
The default latency threshold for Storage I/O Control is 30 milliseconds. The default setting might
be fine for some storage devices, but other devices might reach their latency threshold well before or
after the default setting is reached. For example, solid state disks (SSDs) typically reach their
contention point sooner than the default setting protects against. Not all devices are created equally.
Storage I/O Control Automatic Threshold Detection

Slide 6-34
Storage I/O Control can have its latency threshold set automatically by using the I/O injector model
to determine the peak throughput of a datastore. The resulting peak throughput measurement can be
used to determine the peak latency of a datastore. Storage I/O control can then set the latency
threshold to 90% of the peak latency.
322
Storage I/O Control Requirements

Slide 6-35
Storage I/O Control has several requirements and limitations.

Storage I/O Control is not supported for raw device mappings.
Automated storage tiering is the ability of an array (or group of arrays) to migrate LUNs/volumes or
parts of LUNs/volumes to different types of storage media (solid-state drive, Fibre Channel, SAS,
SATA) based on user-set policies and current I/O patterns. No special certification is required for
arrays that do not have these automatic migration/tiering features, including those that provide the
ability to manually migrate data between different types of storage media.
323
Storage Scalability
Before using Storage I/O Control on datastores that are backed by arrays with automated storage
tiering capabilities, verify that your automated tiered storage array has been certified to be
compatible with Storage I/O Control. See the online VMware Compatibility Guide at
http://www.vmware.com/resources/compatibility.
Configuring Storage I/O Control

Slide 6-36
Storage I/O Control provides quality-of-service capabilities for storage I/O in the form of I/O shares
and limits that are enforced across all virtual machines accessing a datastore, regardless of which
host they are running on. Using Storage I/O Control, vSphere administrators can ensure that the
most important virtual machines get adequate I/O resources even in times of congestion.
When you enable Storage I/O Control on a datastore, ESXi begins to monitor the device latency that
hosts observe when communicating with that datastore. When device latency exceeds a threshold,
the datastore is considered to be congested, and each virtual machine that accesses that datastore is
allocated I/O resources in proportion to their shares.
324
When you allocate storage I/O resources, you can limit the IOPS that are allowed for a virtual
machine. By default, the number of IOPS allowed for a virtual machine is unlimited. If the limit that
you want to set for a virtual machine is in terms of megabytes per second instead of IOPS, you can
convert megabytes per second into IOPS based on the typical I/O size for that virtual machine. For
example, a backup application has a typical I/O size of 64KB. To restrict a backup application to
10MB per second, set a limit of 160 IOPS (10MB per second / 64KB I/O size = 160 I/Os per
second).
On the slide, virtual machines VM1 and VM2 are running an I/O load generator called Iometer.
Each virtual machine is running on a different host, but they are running the same type of workload:
16KB random reads. The shares of VM2 are set to twice as many shares as VM1, which implies that
VM2 is more important than VM1. With Storage I/O Control disabled, the IOPS that each virtual
machine achieves, as well as their I/O latency, is identical. But with Storage I/O Control enabled, the
IOPS achieved by the virtual machine with more shares (VM2) are greater than the IOPS of VM1.
The example assumes that each virtual machine is running enough load to cause a bottleneck on the
datastore.
To enable Storage I/O Control on a datastore:
1. In the Datastores and Datastore Clusters inventory view, select a datastore and click the
Configuration tab.
2. Click the Properties link.
3. Under Storage I/O Control, select the Enabled check box.
4. Click Close.
To set the storage I/O shares and limits:
Storage Scalability
1. Right-click the virtual machine in the inventory and select Edit Settings.
2. In the Virtual Machine Properties dialog box, click the Resources tab.
By default, all virtual machine shares are set to Normal (1000), with unlimited IOPS.
For more about Storage I/O Control, see vSphere Resource Management Guide at
http://www.vmware.com/support/pubs/vsphere-esxi-vcenter-server-pubs.html.
325

Slide 6-37
326
Lesson 3: Datastore Clusters and Storage DRS

Slide 6-38
6
Storage Scalability
327
Learner Objectives
Slide 6-39
328
What Is a Datastore Cluster?

Slide 6-40
The datastore cluster serves as a container or folder. The user can store datastores in the container,
but the datastores work as separate entities.
A datastore cluster that is enabled for Storage DRS is a collection of datastores designed to work as
a single unit. In this type of datastore cluster, Storage DRS balances datastore use and I/O latency.
Storage Scalability
329
Datastore Cluster Rules

Slide 6-41
Datastores and hosts that are associated with a datastore cluster must meet certain requirements to
use datastore cluster features successfully.
A datastore cluster can contain a mix of datastores with different sizes and I/O capacities, and can be
from different arrays and vendors. However, LUNs with different performance characteristics can
cause performance problems.
All hosts attached to the datastores in a datastore cluster must be ESXi 5.0 and later. ESXi 4.x and
earlier hosts cannot be included in a datastore cluster.
NFS and VMFS datastores cannot be combined in the same datastore cluster enabled for Storage
DRS. Storage DRS cannot move virtual machines between NFS and VMFS datastores.
VMFS-3 and VMFS-5 datastores can be added to the same Storage DRS cluster. But performance of
these datastores should be similar.
330
Relationship of Host Cluster to Datastore Cluster

Slide 6-42
A host that is not part of a host cluster can also use a datastore cluster.
331
Storage Scalability
Load balancing by DRS and Storage DRS can occur at the same time. DRS balances virtual
machines across hosts based on CPU and memory usage. Storage DRS load-balances virtual
machines across storage, based on storage capacity and IOPS.
Host clusters and datastore clusters can coexist in the virtual infrastructure. A host cluster refers to a
VMware vSphere Distributed Resource Scheduler (DRS)/VMware vSphere High Availability
(vSphere HA) cluster.
Storage DRS Overview

Slide 6-43
Storage DRS manages the placement of virtual machines in a datastore cluster, based on the space
usage of the datastores. It attempts to keep usage as even as possible across the datastores in the
datastore cluster.
Storage vMotion migration of virtual machines can also be a way of keeping the datastores
balanced.
Optionally, the user can configure Storage DRS to balance I/O latency across the members of the
datastore cluster as a way to help mitigate performance issues that are caused by I/O latency.
Storage DRS can be set up to work in either manual or fully automated mode:
Manual mode presents migration and placement recommendations to the user, but nothing is
executed until the user accepts the recommendation.
Fully automated mode automatically handles initial placement and migrations based on
runtime rules.
332
Initial Disk Placement

Slide 6-44
333
Storage Scalability
By default, Storage DRS locates all the files that make up a virtual machine on the same datastore.
However, Storage DRS anti-affinity rules can be created so that virtual machine disk files can be
placed on different datastores in the cluster.
When a virtual machine is created, cloned, or migrated, the user has the option of selecting a
datastore cluster on which to place the virtual machine files. When the datastore cluster is selected,
Storage DRS chooses a member datastore (a datastore in the datastore cluster) based on storage use.
Storage DRS attempts to keep the member datastores evenly used.
Migration Recommendations
Slide 6-45
Storage DRS provides as many recommendations as necessary to balance the space and, optionally,
the IOPS resources of the datastore cluster.
Reasons for migration recommendations include:
Balancing space usage in the datastore
Reducing datastore I/O latency
Balancing datastore IOPS load
Storage DRS can also make mandatory recommendations based on whether:
A datastore is out of space
Storage DRS anti-affinity or affinity rules are being violated
A datastore is entering maintenance mode
Storage DRS also considers moving powered-off virtual machines to balance datastores.
334
Datastore Correlation Detector

Slide 6-46
The detector works by monitoring the load on one datastore and monitoring the latency on another.
If latency increases on other datastores when a load is placed on one datastore, the datastores are
correlated.
The datastore correlation detector can also be used for Anti-Affinity rules, making sure that virtual
machines and virtual disks are not only kept on separate datastores, but also kept on different
spindles on the back-end.
335
Storage Scalability
The datastore correlation detector uses the I/O injector to determine if a source and destination
datastore are using the same back-end spindles.
The purpose of datastore correlation is to help the decision making process in Storage DRS when
deciding where to move a virtual machine. For example, you gain little advantage by moving a
virtual machine from one datastore to another if both datastores are backed by the same set of
physical spindles on the array.
Configuration of Storage DRS Migration Thresholds

Slide 6-47
In the SDRS Runtime Rules page of the wizard, select or deselect the Enable I/O metric for SDRS
recommendations check box to enable or disable IOPS metric inclusion. When I/O load balancing
is enabled, Storage I/O Control is enabled for all the datastores in the datastore cluster if it is not
already enabled. When this option is deselected, you disable:
IOPS load balancing among datastores in the datastore cluster
Initial placement for virtual disks based on IOPS metric
Space is the only consideration when placement and balancing recommendations are made.
336
Storage DRS thresholds can be configured to determine when Storage DRS recommends or
performs initial placement or migration recommendations:
Utilized Space Determines the maximum percentage of consumed space allowed before
Storage DRS recommends or performs an action.
I/O Latency Indicates the maximum latency allowed before recommendations or migrations
are performed. This setting is applicable only if the Enable I/O metric for SDRS
recommendations check box is selected
Click the Show Advanced Options link to view advanced options:
No recommendations until utilization difference between source and destination is
Defines the space utilization threshold. For example, datastore A is 80 percent full and datastore
B is 83 percent full. If you set the threshold to 5, no recommendations are made. If you set the
threshold to 2, a recommendation is made or a migration occurs.
Evaluate I/O load every Defines how often Storage DRS checks space or IOPS load
balancing or both.
I/O imbalance threshold Defines the aggressiveness of IOPS load balancing if the Enable
I/O metric for SDRS recommendations check box is selected.
6
Storage Scalability
337
Storage DRS Affinity Rules

Slide 6-48
By default, all of a virtual machines disks can be on the same datastore.

A user might want the virtual disks on different datastores. For example, a user can place a system
disk on one datastore and place the data disks on another. In this case, the user can set up a virtual
machine disk (VMDK) anti-affinity rule, which keeps a virtual machines virtual disks on separate
datastores.
Virtual machine anti-affinity rules keep virtual machines on separate datastores. This rule is useful
when redundant virtual machines must always be available.
338
Adding Hosts to a Datastore Cluster

Slide 6-49
You can configure a host cluster or individual hosts to use the datastore cluster enabled for
Storage DRS.
Storage Scalability
339
Adding Datastores to the Datastore Cluster

Slide 6-50
You can select one or more datastores in the Available Datastores pane. The Show Datastores
drop-down menu enables you to filter the list of datastores to display. VMware recommends that all
hosts have access to the datastores that you select.
In the example, all datastores accessed by all hosts in the vCenter Server inventory are displayed.
All datastores are accessible by all hosts, except for the datastores Local01 and Local02.
340
Storage DRS Summary Information

Slide 6-51
Storage Scalability
I/O metrics Displays whether or not the I/O metric inclusion option is enabled
Storage DRS Indicates whether Storage DRS is enabled or disabled
Automation level Indicates either manual or fully automated mode
Utilized Space threshold Displays the space threshold setting
I/O latency threshold Displays the latency threshold setting
The vSphere Storage DRS panel on the Summary tab of the database cluster displays the Storage
DRS settings:
341
Storage DRS Migration Recommendations

Slide 6-52
The Storage DRS tab displays the Recommendations view by default. In this view, datastore cluster
properties are displayed. Also displayed are the migration recommendations and the reasons for the
recommendations.
To refresh recommendations, click the Run Storage DRS link.
To apply recommendations, click Apply Recommendations.
The Storage DRS tab has two other views. The Faults view displays issues that occurred when
applying recommendations. The History view maintains a migration history.
342
Storage DRS Maintenance Mode

Slide 6-53
If the datastore cluster is set to fully automated mode, virtual machines are automatically migrated
to other datastores.
If the datastore cluster is set to manual mode, migration recommendations are displayed in the
Storage DRS tab. The virtual disks cannot be moved until the recommendations are accepted.
To place a datastore into Storage DRS maintenance mode:
1. Go to the Datastores and Datastore Clusters inventory view.
Right-click the datastore in the datastore cluster enabled for Storage DRS and select Enter SDRS
Maintenance Mode.
343
Storage Scalability
When a datastore cluster enters Storage DRS maintenance mode, only registered virtual machines
are moved to other datastores in the datastore cluster. Unregistered virtual machines, templates, ISO
images, and other nonvirtual machine files are not moved. The datastore does not enter maintenance
mode until all files on the datastore are moved. So you must manually move these files off the
datastore in order for the datastore to enter Storage DRS maintenance mode.
Storage DRS allows you to place a datastore in maintenance mode. A datastore enters or leaves
maintenance mode only as the result of your performing the task. Storage DRS maintenance mode is
available to datastores in a datastore cluster enabled for Storage DRS. Standalone datastores cannot
be placed in maintenance mode.
Backups and Storage DRS

Slide 6-54
Scheduled tasks can be configured to change Storage DRS behavior. Scheduled tasks can be used to
change the Storage DRS configuration of the datastore cluster to match enterprise activity. For
example, if the datastore cluster is configured to perform migrations based on I/O latency, you might
disable the use of I/O metrics by Storage DRS during the backup window. You can reenable I/O
metrics use after the backup window ends.
To set up a Storage DRS scheduled task for a datastore cluster:
1. In the Datastores and Datastore Clusters inventory view, right-click the datastore cluster and
select Edit Settings.

2. In the left pane, select SDRS Scheduling and click Add.
3. In the Set Time page, enter the start time, end time, and days that the task should run. Click
Next.
4. In the Start Settings page, enter a description and modify the Storage DRS settings as you want
them to be when the task starts. Click Next.

5. In the End Settings page, enter a description and modify the Storage DRS settings as you want
them to be when the task ends. Click Next.

6. Click Finish to save the scheduled task.
344
Storage DRS - vSphere Technology Compatibility

Slide 6-55
345
Storage Scalability
The table shows some features that are supported with Storage DRS. For information about Storage
DRS features and requirements, see vSphere Resource Management Guide at
http://www.vmware.com/support/pubs/vsphere-esxi-vcenter-server-pubs.html.
Storage DRS - Array Feature Compatibility

Slide 6-56
The table shows some array features that are supported with Storage DRS. For information about
Storage DRS and supported array features and requirements, go to the vSphere Storage DRS
Interoperability whitepaper at http://www.vmware.com/resources/techresources/10286
346
Storage DRS and Storage I/O Control

Slide 6-57
Storage DRS uses IOPS load history to determine migrations. Storage DRS runs infrequently and
does analysis to determine long-term load balancing.
Storage I/O Control monitors the I/O metrics of the datastores. Storage DRS uses this information to
determine whether a virtual machine should be moved from one datastore to another.
347
Storage Scalability
Storage I/O Control runs in real time. It continuously checks for latency and controls I/O
accordingly.
Both Storage DRS and Storage I/O Control work with IOPS and should be used together. Storage
DRS works to avoid IOPS bottlenecks. Storage I/O Control is enabled when you enable Storage
DRS. Storage DRS is used to manage unavoidable IOPS bottlenecks, such as short, intermittent
bottlenecks, and congestion on every datastore in the datastore cluster.
Lab 9
Slide 6-58
348

Slide 6-59
6
Storage Scalability
349
Key Points
Slide 6-60
350

VSOS51 Lecture V1 PDF

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

VSOS51 Lecture V1 PDF

Hochgeladen von

Copyright:

Verfügbare Formate

VMware vSphere:

Optimize and Scale

VMware Education Services

VMware Management Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

VMware vSphere: Optimize and Scale

Powering Virtual Machines On and Off with vmware-cmd . . . . . . . . . .48

Performance in a Virtualized Environment . . . . . . . . . . . . . . . . . . . . . . .57

Displaying the Default Monitor Mode . . . . . . . . . . . . . . . . . . . . . . . . . .91

Network Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125

Editing General Distributed Switch Properties . . . . . . . . . . . . . . . . . . .141

VMware vSphere: Optimize and Scale

Restore a Distributed Virtual Switch Configuration . . . . . . . . . . . . . . .198

Network Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209

Review of Learner Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245

Storage Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .281

Storage Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .295

Storage DRS - vSphere Technology Compatibility . . . . . . . . . . . . . . .345

VMware vSphere: Optimize and Scale

VMware vSphere: Optimize and Scale

VMware vSphere: Optimize and Scale

Module 1 Course Introduction

You Are Here

VMware vSphere: Optimize and Scale

Module 1 Course Introduction

VMware vSphere: Optimize and Scale

Module 1 Course Introduction

1. Click the VCAP5-DCA link on the VMware Certification Web page at

VMware Online Resources

VMware vSphere: Optimize and Scale

vSphere Production Documentation

vSphere documentation is available on the VMware Web site at http://www.vmware.com/support/

Module 1 Course Introduction

VMware vSphere: Optimize and Scale

VMware Management Resources

VMware vSphere: Optimize and Scale

You Are Here

VMware vSphere: Optimize and Scale

Module 2 VMware Management Resources

VMware vSphere: Optimize and Scale

Methods to Run Commands

Module 2 VMware Management Resources

VMware vSphere: Optimize and Scale

Accessing ESXi Shell Locally

Module 2 VMware Management Resources

Accessing ESXi Shell Remotely

with host and reboot the host.

VMware vSphere: Optimize and Scale

4. Select ESXi Shell and click Options.

stop with host and reboot the host.

In the vSphere Client, follow these steps:

Module 2 VMware Management Resources

VMware Management Resources

VMware vSphere: Optimize and Scale

Module 2 VMware Management Resources

vMA Hardware and Software Requirements

VMware vSphere: Optimize and Scale

Module 2 VMware Management Resources

Connecting to the Infrastructure

VMware vSphere: Optimize and Scale

Module 2 VMware Management Resources

VMware vSphere: Optimize and Scale

Adding a Target Server