0470569611 Vm Ware

VCPVMware® Certified

Professional on vSphere™ 4Study Guide

VCPVMware® Certified

Professional on vSphere™ 4Study Guide

Brian Perry Chris Huss

Jeantet Fields

Acquisitions Editor: Jeff KellumDevelopment Editor: Amy BreguetTechnical Editors: Chris Perry; Joep PiscaerProduction Editor: Dassi ZeidelCopy Editor: Liz WelchEditorial Manager: Pete GaughanProduction Manager: Tim TateVice President and Executive Group Publisher: Richard SwadleyVice President and Publisher: Neil EddeMedia Associate Project Manager: Laura Moss-HollisterMedia Associate Producer: Shawn PatrickMedia Quality Assurance: Doug KuhnBook Designers: Judy Fung and Bill GibsonCompositor: Craig Woods, Happenstance Type-O-RamaProofreader: Publication Services, Inc.Indexer: Ted LauxProject Coordinator, Cover: Lynsey StanfordCover Designer: Ryan Sneed

Copyright © 2010 by Wiley Publishing, Inc., Indianapolis, Indiana

Published simultaneously in Canada

ISBN: 978-0-470-56961-0

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Permis-sions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.

Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Web site is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Web site may provide or recommendations it may make. Further, readers should be aware that Internet Web sites listed in this work may have changed or disappeared between when this work was written and when it is read.

For general information on our other products and services or to obtain technical support, please contact our Customer Care Department within the U.S. at (877) 762-2974, outside the U.S. at (317) 572-3993 or fax (317) 572-4002.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.

Library of Congress Cataloging-in-Publication Data Perry, Brian, 1966- VCP : VMware certified professional on vSphere 4 study guide / Brian Perry, Chris Huss, Jeantet Fields. p. cm. ISBN-13: 978-0-470-56961-0 (pbk) ISBN-10: 0-470-56961-1 (pbk) ISBN 9780470916995 (ebk) ISBN 9780470917015 (ebk) ISBN 9780470917008 (ebk) 1. Electronic data processing personnel—Certification. 2. Virtual computer systems—Examinations—Study guides. 3. VMware. I. Huss, Chris, 1972- II. Fields, Jeantet, 1973- III. Title. QA76.3.P4734 2010 005.4’3—dc22 2010019277

TRADEMARKS: Wiley, the Wiley logo, and the Sybex logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. VMware and vSphere are trademarks or registered trademarks of VMware, Inc. All other trademarks are the property of their respec-tive owners. Wiley Publishing, Inc. is not associated with any product or vendor mentioned in this book.

10 9 8 7 6 5 4 3 2 1

http://www.wiley.com/go/permissions

Dear Reader,

Thank you for choosing VCP: VMware Certified Professional on vSphere 4 Study Guide. This book is part of a family of premium-quality Sybex books, all of which are written by outstanding authors who combine practical experience with a gift for teaching.

Sybex was founded in 1976. More than 30 years later, we’re still committed to producing consistently exceptional books. With each of our titles, we’re working hard to set a new standard for the industry. From the paper we print on, to the authors we work with, our goal is to bring you the best books available.

I hope you see all that reflected in these pages. I’d be very interested to hear your com-ments and get your feedback on how we’re doing. Feel free to let me know what you think about this or any other Sybex book by sending me an email at [email protected]. If you think you’ve found a technical error in this book, please visit http://sybex.custhelp.com. Customer feedback is critical to our efforts at Sybex.

Best regards,

Neil Edde Vice President and Publisher Sybex, an Imprint of Wiley

mailto:[email protected]

http://sybex.custhelp.com

We dedicate this book to our students and those entering the world

of virtualization. Many technologies come and go, but virtualization

is here to stay.

AcknowledgmentsThe writing of this Study Guide has been a great challenge for me. In addition to traveling and extolling the virtues of virtualization to others, I help manage an independent instruc-tors group that teaches and consults on VMware virtualization. We found the time to write a comprehensive guide such as this mostly on the road and occasionally from home. There are many individuals and partners we have collaborated with to bring this book to you.

I want to thank Sybex and Wiley for their patience and encouragement along the way. Without the help of Acquisitions Editor Jeff Kellum, Development Editor Amy Breguet, Production Editor Dassi Zeidel, and the rest of the team, this project would not have been completed.

I also want to thank the great folks at VMware. I started my instructing career for VMware over six years ago. Without their help and focus in providing the best IT instruc-tional classes for their products, I would not be in the position I’m fortunate to be in today.

In addition, I’d like to mention two individuals who helped immensely in providing con-tent and critique. John Nouveaux was patient and professional in helping us with additional content. Without his help, this book would have been delayed greatly. The other individual, my brother Chris Perry, provided technical critique of the manuscript. Chris was my mentor and inspiration to get into the IT world many years ago. To work with him on a book was a dream come true for both of us.

Two other people helped to make this book a reality: my business partners, Chris Huss and Jeantet Fields. Chris and I have known and worked with each other now for over five years. I love his passion and focus. Jeantet and I met just four short years ago, but the friendship created was almost instantaneous. Both of these men are an inspiration to me each day and I’m blessed to have them as friends, business partners, and co-authors.

My last thank you goes to my family. As most authors know or come to know very quickly, without the support of family, a book project is very hard to finish. I want to thank both of my children, Alana and Ross, for their patience when I had to take time to work on the book and not be with them. Most importantly, I want to thank my wife Moriah for her encouragement and love. Without my family, the travel and hard work would be unsustainable.

—Brian Perry

It’s been a long journey getting to this point in my life, and I have many people to thank.The people of LIMMCO who gave me my first opportunity to build a network from the

ground up; David Neel of CyberTek Engineering, who gave me my first IT job; Eric Farmer, my friend and mentor; and my friends at LTI, John Heuglin, Steven Cummings, Allen Smith, and Doug Paddock, who encouraged me to get published.

I want to thank Matt Stearly and the good people at Infinite Solutions, Charlie Hagerty and Eric Henderson at New Age Technologies, and everyone who works for the Education group at VMware, who work tirelessly, giving many of us a better quality of life.

x Acknowledgments

I want to thank my business partners at VMTrainers, Brian and Jeantet, who amaze me every day with their patience, stamina, and business savvy.

I want to thank my family, who have given me the life skills to succeed, and who have been my biggest mentors and supporters. I’d like to especially thank my wife Lori, who works endlessly herself but has continued to support me through this very long process.

—Chris Huss

There are many people to whom I owe a heartfelt thanks; the short list starts with my colleagues Brian and Chris, who made both VMTrainers and the idea of authoring a book reality.

I am grateful to my dear Ariane, whose patience and support made it possible for me to contribute to this text. A nod of credit is aimed at my family, whose pride gave me the confidence to dare speaking authoritatively for the benefit of my comrades in IT.

Lastly, a thank-you to the professionals in VMware Education, in particular Kelly and Kirk: you have made my present career possible when you gave me a chance, a few years ago. That’s how I see it, and for that, I thank you.

—Jeantet Fields

About the AuthorsBrian Perry (Somerset, KY) VCP4, VCI, is Managing Partner with Virtual Umbrella LLC (www.vmtrainers.com), a leading VMware Training Provider that provides over 20 certi-fied instructors for VMware-authorized training courses all over the world. He was one of the first to earn the VMware Certified Instructor qualification in 2004 and is currently the longest serving contractor for VMware instruction. He has been working with VMware products for over 10 years, starting with VMware Workstation and progressing to GSX, now VMware Server, various versions ESX/ESXi (starting with version 1.5), and the various ver-sions of vCenter Server. Brian helped create and build one of the first Premier VIP Reseller and VAC partners in the Midwest and continues to provide consulting services for several VMware Partners. Brian has also been a presenter at VMWorld and has attended every VMWorld event since its inception.

Chris Huss (Louisville, KY) VCP4, VCI, is a partner with Virtual Umbrella LLC (VMTrainers) with over 10 years of IT consulting and training experience on a wide range of topics, including Microsoft, CompTIA, and Cisco. Chris has helped several vendors solidify their online instructional offerings and is a large presence online in the many blogs and user communities. Chris leads the online scheduling efforts at VMTrainers. His primary focus, since 2004, has been in the virtualization space.

Jeantet Fields (New York) VCP4, VCI, is a partner with Virtual Umbrella LLC (VMTrainers) and has over 10 years of experience building and managing multiple plat-form infrastructures for small, medium, and enterprise environments. He brings experi-ences from private, government, financial, and international sectors to the VMware course curriculum. Jeantet leads the marketing and scheduling efforts at VMTrainers and works tirelessly for the many instructors who use their services. Jeantet is able to teach the vari-ous VMware courses in three languages: English, Spanish, and French.

http://www.vmtrainers.com

Contents at a Glance

Introduction xxix

Assessment Test liv

Chapter 1 Planning, Installing, and Upgrading VMware ESX/ESXi 1

Chapter 2 Configuring ESX/ESXi Networking 65

Chapter 3 Configuring ESX/ESXi Storage 119

Chapter 4 Installing and Configuring vCenter Server 175

Chapter 5 Deploying and Managing Virtual Machines and vApps 247

Chapter 6 Managing Compliance 303

Chapter 7 Migrating, Backing Up, and Restoring Virtual Machines 363

Chapter 8 Managing and Creating VMware Clusters 413

Chapter 9 Alarm Management 455

Chapter 10 Performing Basic Troubleshooting 495

Appendix About the Companion CD 539

Glossary 543

Index 551

ContentsIntroduction xxix

Assessment Test liv

Chapter 1 Planning, Installing, and Upgrading VMware ESX/ESXi 1

Planning an ESX/ESXi Installation 3Installing VMware ESX/ESXi on Local Storage 6

Upgrading VMware ESX/ESXi 30Planning a VMware vSphere Upgrade 30

Securing VMware ESX/ESXi 39Identifying Default Security Principles 39Understanding Service Console Firewall Operation 42Setting Up User and Group Accounts 43Determining Applications Needed for Accessing

the Service Console in a Given Scenario 44Installing VMware ESX/ESXi on SAN Storage 45

Configuring LUN Masking 45Preparing the SAN 46Configuring Fibre Channel or iSCSI HBA BIOS 46Installing VMware ESX/ESXi 47Determining Boot LUN Size in a Given Situation 47

Identifying vSphere Architecture and Solutions 47Differentiating VMware Platform Products and Editions 47Understanding Datacenter Solutions 50Exploring ESX/ESXi Architecture 52Comparing and Contrasting Bare-Metal vs.

Hosted Architecture 53Summary 55Exam Essentials 56Review Questions 57Answers to Review Questions 62

Chapter 2 Configuring ESX/ESXi Networking 65

Configuring Virtual Switches 67Understanding Virtual Switches and ESX/ESXi NIC

and Port Maximums 68Determining the vSwitch NIC Teaming Policy In

A Given Situation 73Determining the Appropriate vSwitch Security Policies

In A Given Situation 74

xvi Contents

Creating and Deleting Virtual Switches 75Creating Ports/Port Groups 81Assigning Physical Adapters 81Modifying vSwitch NIC Teaming and Failover Policies 83Modifying vSwitch Security Policy and VLAN Settings 86Configuring VMotion 87

Configuring Distributed vSwitches 88Determining the Virtual Port Group NIC Teaming

and Failover Policy In A Given Situation 89Determining the Appropriate Virtual Port Group

Security Policies In A Given Situation 90Creating and Modifying a vNetwork Distributed Switch 93Creating and Modifying Uplink Group Settings 99Creating and Modifying dvPort Group Settings 99Adding a Host to a vNetwork Distributed Switch 102Adding and Deleting a VMkernel dvPort 103Migrating Virtual Machines to a vNetwork

Distributed Switch 104Configuring the VMware ESX/ESXi Management Network 105

Modifying Service Console IP Settings 107Configuring Service Console Availability 108Configuring DNS and Routing Settings for

an ESX Host 108Configuring the ESXi Management Interface 109

Configuring the Management Interface 110Adding a Second Management Interface 111

Summary 112Exam Essentials 112Review Questions 113Answers to Review Questions 117

Chapter 3 Configuring ESX/ESXi Storage 119

Configuring FC SAN Storage 121Identifying FC SAN Hardware Components 122Identifying How ESX Server Connections are

Made to FC SAN Storage 122Describing ESX Server FC SAN Storage Addressing 124Describing the Concepts of Zoning and LUN Masking 124Configuring LUN Masking 125Scanning for New LUNs 126Determining and Configuring the Appropriate

Multipathing Policy 127Differentiating Between NMP and Third-Party MPPs 128

Contents xvii

Configuring iSCSI SAN Storage 129Identifying iSCSI SAN Hardware Components 129Determining Use Cases for Hardware vs. Software

iSCSI Initiators 130Configuring the iSCSI Software Initiator 132Configuring Dynamic/Static Discovery 134Configuring CHAP Authentication 134Configuring VMkernel Port Binding for iSCSI

Software Multipathing 136Discovering LUNs 139Identifying iSCSI Addressing in the Context of the Host 140

Configuring NFS Datastores 141Identifying the NFS Hardware Components 142Explaining ESX Exclusivity for NFS Mounts 142Configuring ESX/ESXi Network Connectivity

to the NAS Device 143Creating an NFS Datastore 144

Configuring and Managing VMFS Datastores 147Identifying VMFS File System Attributes 147Determining the Appropriate Datastore

Location/Configuration for Given Virtual Machines 148Determining Use Cases for VMFS Volumes 149Creating/Configuring VMFS Datastores 150Attaching an Existing Datastore to New ESX Host 155Managing VMFS Datastores 156Growing VMFS Datastores 161


Chapter 4 Installing and Configuring vCenter Server 175

Installing vCenter Server 177Identifying Hardware Requirements 178Understanding Configuration Maximums 179Determining Availability Requirements for a

vCenter Server in a Given Situation 180Determining Appropriate vCenter Server Edition 183Determining Database Size Requirements 183Preparing/Configuring the vCenter Server Database 186Installing vCenter Server Using Downloaded Installer 187Installing Additional Modules 193Determining a Use Case for vCenter Linked Mode Groups 195

xviii Contents

Managing vSphere Client Plug-ins 198Identifying Available Plug-ins 198Determining Required Plug-ins for a Given Application 199Ensuring Permissions to Install Plug-ins 200Enabling Plug-ins After Installation 200

Configuring vCenter Server 200Identifying the vCenter Server Managed ESX Hosts

and VM Maximums 201Joining ESX/ESXi Hosts to vCenter Server 206Configuring Guest OS Customization 209Using Datacenters and Folders to Organize

the Environment 210Configuring and Using Scheduled Tasks 212Configuring/Using Resource Maps 215Using Storage Reports and Maps 216Viewing/Managing Events 217Configuring vCenter Server Settings 220Configuring vSphere Client Settings 221

Configuring Access Control 224Creating/Modifying User Permissions in vCenter 224Creating and Modifying User Permissions in ESX Server 229Restricting Access to vCenter Inventory Objects 229Defining vCenter Predefined Roles and Their Privileges 232Creating, Cloning, and Editing Roles 233Assigning Roles to Users and Groups 236Describing How Privileges Propagate 236Understanding Permissions as Applied to User

and Group Combinations 236Summary 237Exam Essentials 238Review Questions 239Answers to Review Questions 244

Chapter 5 Deploying and Managing Virtual Machines and vApps 247

Creating and Deploying Virtual Machines 249Understanding VM Hardware Maximums 250Creating a Virtual Machine 251Creating and Converting Templates 264Customizing Windows and Linux VMs 265Managing Customization Specifications 267Deploying a VM from a Template 268Deploying a VM Using VMware vCenter

Converter Enterprise 272

Contents xix

Performing a Hot Clone 273Performing a Cold Clone 274Deploying a VM Using Guided Consolidation 275Cloning a VM 277Importing a VM from a File or Folder 279

Managing VMs 279Configuring and Modifying VMs 280Connecting VMs to Devices 281Configuring VM Options 281Configuring VM Resource Settings 284

Deploying vApps 287Determining Whether a vApp Is Appropriate

for a Situation 287Defining Open VM Format (OVF) 288Importing and Exporting a Virtual Appliance 288Building a vApp 288Creating and Adding VMs to a vApp 289Editing vApp Properties 289Exporting vApps 292Cloning a vApp 292


Chapter 6 Managing Compliance 303

Installing, Configuring, and Managing VMware vCenter Update Manager 304

Determining Installation Requirements and Database Sizing 305

Installing Update Manager Server and Client Components 306Configuring Update Manager Settings 314Configuring Patch Download Options 316Create Baselines 323Attaching Baselines to vCenter Inventory Objects 328Scanning ESX Hosts and Virtual Machines 329Remediate ESX Hosts and Virtual Machines 334Staging ESX/ESXi Host Updates 341Analyzing Compliance Information from a Scan 342

Establishing and Applying ESX Host Profiles 343Creating/ Deleting Host Profiles 344Importing/Exporting Host Profiles 347Editing Host Profile Policies 348Associating an ESX Host with a Host Profile 350

xx Contents

Checking for Compliance 351Applying Host Profiles 352Analyzing Configuration Compliance Information

from a Scan 353Summary 355Exam Essentials 355Review Questions 356Answers to Review Questions 361

Chapter 7 Migrating, Backing Up, and Restoring Virtual Machines 363

Migrating Virtual Machines 364Identifying Compatibility Requirements 365Citing the Three Methods of Virtual Machine Migration 367Understanding/Applying Migration Methods 367Determining Migration Use Cases 369Comparing and Contrasting Migration Technologies 370Migrating a Virtual Machine Using VMotion 370Migrating a VM Using Storage VMotion 373Cold Migrating a Virtual Machine 376

Backing Up and Restoring Virtual Machines 378Describing Different Backup/Restore Procedures

and Strategies 378Creating, Deleting, and Restoring Snapshots 380Installing Backup and Recovery Appliances 387Installing the VMware Data Recovery Plug-in 395Creating a Backup Job with VMware Data Recovery 397Performing Test and Actual Restores Using

VMware Data Recovery 402Summary 404Exam Essentials 405Review Questions 406Answers to Review Questions 411

Chapter 8 Managing and Creating VMware Clusters 413

Creating and Configuring VMware Clusters 415Creating a New Cluster 416Adding ESX/ESXi Hosts to a Cluster 418Configuring High Availability Basic/Advanced Settings 419Enabling and Configuring VM Monitoring 424Configuring Distributed Resource Scheduler

Basic and Advanced Settings 425

Contents xxi

Configuring Distributed Power Management 427Configuring Enhanced VMotion Compatibility 428Configuring Swap File Location 429Analyzing HA Host Failure Capacity Requirements 431Analyzing HA Admission Control 431Determining Use Cases for DRS Automation Levels

and Migration Thresholds 433Determining Use Cases for DPM Policies 434

Enabling a Fault-Tolerant Virtual Machine 435Identifying FT Restrictions 435Evaluating FT Use Cases 436Setting Up a Fault-Tolerant Network 437Verifying Requirements of the Operating Environment 438Enabling FT for a Virtual Machine 438Testing an FT Configuration 439Upgrading ESX Hosts Containing FT Virtual Machines 439

Creating and Managing Resource Pools 440Determining Resource Pool Requirements for a

Given Situation 441Evaluating Appropriate Shares, Reservations,

and Limits for a Given Situation 441Evaluating Virtual Machines for a Given Resource Pool 442Creating Resource Pools 443Setting CPU Resource Shares, Reservations, and Limits 444Setting Memory Resource Shares, Reservations,

and Limits 445Defining Expandable Reservation 445Adding Virtual Machines to a Pool 446Describing Resource Pool Hierarchy 446


Chapter 9 Alarm Management 455

Creating and Responding to vCenter Connectivity Alarms 456Listing vCenter Default Connectivity Alarms 457Listing Possible Actions for Connectivity Alarms 458Analyzing and Evaluating the Affected Components 460Creating a vCenter Connectivity Alarm 461Relating the Alarm to the Affected Component 465

Creating and Responding to vCenter Utilization Alarms 467Listing vCenter Default Utilization Alarms 467Listing Possible Actions for Utilization Alarms 468

xxii Contents

For a Given Alarm, Analyzing and Evaluating the Affected Virtual Infrastructure Resource 468

Creating a vCenter Utilization Alarm 470Relating the Alarm to the Affected Resource 473

Monitoring vSphere ESX/ESXi and Virtual Machine Performance 474

Identifying Critical Performance Metrics 474Explaining Memory Metrics 476Explaining CPU Metrics 477Explaining Network Metrics 478Explaining Storage Metrics 479Comparing Overview and Advanced Charts 480Creating an Advanced Chart 481Determining Host Performance Using Guest Perfmon 485


Chapter 10 Performing Basic Troubleshooting 495

Performing Basic Troubleshooting for ESX/ESXi Hosts 497Understanding General ESX Server

Troubleshooting Guidelines 498Troubleshooting Common Installation Issues 498Monitoring ESX Server System Health 500Understanding How to Export Diagnostic Data 501

Performing Basic Troubleshooting for VMware FT and Third-Party Clusters 502

Analyzing and Evaluating VM Population for Maintenance Mode Considerations 502

Understanding Manual Third-Party Failover/Failback Processes 503

Troubleshooting Fault Tolerance Partial/or Unexpected Failures 506

Performing Basic Troubleshooting for Networking 508Verifying VM Is Connected to the Correct

Port Group 508Verifying That Port Group Settings Are Correct 509Verifying That the Network Adapter Is Connected

Within the VM 510Verifying VM Network Adapter Settings 511Verifying Physical Network Adapter Settings 512Verifying vSphere Network Management Settings 512

Contents xxiii

Performing Basic Troubleshooting for Storage 514Identifying Storage Contention Issues 515Identifying Storage Overcommitment Issues 516Identifying Storage Connectivity Issues 517Identifying iSCSI Software Initiator Configuration Issues 518Interpreting Storage Reports and Storage Maps 519

Performing Basic Troubleshooting for HA/DRS and VMotion 522Explaining the Requirements of HA/DRS and VMotion 522Verifying VMotion Functionality 524Verifying DNS Settings 524Verifying the Service Console Network Functionality 525Interpreting the DRS Resource Distribution Graph

and Target/Current Host Load Deviation 526Troubleshooting VMotion Using the Topology Maps 526Troubleshooting HA Capacity Issues 527Troubleshooting HA Redundancy Issues 528


Appendix About the Companion CD 539

What You’ll Find on the CD 540Sybex Test Engine 540Electronic Flashcards 540PDF of the Book 540Adobe Reader 540

System Requirements 540Using the CD 541Troubleshooting 541

Customer Care 542

Glossary 543

Index 551

Table of ExercisesExercise 1.1 Installing ESX on Local Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Exercise 1.2 Installing ESXi from the ISO File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Exercise 1.3 Configuring NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Exercise 1.4 Installing Standalone Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Exercise 1.5 Creating a Regular User Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Exercise 1.6 Using the Host Update Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Exercise 1.7 Working with the ESX Service Console Firewall . . . . . . . . . . . . . . . . . . . . . 42

Exercise 1.8 Exporting a List of Users and Groups on ESX . . . . . . . . . . . . . . . . . . . . . . . 44

Exercise 2.1 Creating a Standard vSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Exercise 2.2 Adding Network Adapters to a vSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Exercise 2.3 Creating a VMkernel Port and Configuring vMotion . . . . . . . . . . . . . . . . . 87

Exercise 2.4 Creating a Distributed vSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Exercise 2.5 Editing Service Console and VMkernel Settings . . . . . . . . . . . . . . . . . . . . 105

Exercise 2.6 Editing the Service Console Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Exercise 3.1 Creating a Claim Rule for Masking a LUN . . . . . . . . . . . . . . . . . . . . . . . . . 125

Exercise 3.2 Configuring the iSCSI Software Initiator . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Exercise 3.3 Configuring VMkernel Port Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Exercise 3.4 Creating an NFS Datastore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Exercise 3.5 Creating a New VMFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Exercise 3.6 Attaching an Existing Datastore to a New ESX Host . . . . . . . . . . . . . . . . 156

Exercise 3.7 Grouping Datastores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Exercise 3.8 Unmounting a Datastore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Exercise 3.9 Deleting a Datastore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Exercise 3.10 Spanning a VMFS Volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Exercise 4.1 Calculating the vCenter Database Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Exercise 4.2 Installing vCenter Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Exercise 4.3 Installing the vCenter Guided Consolidation Module . . . . . . . . . . . . . . . 194

Exercise 4.4 Installing the vCenter Converter Module . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Exercise 4.5 Joining Two vCenter Servers with Linked Mode . . . . . . . . . . . . . . . . . . . 197

Exercise 4.6 Joining an ESX Host to vCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Exercise 4.7 Creating a Snapshot Scheduled Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Exercise 4.8 Creating a Permission in vCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

Exercise 4.9 Creating a Role from Scratch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

Exercise 4.10 Cloning an Existing Role and Editing It . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

xxvi Table of Exercises

Exercise 5.1 Creating a Typical New Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Exercise 5.2 Creating a VM Using Custom Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Exercise 5.3 Creating a Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

Exercise 5.4 Deploying a VM from a Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

Exercise 5.5 Building a vApp and Editing Its Properties . . . . . . . . . . . . . . . . . . . . . . . . 289

Exercise 6.1 Installing VUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Exercise 6.2 Installing the Client Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

Exercise 6.3 VUM Snapshot Policy Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314

Exercise 6.4 VUM ESX Server Retry Policy Configuration . . . . . . . . . . . . . . . . . . . . . . 315

Exercise 6.5 Setting Up Patch Download Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

Exercise 6.6 Installing the Update Manager Download Service . . . . . . . . . . . . . . . . . . 319

Exercise 6.7 Specifying Patches and Updates; Then Exporting and Importing . . . . . 322

Exercise 6.8 Creating a Fixed Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

Exercise 6.9 Attaching a Baseline to an Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

Exercise 6.10 Scanning an Object in the Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

Exercise 6.11 Remediating a Host with a Patch Baseline . . . . . . . . . . . . . . . . . . . . . . . . 335

Exercise 6.12 Remediating a VM with a Patch Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . 338

Exercise 6.13 Staging Patches on ESX Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

Exercise 6.14 Viewing Baseline Compliance Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

Exercise 6.15 Viewing Compliance Data for Inventory Objects . . . . . . . . . . . . . . . . . . . 343

Exercise 6.16 Creating or Deleting a Host Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

Exercise 6.17 Importing or Exporting a Host Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

Exercise 6.18 Editing a Host Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

Exercise 6.19 Attaching a Host Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

Exercise 7.1 VMotioning a VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

Exercise 7.2 Moving a VM to Another Datastore with Storage VMotion . . . . . . . . . . . 373

Exercise 7.3 Cold-Migrating a VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

Exercise 7.4 Taking a Snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

Exercise 7.5 Deleting a Snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

Exercise 7.6 Restoring a Snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385

Exercise 7.7 Installing a VDR Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387

Exercise 7.8 Adding a Virtual Disk to the Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392

Exercise 7.9 Installing the VDR Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395

Exercise 7.10 Formatting the Second Disk of the VDR Appliance . . . . . . . . . . . . . . . . . 396

Exercise 7.11 Creating a Backup Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398

Exercise 7.12 Restoring a VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

Table of Exercises xxvii

Exercise 8.1 Creating a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419

Exercise 8.2 Testing High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432

Exercise 8.3 Checking FT Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439

Exercise 8.4 Upgrading ESX Hosts with FT VMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440

Exercise 9.1 Creating a Connectivity Alarm for a Host . . . . . . . . . . . . . . . . . . . . . . . . . 462

Exercise 9.2 Setting Up an Email Server for vCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . 466

Exercise 9.3 Creating a Utilization Alarm for a VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471

Exercise 9.4 Creating an Advanced Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

Exercise 10.1 Viewing the Hardware Health Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500

Exercise 10.2 Exporting the ESX Diagnostic Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501

IntroductionThe VMware Certifi ed Professional on vSphere 4 (VCP4) certifi cation is the fi rst require-ment to be met for any IT professional administering a VMware vSphere infrastructure. Although there is only one test, the levels of expertise of a conceptual and administra-tive nature are formidable. When looking at the various resources that virtual machines require to run their respective applications, such as CPU processing, memory, network access, and disk I/O, it becomes readily apparent that the successful administrator needs skill sets that include working with server hardware, operating systems, networking, and storage.

VMware has always emphasized to its customers that server virtualization is multi-disciplinary, and the classes they offer provide the prospective certifi cation candidate with a range of topics that need to be thoroughly investigated. Many people come to the table with one or two resource skill sets, but not many have the background for all four. Given this fact, the courses and this Study Guide provide the information needed to grasp the different facets of the products and develop a conceptual understanding of what server virtualization means.

VMware does provide a basic study outline known as the “VMware Certifi ed Professional on vSphere 4 Blueprint” accessible on their website to help test candidates in their quest for certifi cation.

The Blueprint can be found here: http://mylearn.vmware.com/portals/certification/?ui=www. It can also be found later in this Introduction, in the section “VCP-410 Exam Blueprint .”

The Blueprint provides the candidate with additional tools and documents for further reading and understanding. With all these resources outlined in the Blueprint, it can be a daunting task to prepare for the VCP4 exam without some guidance. That is the purpose of this Study Guide. The authors have endeavored to provide concise information culled from the supporting documents, web pages, and community postings to bring into one book what you will need to pass the exam.

In addition to the topics discussed, the Study Guide provides many exercises for the exam candidate to practice and follow through what is being covered. Without these exercises, you may fi nd it diffi cult to understand how a particular feature or function behaves. These exercises reinforce what you are learning and give you reference points to specifi c topics to successfully pass the exam.

Using this Study Guide will help you prepare to pass the VMware Certifi ed Professional on vSphere 4 (VCP-410) exam.

http://mylearn.vmware.com/portals/certification/?ui=www


xxx Introduction

VMware Certified Professional on vSphere 4 (VCP4) ProgramThe VCP4 certifi cation program requires that you complete the following requirements to certify on vSphere 4 if you are new to VMware products or have a certifi cation older than VCP3:

Attend an authorized VMware courseNN

VMware vSphere: Install, Configure, ManageN

VMware vSphere: Fast TrackNN

VMware vSphere: TroubleshootingN

Take and pass the VCP4 examNN

Some candidates are already certifi ed on VMware Virtual Infrastructure 3 (VCP3). In those cases, you will need to complete the following requirements:

Attend the VMware vSphere: What’s New courseNN

Take and pass the VCP4 examN

If the candidate has attended an older VI3 course, but never taken the exam, then the requirements for VCP4 certifi cation are:

Attend the VMware vSphere: What’s New courseN

Take and pass the VCP4 examNN

VMware provides exam objectives to give you a general overview of possible areas of coverage on its exams . Keep in mind, however, that exam objectives are subject to change at any time without prior notice and at VMware’s sole discretion . Visit the VMware Education website (www.vmware.com/education) for the most current listing of exam objectives covered in the VCP4 Exam Blueprint .

Types of Exam QuestionsVMware, like other IT vendors, protects their exams through rigorous internal processes looking for exam cheaters and requiring the exam taker to have hands-on experience with their products. This is why one of the requirements to become a VCP4 is to attend a course. They are very much aware that some candidates will try to memorize test questions, instead of using their knowledge and experience using the products. By attending a course, you have a much better understanding of the wide range of features and functions that are a part of VMware vSphere 4.

VMware uses a variety of question formats. What you will actually see is based on which questions are selected from the pool of questions VMware relies on. Some questions may be multiple choice whereas others will require several “right” answers from a list. Some questions will have exhibits to simulate a situation and require that you have experi-ence working with the product.

http://www.vmware.com/education

Introduction xxxi

VMware regularly adds and removes questions from the pool of possible questions that any exam candidate may see . VMware will also take steps to ensure that if you are taking the test more than once, due to an exam failure, you will not be given the same questions . In addition, if you fail to pass the exam, you must wait seven days before attempting the exam again .

There are 85 questions on the test, and you will have 90 minutes to answer those ques-tions. There is an additional 15 minutes for a survey and related test agreements. If English is not your native language, an additional 30 minutes can be granted. Work with Pearson VUE (www.pearsonvue.com/vmware) if you have questions related to the exam location or the amount of time you require.

Tips for Taking the VMware Certified Professional on vSphere 4 (VCP4) ExamHere are some general tips for achieving success on your certifi cation exam:

Arrive early at the exam center so that you can relax and review your study materials. NN

During this final review, you can look over tables and lists of exam-related information.

Read the questions carefully. Don’t be tempted to jump to an early conclusion. Make NN

sure you know exactly what the question is asking.

Answer all questions. If you are unsure about a question, mark it for review and come NN

back to it at a later time.

For questions you’re not sure about, use a process of elimination to get rid of the obvi-NN

ously incorrect answers first. This improves your odds of selecting the correct answer when you need to make an educated guess.

Exam RegistrationYou may take the VMware exam at any of the more than 5,000 authorized Pearson VUE testing centers around the world. For the location of a testing center near you, use the web-site www.pearsonvue.com/vmware or call Pearson VUE at 800-676-2797. Outside the United States and Canada, contact your local Pearson VUE registration center.

The number of the exam you want to take is VCP410. Register with the Pearson VUE registration center nearest to you. At this point, you will be asked for advance payment for the exam. The exam is $175, and you must take the exam within one year of payment. You can schedule an exam several weeks in advance or the day of the exam, as long as there is availability at the testing center. You can cancel or reschedule your exam if you contact the center at least one working day prior to the exam.

You may also register for your exams online at www.pearsonvue.com/vmware . Be sure to select VMware in the Test Taker Services section of the website .

http://www.pearsonvue.com/vmware



xxxii Introduction

When you schedule the exam, you will be provided with instructions regarding appoint-ment and cancellation procedures, ID requirements, and information about the testing center location. As a new security measure at many testing locations, you may have your photograph taken the day of the test and the photo attached to the test report at the end of the exam. In addition, you will receive a registration and payment confi rmation letter from Pearson VUE.

VMware requires certifi cation candidates to accept the terms of a nondisclosure agreement before taking certifi cation exams.

Is This Book for You?If you want to acquire a solid foundation in VMware vSphere 4 and your goal is to prepare for the exam by learning how to use and manage the new virtual infrastructure, this book is for you. You’ll fi nd clear explanations of the fundamental concepts you need to grasp and plenty of help to achieve the high level of professional competency you need to be successful with VMware virtualization.

However, if you just want to attempt to pass the exam without really understanding VMware vSphere 4, this Study Guide is not for you. It is written for people who want to acquire hands-on skills and in-depth knowledge of VMware vSphere 4.

What’s in the Book?What makes a Sybex Study Guide the book of choice for many VCPs? We took into account not only what you need to know to pass the exam, but what you need to know to take what you’ve learned and apply it in the real world. Each book contains the following:

Objective-by-Objective Coverage of the Topics You Need to Know Each chapter includes a list of the objectives it covers.

The topics covered in this Study Guide map directly to VMware’s official exam objectives (VMware vSphere 4 Exam Blueprint) . Each exam objective is covered completely .

Assessment Test Directly following this introduction is an assessment test that you should take. It is designed to help you determine how much you already know about VMware vSphere 4. Each question is tied to a topic discussed in the book. Using the results of the assessment test, you can fi gure out the areas where you need to focus your study. Of course, we do recom-mend you read the entire book.

Exam Essentials To highlight what you learn, you’ll fi nd a list of Exam Essentials at the end of each chapter. The Exam Essentials section briefl y highlights the topics that need your particular attention as you prepare for the exam.

Introduction xxxiii

Glossary Throughout each chapter, you will be introduced to important terms and concepts that you will need to know for the exam. These terms appear in italic within the chapters, and at the end of the book, a detailed glossary gives the definitions for these terms as well as other general terms you should know.

Review Questions, Complete with Detailed Explanations Each chapter is followed by a set of review questions that test what you learned. The questions are written with the exam in mind, meaning they are designed to have the same look and feel as what you’ll see on the exam. Question types are just like the exam, including multiple choice, exhibits, and select-and-place.

Hands-on Exercises In each chapter, you’ll find exercises designed to give you the important hands-on experience that is critical for your exam preparation. The exercises support the topics of the chapter, and they walk you through the steps necessary to per-form a particular function.

Real World Scenarios Because reading a book isn’t enough for you to learn how to apply these topics in your everyday duties, we have provided Real World Scenarios in special side-bars. These explain when and why a particular solution would make sense, in a working environment you’d actually encounter.

Interactive CD Every Sybex Study Guide comes with a CD complete with additional questions, flashcards for use with an interactive device, and the book in electronic format. Details are in the following section.

What’s on the CD?With this new member of our best-selling Study Guide series, we are including quite an array of training resources. The CD offers bonus exams and flashcards to help you study for the exam. We have also included the complete contents of the Study Guide in electronic form. The CD’s resources are described here:

The Sybex online PDF for VMware vSphere 4 Many people like the convenience of being able to carry their whole Study Guide on a CD. They also like being able to search the text via computer to find specific information quickly and easily. For these reasons, the entire contents of this Study Guide are supplied on the CD, in PDF. We’ve also included Adobe Acrobat Reader, which provides the interface for the PDF contents as well as the search capabilities.

The Sybex Test Engine This is a collection of multiple-choice questions that will help you prepare for your exam. There are four sets of questions:

Two bonus exams designed to simulate the actual live exam.NN

All the questions from the Study Guide, presented in a test engine for your review. NN

You can review questions by chapter or by objective, or you can take a random test.

The assessment test.NN

xxxiv Introduction

Here is a sample screen from the Sybex test engine:

Sybex Flashcards for PCs The “flashcard” style of question offers an effective way to quickly and efficiently test your understanding of the fundamental concepts covered in the exam. The Sybex Flashcards consist of over 100 questions presented in a special engine developed specifi-cally for this Study Guide series. Here’s what the Sybex Flashcards interface looks like:

Introduction xxxv

Hardware and Software RequirementsYou should verify that you have access to the servers for installing ESX/ESXi and vCenter Server. We suggest you use VMware Workstation 7 to create the virtual machines for install-ing ESX/ESXi and vCenter Server.

The exercises in this book assume that you can successfully install ESX/ESXi and vCenter Server on physical hardware or in virtual machines using VMware Workstation 7. Please see Chapter 1 for the physical hardware requirements for these servers. If you are using virtual machines, you can search online for various public documents on how to install using virtual machines.

Contacts and ResourcesTo fi nd out more about VMware educational materials and programs, to register with Pearson VUE, or to obtain other useful certifi cation information and additional study resources, check the following resources:

VMware Educational Services

www.vmware.com/education

This website provides information about the VCP program and exams. You can also download the latest VCP4 Exam Blueprint.

Pearson VUE

www.pearsonvue.com/vmware

800-676-2797

Contact Pearson VUE to register to take an VCP exam at any of more than 5,000 Pear-son VUE Testing Centers around the world.

VCP-410 Exam BlueprintTo prepare for and pass the VCP-410 exam, VMware expects you to have a general knowl-edge a variety of topics, as outlined in the following exam blueprint:

At the beginning of this book, you may have noticed a tear-out card mapping the main domains to the book . This is a more detailed list of objectives .



xxxvi Introduction

Section 1—Plan, Install and Upgrade VMware ESX/ESXi

Objective 1.1—Install VMware ESX/ESXi on local storage

Knowledge

Identify minimum hardware requirementsNN

Download, prepare and validate installation mediaNN

Determine appropriate ESX/ESXi configuration in a given situationNN

Obtain required information for environmentNN

Verify hardware against the VMware Hardware Compatibility GuideNN

Perform a custom installationNN

Customize storage layout for given situationsNN

Configure ESXi from the direct consoleNN

Configure ESX/ESXi NTPNN

Manage ESX/ESXi licensingNN

Compare/Contrast VMware vSphere editionsNN

Manage license keysNN

Tools

VMware Hardware Compatibility GuideNN

VMware ESX/ESXi and vCenter Server Installation GuideNN

Configuration Maximums GuideNN

Product DocumentationNN

VMware Virtualization ToolkitNN

Objective 1.2—Upgrade VMware ESX/ESXi

Knowledge

Plan a VMware vSphere upgradeNN

Backup/Restore ESX/ESXi host configurationNN

Understand Virtual Machine backup optionsNN

Determine if existing hardware meets upgrade requirementsNN

Understand VMware ESX/ESXi upgrade scenariosNN

Perform upgrade to ESX 4.0NN

Upgrade VMware ESX/ESXiNN

Introduction xxxvii

Upgrade virtual machine hardwareNN

Upgrade VMware ToolsNN

Verify success of upgradeNN

Understand upgrade roll back optionsNN

Tools

vSphere Host Update UtilityNN

vCenter Update ManagerNN

vSphere Upgrade GuideNN

ESX 4 Patch Management GuideNN


esxupdateNN

Objective 1.3—Secure VMware ESX/ESXi

Knowledge

Identify default security principlesNN

Understand Service Console firewall operationNN

Service Console Security LevelNN

Opening/Closing ports in the firewall using the vSphere ClientNN

Set up user/group accountsNN

Determine applications needed for accessing the service console in a given scenarioNN

Tools

vSphere ClientNN

ESX/ESXi Configuration GuidesNN


Objective 1.4—Install VMware ESX/ESXi on SAN Storage

Knowledge

Configure LUN MaskingNN

Prepare SANNN

Configure FC or iSCSI HBA BIOSNN

Enable BIOSNN

Select Boot LUNNN

xxxviii Introduction

Install VMware ESX/ESXiNN

Determine boot LUN size in a given situationNN

Tools

FC or iSCSI HBA BIOS ToolsNN

FC SAN Configuration GuideNN

iSCSI SAN Configuration GuideNN


Objective 1.5—Identify vSphere Architecture and Solutions

Knowledge

Differentiate VMware platform products and editionsNN

Understand the various datacenter solutions (View, SRM, Lab Manager, etc.)NN

Explain ESX/ESXi architectureNN

Compare and contrast bare metal vs. hosted architectureNN

Tools

Introduction to VMware vSphere GuideNN


VMware vSphere Editions Comparison ChartNN

Section 2—Configure ESX/ESXi Networking

Objective 2.1—Configure Virtual Switches

Knowledge

Understand Virtual Switch and ESX/ESXi NIC and port maximumsNN

Determine the vSwitch NIC teaming policy in a given situationNN

Determine the appropriate vSwitch security policies in a given situationNN

Create/Delete Virtual SwitchesNN

Create Ports/Port GroupsNN

Assign Physical AdaptersNN

Modify vSwitch NIC Teaming and failover policiesNN

Modify vSwitch security policy and VLAN settingsNN

Configure VMotionNN

Introduction xxxix

Tools



VMware vSphere ClientNN

Objective 2.2—Configure vNetwork Distributed Switches

Knowledge

Understand ESX Host and port maximums for dvSwitchesNN

Determine the virtual port group NIC teaming and fail-over policy in a given situationNN

Determine the appropriate virtual port group security policies in a given situationNN

Create/Modify a vNetwork Distributed SwitchNN

Create/Modify Uplink Group settingsNN

Create/Modify dvPort Group settingsNN

Add an ESX/ESXi Host to a vNetwork Distributed SwitchNN

Add/Delete a VMkernel dvPortNN

Migrate Virtual Machines to a vNetwork Distributed SwitchNN

Tools




Objective 2.3—Configure VMware ESX/ESXi Management Network

Knowledge

Modify Service Console IP SettingsNN

Configure Service Console availabilityNN

Configure DNS and Routing settings for an ESX HostNN

Tools




xl Introduction

Section 3—Configure ESX/ESXi Storage

Objective 3.1—Configure FC SAN Storage

Knowledge

Identify FC SAN hardware componentsNN

Identify how ESX Server connections are made to FC SAN storageNN

Describe ESX Server FC SAN storage addressingNN

Describe the concepts of zoning and LUN maskingNN

Configure LUN maskingNN

Scan for new LUNsNN

Determine and configure the appropriate multi-pathing policyNN

Differentiate between NMP and third-party MPPNN

Tools




Objective 3.2—Configure iSCSI SAN Storage

Knowledge

Identify iSCSI SAN hardware componentsNN

Determine use cases for hardware vs. software iSCSI initiatorsNN

Configure the iSCSI Software InitiatorNN

Configure Dynamic/Static DiscoveryNN

Configure CHAP AuthenticationNN

Configure VMkernel port binding for iSCSI Software multi-pathingNN

Discover LUNsNN

Identify iSCSI addressing in the context of the hostNN

Tools



Introduction xli


esxcliNN

Objective 3.3—Configure NFS Datastores

Knowledge

Identify the NFS hardware componentsNN

Explain ESX exclusivity for NFS mountsNN

Configure ESX/ESXi network connectivity to the NAS deviceNN

Create an NFS DatastoreNN

Tools




Objective 3.4—Configure and Manage VMFS Datastores

Knowledge

Identify VMFS file system attributesNN

Determine the appropriate Datastore location/configuration for given virtual NN

machines

Determine use cases for multiple VMFS DatastoresNN

Create/Configure VMFS DatastoresNN

Attach existing Datastore to new ESX hostNN

Manage VMFS DatastoresNN

Group/Unmount/Delete DatastoresNN

Grow VMFS volumesNN

Tools




xlii Introduction

Section 4—Install and Configure vCenter Server

Objective 4.1—Install vCenter Server

Knowledge

Identify hardware requirementsNN

Understand configuration maximumsNN

Determine availability requirements for a vCenter server in a given situationNN

Determine appropriate vCenter Server editionNN

Determine database size requirementsNN

Prepare/Configure vCenter Server databaseNN

Install vCenter Server using downloaded installerNN

Install additional modulesNN

vCenter Guided ConsolidationNN


vCenter ConverterNN

Determine use case for vCenter Linked Mode GroupsNN

Tools

ESX/ESXi and vCenter Server Installation GuidesNN


Database Sizing Tool/CalculatorsNN

Objective 4.2—Manage vSphere Client plug-ins

Knowledge

Identify available plug-insNN

Determine required plug-ins for a given applicationNN

Ensure permissions to install plug-insNN

Enable plug-ins after installationNN

Tools



vSphere ClientNN

Introduction xliii

Objective 4.3—Configure vCenter Server

Knowledge

Identify the vCenter Server managed ESX Hosts and Virtual Machine maximumsNN

Join ESX/ESXi Hosts to vCenter ServerNN

Configure Guest OS CustomizationNN

Use datacenters and folders to organize the environmentNN

Configure/Use Scheduled TasksNN

Configure/Use Resource MapsNN

Use Storage Reports/Storage MapsNN

View/Manage EventsNN

Configure vCenter Server settingsNN

Configure vSphere Client settingsNN

Tools

vSphere Basic System Administration GuideNN


vSphere ClientNN

Objective 4.4—Configure Access Control

Knowledge

Create/Modify user permissions in vCenterNN

Create/Modify user permissions in ESX ServerNN

Restrict access to vCenter inventory objectsNN

Define vCenter predefined roles and their privilegesNN

Create/Clone Edit rolesNN

Assign roles to users and groupsNN

Describe how privileges propagateNN

Understand permissions as applied to user and group combinationsNN

Tools



vSphere ClientNN

xliv Introduction

Section 5—Deploy and Manage Virtual Machines and vApps

Objective 5.1—Create and Deploy Virtual Machines

Knowledge

Understand virtual machine hardware maximumsNN

Create a virtual machineNN

Determine appropriate SCSI adapterNN

Determine Virtual Disk typeNN

Install/Upgrade/Configure VMware ToolsNN

Create/Convert templatesNN

Customize Windows/Linux virtual machinesNN

Manage Customization SpecificationsNN

Deploy a virtual machine from a templateNN

Deploy a virtual machine using VMware vCenter Converter EnterpriseNN

Perform a Hot CloneNN

Perform a Cold CloneNN

Perform System ReconfigurationNN

Deploy a virtual machine using Guided ConsolidationNN

Perform DiscoveryNN

Analyze discovered virtual machinesNN

Consolidate selected virtual machinesNN

Clone a virtual machineNN

Import a virtual machine from a file/folderNN

Tools



vSphere ClientNN

Introduction xlv

Objective 5.2—Manage Virtual Machines

Knowledge

Configure/Modify virtual machinesNN

Add/Hot Add virtual machine hardwareNN

Grow virtual machine disksNN

Determine appropriate disk formatNN

Connect virtual machines to devicesNN

Configure virtual machine optionsNN

General OptionsNN

Advanced OptionsNN

Power Management OptionsNN

VMware Tools OptionsNN

Configure appropriate virtual machine resource settingsNN

Tools



vSphere ClientNN

Objective 5.3—Deploy vApps

Knowledge

Determine whether a vApp is appropriate for a given situationNN

Define Open Virtual Machine Format (OVF)NN

Import/Export a Virtual ApplianceNN

Build a vAppNN

Create/Add virtual machines to a vAppNN

Edit vApp PropertiesNN

Export vAppsNN

Clone a vAppNN

xlvi Introduction

Tools



vSphere ClientNN

OVF ToolNN

Section 6—Manage Compliance

Objective 6.1—Install, Configure and Manage VMware vCenter Update Manager

Knowledge

Determine installation requirements and database sizingNN

Install Update Manager Server and Client componentsNN

Configure update manager settingsNN

Configure patch download optionsNN

Create baselinesNN

Attach baselines to vCenter inventory objectsNN

Scan ESX hosts and virtual machinesNN

Remediate ESX hosts and virtual machinesNN

Stage ESX/ESXi Host updatesNN

Analyze compliance information from a scanNN

Tools

VMware vCenter Upgrade Manager Administration GuideNN


Update Manager Database Sizing ToolsNN

Objective 6.2—Establish and Apply ESX Host Profiles

Knowledge

Create/Delete Host ProfilesNN

Import/Export Host ProfilesNN

Edit Host Profile PoliciesNN

Introduction xlvii

Associate an ESX host with a host profileNN

Check for ComplianceNN

Apply Host ProfilesNN

Analyze configuration compliance information from a scanNN

Tools



vSphere ClientNN

Section 7—Establish Service Levels

Objective 7.1—Create and Configure VMware Clusters

Knowledge

Create new clusterNN

Add ESX/ESXi hosts to a clusterNN

Configure High Availability basic/advanced settingsNN

Enable/Configure VM MonitoringNN

Configure Distributed Resource Scheduler basic/advanced settingsNN

Configure Distributed Power ManagementNN

Configure Enhanced VMotion CompatibilityNN

Configure swap file locationNN

Analyze HA host failure capacity requirementsNN

Analyze HA admission controlNN

Determine use cases for DRS automation levels and migration thresholdsNN

Determine use cases for DPM policiesNN

Tools

vSphere Availability GuideNN

vSphere Resource Management GuideNN


vSphere ClientNN

xlviii Introduction

Objective 7.2—Enable a Fault Tolerant Virtual Machine

Knowledge

Identify FT restrictionsNN

Evaluate FT use casesNN

Set up an FT networkNN

Verify requirements of operating environmentNN

Enable FT for a virtual machineNN

Test an FT configurationNN

Upgrade ESX hosts containing FT virtual machinesNN

Tools



vSphere ClientNN

Objective 7.3—Create and Configure Resource Pools

Knowledge

Determine Resource Pool requirements for a given situationNN

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

Evaluate virtual machines for a given Resource PoolNN

Create Resource PoolsNN

Set CPU resource shares/reservations/limitsNN

Set memory resource shares/reservations/limitsNN

Define Expandable ReservationNN

Add virtual machines to poolNN

Describe resource pool hierarchyNN

Tools



vSphere ClientNN

Introduction xlix

Objective 7.4—Migrate Virtual Machines

Knowledge

Identify compatibility requirementsNN

Cite the three methods of virtual machine migrationNN

Understand/ApplyNN

Determine migration use casesNN

Compare and contrast migration technologiesNN

Migrate a virtual machine using VMotionNN

Migrate a virtual machine using Storage VMotionNN

Cold migrate a virtual machineNN

Tools



vSphere ClientNN

Objective 7.5—Backup and Restore Virtual Machines

Knowledge

Describe different back-up/restore procedures and strategiesNN

Create/Delete/Restore SnapshotsNN

Install Backup and Recovery ApplianceNN

Install vCenter Data Recovery plug-inNN

Create a backup job with vCenter Data RecoveryNN

Perform test and actual restores using vCenter Data RecoveryNN

Tools

VMware Data Recovery Administration GuideNN


vSphere ClientNN

Backup and Recovery ApplianceNN

l Introduction

Section 8—Perform Basic Troubleshooting and Alarm Management

Objective 8.1—Perform Basic Troubleshooting for ESX/ESXi Hosts

Knowledge

Understand general ESX Server troubleshooting guidelinesNN

Troubleshoot common installation issuesNN

Monitor ESX Server system healthNN

Understand how to export diagnostic dataNN

Tools



vSphere ClientNN

Objective 8.2—Perform Basic Troubleshooting for VMware FT and Third-Party Clusters

Knowledge

Analyze and evaluate VM population for maintenance mode considerationsNN

Understand manual Third-Party failover/failback processesNN

Troubleshoot Fault Tolerance partial or unexpected failoversNN

Tools



vSphere ClientNN

Objective 8.3—Perform Basic Troubleshooting for Networking

Knowledge

Verify VM is connected to the correct port groupNN

Verify port group settings are correctNN

Verify that the network adaptor is connected within the VMNN

Introduction li

Verify VM network adaptor settingsNN

Verify physical network adaptor settingsNN

Verify vSphere network management settingsNN

Tools



vSphere ClientNN

ping, vmkping, tcpdump, nslookupNN

Objective 8.4—Perform Basic Troubleshooting for Storage

Knowledge

Identify storage contention issuesNN

Identify storage over-commitment issuesNN

Identify storage connectivity issuesNN

Identify iSCSI software initiator configuration issuesNN

Interpret Storage Reports and Storage MapsNN

Tools




vSphere ClientNN

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

Knowledge

Explain the requirements of HA/DRS and VMotionNN

Verify VMotion functionalityNN

Verify DNS settingsNN

Verify the service console network functionalityNN

Interpret the DRS Resource Distribution Graph and Target/Current Host Load DeviationNN

Troubleshoot VMotion using topology mapsNN

lii Introduction

Troubleshoot HA capacity issuesNN

Troubleshoot HA redundancy issuesNN

Tools




vSphere ClientNN

DRS Resource Distribution GraphNN

Topology MapsNN

cpuid, ping, vmkpingNN

Objective 8.6—Create and Respond to vCenter Connectivity Alarms

Knowledge

List vCenter default connectivity alarmsNN

List possible actions for connectivity alarmsNN

For a given alarm, analyze and evaluate the affected virtual infrastructure componentsNN

Create a vCenter connectivity alarmNN

Relate the alarm to the affected componentsNN

Tools



vSphere ClientNN

Objective 8.7—Create and Respond to vCenter Utilization Alarms

Knowledge

List vCenter default utilization alarmsNN

List possible actions for utilization alarmsNN

For a given alarm, analyze and evaluate the affected virtual infrastructure resourceNN

Create a vCenter utilization alarmNN

Relate the alarm to the affected resourceNN

Introduction liii

Tools


Product DocumentationN

esxtop/resxtopNN

Performance ChartsN

vSphere ClientNN

Objective 8.8—Monitor vSphere ESX/ESXiand Virtual Machine Performance

Knowledge

Identify critical performance metrics (e.g., CPU ready, queue depth, etc.)NN

Explain memory metrics (ballooning, shared, etc.)N

Explain CPU metrics (ready/wait time, etc.)NN

Explain network metrics (usage, packet drops, etc.)N

Explain storage metrics (latency, queuing, etc.)NN

Compare and contrast Overview and Advanced ChartsN

Create an Advanced ChartNN

Determine host performance using guest PerfmonN

Tools

vSphere Resource Management GuideN


esxtop/resxtopN

Performance ChartsNN

vSphere ClientN

Exam objectives are subject to change at any time without prior notice and at VMware’s sole discretion . Please visit VMware’s website (http://mylearn.vmware.com/portals/certification/?ui=www) for the most current blueprint .



liv Introduction

Assessment Test

1. Which of the following media is not supported as the source for installation of an ESX/ESXi server?

A. DVD

B. NFS

C. SMB/CIFS

D. HTTP/HTTPS

E. FTP

2. Which of the following is not supported as a destination when installing an ESX or ESXi server?

A. NFS

B. Local internal disk

C. SAN LUN

D. iSCSI LUN

3. Which of the following VMware products represents a bare-metal hypervisor as opposed to a hosted hypervisor?

A. Fusion

B. ESX/ESXi

C. Workstation

D. Player

E. Server

4. Which of the following is not a type of virtual switch?

A. Standard

B. Distributed

C. Hidden

D. VMkernel

5. Which of the following is not a valid function of a virtual switch in vSphere 4?

A. Spanning Tree

B. VMkernel

C. Service Console

D. Virtual machine

Introduction lv

6. Which of the following is not configurable on virtual switches?

A. Load balancing on a teamed virtual switch

B. Promiscuous packet mode

C. Inter-switch linking

D. Bandwidth traffic shaping (inbound or outbound)

7. Which of the following storage technologies are not supported as containers for the back-end files for running virtual machines?

A. Fibre SAN LUN

B. NFS NAS

C. iSCSI LUN

D. USB drive

E. ESX/i internal SCSI drive

8. Which of the following storage types will not take a VMFS filesystem?

A. SAN LUN

B. NFS

C. ESX/i internal disk

D. iSCSI LUN

9. Which of the following storage features is new to vSphere 4?

A. LUN masking

B. Third-party storage plug-ins

C. SAN LUN multipath support

D. iSCSI hardware initiator

10. Which of the following is a new feature in vCenter 4?

A. VUM plug-in

B. HA monitoring of individual VMs

C. Group-based roles

D. Linked mode

11. Which of the following is the new product that protects vCenter, providing high availability for the vCenter server and/or its back-end database?

A. vCenter Server Heartbeat

B. vCenter HA

C. DRS

D. vCenter Cluster Service

lvi Introduction

12. Which of the following databases is not recommended for high-end vCenter deployments?

A. SQL Server

B. IBM DB2

C. SQL Server Express

D. Oracle

13. Given a virtual machine, vmA, which of the following represents the file that stores the majority of vmA’s settings?

A. vmA.config

B. vmA.vmx

C. vmA.vmdk

D. vmA.nvram

14. Which of the following virtual hardware is not supported in a vSphere 4 VM?

A. USB thumb drive

B. 10 virtual NICs

C. Floppy drive

D. 8 virtual CPUs

15. Which of the following is not a feature or requirement of vApps?

A. vCenter is required.

B. vApps may contain multiple virtual machines.

C. vApps define resource settings.

D. vApps specify virtual machine failover.

16. Which vSphere 4 feature can be used to quickly apply groups of settings to new or existing ESX/i servers?

A. VUM

B. VCB

C. Data Recovery

D. Host profiles

17. Which of the following is not part of setting up vCenter Update Manager (VUM)?

A. Installing a vSphere Client plug-in

B. Installing Sysprep in Windows VMs

C. Setting up a download repository

D. Creating a baseline

Introduction lvii

18. Which of the following technologies complements vCenter Update Manager (VUM) when patching ESX/i servers?

A. DRS

B. HA

C. FT

D. VCB

19. Which of the following vSphere technologies could you use to move a virtual machine’s back-end files to a different datastore?

A. VMotion

B. FT

C. Storage VMotion

D. Cold migration

20. Which of the following is the new vSphere virtual machine backup product?

A. VMware Consolidated Backup (VCB)

B. Data Recovery

C. VMware Backup

D. Host profiles

21. Which of the following is not a requirement for using VMotion to move a running VM from one ESX server to another?

A. Single vCPU VMs

B. Shared storage

C. Compatible ESX CPUs

D. VMotion network

22. Which technology helps ease the pain of maintaining VMotion migration compatibility with newly purchased ESX/i servers?

A. DRS

B. HA

C. EVC

D. DPM

23. Which new feature in vSphere 4 allows you to leverage large variations in ESX server utilization to save on power and cooling costs?

A. DRS

B. DPM

C. vPower Management

D. EPM

lviii Introduction

24. Which of the following is not an Admission Control Policy with vSphere HA?

A. Percentage of cluster resources

B. Specify a (single) failover host

C. Host failures cluster tolerates

D. Total Resource Pool Reservations

25. Which of the following are new vSphere alarm features?

A. Sending a notification trap

B. Network connectivity alarm

C. Enabling and disabling alarms

D. Defining the alarm trigger frequency

26. Which of the following is not a defined action for vCenter 4 alarms?

A. Sending a notification email

B. Blinking the VMs icon in the vCenter inventory

C. Running a command/script

D. Suspending a VM

27. Which of the following metrics is one of the (if not the) primary identifier of a VM experi-encing a CPU performance bottleneck?

A. Ballooning

B. CPU Ready

C. CPU Wait

D. CPU Usage

28. What is the minimum recommended number of ESX/i hosts in a Fault Tolerant (FT) cluster?

A. 2

B. 3

C. 4

D. 8

29. Which of the following would not be a cause for a virtual switch/VM network connection problem?

A. VM is connected to the wrong port group.

B. The virtual switch is using the wrong uplink adapters.

C. On a teamed switch, the uplink adapters are from different vendors.

D. The VM’s vNIC is not connected to the virtual switch.

30. Which of the following is a potential problem with thin-provisioning of VMs?

A. Thin provisioning is only supported in test, evaluation, or demo environments.

B. Thin provisioning is not supported on ESX/ESXi servers.

C. Thin-provisioned disks cannot be changed to thick-provisioned disks.

D. You run out of storage space.

Introduction lix

Answers to Assessment Test

1. C. ESX/ESXi can be installed from a variety of media. In addition to the media listed here, ESXi may be installed from a USB flash drive and ESX/ESXi may be installed over the net-work (PXE) via a scripted install. For more information, see Chapter 1.

2. A. ESX can be installed onto a variety of destination media but not an NFS datastore. In addition, installing an ESX server onto (and therefore booting an ESX server from) an iSCSI LUN requires a hardware iSCSI initiator. For more information, see Chapter 1 (and Chapter 3 for information on iSCSI initiators).

3. B. The only current VMware virtualization product that uses a bare-metal hypervisor is ESX/ESXi; all the others are hosted products. For more information, see Chapter 1.

4. D. With vSphere 4, virtual switches now come in two basic varieties: vNetwork standard (these are the only type of virtual switches in previous releases of ESX/vCenter) and vNet-work distributed. The new vNetwork distributed switches are instantiated at each ESX server as hidden switches. For more information, see Chapter 2.

5. A. Virtual switches provide network functionality and can be used by the VMkernel (for VMotion, iSCSI storage access, NFS storage access, and VMkernel management on ESXi servers), the Service Console (for management on ESX but not ESXi servers), and by virtual machines (for general network access to both local and remote networks). Virtual switches do not support the Spanning Tree protocol. For more information, see Chapter 2.

6. C. Virtual switches have a number of configurable properties. Among them are Security settings (Promiscuous Mode, MAC Address Changing, Forged Transmits), inbound and outbound traffic shaping, selection of load-balancing policy, failover policy, port blocking, and many more. For more information, see Chapter 2.

7. D. Running virtual machines may have their back-end files stored on Fibre SAN LUNs, iSCSI SAN LUNs, NFS NAS datastores, and ESX/i internal stores (excluding USB, which is currently not supported for running virtual machines). For more information, see Chapter 3.

8. B. The Virtual Machine File System (VMFS) is only supported on block-level type devices, which include all of the options listed except NFS (which does not support an embedded block-level filesystem like VMFS). For more information, see Chapter 3.

9. B. New storage features in vSphere 4 include third-party storage plug-ins, two-way (bidirec-tional) iSCSI CHAP authentication, and per-target iSCSI CHAP authentication. For more information, see Chapter 3.

10. D. vSphere 4 adds several new features to vCenter, including Linked mode, whereby up to 10 vCenter servers can share information and, given proper permissions, allow administra-tors control over remote vCenter inventories. For more information, see Chapter 4.

11. A. vCenter Server Heartbeat is a new, unbundled product providing a clustering technology for protecting the vCenter Server service or its back-end database, or both. For more infor-mation, see Chapter 4.

lx Introduction

12. C. Although SQL Server Express can be used as the back-end database for vCenter 4, it is not recommended if you are managing more than five ESX/i servers or 50 virtual machines or are using vCenter in a production environment. For specific versions of the other supported databases, consult the current vCenter Installation Guide. For more information, see Chapter 4.

13. B. A virtual machine’s main configuration file ends in .vmx. This file contains the VM’s virtual parts list, configuration parameters, and other advanced settings. As a text file, the VMX file is also editable (if you so choose) using a standard text editor, although most administrators will confine their “editing” of this file to the vSphere GUI interface. For more information, see Chapter 5.

14. A. Although USB thumb drives are still not supported in vSphere 4.0 virtual machines, other virtual hardware enhancements had been made since the VI 3.x days. For example, vSphere 4 now supports up to 10 virtual NICs per VM (up from 4 in VI 3.x). For more information, see Chapter 5.

15. D. vApps are a new vCenter inventory container that may consist of several (related) VMs. vApps support various settings such as VM boot order, resource allocations, and IP alloca-tion policy. vApps themselves have nothing to do with failover but do not preclude its use. For more information, see Chapter 5.

16. D. Host profiles provide a way to change all or some of the settings you typically apply to new ESX/i servers. Firewall ports, IP information, licensing, virtual switch, and storage are all part of a host profile definition. Host profiles can be used to set up new ESX/i servers or reconfigure existing servers to a known state. For more information, see Chapter 6.

17. B. VUM requires installing a VUM (and download) server, adding a plug-in to both vCenter and the vSphere GUI Client, setting up enough storage (the download repository) to hold all the patches, and creating and then applying baselines to VMs and/or ESX/i servers. For more information, see Chapter 6.

18. A. When patching ESX/i servers, if you are running a Distributed Resource Scheduler (DRS) cluster in fully automatic mode, VUM having first placed the ESX/i server being patched into maintenance mode, DRS will use VMotion to automatically evacuate all VMs from the ESX/i server so that patching can proceed without any adverse effects on the VMs themselves. For more information, see Chapter 6.

19. C, D. VMotion moves a VM’s memory state and not its back-end files. FT (Fault Toler-ance) is used on mission-critical VMs to keep them running with zero downtime and zero data loss. Storage VMotion can be used to move a running VM’s files with no service inter-ruption to the VM itself. Cold migration moves a VM’s storage files while simultaneously changing the ESX server on which the VM is registered. Cold migration, however, requires the VM be powered off. For more information, see Chapter 7.

20. B. Data Recovery (as implemented in the new Data Recovery appliance) is the new vSphere backup solution for backing up running VMs. Data Recovery also leverages the new Data Recovery API available to third-party backup providers, allowing you to utilize their backup solutions. For more information, see Chapter 7.

Introduction lxi

21. A. VMotion has many requirements, but a single vCPU is not one of them. VMotion can be used to move a VM from one ESX server to another regardless of the number of vCPUs the VM has been configured with. Fault Tolerance, however, does have a single vCPU per VM requirement. For more information, see Chapter 7.

22. C. Enhanced VMotion Compatibility (EVC), first introduced in ESX 3.5 Update 2, allows you to build a DRS/HA cluster such that all ESX servers in the cluster are “throttled” to the cluster’s lowest CPU common denominator, helping you maintain VMotion compatibility as you purchase new ESX servers. For more information, see Chapter 8.

23. B. Distributed Power Management (DPM) is a new feature of DRS/HA clusters that, when ESX hardware utilization drops appropriately, consolidates VMs onto fewer ESX servers, placing the unused ESX servers into Standby mode and thus saving power and cooling costs. When utilization later increases, DPM brings the ESX servers back out of Standby mode to accommodate the increased load. For more information, see Chapter 8.

24. D. VMware High Availability (HA) Admission Control Policy choices have increased with vSphere 4. You now have three options: specify the percentage of cluster recourses dedicated to HA, specify a single failover host, or specify the number (up to four) of host failures the cluster can tolerate. In either case, an appropriate amount of cluster (CPU and memory) resources are reserved by HA and not available to running VMs. For more infor-mation, see Chapter 8.

25. B, C. vSphere has added many new alarm features. In addition to many new alarm types (network, storage categories, etc.), alarms can now be individually enabled and disabled. This means the default alarms no longer have to be removed from vCenter to be disabled! Sending SNMP notification traps and defining the alarm trigger frequency were both fea-tures of alarms prior to vSphere 4. For more information, see Chapter 9.

26. B. There has never been a blink the icon action for a vCenter alarm. For more information, see Chapter 9.

27. B. Interestingly enough, the CPU Ready number (sometimes shown as Ready or %RDY) is one of the better indicators of a VM waiting on CPU. A VM is in the Ready state when the VM itself is ready but all of the physical CPUs are busy. For more information, see Chapter 9.

28. B. As FT replicates a VM (down to memory and running CPU state) on two ESX hosts, having a third ESX host is recommended so that, in the event of the primary FT host fail-ing, you have an available host for re-replication of the FT VM. For more information, see Chapter 10.

29. C. Many things can cause a VM to lose virtual network connectivity. However, using physical uplinks from different vendors is generally not a problem. For more information, see Chapter 10.

30. D. Thin provisioning allows for overcommitment of your physical disks. Care must be taken so you do not run out of physical space over time. vCenter includes overcommitment alarms to help you avoid this problem when you choose thin provisioning. For more infor-mation, see Chapter 10.

Chapter

1Planning, Installing, and Upgrading VMware ESX/ESXi

VCP (VCP-410) EXAM OBjECTIVES COVERED IN ThIS ChAPTER:

Install VMware ESX/ESXi on local storageNÛ

Identify minimum hardware requirementsNN

Download, prepare and validate installation mediaNN

Determine appropriate ESX/ESXi configuration in a NN

given situation

Obtain required information for environmentNN

Verify hardware against the VMware Hardware NN

Compatibility Guide

Perform a custom installationNN

Customize storage layout for given situationsNN

Configure ESXi from the direct consoleNN

Configure ESX/ESXi NTPNN

Manage ESX/ESXi licensingNN

Compare/Contrast VMware vSphere editionsNN

Manage license keysNN

Upgrade VMware ESX/ESXiNÛ

Plan a VMware vSphere upgradeNN

Backup/Restore ESX/ESXi host configurationNN

Understand Virtual Machine backup optionsNN

Determine if existing hardware meets upgrade NN

requirements

Understand VMware ESX/ESXi upgrade scenariosNN

Perform upgrade to ESX 4 .0NN

Upgrade VMware ESX/ESXiNN

Upgrade virtual machine hardwareNN

Upgrade VMwareNN

Verify success of upgradeNN

Understand upgrade roll back optionsNN

Secure VMware ESX/ESXiNÛ



Service Console Security LevelNN

Opening/Closing ports in the firewall using the NN

vSphere Client


Determine applications needed for accessing the service NN

console in a given scenario

Install VMware ESX/ESXi on SAN StorageNÛ

Configure LUN MaskingNN

Prepare SANNN

Configure FC or iSCSI HBA BIOSNN

Enable BIOSNN

Select Boot LUNNN

Install VMware ESX/ESXiNN

Determine boot LUN size in a given situationNN

Identify vSphere Architecture and SolutionsNÛ

Differentiate VMware platform products and editionsNN

Understand the various datacenter solutions (View, SRM, NN

Lab Manager, etc .)

Explain ESX/ESXi architectureNN

Compare and contrast bare metal vs . hosted architectureNN

In this chapter, we’ll examine the relevant aspects of plan-ning, installing, and upgrading VMware ESX/ESXi servers. By following the VMware vSphere Exam Blueprint, Section 1,

we’ll explore fi ve objectives that the prospective exam taker will need to master before taking the exam.

First, we’ll cover topics such as minimum hardware requirements, downloading the installation media, assessing which version of ESX/ESXi is appropriate for a given environ-ment, confi guring the ESXi server from the local console, confi guring NTP, and comparing and confi guring licensing.

Next, we’ll explain how you can plan your upgrade from ESX 3.5 to vSphere 4, discuss upgrade strategies, demonstrate the upgrade process to ESX 4.0, show you how to verify a successful upgrade, and explore rollback scenarios.

Then, we’ll look at the default security setup on an ESX 4.0 server. We’ll explain how to work with the Service Console fi rewall and administer user and group accounts. We’ll also dis-cuss various client connectivity options you can use when working with the Service Console.

Next, we’ll cover using SAN masking options, preparing the storage array for use with ESX 4.0, working with FC or iSCSI HBA BIOS, installing ESX/ESXi on SAN storage, and understanding boot LUN sizing.

Finally, we’ll compare various VMware platform products and editions, explore the various solution products, and discuss ESX/ESXi architecture. You’ll also learn about hosted versus hypervisor-based VMware virtualization.

These objectives will concentrate on VMware ESX/ESXi servers only. VMware vCenter will be covered in Chapter 4, “Installing and Confi guring vCenter Server.”

Planning an ESX/ESXi InstallationThe fi rst basic task that a new VMware administrator undertakes is planning the instal-lation of the VMware ESX/ESXi server. In most cases, an administrator will plan out in minute detail a master server that will serve as a reference server for all other servers that come after it.

To begin, you must meet the hardware requirements for the VMware ESX/ESXi server. VMware ESX/ESXi servers now require 64-bit x86 processors.

As of this writing, processors from AMD (all Opterons) and Intel (Xeon 3000/3200, 3100/3300, 5100/5300, 5200/5400, 7000/7300, and 7200/7400 as well as Intel Nehalem) are supported .

4 Chapter 1 N Planning, Installing, and Upgrading VMware ESX/ESXi

Both installable versions require 2 GB of RAM at a minimum. Both require at least one or more gigabits or 10 GB Ethernet controllers.

Several storage controllers are supported, including basic Small Computer Systems Interface (SCSI) controllers, Redundant Array of Inexpensive Disks (RAID) controllers, Serial Advanced Technology Attachment (SATA) or Serial-Attached SCSI (SAS) controllers, Fibre Channel, and Internet SCSI (iSCSI) host bus adapters.

The final word on any specific hardware device comes from VMware’s online Compatibility Guides, which can be accessed from VMware’s website (http://www.vmware.com/resources/compatibility), as shown in Figure 1.1. There is also an alternative third-party VMware com-munity forum that allows vendors and users to list other hardware that works with ESX/ESXi. These posts cannot be verified by VMware and you must use discretion when considering their use.

Choosing the right version of ESX/ESXi can be somewhat confusing. Either version has the same functionality when it comes to virtualization and providing features such as High Availability (HA), Distributed Resource Scheduling (DRS), and VMotion. What may be a deciding factor is how and where the ESX host will be purchased and ultimately installed.

F I GU R E 1.1 VMware’s online Compatibility Guides

The standard edition of ESX must be installed by the end user. The installation of ESX will require some thought and planning, but it provides for potential flexibility since the Service Console is included. This allows the administrator to run local commands to properly config-ure and troubleshoot issues. The Service Console included with ESX 4.0 does not include the libraries needed to develop or compile agents or third-party software. This functionality has been moved to the vSphere command-line interface (CLI) package, the vSphere software devel-opment kit (SDK) for Perl, or the vSphere Management Assistant (vMA). Therefore, this may require that existing ESX 3.5 scripts and agents that currently run locally be rewritten to run remotely on the vMA applicance.

Several vendors provide ESXi in an embedded format. Purchasing a server with ESXi already installed allows the end user to quickly deploy a new server with the least amount of

http://www.vmware.com/resources/compatibility

http://www.vmware.com/resources/compatibility

Planning an ESX/ESXi Installation 5

effort. In addition, since this version does not have the Service Console, the security footprint is much smaller, and therefore deploying ESXi may provide a level of comfort and confidence in networks that are not as heavily shielded from attack. ESXi can also be installed from a downloaded ISO file, similar to the standard version but missing a Service Console.

Once the hardware and version requirements have been met for a specific environment, you must obtain the installation media. There are several ways to do so. Software vendors sell the CD media with the licenses. Many people download the software directly from VMware’s download section of the website, as shown in Figure 1.2. Be sure to download the most appropriate version for your environment.

F I GU R E 1. 2 Downloading the installation media

Once the media, in the form of an ISO file, has been saved, checking the media for errors is as simple as running an MD5 sum against the file and comparing it with the supplied MD5 sum published on VMware’s website, as you can see in Figure 1.3.

F I GU R E 1. 3 Verifying the checksum of the downloaded ISO file


Installing VMware ESX/ESXi on Local StorageInstalling ESX/ESXi on local storage is the preferred method for many administrators. This approach allows for local troubleshooting in case there is a storage area network (SAN) failure or interruption in SAN connectivity. ESXi can be purchased as an embedded option, and VMware does provide an installable version.

When installing the standard version of ESX, giving some thought to how the installa-tion media will be accessed is prudent. If you’ll be installing just a handful of hosts, using the DVD drive may be all that is necessary. Alternatively, storing the installation media on network-based servers can allow for simultaneous installations and provide scripting options to reduce the amount of direct interaction with the installer.

Here are some examples of the different installation methods:

DVDNN

FTPNN

HTTP/HTTPSNN

NFSNN

USB flash driveNN

There are also three ways to run the installer:

Interactive graphical (the default)NN

Interactive textNN

ScriptedNN

Another consideration before beginning the installation is your partitioning strategy. With ESX/ESXi, the Service Console no longer gets actual partitions on the local storage volume. A virtual disk (VMDK) file is created and stored on the local virtual machine file system (VMFS) partition.

Table 1.1 shows the VMkernel and Service Console partitions that are created during a default installation.

TA B lE 1.1 Default Partitions for ESX Server

Mount Point Type Size Location Description

/boot Ext3 1 .25 GB Physical partition

Where the Grand Unified Bootloader (GRUB) lives

Swap 600 MB by default, 1600 MB maximum

Virtual disk Used as memory when the Service Console has used all available physical RAM


Mount Point Type Size Location Description

/ Ext3 5 GB Virtual disk Contains the Service Console OS and where third-party software is installed

VMFS3 Esxconcole.vmdk, 1200 MB

Physical partition

Used to store virtual machines and the Service Console VMDK

vmkcore 110 MB Physical partition

VMkernel core dumps

/var/log Ext3 2000 MB Virtual disk Stores log files

If you select Advanced partitioning during the installation, you can create optional partitions. The need for these partitions is being phased out due to the retirement of the Service Console at some future date (ESXi is the fi rst product to eliminate the local Service Console and therefore eliminates the ability to install software or agents locally). Administrators should research the newer vMA appliance as an alternative to installing software or agents locally on the ESX server.

In Exercise 1.1, you’ll perform a custom ESX installation using the interactive graphical method. Pay particular attention to the new installation screens as they are quite different from ESX 3.5.

To practice the installation of ESX, try installing into a virtual machine . You can do so by using VMware Workstation 7 .0 and making sure the hardware you use allows for Intel VT or AMD-V to be enabled on the processor . You can find several how-to documents easily on the Internet that can walk you through the initial setup process when using this method .

E X E R C I S E 1 .1

Installing ESX on local Storage

1. Boot from the DVD media until you see the following screen . This screen is “timed,” and if you press nothing it will continue to the graphical installation automatically . Notice the options presented here . If the hardware you are installing to will not sup-port a graphical installation, select the text-based installation . The end result will be the same as the graphical installation .

TA B lE 1.1 Default Partitions for ESX Server (continued)


E X E R C I S E 1 .1 ( c ont inue d )

2. Click Next to proceed past the splash screen .

3. Accept the End User License Agreement (EULA) and then click Next .

4. Choose the appropriate keyboard layout; U .S . English is the default . Click Next .

5. Choose your storage . In most cases, you should only see local storage listed . If the ESX server is connected to other storage devices during the installation, they will appear as well . Please note that this step may not occur, based on your current setup . Be sure to select only the local storage device or volume, and then click Next .



6. Click Next on the Custom Drivers screen .

7. You can now enter the license number or choose to run ESX in Evaluation mode . Evaluation mode will give you 60 days to work with ESX with all features available . If 60 days elapses and you still have not converted to a proper license, you will lose all functionality . At that point, you will be forced to install a license before proceeding . Choose one method, and then click Next .



8. On the Network Configuration screen, choose from the drop-down menu the correct adapter that you will use to manage your server . This adapter will be used when creating the first virtual switch and will most likely be connected to the management network . Given that many servers will have multiple network ports to choose from, you should perform some testing to find the correct one during this selection process . If you’ll be using a virtual local area network (VLAN), check the box, supply the ID in the VLAN Settings field, and then click Next .

9. The next step is to provide the installer with the appropriate IP information . Also, use a fully qualified domain name (FQDN) for the server . A new Test These Settings button gives you the opportunity to find out if you selected the right network interface card (NIC) on the previous screen . Handy! Click Next .



10. On the next screen, the installer gives you an opportunity to use the default partition layout (Standard Setup) or customize (Advanced Setup) . With this edition of ESX, the need to customize the partition layout has been greatly reduced, as VMware is phas-ing out the need to install third-party tools or agents directly on the Service Console . Given this shift in philosophy, creating partitions like /tmp or /opt is not necessary, and the default partition strategy will suffice in most situations . A major change with this release is that the Service Console is encapsulated into a VMDK file instead of having access to actual partitions on the server . Click Next .

11. A dialog box will appear warning you about data loss due to formatting of the volume . Click OK .



12. Next, you will set the time zone . The new Time Zone Settings screen is more user friendly than the previous ESX 3 .5 version . Selecting the correct city to match the correct time zone is much easier . You also have the ability to choose the time zone by clicking the Advanced button . Choose your time zone and then click Next .

13. On the next screen is a new option to type in the Network Time Protocol (NTP) server to be used by ESX to synchronize the hardware clock . Although the graphic shows Internet time server, this will most likely be an internal server that provides NTP services to clients . If you wish to set up NTP services later, you can adjust the option manually . Click Next .

14. The next screen allows you to set the root password according to security policies implemented by your environment . Also, a secondary user can be created to allow for remote access to the ESX server with Secure Shell (SSH) sessions . Click Next when finished with this screen .



15. On the Summary screen, double-check your settings and choices to be sure they are correct . If you want to revisit an item, click the Back button until you reach the screen that needs to be corrected . All other screens will retain their choices and information automatically . If all looks well, click Next to begin the installation .



16. Once the installation has completed, click the Next button to proceed to the last screen .

17. On the last installation screen, take note of the URL listed . This will be used to connect to the ESX server and potentially download vSphere Client . Click Finish to reboot the server .

18. When the server begins the bootstrap process, a new menu is presented that is different from that in ESX 3 .5 .

19. Once the boot process finishes, the status screen is presented . One change here that is puzzling is the omission of the ESX server’s hostname or FQDN . Only the URL using the IP address is offered . By pressing Alt+F1, you can log into the local console .



20. Refer back to step 11 and use SSH to remotely log into the ESX server . The following graphic shows the Service Console’s encapsulated partitioning . The naming convention for the two files, esxconsole.vmdk and esxconsole-flat.vmdk, makes this clear .

21. To see the actual Linux partitions that are encapsulated in the esxconsole-flat.vmdk file, type vdf -h while using SSH to access the ESX server’s Service Console . The first three partitions are the standard Linux partitions created in default installations .

VMware ESXi Server comes in two versions: embedded and installable. The embed-ded version is “installed” directly on the server by the hardware vendor. The installable ESXi version is installed in a similar fashion as ESX, but the resulting server will not have a fully functional Service Console. The steps to install the ESXi installable version are in Exercise 1.2.

E X E R C I S E 1 . 2

Installing ESXi from the ISO File

1. Boot the server with the ESXi installable DVD or ISO and you will be presented with the Welcome screen shown here . You have three options on this screen: Cancel, Repair, and Install . If the system were to develop a corrupted file or if the ESXi server could not boot after a patch installation, choosing Repair may help in getting the server back to a consistent state . In this case, we’ll choose Install to begin a fresh installation of ESXi . Press Enter when you’re ready to proceed .


E X E R C I S E 1 . 2 ( c ont inue d )

2. Accept the EULA by pressing F11 .

3. The next screen will give you a choice in installation volumes . ESXi is only supported on SAS, SATA, and SCSI hard drives . Fibre Channel is supported experimentally at the time of this writing, and IP storage is not supported . Making sure all other storage is detached so that the only storage available is local is the best practice .

4. To start the installation, press F11 .

5. Once the installer finishes, a reboot is necessary .

6. After the reboot completes, an ESXi server has a completely different status screen than the Service Console edition . There are two options: pressing F2 to customize the system or pressing F12 to shut down or restart . Unlike with ESX Server, the installation hasn’t yet given you an opportunity to configure an IP address, hostname, or root pass-word . By pressing F2, you can do this .



7. The first step is to set a root password . Highlight Configure Password if necessary and press Enter .

8. Since this is your first opportunity to set a password, enter a password in the New Password field and again in the Confirm Password field . Then press Enter .



9. Next, highlight Configure Management Network on the list and press Enter . A dialog box appears that allows you to set up the IP and DNS configurations . Highlight IP Con-figuration and press Enter . The dialog box provides a choice to use DHCP or a static IP . Best practice is to always use a static IP . Other fields you must configure are the IP address of the management interface, the subnet mask, and the default gateway . Type that information and then press Enter .

10. Choose DNS Configuration by highlighting the option and pressing Enter . This takes you to the Configuration dialog box, where you can enter two DNS server IP addresses and the FQDN for the server . When you finish typing the information, press Enter .

11. Press Esc to go back to the System Configuration screen, arrow down to select Restart Management Network, and press Enter . By pressing Y to restart the manage-ment network, you’ll save all changes and additions .



12. Once the network management network is set up, press Esc to log out of the direct console . This will take you back to the ESXi status screen .

13. All other configuration settings, such as NTP and licensing, will need to be imple-mented by using your vSphere Client .

Once you’ve accomplished the basic installation of ESX/ESXi Server, you must com-plete three additional tasks: NTP setup, licensing, and creation of regular user accounts (ESX only). Each of these tasks can be configured using the vSphere Client and connecting to the ESX server.

Initiate the installation of vSphere Client by using the vSphere CD or by downloading and installing it from the home page of the newly installed ESX server (see Figure 1.4). Go to http://IP_address_ESX_server and click the link displayed at the top left of the page to begin the download and installation.

F I GU R E 1. 4 Installation of vSphere Client from http

http://IP_address_ESX_server


The installation of the vSphere Client is easy to follow, but there is one screen that is new and provides host updating on standalone hosts (servers not managed by vCenter Server). The vSphere Host Update Utility allows you to upgrade ESX 3.x and ESX 3.5i servers to ESX.4.0 and ESXi 4.0 servers. It may also be used to patch ESXi 4.0 servers. The utility was developed for environments that have 10 or fewer hosts and don’t have vCenter Server or VMware Update Manager. Figure 1.5 shows the check box you click to install this additional functionality.

F I GU R E 1.5 vSphere Host Update Utility check box

Keep in mind that the vSphere Client can be installed on any PC that you choose to use to connect to your ESX or vCenter servers. There is no limit on the number of installations of the client.

Now that the client is installed, you can launch the client to connect to the ESX server to finish the basic configuration, including NTP, licensing, and user account creation. The only user who can log into a freshly installed ESX server is root. In Exercise 1.3, we’ll show you how to configure NTP.

E X E R C I S E 1 . 3

Configuring NTP

1. Once logged in, you are presented with the Home view .



2. By clicking the Inventory icon in the Inventory panel, you can see your ESX server in the traditional format .



3. By clicking on the ESX server, you are presented with several tabs in the panel on the right . For this exercise, click the Configuration tab to access two of the remaining configuration tasks, NTP Setup and Licensing .

4. In the Software section on the left side of the panel, click the Time Configuration link to access the current NTP settings . Since the server was newly installed, there are no time servers listed . Click the Properties link in the top-right corner to add a time server to the ESX server’s configuration .



5. The NTP Client is already running, but by clicking the Options button, we can add a time server .

6. The NTP Daemon (ntpd) Options dialog box appears . Select NTP Settings option on the left, click Add, and type one or more time servers to synchronize the ESX server’s time . Click OK when finished .

7. Restart the NTP service by checking the Restart NTP Service To Apply Changes check box and click OK .



8. In the Time Configuration dialog box, click OK .

9. The NTP service should be running and the newly added time server should be listed . Keep the vSphere Client open .

Now would be a good time to add a proper ESX server license. Adding licenses to stand-alone hosts is not necessary, as they can be added later. Newly installed ESX servers have an evaluation period of up to 60 days. In most cases, you will be adding your ESX servers to vCenter and assigning licenses then. In rare instances, you can add licenses to single hosts individually. In Exercise 1.4, we’ll show you how to install standalone licenses.

E X E R C I S E 1 . 4

Installing Standalone licenses

1. While still viewing the ESX server’s informational panel on the right, click the Licensed Features link in the Software section .



2. Click the Edit link in the top-right corner to access the Assign License dialog box .

3. Evaluation mode gives you time to use the ESX server for a while before installing a license, but switching to a fully functional license now will be one less thing to keep track of . Click the Assign A New License Key To This Host radio button to activate the Enter Key button just below it . Click the Enter Key button, and the New License Key dialog box appears, which allows you to enter the 25-digit key .



4. Click OK and the new license should be ready to use . Click OK again to exit the dialog box .

5. The Licensed Features panel should now show an appropriate license and the fea-tures that are available to use . Leave the vSphere Client open .

You should explore the various license editions available to learn the differences between them. Each edition bundles a set of features and allows you to choose what works best for you. Table 1.2 summarizes those editions and features as of this writing.


TA B lE 1. 2 License Editions and Feature Bundles

Features Included EssentialsEssential Plus Standard Advanced Enterprise

Enterprise Plus

Limits on number of cores per CPU

6 6 6 6 6 12

VMware SMP 4-way 4-way 4-way 4-way 4-way 8-way

Limits on memory per host

256GB 256GB 256GB 256 GB 256 GB No license memory limit

VMware Thin Provisioning

Yes Yes Yes Yes Yes Yes

VMware vCenter Server Agent


VMware vCenter Update Manager


VMSafe Yes Yes Yes Yes Yes Yes

vStorage APIs Yes Yes Yes Yes Yes Yes

VMware HA Yes Yes Yes Yes Yes

VMware Data Recovery

Yes Yes Yes Yes

Hot Add Yes Yes Yes

VMware Fault Tolerence

Yes Yes Yes

vShield Zones Yes Yes Yes

VMware VMotion Yes Yes Yes

Storage VMotion Yes Yes

VMware DRS/DPM Yes Yes

VMware vNetwork Distributed Switch/Third-Party Switch Add-on

Yes


Features Included EssentialsEssential Plus Standard Advanced Enterprise

Enterprise Plus

3rd-Party Multipathing

Yes

VMware Host Profiles

Yes

The last configuration option, with respect to ESX Server and not ESXi, is to create at least one regular user account that allows access to the server remotely with SSH and the vSphere Client without having to use the root account. We’ll do this in Exercise 1.5.

This is a good best practice guideline that protects the root account from being used when not necessary. Many environments do not allow casual use of the root account and for SSH access, the root account is not allowed to log in remotely. A regular user account can facilitate better security precautions.

E X E R C I S E 1 . 5

Creating a Regular User Account

1. Click the Users & Groups tab in the information panel on the right . This will present you with two buttons, Users and Groups, that you can click to view, create, and modify users and groups on the ESX server . A little-known fact is that the Users & Groups tab is only visible when you’re connecting vSphere Client directly to the ESX host . When you’re connecting to vCenter, the only users and groups available will be domain users and groups .

2. By right-clicking a blank area on the panel, you can bring up a menu that will allow for the creation of a user . Select Add .

TA B lE 1. 2 License Editions and Feature Bundles (continued)



3. Once the Add New User dialog box appears, type the name of the user in both the Login and User Name fields, type a password in both the Password and Confirm fields, and then select the users group from the drop-down box . Click OK when finished .

4. Verify the creation of the new user in the User list .



5. The next step is to test the ability of the account to log into the ESX server with a remote client such as SSH . This is important as some tasks and most troubleshooting will need to use this account initially to access the ESX server remotely .

Upgrading VMware ESX/ESXiPlanning an upgrade of ESX/ESXi 3.5 to version 4.0 takes some time and a thorough knowledge of the tools needed. In many cases, customers will choose to install a fresh copy of ESX/ESXi 4.0. In doing so, however, they will lose many of the settings and policies for hosting virtual machines (VMs).

The exam will test your knowledge of the upgrade process and what tools can be used to complete a successful upgrade, not only of the ESX servers, but also the VMs. Although the proper starting point for a virtual infrastructure upgrade begins with Virtual Center 2.5, this section will emphasize upgrading ESX and upgrading the VMs’ virtual hardware and VMware tools.

In this section, we’ll look at the following aspects of upgrading:

Planning a VMware vSphere upgradeNN

Understanding the VMware ESX/ESXi upgrade processNN

Performing an upgrade to ESX 4.0 and an upgrade to the VMs’ virtual hardware and NN

VMware tools

Verifying the success of the upgradeNN

Understanding upgrade rollback optionsNN

Planning a VMware vSphere UpgradeAs mentioned earlier, planning an upgrade of your virtual infrastructure is just as impor-tant, if not more, than the actual upgrade itself. Because of this, VMware is testing each candidate’s knowledge of the upgrade process and several variations in that process.

Upgrading VMware ESX/ESXi 31

Backing Up and Restoring an ESX/ESXi Host ConfigurationOne of the first tasks in an ESX/ESXi upgrade process is to back up information on the ESX hosts prior to upgrading them to ESX/ESXi 4.0. There are several files and configuration set-tings that can be captured as a part of a host configuration backup. These include the follow-ing on an ESX server:

Back up several files, including NN /etc/passwd, /etc/group, /etc/shadow, and /etc/gshadow.

Back up any custom scripts that you use or have deployed locally.NN

Back up any NN .vmx files of virtual machines run locally.

Back up any local VM images, templates, and NN .iso files that may be stored on the local VMFS.

On an ESXi server, you can use the VMware Management Appliance(vMA) to capture host configuration data. Use the command vicfg-cfgbackup -s to save the host configura-tion to a file.

Understanding Virtual Machine Backup OptionsNext, a look at the virtual machines is necessary to see if they are ready for upgrading. The obvious first step is to make sure the VMs have a verifiable backup. There are many tech-niques for backing up VMs:

Install a backup agent on the Service Console and use the network to back up the files NN

that comprise the VM (.vmx, .vmdk, .NVRAM, vmware.log, and so forth).

Install a backup agent inside the VM and use the network to back up files or the NN

VM image.

Use VMware Consolidated Backup (VCB) and a third-party backup tool.NN

Use a SAN-based snapshot tool.NN

Installing a backup agent on the Service Console has been used as a backup method from almost the beginning of some VMware shops’ virtual infrastructure implementations, but it has several major drawbacks. First, the network load created on the Service Console competes with other types of management activities. Also, saturation is a very real pos-sibility given that most environments use one or two physical uplinks for Service Console management. There is also the problem of what to do after the upgrade to ESX 4.0, as the Service Console in ESX 4.0 is not suited for installing agents easily. Or if a customer decides to switch to ESXi 4.0, there is no Service Console for installation of an agent.

Taking the next possibility, anyone can install a typical backup agent into a VM and continue to use the hardware and network to back up files within a VM as they did for physical servers. In many cases, the backup infrastructure already existed and utilizing that infrastructure makes sense. There is one big drawback, though: with high levels of consoli-dation (running many VMs on one ESX host), the possibility of saturating a virtual switch and its uplinks increases. Staggering full backups and scheduling those backups to periods of low VM activity can mitigate some of the network bandwidth needed, but in larger envi-ronments, this may not be possible.


VCB is a tool provided by VMware to facilitate the backup of VMs. There are several pluses to using VCB:

When using a fiber-based SAN, the backup uses the fiber topology.NN

VCB takes a snapshot of the VM, with the possibility of quiescing the VM, before the NN

backup begins.

VCB utilizes a backup proxy server, therefore offloading the backup load to this server NN

and freeing the VM or the Service Console from a backup-based load.

VCB works with most third-party backup software.NN

Another possibility is to use SAN snapshot techniques to back up VMs stored there.

Determining if Existing Hardware Meets Upgrade RequirementsAnother planning consideration is whether or not the current hardware being used with ESX/ESXi 3.5 can be used with ESX/ESXi 4.0. From the very beginning, installing ESX server has required using and following the Hardware Compatibility List (HCL) to ensure a successful installation and to run VMs. When moving to ESX/ESXi 4.0, this is still very much the case. The following hardware requirements are needed to run ESX/ESXi 4.0:

64-bit processorNN

Known 64-bit processors:NN

All AMD OpteronsNN

All Intel Xeon 3000/3200, 3100/3300, 5100/5300, 5200/5400, 7100/7300, NN

and 7200/7400

All Intel Nehalem processorsNN

2 GB of RAM minimumNN

Network adaptersNN

One or more network adaptersNN

Intel or Broadcom gigabit controllersNN

SCSI adapter, Fibre Channel adapter, or internal RAID controllerNN

Installation and storageNN

SCSI disks, Fibre Channel logical unit number (LUN), or RAID LUNNN

Hardware iSCSINN

SAS drivesNN

SATA drives using a supported SAS controllerNN

ATA or IDE drives, using a supported controllerNN

Understanding Upgrade ScenariosThe next task is to ascertain whether or not the version of ESX/ESXi you have can be upgraded. Table 1.3 shows the various versions of ESX/ESXi that have existed and their ability to be upgraded.


TA B lE 1. 3 ESX Versions and Upgrade Support

ESX/ESXi Versions Upgrade Support

ESX alpha, beta, or RC releases (any) None

ESX 1 .x None

ESX 2 None

ESX 2 .1 None

ESX 2 .1 .1 None

ESX 2 .1 .2 None

ESX 2 .1 .3 None

ESX 2 .5 None

ESX 2 .5 .1 None

ESX 2 .5 .2 None

ESX 2 .5 .3 None

ESX 2 .5 .4 None

ESX 2 .5 .5 Limited support

ESX 3 .0 .0 Yes

ESX 3 .0 .1 Yes

ESX 3 .0 .2 Yes

ESX 3 .0 .3 Yes

ESX 3 .5 .x Yes

ESXi 3 .5 .x Yes


Upgrading ESX 2 .5 .5 is supported, but not directly . This is due to the small /boot partition used with this version, which, by default, is not large enough in most cases (<100 MB) . If the /boot partition was created using at least a 100 MB partition, upgrading the ESX 2 .5 .5 server to ESX 3 .x first and then upgrading to ESX 4 .0 is possible .

You should also study the published VMware upgrade scenarios (vSphere Upgrade Guide). There are several possible scenarios:

Upgrading with and without host clustersNN

Upgrading by moving VMs with VMotionNN

Upgrading by powering off or suspending VMs with vCenterNN

Upgrading by powering off or suspending VMs without vCenterNN

Upgrading to vCenter Server on a new machineNN

Consistent with each scenario is a set of steps that must be completed in a specifi c order. In addition, VMware does not support rolling back part of an upgrade with their tools. One exception to this is the ability to roll back an ESX server upgrade, but only when working with ESX 3.5.

Upgrading with and Without Host Clusters

A set of steps most be followed precisely as documented by VMware. To follow through with these steps, certain prerequisites most be in place:

You must be using Virtual Center 2.NN x.

You must be using VMware Update Manager (VUM).NN

All of the hosts must be ESX NN 3.x/ESXi 3.5.

Next are the steps needed to carry out the upgrade; here, we’ll use vCenter to perform many of these tasks. Again, follow these steps exactly in the order they are listed.

1. Upgrade Virtual Center 2.x to vCenter Server 4.0.

2. Install the new vSphere Client.

3. Upgrade VMware Enterprise Converter to vCenter Converter (only if needed).

4. Upgrade Guided Consolidation Planner to vCenter Guided Consolidations (only if needed).

5. Upgrade VMware Update Manager to vCenter Update Manager.

6. Use vSphere Host Update Utility 4.0 or vCenter Update Manager to upgrade ESX3.x hosts to ESX 4.0.

7. Use vCenter Update Manager to upgrade the VMware tools in the VMs.

8. Use vCenter Update Manager to upgrade the virtual hardware in the VMs.

9. Upgrade the product licenses.

In Exercise 1.6, we’ll show you how to use the vSphere Host Update Utility.


E X E R C I S E 1 . 6

Using the host Update Utility

1. Log into the vCenter server or where you have the vSphere Client installed with the vSphere Host Update Utility also installed .

2. Click Start All Programs VMware vSphere Host Update Utility 4 .0 .

3. Select the ESX server you wish to upgrade in the Host List section and then click Upgrade Host .

4. Enter the path to the ESX DVD ISO file or click Browse to locate the file . If you browsed to the file, click Open, and then click Next .

5. Accept the EULA by checking the I Accept The Terms Of The License Agreement box, and then click Next .



6. Enter the host credentials, which include the root account and password . Click Next . You may receive an error stating that the ESX server needs to be in Maintenance mode . If the ESX server is not yet in Maintenance mode, log into the ESX server with the vSphere Client and put the host into Maintenance mode before proceeding to the next step .

7. Next, select the local datastore that will be used to store the newly created Service Console .vmdk file . You need at least 8 .4 GB . Click Next .

8. In the Post Upgrade Options screen, select the check box Attempt To Reboot Host And Rollback Upgrade In Case Of Failure . If you have a postupgrade script, you can specify it here as well . Click Next .



9. Click Finish on the Ready to Complete screen . Watch the progress of the upgrade . If the upgrade fails, the rollback feature will be called upon and the server will be put back to its original ESX3 .5 setup .

10. If you are logged into the console while the upgrade is progressing, you can watch each step take place . You’ll find it very interesting the first time or two .



11. If all goes well, you’ll see the following screen, indicating that you have a newly upgraded ESX4 .0 server .

Securing VMware ESX/ESXi 39

If you want to upgrade many servers that are also being managed by vCenter, use the vCenter Update Manager to upgrade the ESX 3.5 servers.

Securing VMware ESX/ESXiThe security of an ESX/ESXi is made easier by the fact that both products are very secure out of the box. That is not to say that they cannot be made even more secure depending on circumstances. ESX, due to having a Service Console, has several options for the firewall, again depending on what services are enabled. ESXi doesn’t have much to configure, but we’ll take a look at Lockdown mode as a way to protect the root account.

Here are the topics covered on the VCP exam:



Service Console Security levelNN

Opening/closing ports in the firewall using the vSphere ClientNN


Determine applications needed for accessing the Service Console in a given scenarioNN

Identifying Default Security PrinciplesSecurity is near the top of any administrator’s list of objectives when working with servers and IT systems. vSphere provides you with a very secure environment on many different levels. When compared to physical systems, virtual machines are protected more effectively by inher-ent design and engineering principles built into the architecture of ESX/ESXi products.

When looking at ESX server and its security architecture, you’ll note four major design aspects:

The virtualization layerNN

The virtual machinesNN

The Service ConsoleNN

The network layerNN

Each of these contributes to the overall security of the virtual infrastructure. Let’s take a look at each design component and how they work together to improve security.

The Virtualization LayerWhat is probably the most described aspect of an ESX server is the virtualization layer, otherwise known as the VMkernel. The VMkernel was designed to allow VMs to run in secure memory worlds on each ESX server. The VMkernel is responsible for hardware access, scheduling, and resource allocation for the VMs. VMware has gone to great lengths to not include any code that does not enhance its primary purpose of running VMs.


There are two VMKernel protection features:

Memory hardeningNN

Kernel module integrityNN

Memory hardening takes the form of randomly loading or locating different compo-nents of the ESX server into memory, known as address space load randomization (ASLR). With the added protection for nonexecutable memory provided by microprocessors (NX/XD), the ability of malicious code to exploit certain components of an ESX server is greatly diminished.

Kernel module integrity is ensured by digitally signing modules, drivers, and applications as they are loaded into the ESX server’s memory by the VMkernel. With digital signing of modules, ESX can verify the provider of each module, driver, or application and whether each is certified by VMware.

Virtual MachinesFrom the beginning, VMware VMs have been loaded into memory into separate memory silos or worlds. This isolation has several benefits, but in a security context, it allows the VMs to run on the same ESX server but not impact another VM’s memory space. Each VM will be given access to hardware on a shared basis, but not be allowed to impact the perfor-mance or security of another VM.

Since each VM runs in a separate memory world, there is no way for an attacker with administrator access to the guest operating system to attack another VM on the same ESX host. And if the VM were to fail completely, the failure does not impact another VM on the same host.

Virtual machines can only interact with the virtual hardware they have been configured with and are not shown actual hardware or given access to physical hardware that would allow for changes to their configuration.

With the use of reservations and limits, VMs can be protected from each other in case one VM exploits resources to the detriment of others on the same host. If you limit a VM’s access to CPU or memory, a resource denial-of-service (DoS) attack can be largely miti-gated. Reservations allow each VM to perform as expected, even during a possible resource DoS attack by another VM.

Service ConsoleThe ESX server’s Service Console is based on a Linux distribution of Red Hat Enterprise 5.2. This management console allows for monitoring the performance of an ESX host and the VMs running on it. It also provides additional management of the host by using command-line based scripts or commands.

The Service Console is protected by a firewall, and VMware reduces areas of risk with the following strategies:

Only essential services run in the Service Console.NN

The firewall is set to high security, thus blocking all outbound ports and allowing only NN

inbound ports for interaction with the vSphere Client, SSH, and vCenter.


If additional services are installed on the Service Console, ports have to be opened NN

manually.

All communications between ESX servers and clients are SSL encrypted using SHA-1 NN

or RSA-based ciphers.

The Tomcat web service has been restricted to providing limited administration of NN

VMs and monitoring functions and is not vulnerable to most exploits.

VMware monitors several security websites and postings for newly discovered exploits; NN

if a Service Console exploit becomes known, VMware releases a patch.

Services such as FTP and Telnet are not installed due to their inherent lack of security.NN

Applications that use NN setuid or setgid flags have been minimized.

Virtual Networking LayerVirtual networking on an ESX server consists of a VM’s virtual network adapters and virtual switches in the VMkernel. The VMkernel has code that allows for communication between the VMs, iSCSI storage, NAS storage, and other hosts on the physical network using TCP/IP.

By utilizing network security techniques like VLANs, Layer 2 security policies, and fire-walls, ESX provides the basis for a very secure networking environment.

One example of what is possible is the creation of a demilitarized zone (DMZ) internally on the ESX server (see Figure 1.6).

F I GU R E 1.6 An internal DMZ network

Internal DMZ vSwitch

Outbound Public vSwitch

VM-a VM-b NAT Router VM

Physical Switch

Physical NICs


By using a firewall VM, you shield other VMs behind the firewall for protection, thus allowing an ESX server to be placed with one network interface on an external network and another network interface on a private LAN. Although many customer environments discourage such designs, the inherent network security of an ESX server makes it an ideal product for such placement.

Understanding Service Console Firewall OperationConfiguring the Service Console firewall has been made easy with the vSphere Client and the security profile on each ESX server (see Figure 1.7).

F I GU R E 1.7 Default security profile on an ESX Server

By opening a previously closed port for a particular service or agent, you can use the Service Console for other administrative tasks. One word of caution: the list of ports that can be opened by the graphical method is preset, meaning the list cannot be altered to dis-play other ports by the end user. If a port has be opened that is not on the list, you can use the command esxcfg-firewall -o to open it manually.

In Exercise 1.7, we’ll show you how to work with the ESX Service Console firewall.

E X E R C I S E 1 . 7

Working with the ESX Service Console Firewall

1. Log into vCenter with the vSphere Client .

2. Click on a host in the inventory panel .

3. Click the Configuration tab and then click the Security Profile link in the Software section .

4. Click Properties to open the following dialog box, which lets you make changes to the firewall:



5. Click to check the appropriate service or agent to enable firewall access .

6. Click OK .

Setting Up User and Group AccountsBy default, an ESX server provides only one user account for all administration: root. The root account is, by its very nature, the highest privileged user on an ESX server. Misuse of this account can be dangerous to the VMs running on the server or at the very least


detrimental to a properly functioning host. By creating at least one regular user account on the ESX host, you minimize direct usage of root.

One way to audit an ESX server is to export a list of the users and groups, which we’ll show you how to do in Exercise 1.8.

E X E R C I S E 1 . 8

Exporting a list of Users and Groups on ESX

1. Log into the ESX server with the vSphere Client .

2. Click the Users And Groups tab .

3. Click either the Users or the Groups button .

4. Right-click anywhere in the list or blank space and choose Export List .

5. Provide a path and name for the file .

6. Select the file type, and then click OK .

You don’t often have to create additional groups. The steps for doing so are similar to creating a user, but you would first have to click the Groups button on the Users And Groups tab.

Determining Applications Needed for Accessing the Service Console in a Given ScenarioThe administrator has several clients or applications that can be used to access an ESX server’s Service Console:

vSphere ClientNN

WebAccess using a browserNN

SSH ClientNN

Installing VMware ESX/ESXi on SAN Storage 45

Depending on the administrative task you want to perform, one application may be more useful than another. In general, use the vSphere Client to perform most tasks having to do with host and VM administration and configuration.

WebAccess would be used when the installation of the vSphere Client is not possible or if you only need to perform VM administration. WebAccess is limited to just VM administra-tion—changes to the ESX configuration are not possible using this tool.

Use the SSH Client when command-line access is required for running scripts or ESX-specific commands that perform functions or tasks that cannot otherwise be done with the vSphere Client.

Installing VMware ESX/ESXi on SAN StorageInstalling ESX/ESXi on SAN storage is a very real possibility for many customers. With the advent of blade hardware architectures, the need for having local storage has been replaced with booting from a SAN-based LUN. With ESX, Fibre Channel and iSCSI LUNs can be used as boot devices. With ESXi installable, Fibre Channel LUN support for booting is an experimental option and may be supported in future releases. iSCSI booting is not sup-ported with ESXi.

The installation topics covered on the VCP exam are as follows:

Configuring LUN maskingNN

Preparing SANNN

Configuring Fibre Channel or iSCSI HBA BIOS (enabling BIOS, selecting Boot LUN)NN

Installing VMware ESX/ESXiNN

Determining boot LUN size in a given situationNN

Configuring LUN MaskingWhen you’re working with storage arrays, LUN masking is one technique for applying access security to LUNs. In most cases, LUN masking is taken care of by the storage admin-istrator. Using various products from the storage vendors, you can create a single LUN or a group of LUNs, and then give a single host or several hosts access to the LUNs. You do this by assigning World Wide Names (WWNs) or through an alias tied to the WWN, also known as masking.

In simple environments where the storage array has only two controllers or storage processors, both automatically or by default allow any host using those pathways access to those LUNs defined by the masks. In a vSphere environment, there are usually multiple


ESX/ESXi hosts that share access to the same group of LUNs used to run VMs or store files such as CD images or even VM templates.

In vSphere, ESX/ESXi hosts can scan and work with up to 256 LUNs. However, in most cases the storage array will mask many of those IDs to other servers not related to virtualization.

If you boot the ESX server from the SAN, a single, private LUN must be seen by only one server. Proper masking will allow only that server to boot and use the private LUN. For example, if there are ten ESX servers booting from the SAN, the storage administrator will have to create and mask ten LUNs so that each ESX server has its own LUN.

When using diskless servers, do not set up separate diagnostic partitions for each host; instead, share one diagnostic partition between all hosts.

Preparing the SANWith each storage array used with ESX/ESXi servers, some setup is required to be sure that the storage array will be accessed correctly and efficiently. Here are some general prepara-tion guidelines:

Connect the Fibre Channel and/or Ethernet cablesNN

Configure the storage arrayNN

With the storage array administration software, make each ESX/ESXi server visible to NN

the SAN

Set up the ESX host to have the World Wide Port Numbers (WWPNs) of the host’s NN

Fibre Channel (FC) adapters as port names or node names

Create LUNsNN

Assign LUNsNN

Record the IP addresses of the FC switches and storage adapters. Record the WWPN NN

for each storage processor (SP) and host adapter

Configure the host bus adapter (HBA) for boot from the SANNN

Boot ESX/ESXi server from the installation CDNN

Configuring Fibre Channel or iSCSI HBA BIOSEach of the vendors, QLogic and Emulex, provide HBAs that will work in a boot from SAN configuration. Each vendor has its own guidelines for setting up the adapters to work correctly. Here are the basic steps:

1. Enable the HBA BIOS.

2. Enable either the Selectable Boot or the Enable BIOS option.

3. Select the boot LUN in the BIOS.

Identifying vSphere Architecture and Solutions 47

Installing VMware ESX/ESXiThe installation process is much the same, regardless of the boot location. See “Exercise 1.1: Installing ESX on Local Storage,” earlier in this chapter, for the installation steps.

Determining Boot LUN Size in a Given SituationWhen installing ESX, the boot disk needs to have at least 1.25 GB of free space. Several partitions will be created as well, including /boot and vmkcore. The /boot partition will consume 1100 MB.

Identifying vSphere Architecture and SolutionsIn this section, we’ll take a look at some of the other products that VMware offers for various situations and solutions. We’ll also examine the differences in the VM platform products and how they work in a given situation.

Next we’ll look at the differences between hosted platforms and a hypervisor platform, and explore the inherent strengths and weaknesses between the two types. We’ll compare the two approaches as well.

Each product reviewed here has a niche or provides a solution for many circumstances. Knowing the products that VMware has to offer ensures that you’ll provide customers with the best solution for an appropriate cost.

Differentiating VMware Platform Products and EditionsVMware has developed several products for running and hosting VMs that can fit most any situation or budget. Although the VCP certification emphasizes and tests a candi-date’s knowledge mostly on vSphere products like ESX/ESXi and vCenter, there are other VMware products that can run VMs and that may be more appropriate for a given cir-cumstance or project.

VMware has four products for the low-cost market that allow a user to create and work with VMs. These products were developed to run on low-cost laptops or desktops or even generic “white” boxes. These products are also known as “hosted” products as they require the user to install them on computers or servers that already have an operating system installed. These products are:

VMware WorkstationNN

VMware FusionNN

VMware ServerNN

VMware PlayerNN


Each of these products has strengths that may suit a given user’s requirements. Let’s explore how each can be installed and used.

VMware Workstation 6/7VMware Workstation has been sold and enhanced by VMware for over 10 years. This prod-uct continues to introduce new features, many of which ultimately trickle up to ESX/ESXi. One example is the ability to take a virtual machine snapshot. Introduced with VMware Workstation several years ago, this feature, although different in execution, is now a standard feature on ESX/ESXi servers. VMware Workstation will install on top of the host operating system, allowing it to run on an almost infinite combination of hardware platforms.

Here are several features and capabilities of VMware Workstation you should remember:

Provides broad operating system supportNN

32-bit and 64-bit operating systemsNN

Windows or Linux host operating systemsNN

Four-way Virtual SMPNN

Tests multitier applications, service packs, and OS/application updates on a single PCNN

Hosts multiple operating systems for test and development on a single PCNN

Utilizes snapshots to test new code or debug changes in application updatesNN

Demonstrates applications or multitier solutions to customers on a single PCNN

Provides training environments that allow for quick teardown and reset for a new classNN

Allows VMs to span multiple monitorsNN

Virtual machines that can work with USB 2.0 devices such as webcams and iPodsNN

Records all VM screen activity for later playbackNN

Packages and deploys VMs with VMware ACE (Assured Computing Environment) NN

authoring capabilities, providing for encryption and expiration of the package

In short, VMware Workstation allows users to run multiple VMs at the same time on a single PC. This makes it a great tool.

VMware FusionVMware Fusion is similar to VMware Workstation in that it allows users to run multiple oper-ating systems on a single Mac. The user interface has been altered to provide a more Mac-like appearance and allows the end user to run Windows applications on the Mac seamlessly.

Here are several features and capabilities of VMware Fusion:

Using VMware Converter provides a quick way to import your Windows environment NN

into your Mac without losing application settings or data.

VMware Fusion’s Unity feature can run Windows applications as Mac applications.NN

Mirrored folders allow quick access to files on both the Mac and Windows virtual NN

machine.


Application sharing allows you to select the Mac or Windows VM to run any file on NN

either platform.

AutoProtect allows you to take snapshots on regular intervals to protect against unex-NN

pected crashes or updates.

VMware Fusion offers multidisplay support.NN

VMware Fusion is a great product for MAC users, as the importation of an existing Windows environment with the accompanying applications is quite easy. This allows users to continue to use their installed base of applications and learn to use and potentially migrate to an all-Mac environment at the user’s pace.

VMware ServerFor customers just starting their experience with VMs, VMware Server is one of the best products to begin with—and it’s free. Building VMs is streamlined, and working with appli-cations within the VMs allows the user to test, evaluate, or host those applications easily. Using a web-based interface lessens the learning curve for both Windows and Linux users.

Here are several features and capabilities of VMware Server:

Supports over 30 operating systems, including:NN

WindowsNN

LinuxNN

NetWareNN

SolarisNN

Uses inexpensive hardware to get startedNN

Moves VMs between servers without having to reconfigure the VMsNN

Captures the entire state of a VM and rolls back changes if necessaryNN

Supports complex environmentsNN

Allows VMs created with VMware Server to be imported easily into a vSphere environ-NN

ment using VMware Converter

Provides up to 8 GB of RAM per VM and up to 10 virtual network interfaces per VMNN

Supports Volume Shadow Copy Service (VSS)NN

Given that VMware Server is free to download and install on inexpensive hardware, many people new to virtualization start here. The web-based management interface makes administration easy for both Windows and Linux users.

VMware PlayerVMware Player allows a user to run VMs on their PC. It is a free download and provides access to virtual appliances without having to purchase VMware’s other products. Although the product will run VMs, it cannot modify them.


Here are several features and capabilities of VMware Player:

Runs over 60 supported operating systemsNN

Runs 32-bit and 64-bit VMsNN

Runs four-way Virtual SMP VMsNN

Runs Microsoft VMs, Symantec Backup Exec System Recovery images, Norton Ghost NN

images, Norton Save & Restore images, StorageCraft ShadowProtect images, and Acronis True Image images

Shares data between the host computer and the VMNN

Can run ACE VMs with appropriate ACE licensingNN

VMware Player is great way to distribute and evaluate new appliances, run multiple operating systems on a single PC, and share data between the host PC and the VM. Remember, VMware Player cannot modify or create VMs.

Understanding Datacenter SolutionsVMware offers several solution-based products to fit particular needs or situations. In this section we’ll review several of these products that are popular with customers and specifically called out by VMware for review.

VMware ViewVMware View is a virtual desktop solution product. It allows for centralization of desktop computing resources similar to the server-related products. It leverages a VMware vSphere infrastructure to consolidate and secure desktop VMs.

Here are several features and capabilities of VMware View:

Lower costs by using low-cost thin clients at remote offices or locations instead of NN

traditional PCs

Increases security by keeping all storage within the datacenter and providing SSL NN

encryption between the client and the VM desktop

Provisions desktops manually or automatically using desktop poolsNN

Includes View Composer, which by using VMware linked clone technology allows a NN

pool of desktop VMs to share a master image to conserve disk space

Since the VMware View desktops stay in the datacenter, takes advantage of vSphere NN

features such as VMware HA, VMotion, and VMware DRS to provide for high avail-ability and load balancing within the datacenter

Helps reduce energy costs by using energy-efficient thin clientsNN

Unifies client access to other products (terminal servers, physical PCs, and blade PCs) NN

by using an industry-standard connection protocol, Remote Desktop Protocol (RDP)

Provides for “offline” desktops for checkout and synchronization with the master NN

image when checked in


With VMware View, desktops can be virtualized in a way similar to server virtualiza-tion, thereby reducing operating costs. You can flexibly provision new servers efficiently, thus reducing storage costs, and automatically adjust to fluctuating user needs by using desktop pools. VMware View also unifies client connections by providing a client that con-nects the user to desktop VMs, physical PCs, terminal server desktops, and blade PCs.

Site Recovery ManagerVMware vCenter Site Recovery Manager (SRM) is a sophisticated product that reduces the cost and complexity of disaster recovery. SRM works with VMware vSphere, vCenter Server, and storage array replication to automate recovery in case of partial or whole datacenter failure.

Here are several features and capabilities of VMware Site Recovery Manager:

Provides “single button” failover of a datacenter, which would include ESX hosts and VMsNN

Allows organizations to manage their disaster recovery plans more efficiently by making NN

the workflow an integral part of what SRM puts into motion

Provides for testing of the disaster workflows through automated tests that verify NN

VM integrity and replication

Monitors availability of recovery sitesNN

Provides nondisruptive testing by using storage snapshotsNN

Automates the execution of recovery plansNN

Allows for custom user scripts to automate shutdown of VMs and critical applications NN

with the least amount of disruption

VMware vCenter Lab ManagerVMware vCenter Lab Manager provides on-demand access to computer resources in the form of VMs and multitier applications. It provides for application development and testing by offering “datacenter in a box” functionality. Lab Manager deploys, captures, and shares system configuration easily, allowing you to work with new and prototype applications and multitier computing systems. Lab Manager also provides for easy setup and breakdown of test beds for quicker problem resolution; you can mirror production environments or client systems to isolate issues without downtime in those production environments.

Here are several features and capabilities of VMware vCenter Lab Manager:

Provides on-demand access (Self-Service) for the creation of new VMs or test beds that NN

include multiple VMs for development environments

Snapshots whole test beds and reverts to pristine state with one clickNN

Repurposes hardware quickly for higher utilization for testing and developmentNN

Reduces storage costsNN

Increases hardware utilization on existing virtual infrastructureNN

Includes leverage template repository and linked clone technology to provision new NN

servers efficiently and reduce storage costs


Utilizes storage leases to reclaim space from expired imagesNN

Dynamically allocates resources to different teams, projects, and sites and enforces NN

access control

Offers Live Link, which allows you to share complete application environments as a NN

single URL embedded in an email or bug-tracking system

Deploys VM clones behind a “network fence” to eliminate network conflicts without NN

losing configuration settings

Provides a scalable architecture that allows for LDAP, vCenter, and SOAP integrationNN

VMware vCenter Lab Manager offers a robust development and issue resolution environ-ment. It provides higher utilization of testing and development because it lets you quickly set up, tear down, or reimage your lab environment. Lab Manager can also reduce energy and storage costs by better utilizing computer resources.

Exploring ESX/ESXi ArchitectureBoth ESX and ESXi provide the same virtualization platform for VMs. What differentiates one from the other is how they are managed. ESX, as you learned earlier in this chapter, installs with a management console (Service Console), thus allowing for direct access to the host server by vSphere Client or SSH. ESXi, on the other hand, only provides the VMkernel, either embedded or installed, but no Service Console. It can be managed by the vSphere Client or vCenter, but not by SSH.

Deciding which to use involves security concerns and installation complexities. Let’s take a look at each version and what may help a user choose one over the other. By the way, there is no reason why an environment couldn’t deploy both types, taking advantage of both products when it makes sense to do so.

ESX ArchitectureThe main difference between ESX and ESXi is that ESX has a Service Console installed. ESX is a bare-metal hypervisor, but the Service Console runs in a separate memory space. This man-agement console is based on Red Hat Enterprise 5.2 and has been customized to perform some basic tasks, run a limited set of monitoring tools, and run management agents. The latter is being discouraged as VMware has implemented other technologies, such as Common Information Model (CIM) APIs, to help you monitor hardware subsystems and does not require an agent to be installed.

Since the earliest ESX servers, the Service Console has been used to give users flexibility in what products they use with their hosts, such as backup software, hardware, and VM monitoring, as well as other products that provide functionality VMware didn’t include. Another useful purpose for the Service Console is to run custom scripts that provide a multitude of functions or tasks you couldn’t otherwise implement.

In vSphere, the Service Console for ESX 4.0 is allotted 300 MB of memory by default. The NN

maximum amount of memory that can be allotted is 800 MB, but given that customers are being asked to migrate their local agents and scripts to the remote CLI environment, there isn’t much need to increase the default memory setting.


Also, the default partitions created for the Service Console are now encapsulated into a NN

“console” .vmdk file, as mentioned earlier in this chapter. The need to create additional partitions, such as /home and /tmp, is also diminished.

ESXi ArchitectureVMware ESXi provides a bare-metal hypervisor, dispensing with the need for a hosting OS. ESXi requires minimal installation or configuration on the local host. This allows a much quicker implementation. There are two types of ESXi server: embedded or install-able. You purchase the first implementation directly from the hardware manufacturer and it is embedded on the system.

Since there is no Service Console locally on the host, the initial configuration comes down to three steps:

1. Create a “root” password.

2. Configure the IP and DNS settings, including a fully qualified name.

3. Restart “Network Management” so that the IP and name settings take effect.

The ESXi installable implementation allows for regular server hardware or repurposed hardware to have ESXi installed from an .iso file. Once the initial file copy process completes and the server reboots, you complete the same three steps, just as with the embedded version.

In either case, there isn’t a Service Console to work with locally. All management will take place through the vSphere Client connecting directly with the ESXi server or by using vCenter to manage the host. There is also a remote command-line appliance, vMA, which has the vSphere CLI commands installed.

In addition, ESXi has a smaller security footprint since the Service Console is not installed. The number of ports, packages, and small-surface area of the VMkernel reduces the likelihood of being exploited. Since nothing is installed locally other than the VMkernel and the root account can be locked down, an ESXi server can be used in situations that a regular ESX server may not, such as being deployed in a DMZ.

Comparing and Contrasting Bare-Metal vs. Hosted ArchitectureUnderstanding the architectural differences between bare-metal and hosted virtualization platforms provided by VMware is a pretty straightforward concept. At its simplest, hosted products require a base operating system to be installed (such as Windows, Linux, or Mac OS). Hosted products are then installed much like regular applications on top of the base OS. In this case, the application is the VMkernel and the graphical user interfaces. The products that fit this definition are:

VMware WorkstationNN

VMware ServerNN

VMware FusionNN

VMware PlayerNN


Hosted products have several advantages—most notably, they can be installed on most hardware platforms that the host OS can run on. You can therefore use inexpensive or custom hardware. The cost associated with these products is also an advantage in that two are free (VMware Server and VMware Player) and the other two relatively inexpensive. This makes for an easy introduction to virtualization, and in the case of VMware Workstation and VMware Fusion, you can take advantage of some really great features such as snapshots and shared folders. Figure 1.8 shows VMware Workstation.

F I GU R E 1. 8 Workstation home screen

One distinct disadvantage to using hosted products is that the amount of overhead associ-ated with running on top of a host operating system can be substantial. Although CPU and memory allocation to the VMs is handled neatly, giving the VMs access to network or disk resources requires a lot of hand-holding. Sometimes referred to as context switching, basically it boils down to having two different I/O stacks to contend with: one in the VM itself and one in the host operating system for every network packet or disk read or write action.

Bare-metal hypervisors are by definition their own operating system. Although an argu-ment can be made that hypervisors are not technically OSs, for this discussion they provide enough OS functionality to not require the end user to install an intermediary OS such as Windows or Linux. ESX/ESXi is VMware’s hypervisor-based product.

The VMkernel that constitutes the hypervisor has a 32 MB footprint. Although the VMkernel will set aside additional memory for virtualization processes specific to VMs and supporting services, the VMkernel remains very small, stable, and incredibly efficient. It is safe to assume this is by design.

ESX/ESXi can be used alone and can be downloaded and used for free for 60 days. To take advantage of the datacenter-specific features such as VMware HA, VMotion, and VMware DRS, you must purchase vCenter and the requisite licensing. The costs

Summary 55

associated with vCenter licensing can be substantial and depend on the number of pro-cessors being managed. VMware currently does not license by the number of cores within a processor socket, but different editions may limit the number of cores within a socket that can be managed.

In addition, since the hypervisor is proprietary to VMware, all device drivers must be engi-neered and tested by VMware and their partners to ensure stability and compatibility with various hardware products. This is a major difference between the hosted products and ESX/ESXi. All customers are highly encouraged to check VMware’s online Compatibility Guides (http://www.vmware.com/resources/compatibility/search.php) to ensure that ESX/ESXi will run correctly and stably.

SummaryTo help you prepare for the VCP exam, we looked at several important aspects of planning, installing, and upgrading ESX/ESXi servers.

ESX/ESXi can be installed on local storage or can be booted from SAN-based storage (either Fibre Channel or iSCSI). We identified several hardware requirements for installa-tion, including the need for 64-bit processors.

There are two distinct versions of ESX /ESXi servers. ESX must be installed and comes with a management console, known as the Service Console. ESXi can be purchased from the hardware vendor or may be installed on existing hardware, but neither comes with a functional Service Console and they have to be remotely managed with the vSphere Client, vCenter or, the vMA appliance.

Older ESX/ESXi 3.5 servers can be upgraded to the new ESX/ESXi 4.0 server version using one of two methods: the vSphere Host Update Utility or vCenter Update Manager. We dis-cussed methods for backing up the host configuration and the VMs before an upgrade. Also, we looked at the rollback options when upgrading an ESX/ESXi 3.5 server to ESX/ESXi 4.0.

The task of securing ESX/ESXi servers is very straightforward for either type of ESX server. ESXi has an advantage since there is no Service Console to harden. With ESX, the Service Console’s firewall is set to high security and only those services and processes needed for managing and providing virtualization functions are included or running. We also discussed several security design principles inherent in VMware’s ESX architecture.

This chapter also summarized other VMware products that provide customers with solutions for lab environments, datacenter failover, and virtualization and management of desktops.

http://www.vmware.com/resources/compatibility/search.php


Exam Essentials

Know how to plan, install, and upgrade VMware ESX/ESXi server. Proper planning of an ESX/ESXi server will ensure a stable hosting platform for virtual machines. Part of any planning process is to ensure the hardware being considered meets the new requirements for vSphere implementations. Practice installing both ESX and ESXi to familiarize yourself with the differences between each product. Review the licensing schemes and take note of those features that may only be available with one or two editions.

Know how to upgrade an ESX/ESXi server. Review the backup options of a host’s con-figuration for ESX/ESXi servers and for the VMs. Practice upgrading an ESX server from ESX 3.5 to ESX 4.0 using both the vSphere Host Update Utility and the vCenter Update Manager. Also practice upgrading the VMs’ virtual hardware and the VMware tools.

Understand the security design principles of ESX/ESXi architecture. Review the security elements designed into ESX/ESXi, such as memory hardening and kernel module integrity. Work with the ESX server’s Service Console firewall using the vSphere Client, creating additional users and determining which clients or applications can be used to access the Service Console for a given situation.

Know how to install ESX/ESXi on SAN storage. Understand the concept of LUN mask-ing. Know how to prepare a storage array for use with an ESX/ESXi server and how to set up the HBA BIOS. Review the LUN sizing criteria for a boot-from-SAN situation.

Be familiar with other VMware products and their solutions. Review each of the prod-ucts listed in this chapter and what solution each provides the customer for a given cir-cumstance. Also pay close attention to the differences between the hosted products and bare-metal hypervisors.

Review Questions 57

Review Questions

1. Which of the following are unique features of ESX (as opposed to ESXi)? (Choose two.)

A. ESX is an embedded architecture.

B. The root account can be locked down.

C. ESX has a smaller security footprint compared with ESXi.

D. ESX supports the installation of third-party management and backup agents.

E. ESX is managed with the Service Console, running Red Hat Enterprise Linux 5.2.

2. Which of the following cannot be done using the ESXi direct serial console interface? (Choose two.)

A. Creating virtual machines

B. Setting the root password

C. Configuring lockdown mode

D. Configuring the management network

E. Configuring VM virtual switches

3. You want to quickly prototype a demo virtual machine and show your demo to a customer on your laptop (which runs Windows XP Pro). The VM needs to run with two processors, and you would like to be able to take multiple snapshots for rollback or demo purposes. You will occasionally have to modify the VM for various customer demos (changing the amount of RAM allocated to the VM at the very least). Finally, you decide it would be nice to be able to have the product capture video of the VM to leave with the client when the demo is finished.

Which product would best provide your needs as you build this VM?

A. VMware Player

B. VMware Fusion

C. VMware Server

D. VMware Workstation

E. vSphere ESX/ESXi

4. Which of the following should you back up on an ESX 3.5 server before performing an upgrade to ESX 4.0? (Choose two.)

A. VMFS SAN LUNs

B. vCenter custom alarm scripts

C. Locally stored virtual machine files

D. System configuration files in the /etc directory

E. System configuration files in the /config directory


5. Which of the following are not strategies employed by default in the ESX 4.0 Service Console? (Choose two.)

A. setuid and setgid applications are kept to a minimum.

B. Tripwire helps detect if the system has been compromised.

C. The Service Console has the minimal required open network ports.

D. All communications between ESX and any of its clients are encrypted.

E. The installed Telnet and FTP services are disabled by default and must be manually enabled.

6. What is the minimum version of ESX that is supported for upgrading to ESX 4.0?

A. 2.1

B. 2.5

C. 2.5.5

D. 3.0

E. 3.5

7. Which of the following is not explicitly upgraded when upgrading from VI 3.5 to vSphere 4.0?

A. vCenter Server

B. VMtools in each VM

C. VMFS

D. Each ESX server

E. Each VM’s virtual hardware

8. Which of the following describe valid options when setting up licensing on an ESX/ESXi 4.0 server? (Choose two.)

A. You must specify a license server.

B. You can enter a 25-character license code.

C. You can use a 30-day evaluation license.

D. You can use a 60-day evaluation license.

E. ESXi is not a licensed product and so there are no licensing options for ESXi.

9. When testing a multitiered application, you are most likely to benefit from which product?

A. VMware View

B. VMware Lab Manager

C. VMware Fusion

D. VMware Server

E. VMware Site Recovery Manager

Review Questions 59

10. Which of the following boot-from-LUN statements is true?

A. On the SAN, LUN masking is not needed for any boot-from-SAN LUNs.

B. The LUN being booted from should be presented only to the ESX server being booted.

C. VMotion requires all LUNs be presented to all ESX servers.

D. The LUN being booted from should be presented only to the vCenter server.

E. Booting from LUN is not supported in vSphere 4.0

11. After a standard installation, how can you access an ESX Service Console remotely? (Choose three.)

A. Using Telnet

B. Via an SSH Client

C. Via a web browser

D. Using the vSphere (GUI) Client

E. Using Microsoft Remote Desktop

12. How can you manage an ESXi server? (Choose three.)

A. Using the Service Console

B. By direct login with the vSphere (GUI) Client

C. From a vCenter login with the vSphere (GUI) Client

D. Using the vMA management virtual appliance

E. By remotely logging in using SSH

13. When you’re booting an ESX/ESXi server from a SAN, which of the following apply? (Choose two.)

A. Both ESX and ESXi support booting from an iSCSI SAN.

B. An HBA that is supported for boot from SAN is required.

C. The HBA BIOS must be properly configured to support boot from SAN.

D. You must check the installation manual as installing a boot-from-SAN ESX server is substantially different from installing to a local disk.

E. The LUN must be masked so as to be presented to all ESX servers in the DRS/HA cluster as ESX requires shared storage.

14. Which of the following vSphere features requires either the VMware vSphere Enterprise Edition license or the VMware vSphere Enterprise Plus Edition license? (Choose two.)

A. VMware HA

B. VMware VMotion

C. VMware Storage VMotion

D. VMware Consolidated Backup (VCB)

E. VMware vCenter Update Manager (VUM)

F. VMware vNetwork Distributed Switch


15. Which of the following partitions are not created by default when installing ESX 4.0? (Choose two.)

A. /tmp

B. swap

C. /home

D. /boot

E. /var/log

16. Why would you create a nonroot account on an ESX server? (Choose two.)

A. Login to the root account is disabled by default.

B. Logging in as root does not provide adequate auditing of who logged in.

C. A nonroot account can be used to limit root access.

D. Management of ESX requires a nonroot account be set up.

E. A nonroot account is required to log in via the vSphere GUI Client.

17. The development group has supplied you with a VM preloaded to run a customer demo. You have no need to reconfigure this VM and, in fact, development would prefer you always run the demo in the VM as delivered. Which product would be the best fit for running this VM?

A. VMware Player

B. VMware Fusion

C. VMware Server

D. VMware Workstation

E. vSphere ESX/ESXi

18. Which of the following are not supported boot devices for a vSphere 4.0 ESX server? (Choose two.)

A. A SAN LUN on a supported SAN

B. An iSCSI LUN when using a software initiator

C. An iSCSI LUN when using a supported hardware initiator

D. A supported internal disk on the ESX server

E. A boot directory shared via NFS

19. Which of the following is true about ESX/ESXi installation media?

A. Only ESXi is available in downloadable format.

B. Both ESX and ESXi are available in an embedded format.

C. ESX/ESXi are no longer available in physical CD/DVD format.

D. VMware provides an MD5 sum for verification of the downloaded ISO installation media.

Answers to Review Questions 61

20. Which of the following describe techniques or VMkernel engineering design used to harden a vSphere 4.0 environment? (Choose three.)

A. VMkernel memory hardening

B. VMs share the same memory silos or worlds

C. VMs are granted direct access to physical hardware

D. VMkernel module integrity via digital signatures

E. Resource limits and reservations as prevention against DoS attacks


Answers to Review Questions

1. D, E. ESXi has the embedded architecture and supports the locked-down root account (not ESX). ESXi also has a smaller security footprint as it does not include the Service Console management interface as ESX does.

2. A, E. The ESXi direct serial console has limited configuration functionality and, in general, does not include configuring any VM-related features.

3. D. Workstation is an inexpensive choice that will run on a laptop and that will allow for multiple snapshots and video capture. Player won’t allow you to reconfigure the VM, Server does not support either multiple snapshots or video capture, and Fusion runs on Intel Macs only.

4. C, D. Backing up an ESX server includes local system configuration files in the /etc direc-tory, custom scripts stored on the ESX server, and locally stored VMFS file systems (includ-ing virtual machine files, templates, and ISO images). vCenter scripts would be backed up as part of vCenter upgrading, not ESX upgrading, and the contents of SAN LUNs would be backed up as a matter of course by the SAN administration team.

5. B, E. Tripwire is not installed on an ESX server and its use is not supported by VMware. Telnet and FTP are not installed and, in fact, are not even present on the installation media.

6. C. ESX 2.5.5 can be upgraded to ESX 4.0 if the /boot partition was built at least 100 MB in size. If you chose the default 50 MB /boot partition for ESX 2.5.5, you will need to upgrade to ESX 3.x first and then upgrade to ESX 4.0. All properly installed versions of ESX 3.x can be upgraded to ESX 4.0.

7. C. The VMware file system (VMFS) does not need to be explicitly upgraded as part of the VI 3.5 to vSphere 4.0 upgrade path.

8. B, D. ESX/ESXi 4.0 now use a 25-character license code. Although a license server may be specified for backward compatibility with ESX 3.x/VC 2.x, the license server is not required for 4.0 only environments. Finally, a 60-day evaluation license is available.

9. B. VMware Lab Manager has the ability to deploy sets of virtual machines, including their network and other relationships. This is ideal for testing a multitiered application (which typically runs on several servers simultaneously).

10. B. For security and performance reasons, when booting from a SAN (or an iSCSI SAN for ESX servers only), the LUN should be presented only to the server being booted.

11. B, C, D. Remote access to the Service Console is fairly limited and only secure access is enabled by default. The use of Telnet is not supported (in fact, Telnet is not even included in the installation CD/DVD), and there is no GUI desktop to connect to with Microsoft RDP.

12. B, C, D. ESXi has no Service Console and so does not support a Service Console interface or SSH logins.


13. B, C. Boot from SAN specifically requires supported HBA cards capable of booting from a SAN LUN, and the HBA card must be properly configured before installing ESX. ESXi does not support booting from iSCSI as of this writing. The installation of ESX is substantially the same whether booting from local disk or from a SAN LUN. Finally, the LUN should be masked so that only the booting ESX server has access to it.

14. C, F. Motion comes with the Advanced Edition license, while HA, VUM, and VCP come with the Standard Edition license.

15. A, C. Although they may be (optionally) created during the installation, there is no need for the /tmp and /home partitions on an ESX server. Further, the swap and /var/log partitions are now created in a VMFS with ESX 4.0.

16. B, C. When a user logs in as root, there is no way to tell who logged in, making tracking changes difficult. By limiting access to the su and sudo commands, you can limit root access by making users log in as a nonroot account.

17. A. VMware Player will allow you to run the VM from development as is without allowing you to make any modifications.

18. B, E. An ESX server may be booted from a SAN LUN, an iSCSI LUN (when using a hardware initiator), and an internal disk on the ESX server itself. Both iSCSI software initiator and NFS share points are not supported boot configurations on an ESX server.

19. D. The MD5 sum should always be checked to ensure the integrity of the download.

20. A, D, E. VMkernel memory hardening is accomplished via randomization of memory addresses for driver modules as they are loaded (ASLR). In addition, VMkernel modules are digitally signed and VM limits and reservations can serve as a cap on physical resource consumption. VMs do not share memory silos/worlds and are not granted direct access to the server’s physical hardware.

Chapter

2Configuring ESX/ESXi Networking


Configure Virtual Switches.NÛ

Understand Virtual Switch and ESX/ESXi NIC and port NN

maximums .

Determine the vSwitch NIC teaming policy in a given NN

situation .

Determine the appropriate vSwitch security policies in a NN

given situation .

Create/Delete Virtual Switches .NN

Create Ports/Port Groups .NN

Assign Physical Adapters .NN

Modify vSwitch NIC Teaming and failover policies .NN

Modify vSwitch security policy and VLAN settings .NN

Configure VMotion .NN

Configure vNetwork Distributed Switches.NÛ

Understand ESX Host and port maximums for dvSwitches .NN

Determine the virtual port group NIC teaming and fail-over NN

policy in a given situation .

Determine the appropriate virtual port group security NN

policies in a given situation .

Create/Modify a vNetwork Distributed Switch .NN

Create/Modify Uplink Group settings .NN

Create/Modify dvPort Group settings .NN

Add an ESX/ESXi Host to a vNetwork Distributed Switch .NN

Add/Delete a VMkernel dvPort .NN

Migrate Virtual Machines to a vNetwork Distributed Switch .NN

Configure VMware ESX/ESXi Management Network.NÛ

Modify Service Console IP Settings .NN

Configure Service Console availability .NN

Configure DNS and Routing settings for an ESX Host .NN

Once you have installed ESX/ESXi, one of the first items you must configure is vNetworking. vSphere provides two methods of connecting to the physical network: the standard virtual

switch and the distributed virtual switch.This chapter shows you how to configure a virtual switch (vSwitch). A vSwitch is a

software-based module that resides inside the VMkernel of each ESX server; its purpose is to direct network traffic to one of three distinct traffic locations: the Service Console, the VMkernel, and the VM network. The Service Console connects to the network for remote management purposes (ESX only). The VMkernel is utilized for Fault Tolerance, vMotion, iSCSI, and NFS. The VM network is used to allow hosted VMs to connect to the virtual and physical network. (The Service Console network is not utilized when the host is ESXi based.)

This chapter also discusses configuring a distributed vSwitch. Standard vSwitches are defined at each host (ESX) server and can be configured from either the vCenter server or directly on the host. Distributed vSwitches are defined at the vCenter server level and can only be manipulated at this level.

With version 3.5, VMware introduced ESXi. This hypervisor does not have a Service Console and management is done via a special VMkernel port. We will show you how to create and configure the VMware ESXi management stack.

Configuring Virtual SwitchesWith ESX/ESXi, all communication entering or exiting the host server travels via a vSwitch. A vSwitch is a software Layer 2 switch that hooks into the VMkernel and utilizes the ESX server’s physical NICs (pNICs) as uplinks to connect to the upstream physical switches and greater network. Multiple pNICs can be attached to a vSwitch for redundancy and load-balancing purposes. vSphere ESX/ESXi fully supports 802.3ad link aggregation, which will be discussed later in this chapter in the section “Determining the vSwitch NIC Teaming Policy In A Given Situation.”

This section covers nine sub-objectives:

Understanding virtual switches and ESX/ESXi NIC and port maximumsNN

Determining the vSwitch NIC teaming policy in a given situationNN

Determining the appropriate vSwitch security policies in a given situationNN

Creating and deleting virtual switchesNN

Creating ports and port groupsNN

68 Chapter 2 N Configuring ESX/ESXi Networking

Assigning physical adaptersNN

Modifying vSwitch NIC teaming and failover policiesNN

Modifying vSwitch security policy and VLAN settingsNN

Understanding Virtual Switches and ESX/ESXi NIC and Port MaximumsVMware ESX utilizes the concept of virtual switches (vSwitch) to connect VMs running on an ESX/ESXi host to the physical network. These switches have functionality similar to that of their physical cousins. However, there are some differences. Before we move on to creating and managing a vSwitch, let’s look at some definitions:

vNetwork Standard Switch (vSwitch) This is the standard software-based switch utilized by ESX and ESXi to deliver connectivity to VMs. These software devices are connected to physical switches using physical uplink adapters or NICs on the ESX/ESXi server and can be managed from both a vCenter instance and directly using the vSphere Client.

vNetwork Distributed Switch This provides functionality similar to that of a standard vSwitch but spans multiple ESX/ESXi hosts. Distributed vSwitches offer enhanced func-tionality and are mainly managed via a vCenter instance.

Port or Port Group This is a logical object on a vSwitch that is used to provide network-ing connectivity and/or segmentation to the traffic traversing the vSwitch, utilizing one of the three connection types: VMkernel, the Service Console (ESX only), or the VM network traffic.

Service Console Port (ESX Only) A management port configured with an IP address used to provide access to the ESX server. The vswif interface is the term for the ESX management network interface. This interface is normally configured during installation; the first created interface is termed vswif0 and if further service console interfaces are created, the number is incremented—for example, vswif1, vswif2, and so on.

VMkernel Port This is a special port that is configured with an IP address and is used to provide functionality that consists of vMotion, Fault Tolerance logging, iSCSI, NFS, and in the case of ESXi, management functionality similar to that of the Service Console on an ESX server.

Virtual Machine Port Group This is a port group that is configured to allow guest operat-ing system connectivity to an internal network to communicate with other guests and—if the vSwitch has been configured with vmnics (the term used for the physical uplink devices that are attached to the core external network)—to allow those VM guests access to the physical network and other guests running on other ESX hosts.

Virtual Local Area Network (VLAN) A VLAN is a mechanism that allows logical traffic separation on a switch based on a unique number termed the VLAN ID.

Trunk Port This is a special port on a switch that is configured to pass the traffic of more than one VLAN.

Configuring Virtual Switches 69

Access Port This is a port that connects to a guest and can carry only one VLAN ID.

Virtual Network Interface Card (vNIC) There are six types of virtualized network inter-face cards available to guests running on an ESX host.

Vlance This is an emulated AMD79c970 PCnet32 network interface card. It communi-cates at 10 Mbps and can be used with many 32-bit operating systems (except Windows Vista and later). Used to provide immediate network access for the VM.

VMXNET This is a virtualized network adapter that resides within the virtual guest and provides a 1 GB interface to the network. It is a specialized device that is only present with the implementation of the VMware Tools package.

Flexible This can be either a Vlance or a VMXNET adapter within the guest; it depends on which driver initializes the adapter. If the VMware Tools are installed, it will initialize as VMXNET.

E1000 This is a virtualized adapter that emulates the Intel 82545EM Gigabit NIC card to provide a 1 GB interface. It is typically used with Windows XP or later operating systems and Linux versions 2.4.19 or later.

VMXNET 2 (Enhanced) This is based on the VMXNET adapter but is used as a high-performance device that supports jumbo frames and hardware offloads. It is supported by of these operating systems:

Windows 2003 Enterprise/DatacenterNN

32-bit Windows XP ProfessionalNN

Red Hat Enterprise Linux 5.0NN

SUSE Linux Enterprise Server 10NN

64-bit Red Hat Enterprise Linux 4.0NN

64-bit Ubuntu LinuxNN

VMXNET 3 This provides the same features as VMXNET 2 virtual adapters and includes features like Receive Side Scaling, IPv6, and MSI/MSI-X support. It is only sup-ported with the following 32- and 64-bit operating systems:

Windows XP, 2003, and 2008NN

Red Had Enterprise Linux 5.0 or laterNN

SUSE Linux Enterprise Server 10 or laterNN

Asianux 3 or laterNN

Debian 4/Ubuntu 7.04 or laterNN

Sun Solaris 10 U4 or laterNN

UbuntuNN

It is the pNIC (the physical NIC device installed on the ESX/ESXi host) that provides connectivity between the virtual and the physical world. The vNIC provides connectivity between the virtual guest operating system and the vSwitch.


You will notice that there is a disconnect here; this is where the vmnic enters. The vmnic is a virtual object that is linked to a pNIC and used to provide connectivity between the vSwitch and a physical switch via a pNIC. This is somewhat analogous to a trunk port on physical switches.

In addition, there are several networking maximums published by VMware that you should study for the test . Table 2 .1 in the upcoming section “Defining the vSwitch Configuration Maximums” lists several of the most often cited values .

Identifying Similarities and Differences Between Physical Switches and vSwitchesThe vSwitch, just like its physical switch counterport, is a Layer 2 device. Like the physical device, it maintains a MAC address table of all the devices attached to it. It supports VLANs and is capable of trunking, based on the IEEE standard 802.1q.

Although there are several differences between a physical and virtual switch, the one to remember is that the virtual version does not participate in Spanning Tree Protocol. This is because unlike a physical switch, the vSwitch cannot be joined directly to another vSwitch.

Figure 2.1 illustrates the relationship between networks inside and outside of a virtual environment for vSwitches. The pNICs of the host server are connected to the physical switch in a traditional manner. These pNICs are logically mapped to vmnics in ESX, and it is these vmnics that are attached to the internal vSwitch to allow communication between the guests running on the host and the outside world.

On the internal facing side of the vSwitch are the port groups. There are three types in ESX: the Service Console, the VMkernel, and the VM network. ESXi only has two types of port groups because it does not have a traditional Service Console management environment.

In ESX/ESXi, the virtual environment provides similar networking analogs to the physical world. These are virtual network interface cards (vNIC), vNetwork standard switches (vSwitch), vNetwork distributed switches (dvSwitch), and port groups. We will discuss vNetwork Distributed Switches later in the chapter in the section “Creating and Modifying a vNetwork Distributed Switch.”

Just like with a physical machine, every VM hosted on the ESX server requires one or more network cards (on a virtual guest these are termed vNICs). The guest operating system and application programs communicate with a vNIC via the installed device driver. This can be either a native driver, (i.e., e1000) or a VMware device driver, VMXNET, which is optimized for the virtual environment. However, guest OS communication occurs between the machine and the switch exactly as it would with a physical device. Inside the VM, each vNIC has its own MAC address and one or more IP addresses, and it responds to standard Ethernet protocols as a physical NIC would. In fact, an outside agent will not detect that it is communicating with a VM. The only way that you can tell if a guest is virtual is from the MAC address, which uses a defi ned VMware MAC address range. (VMware has three regis-tered MAC vendor IDs; the one most often used for VMs is 00:50:56.)


F I GU R E 2 .1 Logical view of standard virtual switches

NIC (1)

vmnic pNIC

NIC (1)

vNICs

PortGroups

VirtualSwitch

Trunk

ServiceConsole[ / ] #

VMotion iSCSI/NFS FT

VM VM

Port Group

vSwitch

Port GroupPort Group

The virtual switches, as already stated, work as a Layer 2 switch. Each host server will be configured with one or more vSwitches. These switches are configured with ports or port groups, which are used to connect to either the VMs, the VMkernel, or (if ESX) the Service Console. The other side of the vSwitch may be connected to uplink connections, vmnics, which connect to the physical Ethernet adapters installed on the server. Therefore, the path that a VM traverses to connect to the outside world is the same it would use if it were physical.

A vSwitch can either have no uplinks, a single uplink, or multiple uplinks in a teamed configuration. With NIC teaming, two or more physical adapters are used to share the traffic load or to provide failover in the event of a physical adapter hardware failure or a network outage.

The vSwitch allows many servers (via port groups) and uplinks to be connected. A port group is a way of grouping VMs on the vSwitch. Ports on the vSwitch are assigned to the port group either by configuring the VM to use the port group or by powering on the VM. If there are multiple port groups on the same vSwitch, VLANs can be used to isolate VMs in different port groups. Within a vSwitch, a port group can be created with a VLAN ID, thereby allowing only the traffic pertinent to that logical network to traverse between the VMs on that port group and the external physical VLAN.


Defining the vSwitch Configuration MaximumsThe standard vSwitch has some configuration maximums, shown in Table 2.1. The VMware Maximums document is available on VMware’s website and is a highly recommended study aid. Table 2.1 provides a subset of these maximums showing details for the vStandard switch; later, in the section “Creating and Modifying a vNetwork Distributed Switch,” we will show the details for the dvSwitch.

TA B lE 2 .1 Networking Maximums for Standard vSwitches

Item Maximum

Physical NICs

e1000 NICs Ethernet ports (Intel PCI-x NIC) 32

e1000e NICs Ethernet ports (Intel PCI-e NIC) 32

Igb 1 GB Ethernet ports (Intel) 16

tg3 1 GB Ethernet ports (Broadcom) 32

bnx2 1 GB Ethernet ports (Broadcom) 16

forcedeth 1 GB Ethernet ports (NVIDIA) 2

s2io 10 GB Ethernet ports (Neterion) 4

nx_nic 10 GB Ethernet ports (NetXen) 4

Ixgbe Oplin 10 GB Ethernet ports (Intel) 4

bnx2x 10 GB Ethernet ports (Broadcom) 4

Infiniband ports (refer to VMware Community Support) N/A

PCI VMDirectPath devices per virtual machine 2

PCI VMDirectPath devices per host 8

vNetwork Standard Switch

Total virtual network switch ports per host (vDS and vSS ports) 4096

Virtual network switch ports per standard switch 4088


Item Maximum

Port groups per standard switch 512

Standard switches per host 248

Determining the vSwitch NIC Teaming Policy In A Given SituationNIC teaming is the method for setting policies for a vSwitch or port group to either load-balance based on certain algorithms or provide failover in time of hardware failure. There are several methods for configuring NIC teaming; the configuration depends on the needs and restrictions of your environment. Figure 2.2 shows the Load Balancing drop-down box where you select the appropriate policy for the vSwitch (see “Modifying vSwitch NIC Teaming and Failover Policies” later in this chapter.)

F I GU R E 2 . 2 Load balancing options

Load BalancingLoad balancing is the teaming or logical coupling of two or more pNICs to provide greater network traffic throughput. In ESX/ESXi, the team is not like an EtherChannel bond created with physical Cisco switches where the link is logically seen as the sum total of the bonded link. By default, under ESX/ESXi, a single guest will not obtain greater through-put than the sum of a single link. However, the aggregate throughput of the host will be increased to the total value of the teamed ports.

TA B lE 2 .1 Networking Maximums for Standard vSwitches (continued)


The traffic flow through a team is based on one of four load-balancing/failover options. Note the last option in the Load Balancing drop-down list, Use Explicit Failover Order, is not really a load-balancing algorithm; it is a manual method of setting failover policies for uplinks.

Route Based on the Originating Virtual Port ID The virtual port ID policy has been the default setting since ESX 3.0.x. Here the VMkernel assigns a virtual port ID to anything that plugs into the vSwitch, whether it is a VM, the Service Console, or the VMkernel itself. Now based on this virtual port ID, the VMkernel assigns a pNIC as an uplink to the guest on the vSwitch. When the guest attempts communication through the vSwitch out to the physical LAN, the VMkernel will always try to send the traffic through the assigned uplink (pNIC), as long as the link is up.

Route Based on IP Hash Here a vSwitch guest can potentially use multiple uplinks at the same time to communicate with hosts out on the physical LAN. The VMkernel observes the source and destination IP of packets coming from the vSwitch guest, and based on this information, traffic can be allowed to flow to and from any available uplink connected to the vSwitch. However, in order for this policy to work completely, 802.3ad link aggregation must be configured on the physical switch. Cisco terms this functionality “EtherChannel.”

Route Based on Source MAC Hash The source MAC hash policy operates in a simi-lar manner to the virtual port ID policy with regard to vSwitch guests being assigned a single uplink to use. This time, however, the VMkernel uses the MAC address of the guest to assign and distribute available uplinks. As before, the guest is only allowed to use its assigned uplink, even if other uplinks are available. If an uplink fails in a load-balanced setup, the remaining NIC or NICs will handle all the traffic.

Use Explicit Failover Order With the Failover option, only one NIC is active. The other is basically a hot standby on the host. If a network error or device failure occurs on the active NIC, the secondary NIC will take over. This configuration is often used with ESX/ESXi servers with fewer than four NICs and provides some basic separation of traffic between the Service Console port and the VMkernel port used for VMotion, in environments where there is no requirement for large throughput, or when the underlying network is not redun-dant or capable of supporting redundant uplinks.

Determining the Appropriate vSwitch Security Policies In A Given SituationA standard vSwitch has three Layer 2 parameters for applying a security policy, as shown in Figure 2.3:

Promiscuous ModeNN

MAC Address ChangesNN

Forged TransmitsNN


F I GU R E 2 . 3 Security parameters on a standard vSwitch

These parameters can be adjusted to allow VMs to communicate on the network or receive traffic that is not specifically directed to them. Each of these parameters can be configured at the vSwitch level or port group:

Promiscuous Mode The default setting is Reject. If a VM connected to this vSwitch attempts to run a packet-capturing (sniffing) program, the only packets it will be able to capture are those that are specifically addressed to itself; packets for other VMs attached to the same vSwitch will not be captured. However, if the vSwitch is set to Promiscuous Mode, all the packets that are sent or received by the vSwitch will be monitored by this VM.

MAC Address Changes The default setting is Accept. The first time a VM is powered on, a MAC address is created for the vNIC by the VMkernel (if the VM is created locally using the vSphere Client directly connected to the ESX/ESXi host) or vCenter. This address is written to the VM’s VMX configuration file. However, there are occasions when a VM may need to communicate on the network using a different MAC address. If, for example, the VM were part of a Microsoft network load balance (NLB) cluster, the machine would communicate on the network using the NLB cluster MAC address created during the cre-ation of the cluster, not the VM’s actual MAC address.

If the MAC Address Changes box is set to Reject, any VM attached to the vSwitch is not allowed to communicate on the network with a MAC address different from what it was assigned in the VMX file. Any attempt to do so will result in the VM not receiving packets.

Forged Transmits The default setting is Accept. This means that the vSwitch will not compare the source and actual MAC addresses. It will allow MAC addresses to pass that do not relate to the actual virtual machine.

If Forged Transmits is set to Reject, when a VM tries to communicate with a different MAC address other than what it was assigned, the VMkernel will drop all packets from this VM.

Creating and Deleting Virtual SwitchesWith ESX/ESXi, all communication entering or exiting the host server travels via a vSwitch. These vSwitches are what hooks into the VMkernel and utilizes the ESX server’s pNICs as uplinks to connect to the upstream physical switches and greater network. Multiple pNICs can be attached to a vSwitch for redundancy and load-balancing purposes. Further, vSphere ESX/ESXi now supports 802.3ad link aggregation, which will be discussed later in this chapter in the section “Modifying vSwitch NIC Teaming and Failover Policies.”


Creating a Standard vSwitchWhen ESX is fi rst installed, vSwitch0 is created with 24 ports by default. The Service Console port (if using ESX) or the VMkernel port (if using ESXi) is automatically con-nected to vSwitch0 during installation. The number of logical ports on a standard vSwitch is confi gurable from 8 to 4088. When VMs connected to the same vSwitch communicate with each other, their traffi c is routed locally inside the ESX server’s memory at memory bus speed. Depending on an environment’s setup or desires, a single vSwitch may suffi ce, or for traffi c segmentation purposes, multiple vSwitches can be created on each ESX server. In fact, the total number of standard vSwitches that you can create on one ESX server is 248.

When creating a new vSwitch, the default number of ports is 56. However, this is not the true value as the default vSwitch actually has 64 ports. This discrepancy is due to the fact that ESX reserves eight ports per vSwitch for its own use.

One thing to note is that this discrepancy in reporting sizes can be seen when viewing the switch properties from the command line . When utilizing the esxcfg-switch command, you will see the total number of ports assigned to a switch .

This is the same for all the drop-down options through the maximum of 4088 ports (which should really be 4096). That said, for the purposes of the VCP exam, the value that you will be asked is the number of usable ports, and this is always 8 less than the maximum.

Any changes you make will not take effect until the system is restarted .

It is a relatively simple task to create and manage standard vSwitches via the vSphere Client. Exercise 2.1 shows how.


Creating a Standard vSwitch

1. Open the vSphere Client and log on to the host directly using the Fully Qualifi ed Domain Name (FQDN) or IP address, or to a vCenter instance . Enter the correct user credentials .

2. In the resulting screen, choose Networking in the Confi guration section, and click Add Networking on the right .

3. In the Add Network Wizard, you must specify which network will be connected to the vSwitch . The choices are:

Virtual MachineNN

VMkernelN

Service ConsoleNN


E X E R C I S E 2 .1 ( c ont i nu e d )

This step allows the user to initially create a vSwitch for a specific purpose by adding a port or port group . For this exercise, click Virtual Machine and then click Next .

4. On the Network Access screen, you will add this new port or port group to an existing vSwitch or create a new vSwitch . Choose Create A Virtual Switch and select the vmnic1 check box as the uplink to the physical network . Then click Next .



Your ability to add NICs is dependent on the availability of NICs . You do, however, have the option of creating a vSwitch without any connections . This is referred to as an “internal” switch .

5. On the next screen, Connection Settings, you create and label your port or port group and, if necessary, define a VLAN ID .

Enter a network label that complies with your naming standards . As shown here, we chose vNet-1234 . This is to indicate that it is a virtual network assigned to the VLAN 1234 . The number 1234 then appears in the VLAN ID (Optional) field .

If you operate a flat network or are using Virtual Guest Tagging (VGT), then you don’t have to enter anything for a VLAN ID .

6. The Ready To Complete screen shows a summary; review it before clicking Finish to create the new vSwitch .



Here is the vSphere Client showing the newly created vSwitch:

7. To the side of the each port group, you will notice a blue “callout” icon . This is used to display information about the port group . You will also notice another blue “callout” icon next to the physical adapter . Click this icon to display information about Cisco Discovery Protocol (CDP)—assuming that your vSwitch is uplinked to a Cisco switch advertising CDP information about itself .

Deleting a Standard vSwitchThe procedure for deleting a vSwitch is even easier. There is one caveat: all VMs will have to be moved to other vSwitches so that the vSwitch has no active ports. This also includes Service Console or VMkernel ports. To remove a vSwitch, click the Remove link and you are presented with a message box asking if you want to remove the vSwitch, as shown in Figure 2.4. Click Yes. It’s that simple.

Removing Port GroupsTo remove a port group click, click Properties for the vSwitch, click on the port group that you wish to remove, and click Remove (see Figure 2.5).


F I GU R E 2 . 4 Removing a standard vSwitch

F I GU R E 2 .5 Choosing a port group and removing it

Confirm in the message box and that’s all there is to it.

Removing UplinksTo remove an uplink or vmnic from your configured vSwitch, simply select the Network Adapters tab, click the NIC that is to be removed, and click Remove. Select Yes in the warning dialog box.


Creating Ports/Port GroupsIf you don’t add port groups during the creation of a new vSwitch, you can add them later. To do so, follow these steps:

1. Select the desired ESX host, click the Configuration tab, and click the Networking link under Hardware.

2. Click the Properties link next to the vSwitch that needs the new port group. This opens the Properties dialog box.

3. Click the Add button to activate the wizard (see Figure 2.6).

F I GU R E 2 .6 Adding a port group

4. For the purpose of this exercise, we will create a new virtual machine port group. Select Virtual Machine to add a port group for VMs and click Next.

5. Name the new port group, and optionally set the VLAN ID. Click Next and then Finish. The new port group is now added.

Assigning Physical AdaptersTo determine the number of pNICs inside the ESX host, on the Configuration page, click Network Adapters (see Figure 2.7).

F I GU R E 2 .7 Network Adapters


You’ll see a lot of useful information here. Notice that on this particular host there are four pNICs, each with a potential speed and a configured speed of 1GB Full Duplex. You can also find the MAC address (this is a unique hexadecimal number used by Layer 2 net-work devices). The final two columns show the observed IP ranges (traffic) and the Wake On LAN capability of the NICs.

Sometimes a single pNIC will not provide the bandwidth required to pass your traffic and you will need to add extra NICs to the vSwitch. Exercise 2.2 shows you how to add extra network capacity to the vSwitch.

E X E R C I S E 2 . 2

Adding Network Adapters to a vSwitch

1. On the Configuration tab, click Networking . Click the Properties link for the vSwitch . Then click the Network Adapters tab .

2. Click the Add button to gain access to the Add Adapter Wizard . Here, you can select the NICs you want to add .

Once you have checked the boxes relating to your chosen NICs, remember to con-sider physical resilience . For example, if you have onboard NICs and NICs that are connected via a daughter board or PCI card, consider selecting a port from each environment . That way, if your onboard controller breaks, you will still have con-nectivity via the PCI-based card .


E X E R C I S E 2 . 2 ( c ont i nu e d )

3. Click Next to continue .

4. To configure your selected NICs’ activity, you need to select a NIC by highlighting it and then clicking Move Down to make it a Standby adapter . In the following graphic, you can see that the vSwitch has been configured with three pNICs, two of which are active and one that has been configured as a failover device .

5. Click Next and you will be presented with a summary window . Click Finish to complete the changes .

Modifying vSwitch NIC Teaming and Failover PoliciesTo review or modify the general properties of a vSwitch, click the Properties link for a vSwitch. This will display a dialog box where you can select the vSwitch or port group and edit its properties. When you select the vSwitch from the list and choose Edit, you will see four tabs across the top: General, Security, Traffic Shaping, and NIC Teaming. On the General tab, you will be able to modify the name of the vSwitch as well as change the number of ports on the vSwitch. The other tabs will allow you to edit the security, traffic shaping, and NIC teaming settings for the entire vSwitch (see Figure 2.8). This section will look at the NIC Teaming modifications and failover policies.

The options on the NIC Teaming tab are similar to those you use when setting the trunk information on a physical switch (see Figure 2.9).

Now this is quite a complicated tab, so we will work our way from the top to the bottom.


F I GU R E 2 . 8 Editing the vSwitch

F I GU R E 2 . 9 The NIC Teaming tab

Load Balancing

The VMkernel has three built-in methods of load-balancing traffic out of the uplinks, which was discussed in the section “Determining the VSwitch NIC Teaming Policy,” that have been assigned to the vSwitch:

Virtual Port IDNN

Source MAC HashNN

IP HashNN


Network Failover Detection

The next drop-down box, Network Failover Detection, has two settings:

Link Status Only The default position is Link Status Only; the VMkernel uses this setting to determine whether or not to stop sending traffi c down an uplink based on status of the pNIC. This is a basic setting that only checks the link state of the pNIC.

Beacon Probing The alternative, Beacon Probing, is used for situations where bro-ken links need to be detected one or more hops past the pNIC of the ESX server and the fi rst physical switch. When Beacon Probing is enabled, proprietary packets are sent out from each uplink on the physical LAN. If these packets are received by the uplinks, the VMkernel continues to use those paths for guest traffi c. If an uplink doesn’t receive beacons from the other uplinks, the VMkernel will discontinue use of that uplink, and guests will be reassigned a new uplink.

Beaconing can be helpful, especially in blade environments . However, beacon probing can create false positives and cause the VMkernel to shut down an otherwise good uplink . Networking vendors such as Cisco have published documentation on integrating VMware with their products and when to use beacon probing with the VMkernel .

Notify Switches

The default setting is Yes. This allows the vSwitch to notify the physical switch that changes to the physical switch’s MAC table need to occur. Events like VMotion, uplink status, and new VMs coming online trigger the vSwitch to send out Reverse ARP (RARP) requests to the physical switch that it’s uplinked to.

VMware discusses reasons to change Notify Switches to No in KB article 1556, “Microsoft NLB Not Working Properly in Unicast Mode .”

Failback

The default position is set to Yes. When an uplink (pNIC or vmnic) on a vSwitch goes down, any guest on that uplink will be moved over to another uplink connected to the vSwitch (assuming there are redundant uplinks). If the previous uplink comes back online, the guest will fail back to its original uplink. If Failback is set to No, the guest will continue using its current uplink. The uplink that recently became available will have to wait to be placed back into service by a new guest.

Finally, at the bottom of this page, it is possible to move vmnics from Active to Standby or Unused failover categories. Adapters in Standby mode will not be used until the active adapt-ers have failed. Adapters in the Unused Adapters category are never used by the vSwitch. This option is especially helpful at the port group level if you would like to control how uplinks can be used at that level. To confi gure these settings, highlight the desired pNIC and click the Move Down or Move Up button.


Modifying vSwitch Security Policy and VLAN SettingsThe Security tab allows you to accept or reject policies regarding Promiscuous Mode, MAC Address Changes, and Forged Transmits (see Figure 2.10).

For more on these modes, review the section “Determining the Appropriate vSwitch Security Policies.”

F I GU R E 2 .10 vSwitch Properties, Security tab

Controlling Outbound TrafficThe Traffic Shaping tab allows the configuration of outbound traffic (see Figure 2.11). You’ll notice that this is disabled by default. One important thing to note is that this setting does not control inbound traffic to the vSwitch.

F I GU R E 2 .11 The Traffic Shaping tab

When you enable the drop-down list, you will notice that the remaining three boxes are now available:

Average Bandwidth Allows you to control the number of Kbits/sec averaged over time.

Peak Bandwidth Determines the maximum Kbits/sec the vSwitch can handle before having to queue excess packets for later transmission. If the queue fills up, the packets will be dropped.


Burst Size Determines the number of Kbytes to allow in a burst. If the bursts exceed this limit, packets will be queued until the queue fills up. Once full, packets will be dropped until bursting activity subsides and the queue is emptied.

Configuring VMotionVMotion is the VMware process that moves the running state of a virtual guest from one host to another without any downtime. To configure vMotion, you must add a VMkernel port to one of your configured vSwitches. Alternatively, you could add a new one.

To add a VMkernel port to a currently configured vSwitch, see the section “Creating Ports/Port Groups.”

In Exercise 2.3, we will show you how create a VMkernel port and configure it for vMotion.

E X E R C I S E 2 . 3

Creating a VMkernel Port and Configuring vMotion

1. Click the Properties link for a vSwitch .

2. Click the Add button to activate the wizard . The screen gives you three options . Select the VMkernel radio button and click Next .

3. Enter a name for your port group . Remember to follow any naming conventions that you have established . Next, enter a VLAN ID if necessary and remember to check the Use This Port Group For VMotion check box . Click Next .



4. Enter the desired IP address . You do have the option of using a DHCP address, but it is not considered best practice to do so . If you do not set a VMkernel default gateway, you will be prompted to do so . Click Next .

5. Finally, you can see your configured VMkernel port group with the VMotion property enabled .

Configuring Distributed vSwitchesWith the introduction of VMware vCenter 4, VMware unveiled a new networking capability known as the vNetwork distributed switch (dvSwitch). dvSwitches contain the same basic functionality as standard vSwitches but have several additional benefits, including:

Simplified administration and management through vCenterNN

Support for private VLANsNN

Support for ingress and egress traffic shapingNN

Support for third-party customization and developmentNN

dvSwitch architecture consists of a control plane and an I/O plane. This is where the main difference between a standard vSwitch and a distributed one comes in. The control plane is governed by a vCenter server. The vCenter server is responsible for creating the dvSwitch as well as configuring any policies and settings. The I/O plane is effectively a hidden vSwitch that resides on each ESX host participating in the dvSwitch. Each host provides the vmnic(s) or pNIC(s) for the dvSwitch, which serve as the uplinks to the physical network, and all net-work I/O is managed via each host.

One of the greatest management challenges for an implementer or system admin-istrator in the past in regard to managing vSwitches was making sure that they were

Configuring Distributed vSwitches 89

vMotion-compatible across all ESX hosts. This required that the port groups, policies, and settings all had to be the same on each and every switch on the hosts in a cluster. Otherwise, the VMotion event may not occur. The introduction of dvSwitch simplifies these issues, as the VMs are now effectively attached to a single vSwitch, which will span across all the ESX hosts in the cluster or datacenter. Table 2.2 displays the configu-ration maximums for the dvSwitch.

TA B lE 2 . 2 Distributed vSwitch Maximums

Item Maximum

Total virtual network switch ports per host (dvSwitch and vSS ports) 4096

Distributed virtual network switch ports per vCenter 6000

Distributed port groups per vCenter 512

Distributed switches per vCenter 16

Hosts per distributed switch 64

Determining the Virtual Port Group NIC Teaming and Failover Policy In A Given SituationAt first this seems a little bit familiar, and you are correct that the options regarding teaming and failover policy for the dvSwitch are exactly the same as for a standard vSwitch. The reasons behind the choices are the same too, but you need to remember that here you are configuring once for the dvSwitch and those properties and changes are being propagated to each and every host participating in the dvSwitch.

Figure 2.12 shows the failover and teaming choices for the dvSwitch.NIC teaming is the method for setting policies for a vSwitch or port group to either

load-balance based on certain algorithms or provide failover in time of hardware failure. There are numerous methods to configure multiple NICs and the configuration depends on the needs and restrictions of your design. We’ll describes the per-teaming configurations and the situations where they can be utilized.

Load Balancing This is the teaming of multiple pNICs to form a load-balanced configu-ration to handle the traffic from a vSwitch. The traffic flow is based on one of three load-balancing algorithms centered on either a port-based, MAC-based, or IP-based choice (the last one requires a port channel on a physical switch; the others do not require switch con-figuration). Traffic is distributed across the links, which results in a greater throughput to the physical switch. If an uplink fails in a load-balanced setup, the remaining NIC or NICs will handle all the traffic.


Failover With Failover, only one NIC is active, and the other is basically a standby. If a network error or device failure occurs on the active NIC, the secondary NIC will take over. This configuration is often used in NIC-constrained servers to provide basic separa-tion of traffic between the Service Console and VMkernel, in environments where there is no requirement for large throughput, or when the underlying network is not redundant or capable of supporting redundant uplinks.

F I GU R E 2 .12 Determining teaming and failover

Determining the Appropriate Virtual Port Group Security Policies In A Given SituationAgain you’ll notice a little familiarity. The security setting for a dvSwitch are exactly the same as those for a standard vSwitch. So it is all about Promiscuous Mode, MAC Address Changes, and Forged Transmits (see Figure 2.13).

However, this is where the similarities start to fade. A dvSwitch, just like the standard vSwitch traffic policy, can be shaped. However, here you will notice the option to shape both ingress and egress traffic (see Figure 2.14). Remember previously with the standard vSwitch there was only the ability to shape outgoing traffic.


F I GU R E 2 .13 dvSwitch Security settings

F I GU R E 2 .14 Traffic Shaping

VLANs now have more options, including the ability to trunk and create private VLANs (see Figure 2.15).


F I GU R E 2 .15 Setting VLAN policies

A VLAN trunk is a special uplink that fi lters traffi c by VLAN ID. However, unlike the standard VLAN setting, it can pass multiple VLANs.

Private VLANs (PVLANs) are discussed in more depth later in the chapter .

Ports can be blocked to completely isolate a dvSwitch. The default setting is No to allow traffi c to fl ow.

Under the Advanced settings you can allow a single dvPort to override any setting that has been confi gured previously on the port group (see Figure 2.16). This can enable fi ne granularity of control on your dvSwitch.

Click the Edit Override Settings link to see what can be modifi ed (see Figure 2.17).

F I GU R E 2 .16 Advanced properties

F I GU R E 2 .17 Port Group Override Settings


Creating and Modifying a vNetwork Distributed Switch So let’s take a look at creating a dvSwitch. In Exercise 2.4, we will show you how to create a distributed vSwitch.

E X E R C I S E 2 . 4

Creating a Distributed vSwitch

1. Under Inventory, choose Networking to launch the Create vNetwork Distributed vSwitch wizard .

Notice that there is also a keyboard shortcut to this function: Ctrl+Shift+N .

2. When you have selected your datacenter, you will be presented with the following screen:

Either click the New vNetwork Distributed Switch link or right-click on your datacenter inventory object and choose ”New vNetwork Distributed Switch .”

3. The General Properties form of the Create vNetwork Distributed vSwitch wizard is displayed . Specify the name of your dvSwitch and the maximum number of vmnics (pNICs) that each ESX host will provide for this vSwitch . Then click Next .



4. Next, you have the option of adding your ESX hosts to the dvSwitch now or later . If you choose Add Now, you will be asked which ESX hosts and vmnics you want to add to this dvSwitch:



5. The next option is Automatically Create A Default Port Group . If you want to configure a place for virtual machines to plug into this dvSwitch now, leave this box checked and click Finish .

Now that a dvSwitch has been created, you need to configure it. If you right-click on your dvSwitch, you’ll see the menu shown in Figure 2.18.

F I GU R E 2 .18 dvSwitch context menu

These options can also be managed through the Configuration tab (see Figure 2.19). Do you remember when we first attempted to configure a dvSwitch? We clicked the Distributed vSwitch button in the Configuration/Networks section of the host. Well, now when you click that button, it will display your dvSwitch.

Now, let’s explore the settings of the dvSwitch (see Figure 2.20). You access these settings by clicking Edit Settings on the Configuration tab (refer back to Figure 2.19). Under General settings, you can rename your dvSwitch, as well as change the number of dvUplink ports (this can be raised to the maximum number of physical adapters per host). You can view the number of available ports on this vSwitch as well as type in notes at the bottom. You can also rename your dvUplink port names by clicking the Edit dvUplink port button.


F I GU R E 2 .19 Configuring the dvSwitch

F I GU R E 2 . 20 General settings

Next, click Advanced (see Figure 2.21). Here you will change the MTU settings if you want to turn on jumbo frames for this vSwitch. The Cisco Discovery Protocol option is checked by default, and the dvSwitch will listen for CDP information coming from a Cisco switch uplinked to it. This setting can be changed from Listen to Advertise, or both. At the bottom, there is room to type administrative contact information as well.


F I GU R E 2 . 21 Advanced settings

Next, click the Network Adapters tab (see Figure 2.22). Here you are able to view which ESX hosts are providing uplinks (vmnics) on this dvSwitch. Remember a vmnic is an actual physical adapter (pNIC) being managed by the VMkernel.

F I GU R E 2 . 22 Network Adapters


The final tab on this form is called Private VLANs (see Figure 2.23). The options on this tab allow you to define pVLANs on the dvSwitch. This is a new feature introduced with vSphere and is exclusive to dvSwitches. This feature is not available on standard vSwitches.

F I GU R E 2 . 23 PVLAN settings

Cisco defines PVLANs as a method to provide Layer 2 isolation between ports within the same broadcast domain. There are three types of PVLAN ports:

Promiscuous The promiscuous port is able to communicate with all interfaces, including the isolated and community ports within a PVLAN.

Isolated An isolated port is completely separated from all ports except promiscuous, within the same PVLAN at Layer 2. PVLANs will block all traffic to an isolated port, except traffic originating from a promiscuous port. Further, all the traffic from an isolated port is forwarded only to a promiscuous port.

Community Community ports are a friendly bunch and communicate among themselves and also with their promiscuous ports. As with all the port types, Community interfaces are separated at Layer 2 from all other interfaces (community and isolated ports) within their PVLAN.

VMware fully supports the PVLAN model in their dvSwitch. A primary private VLAN (PVLAN) can be defined on the dvSwitch that will work with VLANs defined on the physi-cal switches. Traffic entering from the physical switches on the defined VLAN will commu-nicate with the dvSwitch. Further, segmentation of traffic is provided by creating secondary


PVLANs on the dvSwitch. Now when traffi c enters the ESX server, the dvSwitch further segments the traffi c by making use of the secondary PVLANs confi gured as one of the three types of secondary PVLAN described earlier.

Any VM that is located inside a promiscuous PVLAN is allowed to communicate with any other as well as with any other VM outside their PVLAN. VMs residing within a com-munity PVLAN are only allowed to communicate with those that are defi ned within their own community, and with other VMs within a promiscuous PVLAN. Virtual machines that are in an isolated PVLAN are unable to communicate with each other, and can only communicate with other VMs inside a promiscuous PVLAN.

To defi ne the PVLANs, double-click on the section titled [Enter a private VLAN ID here]. This value is numeric. Next decide on the type of secondary PVLAN by using the drop-down box that is activated upon entry of a PVLAN ID.

Once the PVLAN has been defi ned on the dvSwitch, the settings will need to be defi ned on a dvPortGroup. Remember, a port group, or in this case, a dvPortGroup, is where vir-tual machines will connect to the dvSwitch. To create a new dvPortGroup on the dvSwitch, simply right-click on the dvSwitch and choose New Port Group.

Creating and Modifying Uplink Group SettingsThe addition or modifi cation of uplinks on a dvSwitch is a simple task. First, select the hardware confi guration page for the desired host by navigating to Inventory and clicking the Host And Clusters view, highlighting the host, clicking the Confi guration tab, and selecting Networking under Hardware. Switch to the vNetwork Distributed Switch view by clicking the displayed button.

Click Manage Physical Adapters to open the wizard. Click Add NIC for the uplink port you want to add an uplink to, select the physical adapter you want to add, click Select, and click OK.

Remember if you select an adapter that is attached to another dvSwitch or standard switch, it will be removed from the original switch and assigned to the device you are configuring . Keep this in mind because this procedure could cause a network outage on your original switch if you have not planned correctly .

Creating and Modifying dvPort Group SettingsThe New Port Group wizard allows you to give your dvPortGroup a name, number of ports, and VLAN type (see Figure 2.24). Click Next and then Finish to create the new dvPortGroup.

If you wish to change the settings on the new dvPortGroup, simply right-click on it and choose Edit Settings. From here, you’ll notice many different items that can be changed. Let’s take a look at Figure 2.25 and move down each one.


F I GU R E 2 . 24 Creating a new dvPortGroup

F I GU R E 2 . 25 Editing settings on a dvPortGroup


Under General, you can specify the dvPortGroup’s name and description, the number of ports, and port binding. Port binding is related to how the VMkernel will assign a VM a port on a vSwitch. The available choices are:

Static The virtual machine is assigned a port on a vSwitch as soon as its vNIC is configured to use the distributed switch.

Dynamic A VM is only assigned a port on the vSwitch when it powers on and its vNIC is connected. This is helpful if you have more VMs connected to the vSwitch than you have ports for. The number of ports on a vSwitch is configurable, so it is possible to increase the number of available ports if necessary.

Ephemeral VMs are assigned ports on a dvSwitch as soon as they communicate on the virtual network. The port group does not have a static number of ports defined and will create additional ports as needed for the vNICs communicating within the port group.

Which Binding Type Should A Company Use?

With vSphere 4 .0, the ability to choose the binding type for a vNetwork Distributed Switch gives the administrator more control options for connecting VMs to the virtual switch . Companies are now able to choose the binding type based on how many VMs exist and how many will be concurrently connected . Let’s break each down within the context of three companies .

The binding type Static assigns a virtual port to a VM whether the VM is powered on or not when the VM is assigned to a distributed switch . If Company “A” has a set number of VMs and wants those VMs to use the same virtual port on the virtual switch every time, static binding achieves this goal . In addition, if there is a need for a single port policy for a specific VM, that can be accomplished since every VM connected to the distributed switch will always connect to the same port . The administrator also chooses the number of ports that the virtual switch will be created with, therefore limiting the number of VMs that will have network access .

The binding type Dynamic assigns a virtual port to a VM when it is powered on . It holds that port for as long as it remains powered on . If Company “B” has a fluctuating number of VMs being powered on and off, dynamic binding will provide ports to only those VMs that are powered on, but not necessarily the same port each time . This provides some flexibility for the administrator and allows more VMs to be assigned to a distributed vSwitch than there are actual ports defined since the number of ports is limited to what is needed for concurrent access . This binding method does not allow specific port polices for a VM since a VM may not use the same port each time it is powered on .


The binding type Ephemeral is the only policy where defining the number of ports on the distributed vSwitch is not needed . In other words, ports are created as needed based on the VMs that are powered on and actually communicating on the virtual switch . As more VMs are powered on, more ports are created, limited only by the maximum number of ports for a virtual switch, 4088 . This method of binding is for companies that need maximum flexibility for concurrent VM network access, such as dynamic desktop pools (using VMware’s View desktop virtualization), kiosks, or temporary VMs needed for conventions . As with dynamic binding, there is no way to set a single port policy with this setting .

Companies are free to choose one or all binding types based on their needs and what they are comfortable with . Static binding is the default setting for distributed switches, so the ability to set single port policies is available immediately .

The next setting is Policies. Here is where you manage the following:

SecurityNN

Ingress and egress traffic shapingNN

VLAN typesNN

Teaming and failoverNN

Failover orderNN

You will notice that the security settings are the same as they were for the standard vSwitches. Traffic shaping for dvSwitches can be controlled inbound and outbound. Remember that on standard vSwitches, we could only control outbound traffic. The VLAN type is set to None by default, which means that the dvPortGroup will only receive and send untagged traffic. If the VLAN type is set to VLAN, tagged packets can be received from uplinked trunk ports on the physical switches. If the VLAN type is set to VLAN Trunking, tagged packets will be sent up to the VMs. Finally, if Private VLAN is used, you’ll need to specify one of the PVLANs that were defined earlier when the dvSwitch was created.

The Teaming and Failover settings are the same as they were for the standard vSwitches. Similarly, you can apply a failover order for the dvPortGroup as well.

There is an Advanced section that allows for overriding port policies, live port moving, configuring reset at disconnect, and formatting port names.

We’ve discussed changing settings on a dvPortGroup, and it’s important to note that all of these same settings can be configured at the dvUplink level as well. There is one notable difference under the Miscellaneous tab that allows for blocking all ports at this level.

Adding a Host to a vNetwork Distributed SwitchThe addition of a new host to a preexisting dvSwitch is a simple task. By right-clicking the distributed switch from the Networking inventory view, and selecting Add Host from the menu, additional hosts can be added to an existing distributed switch. When


the Add Host To vNetwork Distributed Switch wizard appears, click the host you want to add; under the host, add the physical adapters from the host that you want to add to the dvSwitch, and click Next. On the last screen, click Finish.

Remember, you can select both free and in-use physical adapters . However, if you select an in-use adapter, there is the risk of network disruption if you fail to plan properly .

Adding and Deleting a VMkernel dvPortTo migrate the other ports, such as the VMkernel and Service Console, you will need to return to the Add Virtual Adapter wizard, which allows you to create a new port or migrate an existing Service Console or VMkernel port from a standard vSwitch to a dvSwitch (see Figure 2.26).

F I GU R E 2 . 26 Service Console and VMkernel ports

Click Add to launch the Add Virtual Adapter wizard. Select Migrate Existing Virtual Adapters and click OK to continue.

Here you can choose either a distributed virtual port group or a port group (see Figure 2.27). The difference is that if you choose a port group and you have already created the necessary dvPortgroups, you can migrate both the Service Console and any VMkernel ports that have been created in one fell swoop.

When you click Next, you are taken to a review form. Click Finish to fi nalize the migration.

You will need to complete this procedure for each host that is to be migrated into the dvSwitch .


F I GU R E 2 . 27 Service Console and VMkernel port migration

Migrating Virtual Machines to a vNetwork Distributed SwitchOur last topic related to dvSwitches is how to connect the Service Console, VMkernel, and virtual machines. If you want to connect virtual machines to a dvSwitch, you can edit each VM’s vNIC settings or use the Migrate Virtual Machine Networking wizard. Right-click on the dvSwitch to move multiple VMs at once (see Figure 2.28).

F I GU R E 2 . 28 Migrating VM networking

Configuring the VMware ESX/ESXi Management Network 105

To virtually migrate the settings, select the source network and then the destination network. Click Show Virtual Machines to display all the machines that are served by that network. Check the appropriate boxes and click OK to migrate. Verify that the machines have been migrated by clicking the Virtual Machine tab.

Configuring the VMware ESX/ESXi Management NetworkWhether you choose to connect to the physical network using standard or distributed vSwitches, you will need to know how to configure and manage your Service Console and VMkernel ports. In this section, we will show you how to accomplish this.

During the installation of ESX, you were asked to provide IP address settings and uplink information to automate the creation of the standard vSwitch0 and Service Console port. If you are using ESXi, there is no Service Console; rather, a VMkernel port was created and con-nected to a standard vSwitch0 for management purposes (see Chapter 1, “Planning, Installing, and Upgrading VMware ESX/ESXi”). When it becomes necessary to create additional Service Console or VMkernel ports, click the Add Networking link on the standard vSwitches and then the Manage Virtual Adapters link for the dvSwitch (as we discussed earlier).

It is always wise to provide redundancy in your network design. VMware recommends multiple Service Console and VMkernel ports (on different subnets) when possible, or at the very least, multiple uplinks on your vSwitches. We need to eliminate single points of failure. This includes having multiple physical switches as well.

In Exercise 2.5, we will show you how to edit existing Service Console and VMkernel ports.

E X E R C I S E 2 . 5

Editing Service Console and VMkernel Settings

1. Under Configuration, click Networking, and then select Virtual Switch . Click on Properties for vSwitch0 . Click Service Console, choose Edit . You will see the follow-ing warning message . Read it carefully .



Remember to be careful when making changes here, since incorrect settings could cause your Service Console to become disconnected from the network . Click Cancel . We will deal with this later .

2. Next, let’s look at the VMkernel port settings . Click on VMkernel and choose Edit . This dialog box should look familiar . Note that you can change the VMkernel IP Address settings as well as turn on VMotion and Fault Tolerance Logging, which are discussed in Chapter 8, “Managing and Creating VMware Clusters .”

3. The final location needed to complete the modification of the special ports is found here . Click Configuration and select DNS And Routing . Then click Properties to edit the Service Console and VMkernel’s DNS, domain, and default gateway information .

Configuring the VMware ESX/ESXi Management Network 107

In summary, vNetworking offers a lot of flexibility when designing and incorporating vSphere into your existing physical network. By knowing how to create vSwitches, add Service Console and VMkernel ports, connect virtual machines to vSwitches, and change settings on all of these things, you are well on your way to building a robust and resilient infrastructure.

In the following sections we will investigate the modification of the Service Console network settings.

Modifying Service Console IP SettingsThe Service Console is an integral part of ESX. It is used to provide management facilities to the host. On the installation of the host, you are required to configure a Service Console with IP addresses; it can be a static or DHCP-assigned address. After installation has been com-pleted, you can add more Service Consoles, and you can change their configuration or even delete a Service Console. The Service Console is attached to one of the two special ports on a vSwitch. Remember, just because the switch is being used to carry Service Console traffic, that does not preclude it for other uses, but best practice is to limit the amount of traffic that this vSwitch has to handle (for example, no IP storage traffic if possible). It is also considered best practice to logically separate your Service Console from the networks carrying your virtual machines.

In Exercise 2.6, we will show you how to edit the Service Console interface.

E X E R C I S E 2 . 6

Editing the Service Console Interface

1. To change the IP settings of an existing Service Console, navigate to Configuration, click Networking, and select Virtual Switch .

2. Click on Properties for vSwitch0 .

3. Click Service Console and choose Edit . Remember you will receive a warning . Do take note of it, however, this time click Continue Modifying This Connection .

4. Select the IP Settings tab .

5. Change the IP settings to your needs . Network connectivity will probably be lost .


Configuring Service Console AvailabilityService Console availability or resilience can be configured in one of two ways:

Assign multiple NICs to the vSwitch where the Service Console port is running. When NN

wired adequately to different switches, this will provide a level of high availability for your Service Console. It will protect you against NIC, wire, and switch failure.

Create a second Service Console port (vswif). This will preferably be on a different virtual NN

switch. If the original vswif port fails, the other vswif port can be used with features such as the heartbeat used with VMware HA.

Configuring DNS and Routing Settings for an ESX HostDNS is increasingly becoming a necessity in a virtual infrastructure. In vSphere, it is integral to HA, and it is heavily utilized in VMware Update Manager (VUM).

DNS stores all the machine names and their respective IP addresses in a central distributed database. Think of it as a telephone directory service. Routing is effectively a pointer to other networks. Without a default gateway, your ESX server would not know where to send pack-ets that are destined for a location different from its own subnet.

To configure DNS and routing, in the Hosts And Clusters view, click select DNS And Routing link in the Software section on the Configuration tab of a host (see Figure 2.29).

Next, click the Properties link to display the DNS And Routing Configuration dialog box shown in Figure 2.30.

Here, you can change the hostname of the ESX server. Remember that ESX is part of the Unix family and as such MYHost is a completely different name from myhost (the name is case sensitive). You can also change the default domain.

If you are obtaining your IP information from a DHCP server (this is not recommended unless there is a reservation set for the server), choose the option Obtain DNS Server Address Automatically. However, it is better to statically assign your DNS information. In the final box, you set the default DNS search domain.

F I GU R E 2 . 29 DNS And Routing

Configuring the ESXi Management Interface 109

F I GU R E 2 . 3 0 DNS And Routing Configuration dialog box

Next click the Routing tab to display options shown in Figure 2.31.

F I GU R E 2 . 31 The Routing tab

Here you can change your default route out of your home subnet. You can also set a VMkernel default gateway for the Service Console. This is not a necessity unless you are vMotioning outside your home subnet, or your iSCSI or NFS storage is on a subnet different from your host’s.

Configuring the ESXi Management InterfaceSo far we have concentrated on the ESX interface. This has not been an issue thus far as there is a commonality of functions between ESX and ESXi. The major difference between ESX and ESXi is the lack of a Service Console. In the section on configuring Service Console port groups, we mentioned that the procedure did not relate to ESXi. This is because with


ESXi the management traffic is carried over a VMkernel port. It is now time to consider the configuration of the management interface of ESXi.

Even though ESXi does not have a Service Console, it still requires an access point to allow the connection of the vSphere Client either directly or via a vCenter instance. In ESXi, this interface is referred to as the management interface and is a VMkernel port.

Configuring the Management InterfaceClick the Configuration tab and then click the Networking link. This will display all the standard vSwitches for the environment (see Figure 2.32).

F I GU R E 2 . 32 Configuration tab displaying all the standard vSwitches

Click the Properties link directly above the vSwitch you need to configure. You will now be presented with the vSwitch Properties dialog box shown in Figure 2.33.

F I GU R E 2 . 3 3 vSwitch Properties

Configuring the ESXi Management Interface 111

Highlight Management Network and click Edit. This will bring up the Management Network Properties dialog box. Enable Management Traffic and click OK. This will return you to the vSwitch properties.

Next we will add a second management interface to the ESXi host. This is often done as a form of resilience.

Adding a Second Management InterfaceIn the vSwitch Properties dialog box, click the Add button to launch the Add Network wizard. Notice that this version provides only two options related to port group selection: Virtual Machine and VMkernel (see Figure 2.34).

F I GU R E 2 . 3 4 Connection types

Select VMkernel and click Next to continue. This opens the VMkernel Connection Settings screen. Again, this screen on first glance looks similar. However on closer inspec-tion, you will see a third check box: Use This Port For Management Traffic. Check the box and click Next to continue (see Figure 2.35).

F I GU R E 2 . 3 5 VMkernel connection settings

Next we add the IP address and gateway to the port group (see Figure 2.36). This can either be a statically assigned address or obtained by DHCP. If you are using DHCP to assign your IP addressing, we recommend that you reserve the address in the DHCP scope.

F I GU R E 2 . 36 Setting IP details


The final screen is a summary of the configuration changes you are about to make; review them and click Finish. If you did not set a default gateway during your configuration, you may receive an error message informing you that there is no default gateway set; you will be asked if you want to configure one now. If you choose Yes, you are presented with the DNS And Routing Configuration dialog box open to the Routing tab.

SummaryThis chapter highlighted the core elements of the networking component of the VCP exam.

We covered the theory behind the various switching models in vSphere. We also explained how to create, configure, and modify both standard and distributed vSwitches and their port groups. Finally, we showed you how to configure the management inter-face on an ESX/ESXi host.

Exam Essentials

Know how to create and respond to connectivity alarms. List the various connectivity alarms and possible actions for each. Practice the creation of a connectivity alarm. Be able to describe the relationship between the alarm and the resource.

Know how to Create and Configure Virtual Switches. Create vStandard Network Switches and configure their use. Understand how to configure NIC teaming, security policies, and VLAN IDs

Know how to Create and Configure vNetwork Distributed Switches. Be able to create a vNetwork Distributed Switch. Be able to configure NIC teaming, security, and failover polices. Understand the three different binding types.

Know how to Configure VMware ESX/ESXi Management Network. Be able to create a management interface for either ESX or ESXi host.

Configure DNS and Routing settings for an ESX Host. Be able to configure DNS and routing for an ESX/ESXi host by using the vSphere Client.

Review Questions 113

Review Questions

1. Which distributed vSwitch port binding policy essentially mimics the dynamic binding of a standard vSwitch?

A. Primary

B. Static

C. Dynamic

D. Ephemeral

2. What is the maximum number of ports you can have defined on a vNetwork standard switch?

A. 56

B. 1016

C. 1024

D. 4088

E. 4096

3. What is the default number of dvUplink ports on a newly created distributed vSwitch?

A. 4 per ESX/ESXi host

B. 8 per ESX/ESXi host

C. 4

D. 8

E. 16

4. You would like to have a VM scan and capture all packets on the virtual switch it is connected to. Which security policy would you have to set to allow this?

A. Forged Transmits

B. MAC Address Change

C. Promiscuous

D. Port Scan

E. Protocol Analyzer Mode

5. Which of the following is not a physical NIC mode when you are manually configuring failover for a teamed vSwitch?

A. Active

B. Passive

C. Standby

D. Unused


6. You have a vSwitch with 56 ports, all of which are in danger of being used up by the increasing number of VMs you are attaching to the vSwitch. In the vSphere Client GUI, you increase the number of ports on the switch to 120. However, after increasing the port count, you are unable to add any additional VMs to the switch. Why?

A. You have to remove all current VMs from a virtual switch before changing the number of ports.

B. The ESX server needs to be rebooted.

C. Changing the port count on virtual switches is not supported.

D. You must power off all VMs using the virtual switch to change the number of ports.

7. Which of the following may be present on a physical switch but not a virtual switch?

A. Teaming

B. Spanning Tree

C. Traffic Shaping

D. Private VLANs

8. After converting a physical machine to a virtual machine, you are interested in using the old physical machine’s MAC address in the VM (say to ease the implementation of application licensing). Which of the following security policies would you need to set?

A. Forged Transmits

B. MAC Address Changes

C. Promiscuous

D. Allow Any MAC

9. When would you choose Virtual Port ID-based load balancing on a teamed virtual switch?

A. You need to guarantee all virtual machines can individually have access to the com-bined bandwidth on the teamed switch.

B. You don’t have any particular per-virtual machine bandwidth requirements and you want to use the lowest-cost load-balancing policy.

C. You want to ensure virtual machines have the maximum opportunity to failover to redundant physical NICs.

D. You need to maximize the security of the virtual switch.

10. Which of the following are settings for egress traffic shaping?

A. Burst Size in Mbits

B. Burst Size in KBytes

C. Peak Bandwidth in Kbps

D. Average Bandwidth in Mbps


11. How many ESX/ESXi hosts can be connected to a distributed virtual switch?

A. 8

B. 16

C. 32

D. 56

E. 64

12. How would you successfully add a second, redundant management interface to an ESXi 4.0 server?

A. Add a second physical NIC to the existing management interface.

B. Create a new VMkernel port on a different vSwitch and configure it for management.

C. Create a new Service Console virtual switch and configure it for management.

D. Add a second VMkernel port group to the existing management virtual switch.

13. Which of the following settings is exclusive to a distributed vSwitch?

A. Private VLANs

B. Port Blocking

C. Egress Traffic Shaping

D. VLAN Trunking

E. Port Group Override Settings

14. You are interested in a virtual machine (hosting a web server, for instance) so you can take advantage of the combined bandwidth of two 1 GB physical NICs connected to a production vSwitch. If this virtual machine has a single virtual NIC, which of the follow-ing load-balancing policies should you set on the production vSwitch?

A. Virtual ID port based

B. Source MAC based

C. IP based

D. Round Robin

E. Fixed

F. Most Recently Used

15. Which of the following is not unique to a distributed vSwitch?

A. Virtual machine network statistics that follow the VM after a VMotion migration

B. Third-party plug-in support

C. Egress traffic shaping

D. Per-VM port blocking


16. Which of the following is required to configure VMotion on a virtual switch?

A. Create a Service Console port group, assign a unique IP address and subnet number, and select the Use This Port Group For VMotion check box.

B. Create a VMkernel port group on the Service Console (network management) virtual switch, and assign a unique IP address and subnet number.

C. Create a VMkernel port group on the virtual machine network, and assign a unique IP address and subnet number.

D. Create a VMkernel port group, assign a unique IP address and subnet number, and check the Use This Port Group For VMotion check box.

17. When configuring private VLAN (PVLAN) settings on a distributed vSwitch, you want to ensure all the virtual machines in a port group can communicate with each other but not with most other port groups. What type of PVLAN would you select?

A. Primary

B. Secondary

C. Promiscuous

D. Community

E. Isolated

18. How could you have a virtual machine utilize the bandwidth of two or more physical NICs on a vSwitch?

A. Add additional virtual NICs to the virtual machine.

B. Use IP-based load balancing on the teamed virtual switch.

C. Use virtual port–based load balancing on the teamed virtual switch.

D. Use Source MAC–based load balancing on the teamed virtual switch.

19. Which of the following functions are not provided by a VMkernel port in either a standard or distributed vSwitch?

A. VMotion

B. iSCSI storage access

C. Distributed Resource Scheduler (DRS)

D. Service Console management

E. NFS storage access

F. SMB storage access

20. Which of the following would not trigger the VMkernel to send out a Notify Switches RARP packet to a physical switch?

A. Powering on a VM

B. Cold migration of a VM

C. Hot migration of a VM

D. Change in uplink status of a physical NIC



1. D. Ephemeral binding on a distributed vSwitch is the same as the dynamic binding used on standard vSwitches.

2. D. Standard vSwitches allow for a maximum of 4088 ports (4096 – 8, with eight ports reserved for the VMkernel’s internal switch management use). Note the maximum for distributed vSwitches is 4096.

3. A. A distributed vSwitch, by default, supports a maximum of 4 dvUplinks (physical NIC adapters) per ESX/ESXi host.

4. C. Putting a vSwitch port group into Promiscuous mode allows all VMs connected to that port group to put their vNICs into Promiscuous mode as well, thereby allowing for the capture of all packets on their VLAN.

5. B. When manually configuring failover for a vSwitch, each physical NIC can be put into one of three modes: Active (this physical NIC will be used for network communication), Standby (this NIC will be available for failover), and Unused (this NIC will not be used). Unused, in particular, is helpful when defined at the per-port group level.

6. B. Changing the number of ports on a virtual switch requires that an ESX server be rebooted before the changes can take effect. Using VMotion to move the VMs to another ESX host first, although not required, would allow for the change in a nondisruptive way to the VMs.

7. B. Virtual switches, as they cannot be interconnected, have no need for, nor do they support, the Spanning Tree protocol.

8. A. Setting Forged Transmits to Allow is the only way to set a MAC address within a VM to any arbitrary MAC address (including reusing an old physical server’s MAC address). Mac Address Changes only allows changing the VM’s MAC address via its VMX file and then with the restriction of only using the VMware approved MAC address range: 0:50:56:00–3f:xx:yy (where the fourth octet must be in the range 00–3f, and xx and yy can be any hexadecimal numbers you choose).

9. B. With Virtual Port ID-based load balancing, individual virtual machines (assuming they have a single virtual NIC) will only have access to a single physical NIC’s bandwidth at any moment in time. To simultaneously utilize the bandwidth of multiple physical NICs, you would have to use the IP-based load-balancing policy. The Virtual Port ID load-balancing policy also has the benefit of being the default and, generally, the lowest “cost” in terms of VMkernel management effort.

10. B, C. The traffic shaping settings are Average Bandwidth in Kbps, Peak Bandwidth in Kbps, and Burst Size in KBytes.

11. E. Distributed virtual switches support a maximum of 64 ESX/ESXi hosts each.


12. A, B. For true redundancy, you would need to use a second physical NIC connected to a second VMkernel virtual port group. Remember, ESXi servers do not use Service Console ports as ESXi does not have a Service Console. Creating a second VMkernel port on a different vSwitch would offer more redundancy than merely adding a second NIC to an existing virtual switch. as you could configure a completely isolated redundant path, including a separate default gateway.

13. A, B, D, E. Egress (outbound) traffic shaping is supported on both standard vSwitches as well as distributed vSwitches. All of the other answers are unique to the new vSphere distributed vSwitches.

14. C. Of the three load-balancing vSwitch teaming policies (Virtual ID port based, source MAC based, and IP based), only IP based allows for using multiple physical NICs in a virtual machine containing a single virtual NIC. Remember, the use of the IP-based load-balancing policy requires that proper trunking be configured on the physical switch as well.

15. C. Distributed vSwitches add ingress traffic shaping (egress traffic shaping has been part of the standard vSwitch for a long time), per-VM port blocking capabilities, VM network statistics that follow the VM across VMotion migrations, and third-party plug-in support.

16. D. VMotion requires a VMkernel port group with the IP address and subnet defined. In addition, the Use This Port Group For VMotion check box must be selected; otherwise, the VMkernel will not use it for VMotion purposes.

17. D. VMs on a community PVLAN can communicate with each other and with the (generally few) VMs on promiscuous PVLANs, but not with any other community or isolated PVLANs by default. For a VM in a community PVLAN to communicate with VMs on another com-munity or isolated PVLAN you would have to configure a router in a promiscuous PVLAN.

18. A, B. Adding a second virtual NIC to a virtual machine allows, with any of the load-balancing policies on a teamed switch, the virtual machine to utilize multiple physical NICs up to the number of virtual NICs you have added to the virtual machine. Using the IP-based load bal-ancing allows for virtual machines with a single virtual NIC to use multiple physical NICS.

19. D, F. VMkernel ports provide VMotion, iSCSI, and NFS access. Since DRS requires VMotion, a VMkernel port is also used and needed for DRS functionality. SMB is not a supported file sharing protocol within the VMkernel for storage access.

20. Answer: B. If you have Notify Switches set (the default), the VMkernel will send an RARP packet to notify a physical switch whenever there is a need for the physical switch to update its internal MAC table. VMotion, powering on a VM, and physical NIC uplink status changes can all result in this RARP notification being sent. With cold migration, the VM isn’t powered on; no packets will be sent from the VM until it is powered on, and so there is no need to notify the physical switch.

Chapter

3Configuring ESX/ESXi Storage


Configure FC SAN Storage.NÛ

Identify FC SAN hardware components .NN

Identify how ESX Server connections are made to NN

FC SAN storage .

Describe ESX Server FC SAN storage addressing .NN

Describe the concepts of zoning and LUN masking .NN

Configure LUN masking .NN

Scan for new LUNs .NN

Determine and configure the appropriate NN

multi-pathing policy .

Differentiate between NMP and third-party MPP .NN

Configure iSCSI SAN Storage.NÛ

Identify iSCSI SAN hardware components .NN

Determine use cases for hardware vs . software iSCSI NN

initiators .

Configure the iSCSI Software Initiator .NN

Configure Dynamic/Static Discovery .NN

Configure CHAP Authentication .NN

Configure VMkernel port binding for iSCSI Software NN

multi-pathing .

Discover LUNs .NN

Identify iSCSI addressing in the context of the host .NN

Configure NFS Datastores.NÛ

Identify the NFS hardware components .NN

Explain ESX exclusivity for NFS mounts .NN

Configure ESX/ESXi network connectivity to the NAS device .NN

Create an NFS Datastore .NN

Configure and Manage VMFS Datastores.NÛ

Identify VMFS file system attributes .NN

Determine the appropriate Datastore location/configuration NN

for given virtual machines .

Determine use cases for multiple VMFS Datastores .NN

Create/Configure VMFS Datastores .NN

Attach existing Datastore to new ESX host .NN

Manage VMFS Datastores .NN

Group/Unmount/Delete Datastores .NN

Grow VMFS volumes .NN

In this chapter, we’ll take a look at the topics and aspects of storage that are covered on the VCP-410 test. Storage plays a big role with vSphere-related features such as VMotion, Distributed

Resource Scheduler (DRS), and High Availability (HA). By utilizing storage that can be shared between several hosts, you can take full advantage of these features. Section 3 of the VMware vSphere Exam Blueprint contains four objectives that the certification candidate will need to master before taking the exam.

First, we’ll discuss the setup and management of fiber-based datastores on SANs. We’ll explore Fibre Channel (FC) hardware components, show you how ESX connects to FC stor-age, examine FC addressing, and describe the concepts of switch zoning and LUN masking.

Next we’ll look at working with iSCSI storage. For the exam, you’ll need to identify iSCSI hardware components and understand when to use hardware or software iSCSI initiators. You’ll need to know what steps are taken to configure the software initiator. We’ll also look at the difference between dynamic and static target discovery. We’ll show you how to config-ure Challenge Handshake Authentication Protocol (CHAP) authentication, VMkernel port binding for software multipathing, and iSCSI addressing on an ESX server.

Then we’ll focus on NFS datastores. We’ll discuss the hardware components and ESX server access to NFS mounts. We’ll show you how to configure ESX network connectivity with an NFS device and how to create a Network File System (NFS) datastore.

Finally, this chapter explores virtual machine file system (VMFS) datastores and how they’re configured and managed. We’ll look at the file system attributes and show you how to determine the best location for virtual machines (VMs). Also, we’ll present use cases for using multiple VMFS volumes. In addition, you’ll learn how to create and con-figure a new VMFS datastore, discover an existing VMFS datastore with a new ESX host, and grow a VMFS volume.

Configuring FC SAN StorageIn many vSphere environments today, the type of storage used is a Fibre Channel–based storage area network (SAN). There are many reasons for this, but the primary reason usually centers on performance. Although iSCSI and NFS can hold their own in the performance category when using the latest Ethernet technologies, the edge goes to FC SANs due to the maturity of the technology and bandwidth of the topology.

We’ll cover eight sub-objectives in this section:

Identifying FC SAN hardware componentsNN

Identifying how ESX Server connections are made to FC SAN storageNN

122 Chapter 3 N Configuring ESX/ESXi Storage

Describing ESX Server FC SAN Storage addressingNN

Describing the concepts of zoning and LUN maskingNN

Configuring maskingNN

Scanning for new LUNsNN

Determining and configuring the appropriate multipathing policiesNN

Differentiating between NMP and third-party MPPNN

Identifying FC SAN Hardware ComponentsThe key system components for ESX/ESXi server architecture include the following:

Virtualization Layer VM virtual hardware to physical hardware resource access is handled by the virtual machine monitor (VMM) and the VMkernel. This layer schedules VM disk access and Service Console disk access. The VMkernel uses drivers that are modified Linux drivers to access the physical storage, but do not infer from this that the VMkernel is based on Linux—it isn’t.

Hardware Interface Components VMs use virtual device drivers that are specially written to provide performance without exposing the underlying physical hardware to the VM.

User Interface Several tools can be used to view and manage the ESX/ESXi servers and VMs access to storage:

vSphere ClientNN

vSphere Web Access ClientNN

vCLI/vMA remote command-line accessNN

A SAN is many things. Certainly, there is the storage array itself. The storage array provides the physical disks and is managed by software provided by the vendor to create logical volumes for use by ESX. There are FC switches (SAN fabric) that connect the stor-age array to the many hosts needing access to highly available volumes. On the ESX/ESXi hosts themselves, the connectivity devices are known as host bus adapters (HBAs). Include the cabling and you have an FC SAN that encompasses the whole topology. Figure 3.1 shows an example of an FC SAN and ESX connectivity.

The protocol that makes use of this topology is the FC protocol. This protocol encap-sulates SCSI block-level commands into FC frames for transmission between hosts and the storage array.

Identifying How ESX Server Connections are Made to FC SAN StorageESX/ESXi servers use the SAN topology to make connections to the storage array. By utilizing their HBAs, ESX servers begin the connection process. The HBAs are usually connected to fiber switches. Although each ESX server will probably have two or more HBAs installed, only one HBA is used for any logical unit number (LUN) at a given time.

Configuring FC SAN Storage 123

F I GU R E 3 .1 ESX FC SAN components

ESX Host

HBA 1 HBA 2

SP A

SAN

LUNs

SP B

FC Switch A FC Switch B

Each device, whether an HBA, fiber switch, or the storage array itself, connects to the SAN topology via ports. Ports are usually addressed by two methods:

WWP World Wide Port Numbers (WWPNs) WWPNs are globally unique identifiers that applications use to access the port.

PortIDs PortIDs are FC addresses that uniquely identify each port. The PortID allows routing between devices logged into the SAN. N-Port ID Virtualization (NPIV) uses a single FC HBA port but registers multiple WWPNs for that port. Each WWPN ultimately is assigned to individual VMs so that the storage array administrator can better analyze which VMs are consuming the most bandwidth on the SAN.

Figure 3.2 shows the basic fiber topology between ESX hosts and the storage array.

F I GU R E 3 . 2 ESX WWPNs

The ESX/ESXi administrator’s job is to utilize the FC SAN as efficiently as possible while providing good performance for the VMs that are ultimately stored and run there. There are four considerations to establish the difference between a VM’s responsibilities and the ESX/ESXi server’s responsibilities:

Traditional SAN tools cannot monitor specific VM operating systems; you need to use NN

the vSphere Client to monitor the VMs.


A VM is usually configured with one virtual disk and one SCSI controller by default. NN

Modify the VM’s settings for SCSI controller type and SCSI bus sharing.

HBAs are only seen by the ESX/ESXi administrator and not the VM’s administrator.NN

Multipathing is the job of the ESX/ESXi server, not the VM or software running in NN

the VM.

Describing ESX Server FC SAN Storage AddressingESX/ESXi addressing revolves around FC addresses known as World Wide Names (WWN). These addresses are similar in concept to Media Access Control (MAC) addresses used in Ethernet and are in hexadecimal. Half the address denotes the vendor that manufactured the HBA or storage array, and the other half denotes the unique address of the adapter or storage processor of the disk array.

Figure 3.3 shows addressing on both the ESX side and the storage side.

F I GU R E 3 . 3 Addressing in an FC SAN

WWNs are the basis for communication on the FC SAN topology, but storage adminis-trators usually give each ESX/ESXi host an alias and assign the WWNs to that alias since the hexadecimal addresses are tedious to use.

Describing the Concepts of Zoning and LUN MaskingOnce the ESX/ESXi servers are connected to the FC SAN topology, they need to be given access to LUNs on the storage array. Before that can happen, the ESX hosts must be given access to the disk array by a technique known as zoning. This is done on the fiber switches and ensures that a host communicates only with certain storage processors or communication ports on the storage array. A storage array may have many storage pro-cessors, but in general, each ESX server is given access to at least two storage processors for fault tolerance.

Zoning is accomplished in two ways on most fiber switches:

Hard Zoning The ESX server is connected to a port on the switch, and this port is then mapped or zoned to communicate with a particular storage processor, also connected to the switch.

Soft Zoning The ESX server is connected to a port on the switch, and the administrator then adds the ESX server’s WWNs or alias to a list of servers allowed to communicate with a storage processor or processors also connected to the switch. Soft zoning has the benefit of allowing the ESX server’s connection to be on any port, not a particular one.


Masking is the storage administrator’s technique of providing visibility to specific LUNs to specific hosts. A host may be given access to one or more LUNs. Each storage processor, through the use of masking, presents to the host only those LUNs that have been assigned to that host. All other LUNs that have been created on the disk array will be “masked” away from that host. This approach allows granular control of LUN visibility so that hosts write only to those LUNs they are supposed to.

Configuring LUN MaskingMasking is almost always done on the storage array side by using the array’s manage-ment software. Limited masking can be done on the ESX server side. This allows the ESX server administrator to hide individual LUNs from a particular host temporarily or indefinitely. LUN masking on the ESX server used to be accomplished through the Virtual Infrastructure Client, now the vSphere Client, but no longer. By using the vSphere CLI, a claim rule can be created that masks individual LUNs on an ESX server. In Exercise 3.1, you’ll create a claim rule for masking a LUN.


Creating a Claim Rule for Masking a lUN

1. Log into the vCLI, either installed on your PC or using the vSphere Management Assistant (vMA) .

2. Check to see what claim rule would be next on the list . If rules for 101 and 102 were already in use, then the next rule could be 103:

#esxcli corestorage claimrule list

3. Add new claim rules to mask LUN 1 on HBA 1 and 2 and targets 0 and 1:

#esxcli corestorage claimrule add -P MASK_PATH -r 103 -t location -A vmhba1

-C 0 -T 0 -L 1

# esxcli corestorage claimrule add -P MASK_PATH -r 104 -t location -A vmhba2

-C 0 -T 0 -L 1

esxcli corestorage claimrule add -P MASK_PATH -r 105 -t location -A vmhba1

-C 0 -T 1 -L 1

esxcli corestorage claimrule add -P MASK_PATH -r 106 -t location -A vmhba2

-C 0 -T 1 -L 1

4. Load the new claim rules:

#esxcli corestorage claimrule load

5. List the claim rules to see if the preceding commands were accepted:

#esxcli corestorage claimrule list



6. If a claim rule for the masked path already exists, remove it:

#esxcli corestorage claiming unclaim -t location -A vmhba1

#esxcli corestorage claiming unclaim -t location -A vmhba2

7. Run the claiming path rules defined earlier:

#esxcli corestorage claimrule run

Scanning for New LUNsAt boot, ESX/ESXi servers scan the FC SAN for LUNs that have been masked to be seen by the host. But how is the server to find new LUNs after the server has booted? In vSphere Client, there is an easy method for doing so. Choose the ESX server in the inventory panel, click the Configuration tab, and click the Storage Adapters link in the Hardware section. Then choose one of the HBAs from the informational panel and click the Rescan link in the top-right corner to scan the storage array.

An ESX/ESXi server can use up to 256 LUNs and up to 16 HBA ports when communi-cating with the storage array. Figure 3.4 shows Rescan dialog box that you use to scan for new LUNs after they have been created on the storage array.

F I GU R E 3 . 4 Scanning for new LUNs


Determining and Configuring the Appropriate Multipathing PolicyChoosing and configuring multipathing for ESX/ESXi servers depends on several factors. In some cases, the storage array will dictate which policy you will use. In others, a need to dis-tribute loads will be the determining factor. In all cases, multipathing is used to allow the host to maintain connectivity to the storage array in case there is a failure on the FC topology.

Three multipathing polices are in use today natively on ESX/ESXi based on the Native Multipathing Plug-in (NMP):

Most Recently Used (MRU) Selects the path ESX/ESXi used most recently to access a given LUN. Allows for path failover in case of a failure on the FC fabric. This policy does not allow for a preferred path or failback to a preferred path.

Fixed Allows the ESX administrator to select a “preferred” path for a given LUN. This is useful in manually distributing load for many LUNs across as many paths as the ESX server has visibility. If the preferred path is unavailable or a path fault occurs, the policy allows for switching to an alternate path. If the preferred path comes back online, the VMkernel “fails back” to the preferred path.

Round Robin Chooses a path for each LUN by rotating through all available paths.

For each LUN presented to an ESX server, the administrator can access that LUN’s prop-erties and manage its multipathing policy. If the storage array uses an active-passive storage processor design, MRU is typically used. If the storage array uses an active-active storage pro-cessor design, Fixed or Round Robin may be used. Figure 3.5 shows the dialog box that allows you to choose one of these policies.

F I GU R E 3 .5 Choosing a multipathing policy


Differentiating Between NMP and Third-Party MPPsVMware has changed the architecture of the VMkernel and its access to storage by using a modular approach called a Pluggable Storage Architecture (PSA). This architecture uses a modular approach to storage access and managing I/O requests. The VMkernel uses a default multipathing plug-in called the Native Multipathing Plug-in (NMP) that provides support of all storage arrays on the SAN Compatibility List. The NMP uses the multipathing policies we just discussed to choose the most appropriate path for a given LUN.

The NMP uses a native plug-in for array specific operations known as the Storage Array Type Plug-in (SATP). An SATP handles path failover for the storage arrays on the HCL. There are three types of SATPs provided by VMware:

Active/passive, nonspecific storage arrayNN

Active/active, nonspecific storage arrayNN

Local, for locally attached storageNN

The SATPs included with ESX server are non-vendor-specific and can perform standard operations such as detecting path state and activating a previously inactive path in case of a path failure.

Path Selection Plug-ins (PSPs) are used by the VMkernel to select a physical path for I/O requests. The three PSPs, which were covered in the previous section, are

Most Recently UsedNN

FixedNN

Round RobinNN

Both the SATPs and the PSPs are part of the overall NMP provided by VMware.As an alternative or replacement for the NMP, a third-party multipathing plug-in (MPP)

can be used that is storage array–specific and that utilizes features and/or load-balancing algorithms that a particular storage array provides.

Table 3.1 summarizes many of the storage maximums for VMFSs that you need to know for the exam.

TA B lE 3 .1 VMFS Storage Maximums

Fibre Channel Maximum

LUNs per host 256

Paths to a LUN 16

HBAs per host 8

HBA ports 16

Source: Configuration Maximums (VMware)

Configuring iSCSI SAN Storage 129

Configuring iSCSI SAN StorageUsing iSCSI with ESX/ESXi servers has become common today. In many environments, using iSCSI is just a natural extension of the Ethernet network. Although storage has not traditionally been discussed in an Ethernet context, with the advent of iSCSI and NFS the use of those networks to transmit disk I/O is well understood and accepted.

Many operating systems come with a software initiator. This often eliminates the need for a dedicated hardware initiator. In early implementations of ESX/ESXi servers, the hardware initiator was more efficient at processing SCSI data and communicating with the storage array. That is not necessarily the case today.

There are eight sub-objectives in this section:

Identifying iSCSI SAN hardware componentsNN

Determining use cases for hardware vs. software iSCSI initiatorsNN

Configuring the iSCSI software initiatorNN

Configuring dynamic/static discoveryNN

Configuring CHAP authenticationNN

Configuring VMkernel port binding for iSCSI software multipathingNN

Discovering LUNsNN

Identifying iSCSI addressing in the context of the hostNN

Identifying iSCSI SAN Hardware ComponentsThe hardware components used for an iSCSI topology are similar to an FC SAN but use Ethernet-based devices. As Figure 3.6 shows, the storage array is identical except for the Ethernet-connected targets. Ethernet switches are used instead of fiber switches. The hard-ware initiators or iSCSI HBAs are also Ethernet-connected. If the software initiator is used, standard 1 GB or 10 GB Ethernet interfaces are used to communicate with the storage array.

The storage array will present LUNs to the ESX/ESXi hosts through the storage ports, similar to storage processors on an FC SAN. There are three types of storage systems:

Active/Active Allows access to LUNs on multiple storage ports simultaneously. All paths are active unless a failure occurs.

Active/Passive One storage port provides access to a given LUN at a time. All other ports can provide fault tolerance if the active port fails, but the other ports may be active for other LUNs.

Virtual Port Allows access to all LUNs through the use of a virtual port. These devices are also active/active but do not advertise other storage ports to ESX/ESXi servers. If a fault occurs with a storage port, the failover to another port is handled by the storage array and is transparent to the ESX server.


F I GU R E 3 .6 iSCSI hardware components

ESX Host

Hardware iSCSIinitiators

ESX Host

Software iSCSIinitiators

SP A

SAN

LUNs

SP B

Switch A Switch B

Determining Use Cases for Hardware vs. Software iSCSI InitiatorsThere are two types of initiators used to communicate with an iSCSI appliance:

Hardware Initiator A dedicated iSCSI HBA with Ethernet connectivity that receives the SCSI commands from the operating system, in this case the VMkernel, and then packages those commands and data for transmission over an IP network. Hardware initiators usually have onboard processing capabilities that allow the VMkernel to pass on the SCSI data with-out further data processing.

Software Initiator A software-based adapter that is built into the operating system, again in this case the VMkernel, that uses standard network adapters to communicate with the storage array. This type of initiator will use native processing cycles of the server’s CPUs to do the work of packaging and transmitting SCSI data.

The use cases for using one type of initiator over another are usually based on two factors: cost and performance. If the implementation cost of iSCSI storage is a primary factor and performance is secondary, using the software initiator can reduce costs. If performance is the primary factor and cost is secondary, using the hardware initiator may provide performance enhancements.

Using the software initiator allows for the use of standard network interfaces, both 1 GB and 10 GB. Using the latter may not be as cost effective but would improve performance in communicating with the iSCSI storage array. The storage array would also need to be outfit-ted with 10 GB storage ports. Using 1 GB network interfaces is truly a lower-cost solution and, with the addition of jumbo frame support, improves overall communication with the disk


array. With the enhancements by VMware to the iSCSI module and the use of the newer TCP/IP stack, the software initiator is adept at processing such disk I/O effectively and efficiently.

There are also cost savings when you consider that two such iSCSI HBAs are necessary for fault tolerance. Multiply those two adapters by the number of ESX/ESXi servers and the sav-ings can be a substantial sum. For small to medium-sized businesses, using the software initia-tor lowers the cost of implementation. Given that many ESX/ESXi servers rarely utilize over 60 percent of their CPUs’ capacity, there are many native cycles that the software initiator can take advantage of.

The supported iSCSI HBAs that are used today with ESX/ESXi servers are built so that they have onboard TCP/IP offload engines (TOEs). This architecture improves throughput significantly and allows the VMkernel to move on to other tasks. Two adapters manufac-tured by QLogic are compatible with vSphere: the QLA4050 PCI-X and QLA4060 PCI-E series of cards. There are single-port and dual-port versions of these cards, and they are often rebranded by server hardware vendors.

Software Initiator vs. hardware Initiator

A law office has decided to virtualize their server infrastructure . In making this decision, they will also need to purchase a centralized storage technology that doesn’t break the bank . Fibre Channel was considered, as their storage needs are not enormous, but this option was discarded due to the perceived costs associated with the topology that would need to be implemented . Their next option, iSCSI, was considered . They would need to decide which type of initiator they wanted to use, hardware or software, to achieve per-formance requirements and keep topology costs down .

An assessment was conducted on their physical server infrastructure to determine the various workloads, including storage I/O . They found that only two servers, email and a digital document archiver, had performance metrics that would require careful attention . The discussion then turned to the two types of initiators . With vSphere 4 .0, the improve-ments to the iSCSI module and the TCP/IP stack could save them the costs associated with purchasing the hardware-based HBAs .

The decision was made to implement the software initiator on all ESX hosts using 1 Gb adapters and jumbo frames . This would save the virtualization project around $1,500 per host . Since four hosts would be initially used, this was a savings of over $6,000 for the project . If after the implementation of the software initiator it was determined that the per-formance for the two applications was not sufficient, the hardware initiators could be pur-chased and substituted for the software initiator .

In the end, the software initiator was more than up to the task . With the proper iSCSI multipathing setup, the law firm had a robust and cost-effective solution that didn’t require a new, expensive storage topology .


Configuring the iSCSI Software InitiatorThe iSCSI software initiator is code that is built into the VMkernel to provide iSCSI com-munications between the virtual machines, whose SCSI commands need translations, and the storage array, whose LUNs store the virtual disk fi les that are read and written to. The four steps to confi guring the software initiator are as follows:

1. Configure a VMkernel port for network communication between the ESX/ESXi server and the storage array.

2. Enable the iSCSI software adapter.

3. Configure the iSCSI target.

4. Configure iSCSI security (optional unless security policy dictates its usage).

In Exercise 3.2, these steps are followed and provide a good view of the process for uti-lizing this type of storage.

Creation of the VMkernel port on a virtual switch is covered in Chapter 2, “Configuring ESX/ESXi Networking .” Exercise 3 .2 assumes this step has already been completed . Also, if multipathing will be used, two physical adapters will need to be assigned to the virtual switch and two VMkernel ports mapped to these adapters in a 1:1 mapping . The steps for doing multipathing are in the iSCSI SAN Configuration Guide .

E X E R C I S E 3 . 2

Configuring the iSCSI Software Initiator

1. Log into the vSphere Client, either directly to the ESX/ESXi server or to vCenter . Select the ESX host from the inventory panel and click the Confi guration tab .

2. Click the Storage Adapters link in the Hardware section and fi nd the iSCSI Software Initiator in the adapters list in the informational panel . Click Properties in the bottom-left Details panel .



3. Click the Configure button . The General Properties dialog box will open, showing empty fields for the software initiator configuration . Select the Enabled check box and click OK .

4. Review the configuration details of the software initiator in the Properties dialog box .


Configuring Dynamic/Static DiscoveryAdministrators have a couple of options when it comes to setting up the way an ESX/ESXi server learns or “discovers” iSCSI target address. The administrator can provide the targets or the software initiator can discover them. Both methods are now supported by the iSCSI software initiator.

There are two types of target discovery methods for iSCSI initiators:

Dynamic Discovery This method of target discovery is also known as Send Targets dis-covery. The initiator, with the help of one target address supplied by the administrator on the Dynamic Discovery tab, sends a Send Targets request when it communicates with the iSCSI appliance. The iSCSI appliance returns a list of available targets, including target names and the IP address. These addresses will then show up on the Static Discovery tab.

Static All targets are predefined on the Static Discovery tab (see Figure 3.7) by the administrator.

Configuring CHAP AuthenticationThere is only one method of authentication when using the iSCSI software initiator: Challenge Handshake Authentication Protocol (CHAP). This authentication protocol has been around in the computer world for many years and is sometimes referred to as “Shared Secret” authenti-cation. In previous version of ESX Server, there was only one-way authentication, meaning the ESX server authenticated to the iSCSI appliance. With vSphere, there can now be bidirectional CHAP authentication.

In addition, in the previous release of ESX Server only one password could be used regard-less of the number of targets or iSCSI appliances used. vSphere now supports per-target CHAP where different passwords can be used for each target, usually a different password for each storage appliance.

You can set four CHAP security levels with the software initiator:

Do Not Use CHAP This level disables CHAP.

Do Not Use CHAP Unless Required By Target The ESX server will only use CHAP if the iSCSI appliance requires its use.

Use CHAP Unless Prohibited By Target The host will attempt to use CHAP, but will connect without it if the iSCSI appliance does not support it.

Use CHAP The ESX server will require the use of a CHAP connection and the connection will fail if the iSCSI appliance cannot support it.

Figures 3.8 and 3.9 show the different CHAP options, per initiator or per target.If CHAP is disabled for either an initiator or for targets, the existing connections will

continue to use CHAP. A reboot of the ESX/ESXi server is necessary to completely disable CHAP authentication.


F I GU R E 3 .7 Dynamic Discovery tab

F I GU R E 3 . 8 CHAP authentication, Software initiator


F I GU R E 3 . 9 CHAP authentication, per target

Configuring VMkernel Port Binding for iSCSI Software MultipathingWhen using multipathing with the iSCSI software initiator, each uplink on the virtual switch is mapped to a corresponding VMkernel port on the same virtual switch. Once the virtual switch has two VMkernel ports and two uplinks adapters, the ports can be bound to the physical adapters. Exercise 3.3 shows the steps for creating the VMkernel port bind-ing for iSCSI software multipathing.

In Exercise 3 .3, creation of the virtual switch has already been completed . The selection of the physical adapters and the creation of the corresponding VMkernel ports have also been completed . See Chapter 2 on the steps used to perform these operations .

E X E R C I S E 3 . 3

Configuring VMkernel Port Binding

1. Map each VMkernel port to one active physical adapter . Click the Ports tab, choose one of the VMkernel ports, and click Edit .



2. Click the NIC Teaming tab and select the Override vSwitch failover order . Choose one adapter to be active with this VMkernel port and move the other physical adapter to the Unused Adapters section .



3. Click OK . Repeat the previous steps for the other VMkernel port, choosing the other physical adapter as the active adapter and moving the first adapter to the Unused section .

4. The next steps must be performed using the vCLI . Using the esxcli command, con-nect the software initiator to the two VMkernel ports .

5. Next, verify that the ports are properly connected .



6. Backtrack to the Storage Adapters link in the Hardware section on the Configuration tab and perform a rescan on the software initiator .

7. Using the Paths view for the iSCSI software adapter (vmhba33 would be an example), you should see two different paths being used to access the same target . The runtime name will have a different “C” value, most likely C1 and C2, where C1 and C2 refer to the two physical adapters mapped to the two VMkernel ports (vmhba33:C1:T1:L1 and vmhba33:C2 :T:1:L1) .

Discovering LUNsBy default, ESX/ESXi discovers LUNs upon each reboot of the server. An ESX server can scan for LUNs with LUN IDs from 0 to 255 for a total of 256 LUNs. In most environments, LUN IDs are in the single and double digits. Scanning the higher ranges results in longer boot and rescan times. A way to shorten this scan time is to use an Advanced Setting, Disk.MaxLUN, to specify a lower number closer in value to the highest LUN ID used.

To discover new LUNs that have been created since the ESX/ESXi server has been rebooted, you can rescan the storage adapters (see Figure 3.10) to update the device list for each adapter. You can rescan one adapter or all of them. On ESXi, it is not possible to rescan a single adapter.


F I GU R E 3 .10 Rescanning a storage adapter

Identifying iSCSI Addressing in the Context of the HostAddressing in the context of the host follows a naming convention known as IQN (iSCSI qual-ified name). IQNs have a defined format that they must follow. For example, iqn.1998-01 .com.vmware:hostname-xxxxxxx would follow this standard. Let’s break down the name and see where the constituent parts come from:

iqn Denotes the name format being used. An alternate naming convention is called eui (enterprise unique identifier).

yyyy-mm The year and the month when the naming authority was registered.

Naming Authority The reverse name of a registered domain name.

Unique Name Any unique name that refers to the iSCSI host. For ESX/ESXi servers this name is derived from the hostname of the server with a hexadecimal appendage randomly assigned to assure uniqueness.

Figure 3.11 shows the dialog box where the IQN can be found.

F I GU R E 3 .11 IQN name of an ESX server

Table 3.2 summarizes many of the storage maximums for iSCSI that may be asked of you during the exam.

Configuring NFS Datastores 141

TA B lE 3 . 2 iSCSI Storage Maximums

Hardware Initiators Maximum

LUNs per host 256

Initiators per host 4

Paths to a LUN 8

Software Initiators

LUNs per host 256

NICs port bound with the software iSCSI stack per server

8

Targets 256

Paths to LUN 8

Total paths 1024


Configuring NFS DatastoresWith the introduction of VI3, Network File System (NFS) datastores have been a possibility for storing the same kinds of files that a VMFS datastore can. Although NFS was usually spo-ken of in the context of storing static content such as templates, today’s NFS appliances and network-attached storage (NAS) devices can perform on par with iSCSI and close to FC SANs.

There are four specific test objectives in this section:

Identifying the NFS hardware componentsNN

Explaining ESX exclusivity for NFS mountsNN

Configuring ESX/ESXi network connectivity to the NAS deviceNN

Creating an NFS datastoreNN

NFS has an easy setup procedure, as you will see, and it has the advantage of not being tied to the VMkernel from a management standpoint. The underlying file system is managed by the appliance and therefore can be whatever the vendor wishes to use, even proprietary. There are some disadvantages as well when using NFS, but many customers are finding it quite easy to bypass those issues and work completely with NFS as their storage technology.


In other environments, NFS is used as one storage technology, but not the only one. Some environments use FC SANs for their primary servers or heavy disk usage applications, and then use NFS for everything else. This approach is sometimes referred to as “tiered” storage. No matter the actual usage, NFS has developed a strong customer following, and knowing how to use it with ESX/ESXi is critical.

Identifying the NFS Hardware ComponentsUsing NFS storage with ESX/ESXi is not complicated. One of the biggest selling points for using NFS is the relative ease in getting ESX Server to use the NAS, and therefore by exten-sion, the NFS storage. On the hardware side, there is the NAS appliance that provides the NFS storage on the network. Then there is the switching and cabling on the Ethernet topology for connecting the devices and hosts to one another. Then there are the ESX servers themselves with network interfaces to connect them to the same Ethernet topology.

The NFS appliance can sometimes be created by the end user by utilizing a standard Linux server that provides NFS services. This type of implementation has one big disad-vantage: lack of performance. On the other hand, using a dedicated NAS appliance that is built from the ground up to be an efficient NFS server can have many advantages. The costs associated with these types of storage devices are significantly less than those for their Fibre Channel brethren.

On the network side, there are the Ethernet switches and network interfaces that con-nect all the devices and hosts together. With the introduction of vSphere, 10gE interfaces are now supported. This may sound expensive, but in implementation, only the network being used for the disk I/O is upgraded to use these adapters. With these faster interfaces, NFS can perform quite well and handle large volumes of traffic.

The ESX/ESXi servers, with the right networking architected, can access the NFS appliance or server by using a simple wizard to set up the connection. ESX Server has added jumbo frame support for NFS that provides superior throughput with existing 1 Gb or 10 Gb interfaces.

Figure 3.12 shows the basic layout of an NFS topology.

Explaining ESX Exclusivity for NFS MountsWhen a VM is powered on, the ESX/ESXi servers lock the VM out to other hosts so that the virtual machine’s virtual disks cannot be accessed by another host. On a VMFS file system, this is handled with metadata locks on the files that the VMkernel controls exclusively. With NFS, since the VMkernel does not have exclusive access to the underlying file system when using NFS, it uses an alternate method for locking the VM’s virtual disks.

The NFS method uses a lock file with a syntax of .lck-XXX, which is created in the same directory as the virtual disk being locked. This prevents another ESX server from attempting to access the virtual disk or another VM from sharing a disk. In other words, there is no way to share virtual disks on NFS storage as you would using VMFS and a Microsoft cluster.


F I GU R E 3 .12 NFS hardware components

ESX Host

NFS Server

/share

Switch A Switch B

Configuring ESX/ESXi Network Connectivity to the NAS DeviceUtilizing NFS as a datastore requires that the ESX/ESXi servers be connected to the NAS appliance or server using a VMkernel port on a virtual switch. The first step is creating the virtual switch, either a standard switch or the newer distributed switch. In either case, a VMkernel port must be created on the switch to allow the VMkernel to communicate with the NFS protocol to the NAS appliance. You learned how to create the switch and the VMkernel port in Chapter 2.

Figure 3.13 shows the connectivity between the ESX server’s virtual switch and the NFS appliance.

F I GU R E 3 .13 NFS and ESX connectivity


Creating an NFS DatastoreOnce the virtual switch and the VMkernel networking have been implemented, using the Add Storage wizard and providing the network and NFS information, as seen in Exercise 3.4, is all that is needed.

E X E R C I S E 3 . 4

Creating an NFS Datastore

1. Log into the vSphere Client and click on the ESX server in the inventory panel .

2. Click the Configuration tab, and then click the Storage link in the Hardware section of the informational panel .



3. Click the Datastores button and then click the Add Storage link in the top-right corner of the informational panel .

4. In the resulting screen, choose the Network File System option and then click Next .

5. On the next screen, enter the NFS server name or IP address . Enter the mount folder in the next box and then enter the datastore name or label . If you wish the VMkernel to treat this datastore as a read-only mount, you must also click the Read-Only check box . If you plan to use the NFS mount as a place to run VMs, do not check this box . Click Next .



6. On the summary page, watch the progress of the NFS creation task in the Tasks pane and then keep an eye in the Storage panel for the NFS mount to be created . You should see it listed by the name or label you provided .

Table 3.3 summarizes the storage maximums for NFS that you should be familiar with.

TA B lE 3 . 3 NFS Storage Maximums

Datastores Maximum

Default NFS datastores 8

NFS datastores 64 (requires changes to advanced settings)


Configuring and Managing VMFS Datastores 147

Configuring and Managing VMFS DatastoresThe VMFS is VMware’s proprietary file system used to store VMs, ISO files, and tem-plates. The file system was developed from the ground up to provide features that sup-port fault tolerance, high availability, simultaneous access by multiple hosts, and file locking security. A VMFS is optimized for very large files, and it allows for VMs to access non-VMFS volumes through the use of raw device mappings (RDMs).

A VMFS is used by the VMkernel to store the VM’s files, templates, and ISOs. The VM believes it has local SCSI storage when in fact the file that represents the virtual disk can be stored on a VMFS that the VM never sees or is aware of.

The VMFS can be extended across multiple LUNs to create ever larger volumes. The VMFS can also be “grown” to append to the file system additional storage made available by the storage administrator. This feature is one of the newest changes to the file system on vSphere.

There are seven objectives in this section:

Identifying VMFS file system attributesNN

Determining the appropriate datastore location/configuration for given virtual machinesNN

Determining use cases for multiple VMFS datastoresNN

Creating/configuring VMFS datastoresNN

Attaching an existing datastore to a new ESX hostNN

Managing VMFS datastoresNN

Group/unmount/delete datastoresNN

Growing VMFS datastoresNN

Identifying VMFS File System AttributesThe VMFS has been optimized for storing and accessing large files. There are many file systems in the computer universe, but most were not created to access large files written in long continuous blocks. In fact, most other file systems are optimized for small, randomly accessed files. The VMFS can be used to store the files that make up a VM or template, and to store ISOs of CD/DVD media and occasionally other files such as drivers on floppy images.

The VMFS has several attributes worth noting:

The VMFS must reside on a SCSI disk or volume, which may include local storage, NN

Fibre Channel, or iSCSI devices. There is no method for creating VMFS on anything but SCSI-based devices.


A VMFS can have a maximum volume size of 64 TB, but single VMFS datastore can NN

only be 2 TB. By using a technique known as spanning, multiple extents can be joined together to form a larger logical volume.

A VMFS cannot be deleted or reformatted if any host sharing that volume has a VM NN

lock on one or more files.

The VMFS datastore can be grown to a new size, but still restricted to the 2 TB limit, NN

if the corresponding LUN size has been increased on the storage array.

A VMFS-2 datastore can be upgraded to a VMFS-3 file system.NN

A raw device mapping (RDM) can be created on a VMFS to allow a VM’s operating NN

system to access storage in its native file system format without encapsulation. The RDM file resides on the VMFS, but points to another LUN with a file system the VM’s operating system expects.

Multiple VMs can share the same VMFS volume and run simultaneously.NN

Each VM resides in a separate single directory.NN

Block sizes can be adjusted to allow for the creation of larger virtual hard disks (VMDKs):NN

1 MB – up to 256 GB VMDKNN

2 MB – up to 512 GB VMDKNN

4 MB – up to 1 TB VMDKNN

8 MB – up to 2 TB VMDKNN

Determining the Appropriate Datastore Location/Configuration for Given Virtual MachinesChoosing the correct datastore for a VM is critical to its ability to perform according to the expected service level. You will need to consider several factors when choosing the location for a VM:

CostNN

PerformanceNN

High availabilityNN

There are also different service levels, called tiers, that can determine where a VM will reside. Keep in mind that a VM does not have to live in one tier its entire lifecycle. VMs can move between tiers based on performance criteria and high availability needs. The three storage tiers are:

High Tier This storage tier provides the ultimate in performance and high availability. In most cases, this storage tier will cost more than the other tiers. Redundant storage processors (SPs), replication, fiber drives, and SAN snapshots are features commonly used in this tier. Reserve this tier for VMs that demand the highest service levels and for the most critically necessary applications.


Mid Tier This storage tier provides mid-range performance, some high availability, some SP redundancy, and lower-cost SCSI drives. Reserve this tier for VMs that are not as disk intensive.

Lower Tier This storage tier provides lower performance and may not provide redundancy other than what can be supplied by back-end RAID levels and network fault tolerance. This tier uses low-cost disk such as SATA, SAS, or regular SCSI drives. Reserve this tier for VMs that have very little disk I/O and for applications that are not mission critical.

You can ask about several factors to help in the placement of a VM:

CriticalityNN

Performance as it relates to application needsNN

High availability as it relates to storage snapshotsNN

Point-in-time restoration needsNN

Backup requirementsNN

Replication requirementsNN

The needs of a VM may change throughout its lifecycle. It may inhabit a lower tier for its early life and initial development. Later you may find it necessary to move it into a higher tier due to the critical nature of the application running within. The reverse is true of certain fea-tures that were once only possible in the higher tier—for example, if high availability became available in the mid or lower tiers, the VM could move to lower-cost storage.

Determining Use Cases for VMFS VolumesA variety of methods are available for creating VMFS volumes that have particular charac-teristics, RAID levels, and sizes to fit just about any situation. Keep the following in mind when creating a VMFS datastore:

Each LUN should have one partition and therefore one VMFS.NN

Each LUN should have the correct RAID level that best corresponds to the needs of the NN

applications running in the VMs stored there.

Disk shares can be used to prioritize VM LUN access within the same VMFS.NN

LUN sizing also has several considerations. For fewer, larger LUNs, consider these reasons for their creation:

More space, less interaction with storage administrators, and more flexibility in the NN

sizing of the VM’s VMDKs

Added flexibility in growing VMDKs and the growth of snapshotsNN

Reduced datastore managementNN

For smaller datastores, consider these reasons:

Potential for less wasted storage spaceNN

The ability to customize a datastore’s characteristics for a specific applicationNN


Disk shares that have smaller datastores and fewer VMs in themNN

Microsoft clusters volumes that can be assigned their own LUNsNN

The fact that fewer VMs in a particular datastore may mean better performance due to NN

less contention

At times, even with these considerations, it is difficult to place a VM in a particular datastore if little is known about its eventual behavior. In such cases, it may be best to choose between two datastore creation schemes to guide your placement:

Predictive schemeNN

1. Create several LUNs with varying storage characteristics.

2. Format the volumes with one VMFS and label the volumes based on the character-istics used in its creation.

3. Use these datastores for VM data volumes.

4. Use disk shares, if necessary, to prioritize the VMs residing in the same datastore. Keep in mind that shares are host specific, meaning that shares given to a VM on one host are not seen by other hosts running VMs out of the same datastore.

5. Run tests to see if the applications are able to achieve the service levels required.

Adaptive schemeNN

1. Create a large datastore with RAID 1+0 or RAID 5 and with write caching enabled.

2. Build a single VMFS in that volume.

3. Put several VM VMDKs into the volume.

4. Run performance tests to see if the VMs are able to achieve acceptable service levels. If so, place additional VMDKs in the VMFS volume and rerun the tests. If the tests continue to achieve acceptable performance, repeat the process until the volume can no longer support the performance of all VMs sharing the datastore.

Creating/Configuring VMFS DatastoresCreating a new VMFS datastore is easy. By using the Add Storage wizard, you’ll find the process is simple and straightforward. In Exercise 3.5, we’ll create a new VMFS with default characteristics.

E X E R C I S E 3 . 5

Creating a New VMFS

1. Log into the ESX server or vCenter using the vSphere Client .



2. Choose an ESX server in the inventory panel, and then click the Configuration tab .

3. In the Hardware section, click the Storage link .



4. Click Datastores and then click the Add Storage link in the top-right corner .

5. Select Disk/LUN as the storage type and click Next .

6. Select the storage device from the list that you wish to format and click Next . Be careful, as the datastore selected may already have a VMFS on it, denoted by having a label . Click Next .



7. Make sure that the Current Disk Layout section shows that the disk is blank . Click Next .



8. On the Properties screen, give the volume a name . Using a descriptive name will allow the ESX server administrator to know how the new VMFS will be used and for what purpose . Click Next .

9. On the next screen, the option to choose a different capacity is offered . In most cases, the full capacity of the LUN or disk will be used . Click Next .



10. On the Ready To Complete screen, review the properties that are summarized for any errors in typing or capacity issues . If all looks fine, click Finish .

Once a new VMFS is created on the FC or iSCSI SAN on one ESX server, all the ESX servers will automatically have the volume added. This is a slight difference from past versions that required a rescan of the storage adapters to pick up newly created VMFS volumes.

Attaching an Existing Datastore to New ESX HostMounting an existing datastore to a new host can proceed on two different paths. One path has the datastore mounted and keeping the existing signature. The other resignatures the volume while mounting it. What is the distinction?

If the VMFS volume was created by an ESX server and that server becomes unusable and a new ESX server is built to replace the original, there is no need to create a new volume signa-ture. Also, if the VMFS volume is replicated to another site and a different ESX server will be mounting the volume in accordance with a disaster recovery plan, no resignature is needed.

If, on the other hand, the volume is a snapshot of an existing volume and the snapshot may be visible to the original ESX server, a disk resignature will be necessary to keep the ESX server from seeing a clone of a disk and confusing the original with the copy.

In the former two examples, attaching or mounting the existing datastore is straight-forward. In Exercise 3.6, we’ll attach the existing datastore.


E X E R C I S E 3 . 6

Attaching an Existing Datastore to a New ESX host

1. Log into the vSphere Client, either directly to the ESX server or vCenter .

2. Select the ESX host from the inventory panel, and then click the Configuration tab in the informational panel .

3. In the Hardware section, click the Storage link and then click the Add Storage link in the top-right corner .

4. Select Disk/LUN as the storage type and then click Next .

5. Select from the list of storage devices the LUN that already has a label in the Label column and click Next .

6. Under Mount Options, choose Keep Existing Signature . Click Next .

7. On the Ready To Complete screen, review the summary and click Finish .

8. Select Disk/LUN as the storage type and then click Next .

Managing VMFS Datastores Once you’ve created the datastores, you may at some point in the future have to modify or delete them. This is accomplished in the Datastores view and makes management of the VMFS datastores much easier. Let’s take a look at three actions that can be done from this view.

First, to group datastores for organizational purposes, both for management and for permission delegation, a folder needs to be created. This is a new feature of vSphere. In Exercise 3.7, we’ll create a folder for grouping datastores.

E X E R C I S E 3 . 7

Grouping Datastores

1. Log into the vSphere Client, either to the ESX server directly or vCenter .

2. In the inventory panel, choose Datastores .



3. Select the datacenter which has the datastores you want to group, right-click the datacenter, and choose New Folder . Name the folder and click OK .

4. Click and drag each datastore into the folder until all datastores required are grouped .

The next action you may find necessary is unmounting a datastore. You can unmount only two datastores:

NFS datastoreNN

VMFS datastore copy mounted without resignaturingNN

Exercise 3.8 will show how this is done.


E X E R C I S E 3 . 8

Unmounting a Datastore


2. From the Inventory panel, choose Datastores .

3. Right-click the datastore to be unmounted and choose Unmount .



4. If the datastore is being shared, you will have to specify which hosts will no longer be accessing the datastore . By default, all hosts will be selected . If you wish one or more ESX servers to maintain access, deselect them from the list . Click Next .

5. The next page allows you to double-check your work and go back if a host was improperly selected or deselected . If all looks fine, click Finish . You are given one last opportunity to cancel the operation . Click OK (not shown) .


Last, how do you go about deleting a datastore? Well, it depends. If the datastore is a VMFS volume, selecting one will destroy any data that may reside on it. If the volume is an NFS mount, the mount is removed and no data is destroyed on the storage device. Exercise 3.9 shows the deletion of a VMFS volume.

E X E R C I S E 3 . 9

Deleting a Datastore


2. From the Inventory panel, choose Datastores .

3. Right-click the datastore to be deleted and choose Delete .



4. You must confirm the deletion; this will be your last chance to cancel the operation .

Growing VMFS DatastoresThere are times when an existing datastore needs to grow—it may be running out of space or have to expand past the single VMFS datastore limit of 2 TB. You can choose between two methods of increasing the size of a VMFS datastore:

Spanning You dynamically add one or more extents to the original VMFS.

Grow This approach increases the size of the original extent only. Only extents with free space immediately after them are expandable.

Both of these techniques are shown in Exercise 3.10.

E X E R C I S E 3 .10

Spanning a VMFS Volume

1. Log into the vSphere Client, either the ESX server directly or the vCenter server .



2. Select an ESX server in the inventory panel, and then click the Configuration tab .

3. Click the Storage link in the Hardware section; then right-click the datastore you wish to increase and choose Properties .

4. Near the top of the screen, click the Increase button .



5. Choose a LUN from the list that you want to add to the original VMFS volume . If you wish to span the original LUN, choose a different LUN from the list . If you wish to grow the existing LUN, choose the same LUN from the list, making sure that the Expandable column shows Yes . This will only be the case if the storage administrators have grown the LUN on the array and you have rescanned the adapter . Click Next .

6. Depending on which LUN you chose, your options will be as follows:

Use Free Space To Add New Extent Adds the free space on the existing disk as a new extent . This will create a new partition on the same LUN .

Use Free Space To Expand Existing Extent Grows the existing extent by some amount you specify on the next screen .

Use Free Space Creates a new extent with the new space and is only available when choosing to span extents .

Use All Available Partitions Creates a new extent on the LUN, but the LUN is not blank and has existing partitions and/or data . All data is destroyed . This option is only available when adding an extent .



7. Choose the capacity of the extent, which by default will be all of the free space available . Click Next .



8. Double-check your work and options to be sure that the choices selected are correct . Click Finish .

9. Refresh the datastore on each host that shares the same volume so that the vSphere Client will display the correct information about the VMFS volume .

Remember, when growing a VMFS volume by increasing its size with free immediate space, not an extent, the maximum size for the extent is still 2 TB . You can grow an extent as many times as you like, but you will not be able to grow past this limit .


Table 3.4 summarizes many of the storage maximums for VMFS that you should know for the exam.

TA B lE 3 . 4 VMFS Storage Maximums

VMFS-General Maximum Amount

Volume size 64 TB minus 16 KByte

Host per volume 64

Virtual machines per volume 256

Volumes per host 256

Extents per volume 32

Hosts per cluster 32

Extents Size 2 TB minus 512 Bytes

VMFS-3

VMFS-3 volumes configured per host 256

Files per volume ~30,720

Block size 8 MB

File size with 1 MB block 256 GB minus 512B

File size with 2 MB block 512 GB minus 512B

File size with 4 MB block 1 TB minus 512B

File size with 8 MB block 2 TB minus 512B


SummaryTo prepare you for the VCP exam, we looked at several aspects of storage and how ESX/ESXi use that storage.

We identified Fibre Channel hardware components and explained how the ESX server connects to the FC SAN storage. We also looked at storage addressing and the concepts of

Exam Essentials 167

zoning and masking. Scanning for new LUNs was next. Then we discussed multipathing policies and how to differentiate between NMP and third-party MPPs.

Next we looked at configuring iSCSI storage. We identified hardware components, determined use cases for hardware and software initiators, configured the software initia-tor, explored dynamic and static discovery, and discussed CHAP authentication. We also examined VMkernel port binding for iSCSI software multipathing, and you learned how to discover new LUNs and how addressing is accomplished with iSCSI.

We then took a look at the third storage technology, NFS, and how it is configured. We discussed the hardware components, ESX exclusivity for NFS mounts, network connectivity to the NAS device, and NFS datastores.

Finally, we looked at how to configure and manage VMFS datastores. We discussed identifying file system attributes, appropriate datastore location/configuration for given virtual machines, use cases for multiple VMFS datastores, and the creation and configura-tion of VMFS datastores. We also looked at attaching an existing datastore to a new ESX server, managing datastores, and growing a datastore.

Exam Essentials

Know how to configure FC SAN storage. Being able to identify hardware components at a high level and how to connect the ESX server to the Fibre Channel SAN is a must. Understanding the addressing scheme used for FC storage will help when troubleshooting multipathing scenarios. A high-level understanding of zoning and masking is needed, but not to the extent of actual fiber switch knowledge or storage array techniques with their administrative front ends. Review the sections that explain what an NMP, MMP, PSA, PSP, and SATP mean and how they are related.

Know how to configure iSCSI SAN storage. Be able to identify iSCSI hardware components—in particular, the hardware initiator and the software initiator and what hardware they use. Review the steps of the software initiator setup, the differences between dynamic and static discovery of targets, and the new CHAP options (such as bidirectional authentication and per-target CHAP authentication). Review the addressing schemes used with ESX/ESXi.

Know how to configure NFS datastores. Be able to identify NFS hardware components and know how to set up networking on the ESX server. Also, review the ESX exclusivity for NFS mounts and how it works.

Be familiar with configuring and managing VMFS datastores. Review the VMFS attributes and know how to determine the appropriate locations and configurations of datastores for your virtual machines. Also review the use cases for having multiple VMFS volumes, how to create and configure VMFS datastores, how to attach an existing datastore to a new ESX server, and how to manage a VMFS. Also, take a good look at the differences between using spanning with extents and growing an extent and when to use one or the other.


Review Questions

1. In which of the following cases can you get away with specifying (checking the box for) Read-Only when creating an NFS datastore on an ESX server? (Choose two.)

A. The NFS datastore will contain running VMs.

B. The NFS datastore will contain Installer ISO images.

C. The NFS datastore will be a secondary location for a VM’s VSWP file.

D. The NFS datastore will contain templates (which are periodically updated).

E. The NFS datastore will contain templates (which are not updated).

2. Which of the following are techniques for masking LUNs in a Sphere 4.0 ESX environment? (Choose two.)

A. Setting a mask (permission list/ACL) on the fiber switch

B. Setting a mask (permission list/ACL) on the SAN array

C. Setting a mask (vCLI) on the ESX server via the vMA appliance

D. Setting a mask (permission list/ACL) on the ESX server using the vSphere Client

3. Which of the following is not used as part of an ESX/NFS data storage implementation?

A. NFS NAS appliance

B. Linux NFS server

C. Ethernet network infrastructure

D. Hardware initiator with TCP Offload Engine (TOE)

E. Virtual switch with VMkernel storage port configured

4. Which Storage Array Type Plug-in (SATP) is not supported by ESX 4.0? (Choose two.)

A. Active/passive, nonspecific storage array

B. Active/active, nonspecific storage array

C. Local, for locally attached storage

D. Most Recently Used

E. Round Robin

5. You have a single LUN on an iSCSI array. You have configured a virtual switch to support multipathing of VMkernel ports for use in a software-initiated iSCSI environment by having the virtual switch bound to two physical network adapters. Each VMkernel port is configured to use a single physical adapter only, with a second adapter configured as Unused. Further, each VMkernel port uses a different adapter as its primary adapter. Which of the following would represent the VMkernel ports used in this switch?

A. vmhba32:C0:T0:L19 and vmhba33:C0:T0:L19

B. vmhba32:C0:T0:L19 and vmhba32:C1:T0:L19

C. vmhba32:C0:T0:L19 and vmhba32:C0:T1:L19

D. vmhba32:C0:T0:L19 and vmhba32:C0:T0:L20


6. What are the primary factors used to determine whether to use a software or a hardware initiator when setting up an iSCSI array on an ESX 4.0 server? (Choose two.)

A. The number of PCI slots you have in your physical servers

B. The cost savings when using software initiators

C. Whether you have 1 GB or 10 GB Ethernet NICs in your ESX servers

D. The added performance of using hardware initiators

E. The number of LUNs you are using

7. What are the primary factors when choosing a datastore for a VM?

A. Cost, performance, and high availability

B. VMotion compatibility, FT compatibility, and RDM support

C. Storage VMotion compatibility, size, and RAID level

D. Fibre Channel, shared storage, and redundant HBAs

8. Which of the following SAN multipathing policies is typically preferred with the Native Multipathing Plug-in (NMP) when using an active-passive SAN?

A. Fixed

B. IP Address

C. Round Robin

D. Virtual Port

E. Source MAC Address

F. Most Recently Used (MRU)

9. When you delete a VMFS datastore, which of the following will happen?

A. Any running VMs will immediately crash.

B. All data contained within should be considered irretrievably lost.

C. If the VMFS contains extents, you will be asked which extent(s) to remove.

D. The VMFS automatically creates a backup mirror of the data in the datastore before deletion.

10. In which of the following scenarios would resignaturing of a VMFS datastore be required?

A. An ESX server dies and needs to be replaced with a new server.

B. The VMFS datastore is copied to a DR site; neither site will see the other site’s datastores.

C. A VMFS is a snapshot of an existing volume, and both the original and the snapshot will be visible to the same ESX server simultaneously.

D. A VMFS is a snapshot of an existing volume, and the original and snapshot will never be visible to the same ESX server simultaneously.


11. Which of the following is a valid IQN name for an ESX server?

A. iSCSI.1998-01.com.vmware.esx29-7c79e548

B. iqn.1998-01.com.vmware:esx29-7c79e548

C. iSCSI-iqn.com.vmware.1998-01:esx29-7c79e548

D. iqn.1998-01.vmware.com:esx29-7c79e548

E. iSCSI.vmware.com.1998-01.esx29-7c79e548

12. Which of the following features is not supported by the VMFS?

A. Fault tolerance

B. Extending across multiple logical volumes

C. Virtual disks up to 64 TB in size

D. Optimization for large file access

E. Simultaneous access by multiple ESX servers

13. Which of the following is not an iSCSI storage maximum in vSphere 4.0?

A. 256 LUNs per ESX host

B. 16 paths to each LU

C. 4 hardware initiators

D. 1024 total paths

14. Which of the following SAN multipathing policies is typically preferred with the Native Multipathing Plug-in (NMP) when using an active-active SAN? (Choose two.)

A. Fixed

B. IP Address

C. Round Robin

D. Virtual Port

E. Source MAC Address

F. Most Recently Used (MRU)

15. ESX uses what hardware address when referencing FC HBA cards?

A. MAC address

B. WWN

C. IP address

D. URL

E. FC Alias


16. Which of the following are true statements about LUN discovery? (Choose two.)

A. At boot time, an ESX server scans LUNS 1–256.

B. At boot time, an ESX server scans LUNS 0–255.

C. After the initial boot, an ESX server does not automatically scan for LUNs at boot time.

D. Setting Disk.MaxLUN to 30 would change scanning to stop at LUN number 30.

E. LUNs can be scanned from the GUI and from the command line.

17. Which of the following are not supported features when using NFS datastores on an ESX 4.0 server? (Choose two.)

A. 10 GB Ethernet NIC cards

B. TCP Offload Engine (TOE)

C. Jumbo frames

D. Linux NFS servers (you must use an NFS NAS appliance)

E. Teamed virtual NICs

18. Which of the following is not a design consideration when building a VMFS?

A. Each LUN should contain one partition with a single VMFS.

B. Each LUN should be configured with a RAID level appropriate to the application that will reside on the LUN.

C. Disk shares can be used to allocate access to LUNs on a per-VM/per-datastore basis.

D. Group related VMFS LUNs in the same resource pool for optimal disk resource allocation.

E. Choose a VMFS block size to support the largest VM file you expect on the LUN.

19. Which of the following describe connecting ESX servers to FC storage in support of running VMs? (Choose two.)

A. Multiple HBAs per LUN may be used simultaneously to improve throughput.

B. ESX servers use NPIV to track WWPN addresses per VM.

C. Traditional SAN tools can be used to monitor per-VM performance statistics.

D. Physical HBAs can be configured or queried by VMs.

E. Multipathing HBAs is done on the ESX server, not within VMs.

20. Which of the following are true about CHAP authentication of an iSCSI array on an ESX 4.0 server? (Choose two.)

A. Only one-way CHAP authentication is supported.

B. Unique per-target CHAP passwords are supported.

C. Even if not used, iSCSI arrays must support CHAP authentication.

D. The ESX administrator can select from four different CHAP security levels.

E. CHAP passwords can be passed to and from the array on a completely open/unen-crypted network.



1. B, E. Any time you need to modify data on the NFS datastore, you should not check the Read-Only box. Further, if the NFS server is serving the datastore as read only (export file properties, for example), you should check the Read-Only box.

2. B, C. Setting a mask on the SAN and setting a mask on an ESX server via the vCLI are both techniques for masking SAN LUNs in a vSphere 4.0 ESX environment.

3. D. The administrator can choose between a NAS appliance and a Linux NFS server. Ethernet network infrastructure and a virtual switch are both necessary components of an NFS data storage network on an ESX server. There is no need for, and the VMkernel will not use, the TOE engine in an NFS storage network (a TOE engine is used in an iSCSI environment with a hardware initiator).

4. D, E. Most Recently Used and Round Robin are Path Selection Plug-ins (PSPs) and not SATPs.

5. B. Binding individual physical outbound adapters to respective VMkernel ports in the same virtual switch may result in different C values in the vmhba VMkernel port names. A single virtual switch will use a single vmhba instance (vmhba32, for example). Here, the multi-pathing is being configured on the virtual switch on the ESX server; the T (iSCSI target) is not part of the answer. As the path is being set up for a single LUN, the L (LUN) number will be the same.

6. B, D. The decision to go with a software or a hardware initiator is primarily one of cost versus performance. Software initiators, especially in large deployments, can result in sig-nificant cost savings. Hardware initiators may result in increased data throughput to the SAN and reduced CPU load on the ESX servers as the hardware HBA offloads much of the iSCSI data packet processing.

7. A. The incorrect answers all have specific examples of the primary considerations: cost, performance, high availability (or just availability if you prefer), but are not primary con-siderations in and of themselves.

8. F. Most Recently Used is the policy typically used for active-passive arrays. Active-active arrays typically use Fixed or Round Robin as the multipathing policy of choice. Virtual Port, Source MAC Address, and IP Address are policies used on a virtual switch, not a SAN.

9. B. The VMFS deletion wizard will not let you delete a VMFS datastore with running VMs as the running VMs will have created exclusive locks on their virtual disk files in the VMFS. Deletion, once confirmed, is immediate and permanent, and should be considered irrevers-ible. Deletion of a VMFS removes all extents; you cannot remove individual extents from an extended VMFS. Finally, VMFS does not create backup or mirrors at any time. Backing up data is (still) entirely your responsibility.

10. C. In general, resignaturing is required when a volume is duplicated and both the original and copy are presented to the same server at the same time. In this case—presuming the copy is identical and using the same SCSI and VMFS internal identifiers—resignaturing keeps the server from confusing the original with the copy.


11. B. Valid IQN names are of the form iqn.yyyy-mm.naming-authority:unique-name. The naming authority is in reverse DNS domain name notation. The unique name, by default, contains a unique hex string at the end.

12. C. The maximum virtual disk size in a VMFS is 2 TB.

13. B. There are only 8 paths to a LUN supported in vSphere 4.0.

14. A, C. Active-active arrays typically use Fixed or Round Robin as the multi pathing policy of choice. Virtual Port, Source MAC Address, and IP Address are policies used on a virtual switch, not a SAN. Most Recently Used is the policy typically used for active-passive arrays.

15. B. World Wide Names (WWNs) are the hardware addresses used in an FC SAN environment. MAC addresses are used in an Ethernet-based networking environment, IP addresses are software addresses used for routing packets in a TCP/IP-based network, Uniform Resource Locators (URLs) are logical addresses used primarily in web environments, and the FC Alias is a software “equivalent” of the WWN used to make our (human) lives easier.

16. B, E. LUN numbering starts at 0 (zero), so ESX would scan LUNs 0–255 at boot time. Disk.MaxLUN sets the maximum number of LUNs to scan, not the maximum LUN number.

17. B. The presence of TOE on a NIC, although it won’t break an NFS datastore implementation, is not necessary and TOE will not be used.

18. D. Disk, LUN, and VMFS access is not currently controlled by resource pools (currently resource pools control only memory and CPU resource allocation).

19. B, E. ESX only supports a single active HBA per LUN at any moment in time. ESX servers use NPIV to track individual VM storage usage. This can be useful for storage performance analysis. Traditional SAN tools have no idea of VMs and so are generally not used to moni-tor per-VM statistics. The VMkernel does not allow a VM to query any hardware. In fact, the VMkernel does not present physical HBAs to VMs in any way. Thus, because the VMk-ernel does not present HBAs to VMs, there is no way a VM can configure physical multi-pathing in a SAN environment. This is done on the ESX server.

20. B, D. Two-way CHAP authentication is now supported in ESX 4.0. iSCSI arrays are only required to support CHAP authentication if the administrator chooses the Use CHAP secu-rity level. Finally, once a CHAP password has been selected on either the array or ESX side, it will need to be copied to the other side in some manually secure way like a phone call, walking it down the hall, and so forth. CHAP provides no mechanism for transmitting the password over an open network securely.

Chapter

4Installing and Configuring vCenter Server


Install vCenter Server.NÛ

Identify hardware requirements .NN

Understand configuration maximums .NN

Determine availability requirements for a vCenter server in a NN

given situation .

Determine appropriate vCenter Server edition .NN

Determine database size requirements .NN

Prepare/Configure vCenter Server database .NN

Install vCenter Server using downloaded installer .NN

Install additional modules .NN

vCenter Guided Consolidation .NN

vCenter Update Manager .NN

vCenter Converter .NN

Determine use case for vCenter Linked Mode Groups .NN

Manage vSphere Client plug-ins.NÛ

Identify available plug-ins .NN

Determine required plug-ins for a given application .NN

Ensure permissions to install plug-ins .NN

Enable plug-ins after installation .NN

Configure vCenter Server.NÛ

Identify the vCenter Server managed ESX Hosts and Virtual NN

Machine maximums .

Join ESX/ESXi Hosts to vCenter Server .NN

Configure Guest OS Customization .NN

Use datacenters and folders to organize the environment .NN

Configure/Use Scheduled Tasks .NN

Configure/Use Resource Maps .NN

Use Storage Reports/Storage Maps .NN

View/Manage Events .NN

Configure vCenter Server settings .NN

Configure vSphere Client settings .NN

Configure Access Control.NÛ

Create/Modify user permissions in vCenter .NN

Create/Modify user permissions in ESX Server .NN

Restrict access to vCenter inventory objects .NN

Define vCenter predefined roles and their privileges .NN

Create/Clone Edit roles .NN

Assign roles to users and groups .NN

Describe how privileges propagate .NN

Understand permissions as applied to user and group NN

combinations .

This chapter will look at identifying hardware and software requirements for the installation of vCenter Server. This task involves determining the appropriate edition of vCenter, sizing

the database, and determining configuration maximums for ESX hosts and virtual machines. This chapter also describes the various modules that can be installed with vCenter to provide additional functionality. We’ll also discuss vCenter Linked Mode Groups as a way to search across multiple vCenter instances for inventory objects.

Next we’ll examine the vSphere Client plug-ins. Plug-ins are installed for each instance of the vSphere Client. You need to install only those plug-ins that relate to your job responsi-bilities. We’ll look at the permissions required to install and enable a plug-in.

This chapter also shows you how to configure various aspects of vCenter Server. This includes several configuration maximums for managed ESX hosts and virtual machines. We’ll also discuss configuring and using several features of vCenter, such as scheduled tasks, resource maps, storage reports and maps, and the Task And Events tab. We’ll also explore several vCenter Server and vSphere Client settings that alter or adjust application or client behavior.

Finally we’ll look at access control. This topic is extremely important, but as you’ll see, the feature is relatively easy to implement. With vSphere, role assignments and the inventory objects that can be used to restrict access have been enhanced. We’ll investigate the predefined roles and break down one role to look at the privileges that define it. Creating, cloning, and editing a role will also be covered. We’ll present several permission assignment scenarios to see how vCenter propagates a role and how permissions are handled when multiple users or groups are assigned more than one role.

Installing vCenter ServerThe installation of vCenter is straightforward, but some planning is necessary to ensure a stable platform for managing a vSphere infrastructure. The primary reasons for purchasing vCenter Server are to

Consolidate your management tasksNN

Provide a single view into your environmentNN

Provide a robust set of features and functions to enhance datacenter managementNN

The installation can be broken down into four parts: planning, configuring the database, installing the vCenter Server application, and installing additional modules if needed.

178 Chapter 4 N Installing and Configuring vCenter Server

This objective has nine subobjectives:

Identifying hardware requirementsNN

Understanding configuration maximumsNN

Determining availability requirements for a vCenter server in a given situationNN

Determining the appropriate vCenter Server editionNN

Determining the database size requirementsNN

Preparing and configuring a vCenter server databaseNN

Installing vCenter Server using the downloaded installerNN

Installing additional modules:NN

vCenter Guided ConsolidationNN


vCenter ConverterNN

Determining a use case for vCenter Linked Mode GroupsNN

Identifying Hardware RequirementsBefore installing vCenter Server, you must meet the hardware requirements, regardless of whether the installation is on a physical machine or a virtual machine. The hardware require-ments have changed from the previous versions; Table 4.1 lists the minimum requirements.

TA B lE 4 .1 Minimum Hardware Requirements

Hardware Requirements

Processor Two Intel or AMD processors or two cores, 2 GHz each (processor speed may need to be higher if the database is on the same server)

Network Gigabit Ethernet recommended

Memory 3 GB (may be higher if the database is on the same server)

Storage 2 GB (may be higher if the database is on the same server)

VMware also makes recommendations for optimal performance, depending on whether the application is installed on a 32- or 64-bit Windows operating system and the number of ESX hosts that will be managed. VMware supports up to 200 hosts when you’re using a 32-bit OS and up to 300 hosts when you’re using a 64-bit OS. Table 4.2 provides the optimal performance recommendations.

Installing vCenter Server 179

TA B lE 4 . 2 Recommendations for Optimal Performance (Based on the Number of Managed Hosts)

Up to 50 Hosts, 250 Powered on VMs Recommendations

Processor Two CPUs

Memory 4 GB

Storage 3 GB

Up to 200 Hosts, 2,000 Powered on VMs Recommendations

Processor Four CPUs

Memory 4 GB

Storage 3 GB

Up to 300 Hosts, 3,000 Powered on VMs Recommendations

Processor Four CPUs

Memory 8 GB

Storage 3 GB

VMware recommends that customers use a 64-bit Windows OS for optimal performance and flexibility. If the logging or statistical levels are changed, additional storage will be needed. (See “Configuring vCenter Server Settings” later in this chapter for more information on adjusting statistical levels.)

Understanding Configuration MaximumsVMware publishes a document that provides maximum values for many features or aspects of the product. For vCenter, there are several maximums that relate to ESX hosts and VMs that you’ll need to know for the test. A maximum does not necessarily mean that a higher number could not be obtained, but it does represent a maximum value that will be supported.

Table 4.3 lists the configuration maximums. All numbers included here are fair game for inclusion on the test.


TA B lE 4 . 3 vCenter Configuration Maximums

Hosts or VMs Maximum

Managed hosts when using a 32-bit OS 200

Powered-on VMs when using a 32-bit OS 2,000

Registered VMs when using a 32-bit OS 3,000

Managed hosts when using a 64-bit OS 300

Powered-on VMs when using a 64-bit OS 3,000

Registered VMs when using a 64-bit OS 4,500

Hosts per datacenter 100

Other configuration maximums will be reviewed in the section “Determining a Use Case for vCenter Linked Mode Groups” later in this chapter.

Determining Availability Requirements for a vCenter Server in a Given SituationWhen looking at high availability (HA) options for vCenter, you should consider several scenarios. But first, you have to determine what amount of downtime can be tolerated for vCenter. On a positive note, even if the vCenter server were to fail or go down, the ESX hosts and the VMs they host are usually not affected much. Certain features managed by vCenter will no longer be available, such as DRS’s ability to use VMotion to achieve load balancing across servers. This can have an impact on the VM’s ability to acquire resources if a particular ESX host is overloaded, but the VM itself will still be running (although it will be degraded if DRS cannot be reestablished within a few minutes). Let’s look at several ways to provide high availability for vCenter and the pros and cons of each approach.

VMware vCenter Server HeartbeatIf your datacenter cannot tolerate any downtime for vCenter, VMware has a separate product that you can buy called vCenter Server Heartbeat. This product provides high availability for the vCenter application, its components (including licensing and plug-ins), and the database. vCenter Server Heartbeat will allow for a primary vCenter server, either physical or virtual, and a secondary vCenter server, also either physical or virtual. This product can monitor for software, operating system, network, hardware, and other out-ages that could impact your vCenter server.


Although there is a significant cost for this product, with more environments becoming heavily reliant on their vSphere infrastructures, any outage of the management of that infra-structure could be more costly than the cost of the product. Customers who will probably take advantage of vCenter Server Heartbeat include server-hosting providers and environments with many datacenters and a single vCenter server (a single point of failure).

VMware HAIf the datacenter can tolerate a few seconds of downtime and some loss of vSphere Client connectivity in that short timeframe, then using a virtual machine as your vCenter Server and allowing HA to restart the VM after an OS or ESX server hardware failure is an option. HA can monitor for OS failure or ESX host failure, but it will not monitor the application or networking outages on the VM or ESX host. VMware recommends that the vCenter server not be running in the same ESX environment that it is monitoring. The database should be kept separate, probably in its own high-availability cluster.

Creating a Microsoft ClusterIf the datacenter can tolerate a few second of downtime, the vCenter application can be clus-tered using a Microsoft cluster. Although vCenter Server is not a cluster-aware application, you can create a resource group that includes the vCenter application and fail it over to the passive node. For this to work correctly, you must create an active-passive cluster, either with physical or virtual servers. If you’re using VMs, the active node should be on one ESX host and the passive node on a different ESX host.

This type of high availability can monitor for operating system, network, or hardware failures. The database will usually be kept separate in its own high-availability cluster.

Creating a vCenter CloneIf the datacenter can tolerate a few minutes of unplanned downtime, then you could bring online a clone of the vCenter server (either physical or virtual) if the original vCenter server, usually a physical server, fails for whatever reason. There are some caveats to this method: you must test the clone periodically for updates in the domain and install any operating system patches in the clone at regular intervals. This method, especially if you’re using a VM as the clone, can be the least costly way to provide a form of high availability. This method could also be automated programmatically.

As mentioned several times earlier, the vCenter database is usually installed on a separate server. The reason is that many customers use Microsoft SQL or Oracle and the database has all of the vSphere infrastructure information. The database needs to be protected, backed up regularly, and monitored to ensure that the vCenter Server can do its job. Although Microsoft SQL Server 2005 Express can be used, it has never been recommended for production envi-ronments. Many customers create separate Microsoft SQL clusters, and the vCenter database is housed within those clusters.


VMware high Availability: Choosing the Best Option

Many customers use vSphere Client almost exclusively to administer various aspects of the vSphere environment . In most cases, the client needs to connect to vCenter to facilitate those tasks . Although some tasks can be accomplished by connecting vSphere Client directly to the ESX/ESXi server, this is considered bad form and many features are not available . You must choose the best option for your customer to provide high availability for vCenter Server .

What are the options and what are their pros and cons? As discussed earlier, there are at least four options:

vCenter Server HeartbeatNN

VMware HANN

Microsoft clusterNN

Virtual machine cloneNN

Some customers will have the budget to purchase vCenter Server Heartbeat . What is nice about this option is that it doesn’t matter if the vCenter server is physical or virtual . All vCenter services can be monitored, and if you’re using Microsoft SQL Server, it can be monitored as well (with both either on the same server or on a different server) . This product creates an active-passive application cluster and provides zero downtime for vCenter . The negative? It has a relatively high cost, especially for small businesses .

Using a Microsoft cluster or VMware HA are two options that will provide high availability for a low cost . If you’re using a Microsoft cluster in an active-passive design, the vCenter server can be physical and the passive failover node can be a VM . When you’re using VMware HA, the vCenter server will need to be running in a VM . The disadvantage to using these two options is that there will be some downtime as the Microsoft cluster fails over the resource group or while VMware HA restarts the virtual machine . The customer will have to decide whether this downtime is tolerable .

The last option, discussed earlier, is the use of a powered-off clone for the vCenter server . This option is easy to set up; you can make the clone of the active vCenter Server VM or a physical server . There’s no real cost to this solution . The disadvantage in this arrangement is the amount of downtime that can be experienced before the clone is powered on . The data-base will need to be on a separate server or cluster, but the vCenter application and services will be restarted on the clone . Unless you script the startup of the clone, this option may have the most downtime . In addition, the clone will need to be powered on once a month to reacquaint itself with the domain .


Two factors you should keep in mind when evaluating which option is right for a given environment are the amount of downtime that can be tolerated and the costs associ-ated with providing high availability . A good compromise for many customers is to use VMware HA for its ease of setup and relatively low amount of downtime .

Determining Appropriate vCenter Server EditionWhen looking to purchase an edition of vCenter Server, you should take an inventory of features that will be most relevant to your environment. Generally, the larger the environ-ment, the more features required and the more costly the license.

VMware has six license editions that provide a tiered approach to features: Essentials, Essentials Plus, Standard, Advanced, Enterprise, and Enterprise Plus. (See Table 1.2 in Chapter 1, “Planning, Installing, and Upgrading VMware ESX/ESXi.”)

As you can see, some of the more interesting features are only available with Advanced and Enterprise Plus. Even when comparing those two, only Enterprise Plus allows for utili-zation of VMware Storage VMotion, DRS/DPM, distributed switches, and host profiles.

Determining Database Size RequirementsvCenter utilizes a database to store just about anything having to do with your vSphere infra-structure. Over time, this database can become very large, mostly due to performance data that is used to provide trend analysis for different intervals. By default, vCenter can provide data for up to a year, so the amount of data that is stored to show those performance charts is quite large.

A nice feature built into the product is a sizing estimator to give you something to work with when you’re doing capacity planning for the database. Figure 4.1 shows the default view of this calculator.

Not only can you put your own numbers into the two fields for hosts and virtual machines to calculate a size, but in the top section of the calculator, you can change your retention set-tings for much of the data that is collected. These retention settings can greatly enlarge the size of the overall database. Be careful to avoid changing these settings if you are unsure about the amount of space that is available on the database server.

Exercise 4.1 shows the steps to make adjustments or calculate the size of the database.


Calculating the vCenter Database Size

1. Log into the vCenter server with the vSphere Client and on the menu bar, click Administration vCenter Server Settings .



2. From the item list on the left of the resulting dialog box, choose Statistics . The pane on the right shows you the default statistics intervals at the top and the database size calculator at the bottom .

3. Let’s tackle the bottom section first . Let’s say you have 25 ESX hosts and plan on converting and/or creating up to 500 virtual machines over the next year . Plug those two numbers into the fields and you can see that the estimated size after a year is 3 .92 GB of database space needed . From a capacity-planning perspective, this gives you some insight to the growth of the database .



4. Let’s change the numbers . Say that you’ve been given new information and because your organization is acquiring another company, the number of ESX hosts are expected to grow to 125 and the number of VMs on those hosts to about 1,200 . Plug those numbers in and you can see that the database will grow to around 9 .53 GB .

5. These examples were predicated on the fact that the statistics intervals were set to their default values . There may be environments that want to hang on to data longer for more granular performance analysis over longer intervals . By moving up to the Statis-tics Intervals section, you can adjust the retention policies . Let’s change the “5 Minutes” interval to a retention policy of 5 days (Save For) and a Statistics Level setting of 4, which provides more counters for analysis . We won’t change the bottom two numbers in the Database Size section .

6. As you can see, the database size went from 9 .53 GB to 99 .36 GB, or more than a ten-fold increase . Obviously, changing the settings in the Statistics Intervals section has an impact . Be careful to ensure that there is room for such growth . Change the set-ting for the “5 Minutes” interval back to the default or a retention policy of 1 day .


F I GU R E 4 .1 vCenter database sizing calculator

VMware also has a Microsoft Excel spreadsheet calculator for vCenter Server 4.0 that you can download from www.vmware.com/support/vsphere4/doc/vsp_4x_db_calculator.xls. This spreadsheet provides more variables and will also give you range and growth estimates for the database. In addition, use the spreadsheet if you haven’t installed vCenter yet. You may want an estimate before creating the database and installing vCenter.

Preparing/Configuring the vCenter Server DatabaseThe vCenter Server requires a database. VMware recommends that the database be installed on a separate server for inclusion with high-availability clusters and for proper backup of the database.

Table 4.4 shows various database products and their versions that can be used with vCenter Server.

TA B lE 4 . 4 Database Formats and Versions

Product Driver

Oracle 10g Release 2 (10 .2 .0 .4 .0)

Oracle 11g Release 1

SQL Server 2005 SP1 or newer SQL Native Client

SQL Server 2005 Express SQL Native Client

SQL Server 2008 SQL Native Client

IBM DB2

http://www.vmware.com/support/vsphere4/doc/vsp_4x_db_calculator.xls


Once you’ve chosen a database product, you will need to create a database on that server. Doing so involves creating the following:

The databaseNN

A user account for the installationNN

An Open Database Connectivity (ODBC) connection on the server on which vCenter NN

will be installed that will allow the application to connect to the database

The creation of the database is pretty straightforward when using either Microsoft SQL or Oracle. The key is to ensure that a user account has been assigned that has the correct rights. The account that is used to interact with the database as listed in the ODBC connec-tion will need Database Operator (DBO) rights for SQL databases (this level of privilege is necessary only for the installation or upgrade and can be lowered once these operations are completed) and the Resource role for Oracle databases.

Creation of the ODBC connection is also pretty straightforward. The key component is the user account used to communicate to the database.

Installing vCenter Server Using Downloaded InstallerInstalling vCenter Server helps you take advantage of the best features of VMware virtualiza-tion: VMware HA, DRS, DPM, VMotion, and vCenter Update Manager, among others. The vCenter Server is an application that runs in Windows, and there is no version for Linux.

You can download the vCenter installer from VMware’s website (see Figure 4.2), but only if you have a VMware Store account authorized for download. There are two types of downloads: a zip file that can be extracted and then used to install the product and modules or an ISO file that can be burned to media and then used to install. With either file, be sure to run a MD5 checksum to ensure that the downloaded file is not corrupted.

The installation of vCenter is broken down into separate parts for the application, the modules, and vSphere Client. In the past, a Typical installation installed everything, and a Custom installation let you choose what you wanted to install. Today’s installer installs only one component at a time (see Figure 4.3).

There are two ways to install a vCenter server: on a physical box or on a virtual machine. The installer doesn’t make a distinction between physical and virtual machine. In either case, making sure that minimum hardware requirements and operating system requirements are met will ensure a stable installation.

Many environments are small enough that dedicating a physical server for running vCenter is not very efficient, given that we try to virtualize just about any application. VMware has for some time recommended that if you want to run the vCenter server on a VM, don’t run the VM in the same environment that it manages. This can prove difficult if the customer only has one group of ESX hosts, so VMware has relaxed that language. You must take care to ensure that vCenter running on a VM gets the resources it needs to manage the environment. This can be accomplished with CPU or memory reservations in most cases.

If you’re considering installing vCenter on a VM, there are some advantages:

You don’t have to dedicate a physical server.NN

You can provide high availability using VMware HA.NN


You can migrate the vCenter workload to another ESX host as needed.NN

You’ll have the ability to use snapshots, like any other VM, for help with rolling back NN

patches that have an adverse impact, creating backups, or archiving.

F I GU R E 4 . 2 Download page for the vCenter installation files

F I GU R E 4 . 3 Initial installation screen


In many environments, the first VM created on the first ESX host is used to install vCenter. Here is the process for installing vCenter on the first VM:

1. On the first hardware server, install ESX.

2. On a PC that has access to the ESX server network, install vSphere Client.

3. Log into the ESX host with vSphere Client. Create a virtual machine, following vCenter hardware requirements, and install the appropriate Windows operating system.

4. Map the virtual CD-ROM drive of the VM to the vCenter installer ISO file and install vCenter.

The installation of vCenter on a dedicated physical server is similar to installing any other application. Again, be sure to meet the minimum hardware requirements. Using a dedicated physical server prevents the vCenter application from having to compete for resources. Exercise 4.2 covers the installation process.

E X E R C I S E 4 . 2

Installing vCenter Server

1. After logging into the server to be used for vCenter, kick off the installer by finding the installation media or folder where the autorun.exe file is located .

2. From the main installation menu, VMware vCenter Installer, choose the menu option vCenter Server to install . In the Choose Setup Language dialog box (shown here), select the language for the installer and click OK .

3. On the Welcome screen, click Next . The End-User License Agreement (EULA) will then be presented; select the “I agree to the terms in the license agreement” check box and click Next .



4. On the Customer Information screen, type your name, organization, and optionally the vCenter license key (if you have one) . The key does not have to be entered at this time . If you don’t enter a key, the vCenter Server will run in Evaluation mode . You have 60 days to install a proper key . (Once vCenter is installed, the license can be added by logging into vCenter with vSphere Client and following the procedures for adding a license .) Click Next .

5. On the Database Options screen, choose the database you wish to use . You have two choices:

Install a SQL Server 2005 Express instance (for small-scale deployments)NN

Use an existing supported databaseNN

If a database is not available, choose the first option . This is the easiest option to start with and does not require you to create an ODBC DSN . But the downside is that it is only good for up to 5 hosts and 50 VMs in addition to having a 4 GB database size limitation . If a database does exist, you will select the correct ODBC DSN from the drop-down list . Click Next .



6. On the second Database Options screen, for Database Username, use an account that has local administrative rights and provide the correct password . Click Next .

7. You may see a warning box about reinitializing the database if you’re trying to install vCenter over a previous installation . If the database needs to be reinitialized, choose “Replace my existing database with an empty one” and click Next .

8. On the vCenter Service screen, select which account needs to be used to start the vCenter Server and related services . By default, the local System account is selected . In many environments, this is not allowed, and you must create an account in the domain that will be used that has fewer privileges (Logon As A Service) on the local server . Once you’ve selected or entered an account, click Next .



9. The next page is the Destination Folder screen . In most cases, the default locations for the installation on the local drive will be sufficient . Click Next .

10. Next is the vCenter Server Linked Mode Options screen . If this is the first vCenter Server, choose “Create a standalone VMware vCenter Server instance .” For this example, that’s what we’ll choose . Click Next .

11. The Configure Ports screen is next . In most cases you will not have to make any changes . Click Next .



12. On the Ready To Install The Program screen, click Install . Remember, this process will only install vCenter Server . If you need the other modules, such as VMware Enterprise Converter, you will have to install them separately .

13. Once the installation completes, click Finish .

At this point, you can further configure your newly installed vCenter Server by installing vSphere Client, logging into vCenter Server, and then adding licenses, creating datacenter objects, adding ESX hosts, creating folders for the virtual machines that will be built, and many other tasks.

Installing Additional ModulesFor many environments, the next step to configuring a vCenter Server is to install the vari-ous modules that enhance its functionality. These modules are installed separately with vSphere, unlike previous editions where many of the modules were installed with vCenter by default. This edition lets you choose what you actually need.

Here are the three modules that VMware makes available:

vCenter Guided Consolidation Used to discover, analyze, and plan the conversions of physical servers

vCenter Update Manager (VUM) Provides patch and upgrade management for virtual machines, virtual appliances, and ESX hosts

vCenter Converter Used to convert physical servers, backup images, third-party images, and other types of VMs, both VMware and third party, and to restore VMs from VMware Consolidated Backups images

The first module we’ll take a look at installing will be vCenter Guided Consolidation. This module is used by the customer to identify, assess, and convert physical servers into virtual machines. VMware has a service known as Capacity Planner that can be purchased from an authorized partner. The Guided Consolidation module is a “lite” version of that service and tool.

The current version of Guided Consolidation can discover physical servers in a domain-specific IP subnet, or you can import a list into the product. Once the servers have been discovered, you can select up to 500 servers to be analyzed for current perfor-mance trends, or you can assess peak workloads for CPU, memory, disk, and network. After the analysis has had a chance to run for a while, the next step is to create a consol-idation plan, which will allow you to select those physical servers you want to convert. Once you’ve made your selections, vCenter Converter is launched, and the conversion of the physical server begins.

The installation files for vCenter Guided Consolidation are contained on the same installer media as vCenter Server. Guided Consolidation is listed as a separate item for installation. To


begin the installation, click on the link on the first screen that presents the installation options. Exercise 4.3 walks you through the installation of this module.

E X E R C I S E 4 . 3

Installing the vCenter Guided Consolidation Module

1. On the CD or from the directory of the installer files, double-click the autorun.exe file to begin .

2. On the main window, click the vCenter Guided Consolidation link .

3. Choose the installation language and click OK . Next, on the Welcome screen, click Next . On the EULA screen, select “I agree to the terms in the license agreement” and click Next .

4. On the Default Installation Location screen, choose the directory in which you wish to install the service . Typically, the defaults are fine . Click Next .

5. Provide an administrative username and password for the service . This will usually be the same account that you used for vCenter Server installation . Click Next .

6. On the Configure Ports screen, review the ports and then click Next .

7. Next, provide the IP address or fully qualified name of the vCenter server on which the Guided Consolidation module will be working . If the same server is being used for both components, then type localhost as the name of the vCenter Server .

8. On the next screen, choose an HTTP/HTTPS port to use for communication . Port 443 will be used by default . Also, provide a username and password that has administra-tive privileges on the vCenter server that allows for module registration . Click Next .

9. From the drop-down list, choose vCenter Server and click Next .

10. Click Install; after the installation has completed, click Finish .

The next module to install is the VMware vCenter Update Manager (VUM). This module is of great importance in many environments as it will be the patch and upgrade management module that keeps the virtual machines, virtual appliances, and ESX hosts up-to-date. This module has many features that are covered in Chapter 6, “Managing Compliance.”

The installation has a similar feel to the previous Guided Consolidation module. Unlike the previous module, VUM requires a supported database. Once a database has been created or the decision has been made to use the Microsoft SQL Server 2005 Express database, the installation can begin. See Chapter 6 to learn how to install vCenter Update Manager.

The next module to install is the vCenter Converter. This module allows for the conver-sion of physical servers, images, and other sources. Having this module installed with vCenter allows you to stay logged into vCenter but still perform conversions. The vCenter Converter module, like VUM, can be installed separately if the workload is high enough to have a nega-tive impact on the vCenter Server service if they are installed on the same server.


Exercise 4.4 outlines the steps for the installation of the vCenter Converter module.

E X E R C I S E 4 . 4

Installing the vCenter Converter Module

1. On the CD or from the directory for the installer files, double-click the autorun.exe file to begin .

2. On the main window, click the vCenter Converter link .

3. Choose the installation language and click OK . Next, on the Welcome screen, click Next . On the EULA screen, select “I agree to the terms in the license agreement” and click Next .

4. On the Default Installation Location screen, choose the directory in which you wish to install the service . Typically, the defaults are fine . Click Next .

5. The next screen allows for two types of installation: Typical (Recommended) or Cus-tom . Select Typical .

6. On the same screen, enter the IP address or fully qualified domain name for the vCenter server . Next choose an HTTP/HTTPS port to use for communication . Port 443 will be used by default . Also, provide a username and password that has admin-istrative privileges on the vCenter server that allows for module registration .

7. On the Configure Ports screen, review the ports and then click Next .

8. From the drop-down list, choose vCenter Server and click Next .

9. Click Install; after the installation has completed, click Finish .

Do not forget to install the plug-in, which we’ll cover in the section “Manage vSphere Client Plug-ins” later in this chapter .

Determining a Use Case for vCenter Linked Mode GroupsA highly requested feature by the user community has been the ability to link more than one vCenter Server together. This arrangement allows an administrator to search across multiple vCenters or administer objects in another vCenter server other than the one he or she is logged into. In the past, each instance of the older VirtualCenter server was an island and did not have the ability to look across to neighboring VirtualCenter instances. Today, multiple environments can be linked.

Linked Mode is accomplished by using Microsoft’s Active Directory Application Mode (ADAM) to store specific data about each instance of the vCenter servers that are linked. With vSphere 4.0, ADAM is automatically installed and will show up in the Window’s Services


applet as VMwareVCMSDS service. After you link at least two instances of vCenter together, you can do the following:

Log into one vCenter server but have access to all linked servers.NN

Search across all vCenter servers that are linked (although you are restricted by NN

permissions).

View inventories across more than one vCenter server in one view.NN

Here are several requirements for using a Linked Mode group:

DNS is mandatory so that replication will work correctly.NN

The vCenter servers must be in the same domain or in domains with two-way trusts.NN

The user account needed to link the two vCenter instances will need to have adminis-NN

trative rights on both servers (most likely a domain administrator).

Time synchronization must be in place and working on both servers, and they cannot NN

be more than 5 minutes apart.

When considering the use of a Linked Mode group, review these factors before linking two or more vCenter servers together:

A user logged into one vCenter Server will only see objects in another linked server if NN

appropriate permissions have been assigned. Otherwise, the user will still be limited to seeing only objects in the vCenter server they have logged into.

The first vCenter server must be installed as a standalone server. If other vCenter servers NN

are installed, they can then be pointed to the first server for linking.

Each vCenter server can use a different domain user account for starting the related NN

services. By default, the local System account is used.

During the process of linking two servers together, if an IP is used to reference a vCenter NN

Server, it will be resolved to the fully qualified domain name.

Linked Mode cannot be accommodated during an upgrade of an older version of Virtual-NN

Center. After the upgrade process, Linked Mode can then be accommodated.

Once you’ve reviewed these considerations, identify the reason you want to link two vCenter servers. If administrators in multiple locations and probably datacenters are respon-sible for objects in other locations and datacenters, then a case can be made to link vCenters installed at each datacenter. In the past, administrators would have to log into each instance of vCenter to manage those objects in different locations and datacenters.

In addition, many customers have purchased more than one instance of vCenter due to geographical, regulatory, or administrative reasons. Since earlier editions could not work together, managing across vCenter server instances required logging out of one instance and logging into another. With Linked Mode and the correct permissions, this is unnecessary.

Let’s take a look at one example in which using Linked Mode can be very advanta-geous. Say your customer has such a large environment that they’ve hit the limit for one vCenter server instance. Table 4.3 earlier in this chapter lists the configuration maxi-mums and shows the limits for one vCenter server for ESX hosts and virtual machines.


If your customer has more than 300 hosts or more than 3,000 powered-on VMs, they will have to install another vCenter server instance. This scenario is more common when virtual desktops are being used.

To allow the same company the ability to manage all their objects by logging into one vCenter server, Linked Mode can be used. Table 4.5 shows the configuration maximums for vCenter servers in Linked Mode.

TA B lE 4 .5 vCenter Configuration Maximums: Linked Mode

Scaling Maximum

Linked vCenter Server instances 10

Hosts 1,000

Powered-on VMs 10,000

Registered VMs 15,000

As Table 4.5 shows, the increase in the number of hosts and virtual machines is not lin-ear when compared with a single vCenter server instance. Using our earlier example, if the company has 7,000 virtual machines, three vCenter Servers will need to be installed, each accommodating up to 3,000 VWs. The first instance will be installed as a standalone, and the other two will then be installed and linked to the first instance. This will give your cus-tomer a maximum of 9,000 VMs, and the administrator would have to log into only one instance to see any VM on any of the three vCenter servers.

Exercise 4.5 shows the steps to joining two vCenter servers together in Linked Mode after the initial installation.

E X E R C I S E 4 . 5

joining Two vCenter Servers with linked Mode

1. On the server where vCenter is installed, click Start Programs VMware vCenter Server Linked Mode Configuration . On the Welcome screen, click Next .

2. On the next screen, select Modify Linked Mode Configuration; then click Next .

3. On the next screen, click “Join this vCenter Server instance to an existing linked mode group or another instance” and click Next .

4. Next, type the fully qualified name of the first server and review the LDAP port number (which should not have to be changed) . Click Next .



5. The Linked Mode installer may detect that there are role conflicts between the two servers . This usually comes about due to having a role on each server with the same name but with slightly different privileges . You are given two options:

Yes, let VMware vCenter Server resolve the conflicts for me .

No, rename the conflicting roles manually or change the privileges to match for both roles .

Click Next . Some time will elapse as the two servers are synchronized .

6. Click Finish .

Managing vSphere Client Plug-insStarting with VirtualCenter 2.5, the ability to install additional functionality or enhance the client was introduced. With the release of vSphere 4.0, vSphere Client can be augmented with a great many plug-ins, from both VMware and third-party sources. These plug-ins continue the evolution of vSphere Client and will provide the end user with a highly extensible tool.

We examine four subobjectives in this section:

Identify available plug-insNN

Determine required plug-ins for a given applicationNN

Ensure permissions to install plug-insNN

Enable plug-ins after installationNN

Identifying Available Plug-insOnce a module, either VMware or third party, has been installed, a client component becomes available for installation with a vSphere Client. Each vSphere Client should install only those plug-ins that allow the administrator to accomplish their job responsibilities or functions. There is no way at this time to restrict who can download and install a specific plug-in. The administrator will need to have administrative rights to their local machines for the installation of a plug-in. Plug-in management is done using the Plug-in Manager window (shown in Figure 4.4).

The Plug-in Manager is used to do the following:

View plug-ins that have been installedNN

View plug-ins that have not been installed but that are availableNN

Download and install the plug-in into the vSphere ClientNN

Enable or disable a plug-inNN

Managing vSphere Client Plug-ins 199

F I GU R E 4 . 4 Plug-in Manager

Determining Required Plug-ins for a Given ApplicationModules that are installed to work with vCenter have a corresponding vSphere Client plug-in. The plug-ins are easy to identify, as you saw in the previous section. In the Plug-in Manager, each plug-in is named for the module or function that was installed on the vCenter server or installed on a separate server that is working with vCenter Server. Usually three plug-ins are installed during the default installation of vCenter (see Figure 4.5):

vCenter Storage MonitoringNN

vCenter Hardware StatusNN

vCenter Service StatusNN

After a new module is installed, such as vCenter Converter, the plug-in will be listed in the Available Plug-ins section, as you can see in Figure 4.5.

F I GU R E 4 .5 Plug-in Manager


Ensuring Permissions to Install Plug-insInstalling the plug-ins will require administrative rights to the local machine where the vSphere Client is being run and where the plug-in will be installed. An account that is not a member of the local Administrators group will not be able to install a plug-in.

Enabling Plug-ins After InstallationOnce you install a plug-in, you can enable or disable it by using the Plug-ins Manager. Figure 4.6 shows the option to enable a plug-in.

F I GU R E 4 .6 Enabling a plug-in

Configuring vCenter ServerMany features and settings can be configured on a vCenter server. Adding ESX hosts, scheduling tasks, organizing objects, looking over the maps, and managing events are just some of the possibilities. Many of the settings will enhance productivity and provide orga-nization for the many objects that are created. Other settings manage the behavior between vCenter and the database, mail servers, SNMP management systems, and Active Directory.

You should develop a good understanding of these settings and objects to get the most out of your vSphere infrastructure.

Ten subobjectives are covered in this section:

Identifying the vCenter Server managed ESX hosts and virtual machines maximumsNN

Joining ESX/ESXi hosts to vCenter ServerNN

Configuring guest OS customizationNN

Using datacenters and folders to organize the environmentNN

Configuring/use scheduled tasksNN

Configuring vCenter Server 201

Configuring/use resource mapsNN

Using storage reports/storage mapsNN

Viewing/Managing eventsNN

Configuring vCenter Server settingsNN

Configuring vSphere Client settingsNN

Identifying the vCenter Server Managed ESX Hosts and VM MaximumsAs we have seen earlier in this chapter, there are many configuration maximums. Thus far, we have seen maximums as they pertain to vCenter Server and the number of man-aged ESX hosts and virtual machines. In this section, we’ll look at maximums that per-tain specifically to the ESX hosts and the virtual machines. Many of these maximums are never seen in real-world environments, but VMware has qualified and will support the numbers that are published.

Maximums as they relate to managed ESX hosts fall into five categories and are listed in Table 4.6. This table lists many interesting facts, but does not include all the information published by VMware. Always check for the latest numbers as new vSphere updates some-times increase maximums.

TA B lE 4 .6 ESX Host Maximums

Storage Maximum

VMFS

Raw device mapping size 2 TB, less 512 Bytes

Volume size 64TB, less 16K

Virtual machines per volume 256

Volumes per host 256

Extents per volume 32

Host per cluster 32

Extent size 2 TB, less 512 Bytes

Block size – VMFS3 8 MB

File size using 1 MB block 256 MB, less 512 Bytes


Storage Maximum

File size using 2 MB block 512 GB, less 512 Bytes

File size using 4 MB block 1 TB, less 512 Bytes

File size using 8 MB block 2 TB, less 512 Bytes

Fibre Channel

LUNs per host 256

LUN size 2 TB, less 512 Bytes

Paths to LUN 32

LUN ID 255

HBAs per host 8

HBA ports 16

Targets per HBA 256

NFS

Default NFS datastores 8

NFS datastores 64

Hardware iSCSI

LUNs concurrently used 256

Initiator ports per host 4

Paths to LUN 8

Dynamic targets per adapter port 64

Static targets per adapter port 61

Software iSCSI Initiators

NICs port bound with the software iSCSI stack per server 8

TA B lE 4 .6 ESX Host Maximums (continued)


Storage Maximum

Targets, the sum of both dynamic and static targets 256

Paths to a LUN 8

Compute

Virtual CPUs per host 512

Virtual machines per host 320

Logical processors per host 64

Virtual CPUs per physical core 20

Virtual CPUs per physical core for Update 1 25

Memory

RAM per host 1 TB

Service Console RAM 800 MB

Networking

Physical NICs

1GB Intel 32

1GB Broadcom 32

10GB Various 4

vNetwork Standard Switch

Total ports per host 4,096

Total ports 4,088

Port groups 512

Standard switches per host 248



Storage Maximum

vNetwork Distributed Switch

Distributed virtual network switch ports per vCenter 6,000

Distributed port groups per vCenter 512

Distributed switches per vCenter 16

Hosts per distributed switch 64

Resource Pool and Cluster

HA Cluster

Hosts per cluster 32

Virtual machines per host with 8 or fewer hosts 100

Virtual machines per host with 8 or fewer hosts Update 1 160

Failover hosts 4

Failover percentage 50%

DRS

Hosts 32

Virtual machines 1,280

Virtual machines per host 256

Resource Pool

Resource pools per host 4,096

Children per resource pool 1,024

Resource pools per cluster 512



Maximums as they relate to managed virtual machines fall into seven categories (see Table 4.7). This table lists many interesting facts, but does not include all the information published by VMware. Always check for the latest numbers as new vSphere updates some-times increase maximums.

TA B lE 4 .7 Virtual Machines Maximums

Compute Maximum

Virtual CPUs (Virtual SMP) 8

Memory

RAM 255 GB

Virtual machine swap file size 255 GB

Storage Virtual Adapters and Devices

Virtual SCSI adapters 4

Virtual SCSI targets per adapter 15

Virtual SCSI targets 60

Disk size 2 TB, less 512 Bytes

IDE controllers 1

IDE devices (CD-ROM) 4

Floppy devices 2

Networking Virtual Devices

Virtual NICs 10

Virtual Peripheral Devices

Parallel ports 3

Serial ports 4

Miscellaneous

Concurrent remote console connections to a VM 40


Joining ESX/ESXi Hosts to vCenter ServerThere wouldn’t be much to do without ESX hosts to manage in vCenter. Adding a host is easy. Logging in with the vSphere Client—either directly to the host or through vCenter—allows you to manage a host or hosts. If you are directly connected to a host, you can modify most configuration settings for the host and the virtual machines. Any features that involve multiple hosts will require connecting to vCenter Server. The rule of thumb is to always use vCenter Server for administration tasks unless you are unable to do so.

A very important detail when joining an ESX host to vCenter is to make sure that the host has a fully qualified domain name (FQDN) and that the root account and its password are known. Once the ESX host has been added to the inventory, any VMs that are being hosted on ESX will be discovered by vCenter and added to the inventory. Exercise 4.6 walks you through the process of joining an ESX host to vCenter.

E X E R C I S E 4 . 6

joining an ESX host to vCenter

1. Login to the vCenter server with the vSphere Client and click Host And Clusters in the Inventory section . From the Host And Clusters inventory view, right-click a datacen-ter, cluster, or folder and choose Add Host .

2. On the first screen of the Add Host Wizard, type the FQDN of the ESX host and pro-vide the root user account and password . Click Next .

3. Review the Host Information screen, which will show the ESX server hardware, build number, and any VMs being hosted . Click Next .



4. On the Assign License screen, select the “Assign a new license key to this host” and click the Enter Key button . Type the 25-digit key that corresponds to your ESX servers and click OK . Then click Next .



5. On the Choose the Destination Resource Pool screen, choose what to do with any “standalone” resource pools that the ESX server may have . If the ESX server does not have any resource pools, this screen will not show . Click Next .

6. Review the information on the Ready To Complete screen . Click Finish .

After the host had been joined to the inventory, it will be managed through vCenter almost exclusively. With the proper configuration of vCenter and visibility to storage and networking, an ESX server can participate fully with a cluster of ESX servers and take advantage of the DRS and HA features.


Configuring Guest OS CustomizationA great feature of vCenter is the ability to provision new virtual machines from a template or to clone an existing VM to create a new virtual machine. Since both methods start with an existing VM, the newly created VM may possibly confl ict with the original VM or image if certain aspects of the operating system are not changed. This process of change is known as guest operating system customization and is provided as an option when using the deploy from template and clone wizards to create a new VM.

To have access to this feature for Windows virtual machines, you will have to download and install the fi les that make up Microsoft’s Windows Sysprep. These fi les are not part of vCenter Server’s installation, and you have to download them from Microsoft’s website (refer to VMware KB article 1005593 for help in downloading the correct versions for different Windows operating systems) and then extract the fi les into the appropriate directories on your vCenter server.

The steps necessary to extract the fi les to the right directory on your vCenter Server are as follows:

You must download the Sysprep files before proceeding . The version of Sysprep used in this example will work for several versions of Microsoft Windows .

1. On the server where vCenter is installed and the Sysprep files are located, double-click the Sysprep file. This will open the cabinet file and present the files that make up Sysprep. Select all the files and then right-click and choose Extract from the context menu.

2. Browse to this path:

c:\Documents and Settings\All Users\Application Data\VMware\

VMware VirtualCenter\Sysprep\svr2003

In this example, we are only concerned with Microsoft Windows 2003, but if other versions are being used, extract the appropriate fi les into their respective folders.

3. Close the window displaying the cabinet files.

At this point, if you create a new virtual machine from either the template or clone wizard, the Guest Customization screen will display two available options: Customize Using The Customization Wizard and Customize Using An Existing Customization Specifi cation. If for some reason the fi les were extracted into the wrong folder or were never downloaded and extracted, these two options will be unavailable. Figure 4.7 shows the two new options.


F I GU R E 4 .7 Guest Customization options

Using Datacenters and Folders to Organize the EnvironmentThe creation of datacenter and folder objects in the inventory hierarchy is great way to begin organizing the ESX hosts, virtual machines, templates, and virtual appliances. Without these objects, everything would be jumbled together, making it hard to locate or discern which objects are which.

Every vCenter server needs at least one datacenter. The datacenter object allows the cre-ation or addition of the following objects:

FoldersNN

ClustersNN

HostsNN

NetworksNN

DatastoresNN

Virtual machinesNN

Without a datacenter, only folders can be created. If a company has more than one loca-tion with resources and ESX hosts at each, then more than one datacenter may be needed. Datacenters are logical boundaries; a datacenter relates to the resources it contains, mean-ing datacenters do not share VMs, networking, or storage. The one exception to this rule


is the ability to use templates or clones in one datacenter and deploy a new VM to another datacenter. Figure 4.8 shows a datacenter in the Hosts And Clusters view.

Folders are used in many of the inventory views to organize various objects. Folders can organize the following inventory objects:

DatacentersNN

ClustersNN

HostsNN

Virtual machinesNN

Other foldersNN

F I GU R E 4 . 8 Datacenter object in Host And Clusters view

Depending on the inventory view used, folders are either yellow or blue in color. If they are yellow, the vSphere Client is in Host And Clusters or Datastores view. If the folders are blue, the VMs And Templates view is being used. Figure 4.9 shows folders in Host And Clusters view, and Figure 4.10 shows folders in VMs And Templates view.

F I GU R E 4 . 9 Folders in Hosts And Clusters view


F I GU R E 4 .10 Folders in VMs And Templates view

Configuring and Using Scheduled TasksThe Scheduled Task feature is great for operations that may need to be performed when you are unavailable or when a task is repeated on a consistent interval. In some cases, only one task is necessary to achieve the desired result; in other cases, two tasks are needed (one to set a value and the other to take away that value, such as reservations being set on a VM or resource pool).

You can schedule the following tasks:

Change The Power State Of A Virtual MachineNN

Clone A Virtual MachineNN

Deploy A Virtual MachineNN

Migrate A Virtual MachineNN

Create A Virtual MachineNN

Make A Snapshot Of A Virtual MachineNN

Add A HostNN

Change Resource Settings Of A Resource Pool Or Virtual MachineNN

Check Compliance For A ProfileNN

To create a schedule task, select one of these scheduled tasks from the drop-down menu. This will launch a wizard that will step you through the specific task and then allow you to run the task at a predetermined time or repeat it at a specific interval.

Exercise 4.7 shows the steps for creating a snapshot scheduled task.

E X E R C I S E 4 . 7

Creating a Snapshot Scheduled Task

1. Log into the vCenter server with the vSphere Client and click Scheduled Tasks in the Management section .



2. In the Scheduled Tasks view, click the New button in the top-left corner . The Select a Task to Schedule dialog will appear .

3. Select Make A Snapshot Of A Virtual Machine from the drop-down list and click OK .

4. On the Select Virtual Machine screen, browse the inventory hierarchy on the right panel and select the VM you wish to snapshot . Click Next .



5. Next, on the Describe The Snapshot screen, provide a name and description for the snapshot that will be seen in the Snapshot Manager for that VM . In addition, you can select Snapshot Memory or Quiesce Guest File System (Needs VMware Tools Installed) as a part of the snapshot . Click Next .

6. On the Schedule Task screen, provide a name and description for the task . Choose how often the task should be run from the Frequency drop-down list (Once, After Startup, Hourly, Daily, Weekly, or Monthly) . In the Start Time section, there are two choices: Now or Later . If you choose Later, type the time for the task to commence and, depending on the Frequency option selected, how often to repeat the task .

7. Next, on the Notification screen, select the “Send email to the following addresses when the task is complete” check box if desired . If you select that option, you must also supply the email address of the recipient .



8. On the Summary screen, review the choices selected and click Finish .

9. If you defined the task to run “Now,” after a few moments the task will begin and will appear in the Recent Tasks bar at the bottom of the vSphere Client . Otherwise, the task will begin at the scheduled time you defined .

Configuring/Using Resource MapsA resource map is a feature that is useful for documentation and for verifying consistent vSphere relationships between various objects. Many objects provide a Maps tab, which allows you to see a particular object’s relationship with other objects in the datacenter. For example, select a VM from the inventory and look at the Maps tab to see its relationship with the host, datastore, and networking. These objects provide a Maps tab:

vCenter ServerNN

DatacenterNN

FoldersNN


ClustersNN

Resource poolsNN

Virtual machinesNN

For instance, a datacenter map can be configured to show several different relationships. Datacenter maps are host or virtual machine centric. Within each type are relationships that can be turned on by selecting check boxes. Figure 4.11 shows a datacenter map with all of the host-centric relationships turned on.

F I GU R E 4 .11 Datacenter relationships

Virtual Machine maps can show not only the relationships between the VMs and their host, but also networking and datastore relationships. In addition, they can also indi-cate the likelihood of a successful VMotion operation. A host that is that is eligible for a VMotion operation will show a green halo. A host that is not eligible will show a red halo and an “X.” Although not a guarantee that a VMotion will work, the green halo verifies that the network and datastore relationships the VM has with its hosts are valid. Figure 4.12 shows the map from the Maps tab for a VM and indicates whether the VM is eligible for a VMotion.

If a map needs to be saved for documentation or to show an issue with the configuration of a host or VM, choose File Export. In the resulting dialog box, select the file format and location for the saved file. You can also preview and print a map.

Using Storage Reports and MapsStorage resources have their own reports and maps. The Storage Views tab gives you a way to look at storage by type, host, resource pool, cluster, virtual machine, and cluster. The reports


also allow you to drill down for more detail about a datastore. Figure 4.13 shows a Storage Views report that shows all SCSI volumes (LUNs).

F I GU R E 4 .12 VMotion verification

F I GU R E 4 .13 Storage Views Report Example

Maps are another nice feature of the Storage Views tab. Clicking this button displays relationships between the datastores and hosts, datacenters, virtual machines, and clusters. You can adjust these maps as well as move or hide objects. Also, you can export these maps into Visio. Figure 4.14 shows the Storage Views tab and the Maps button.

Viewing/Managing EventsWith every complex application comes the inevitable need to view data about what events have taken place and who initiated them. You may want to save this information for archi-val or regulatory reasons. On the Home page, simply click the Events button to see what has transpired in the datacenter.

Each event will have data in several of the descriptive columns, such as type, timestamp, task, target, and user. The description will provide detail about what event took place. The Type column contains one of three levels of priority: Info, Warning, and Error. Next comes the timestamp, which shows when the event happened. The Task column shows what task was performed or scheduled to run. The Target column tells you if the task was performed


on a specific object, and the User column shows which administrator performed the opera-tion. Figure 4.15 shows the Events pane.

F I GU R E 4 .14 Storage Views Maps Example

F I GU R E 4 .15 The Events pane

With the long list of events shown, finding events for a particular task would be difficult if not for the Search feature in the top-right corner. This feature lets you type a text string that filters out events that are not relevant and shows only events that are of interest to you. Once cleared, the whole list is presented again. Figure 4.16 shows using the Search feature.


F I GU R E 4 .16 Using the Search feature

Also, in the top-left corner there is an Export Events button. The list of events can be exported into several different file formats based on several criteria. Figure 4.17 shows the Export Events dialog box that provides you with several ways to archive an event list by type, users, time, and limits.

F I GU R E 4 .17 Exporting events

When you select an event from the list, the Event Details pane at the bottom of the screen lists more information about the event and the object acted upon. In some cases, an event is composed of several tasks, and they appear in the order in which they were run. Figure 4.18 shows an event with multiple entries in the Event Details pane.


F I GU R E 4 .18 Event Details pane

Configuring vCenter Server SettingsThe default installation of vCenter Server will suffice for many things, but you’ll likely need to adjust several configuration settings. Table 4.8 shows the items that can be configured.

TA B lE 4 . 8 vCenter Configuration Settings

Setting Purpose

Licensing Assigns a vCenter license after the installation and specifies a license server for ESX 3 .x/3 .5 hosts .

Statistics Alters statistics intervals to retain performance data or increase the number of statistics gathered . The vCenter database calculator is also found here .

Runtime Settings vCenter Server Unique ID can be specified as well as the server’s IP address and FQDN .

Active Directory Specifies timeout values and query limits and enables validation periods when synchronizing with AD .

Mail Specifies a mail server to forward emails for triggered alarms .


Setting Purpose

SNMP Configures up to four SNMP receivers for traps .

Ports Specifies HTTP ports to be used with vSphere Clients and WebAccess clients .

Timeout Settings Specifies client connection timeout values .

Logging Options Configures the amount of detail collected in the vCenter logs .

Database Specifies maximum number of connections .

Database Retention Policy Specifies how long tasks are retained in the database; default is indefinitely .

SSL Settings vCenter will validate all connections with hosts based on SSL certificates .

Advanced Settings Contains settings and attributes that can be changed to alter vCenter behavior .

Two examples from Table 4.8 that are almost always configured are Licensing and Mail. Licensing allows the vCenter server to allocate licenses to ESX hosts (assets) as they are added to vCenter. Licensing also covers the vCenter server itself and what features are included. In most cases, two licenses will need to be added so that both the vCenter server and ESX hosts will operate with a license. Licenses consist of 25-digit keys. The keys represent the type of license, purchased features, and the number of CPUs to manage. Figure 4.19 shows the dialog box for entering additional keys.

Mail will allow the administrator to set up an email server to receive emails for triggered alarms. Each alarm has a specified email address that becomes the recipient of the alarm message. Figure 4.20 shows the fields where you enter the email server information.

Be sure to examine each setting and what it does in order to prepare for the exam.

Configuring vSphere Client SettingsIn addition to the vCenter server settings, vCenter Server has vSphere Client settings. The Client Settings dialog box is the control mechanism for how vCenter will interact with the client. Figure 4.21 shows the various sections of the General tab.

Typically, on the General tab, only the Tabs section at the bottom is used; you select Show Getting Started Tabs for each inventory object in your hierarchy and Default To Advanced Performance Charts.

TA B lE 4 . 8 vCenter Configuration Settings (continued)


F I GU R E 4 .19 Add License Key dialog box

F I GU R E 4 . 20 The Select Mail Sender Settings

On the Lists tab, three settings can be changed. In some cases, you’ll want to deselect the Show Virtual Machines In The Inventory check box in the Inventory View pane so that a large virtual machine inventory doesn’t force scrolling in Host And Clusters view (see Figure 4.22). Deselecting this option means that the VMs will be hidden from view, although you can still see them using the VMs And Templates view. Figure 4.23 shows the effect of deselecting this check box in Hosts And Clusters view. Figure 4.24 shows that the VMs are still visible in VMs And Templates view.


F I GU R E 4 . 21 General tab of the Client Settings dialog box

F I GU R E 4 . 22 The Lists tab for Client Settings in vCenter

F I GU R E 4 . 23 VMs hidden from view


F I GU R E 4 . 24 VMs still visible in VMs And Templates view

Configuring Access ControlWith the complexity and number of objects that can be created and managed in vSphere, there has to be a way to manage access to those objects. In vSphere, those objects can have a huge impact on an environment such as servers (VMs), datastores housing those VMs, and networking. Any change that is not well thought out could be disastrous.

This section covers eight sub-objectives:

Creating/Modifying user permissions in vCenterNN

Creating/Modifying user permissions in ESX ServerNN

Restricting access to vCenter inventory objectsNN

Defining vCenter predefined roles and their privilegesNN

Creating/Cloning/Editing rolesNN

Assigning roles to users and groupsNN

Describing how privileges propagateNN

Understanding permissions as applied to user and group combinationsNN

Creating/Modifying User Permissions in vCenterAccess control is implemented in vSphere based on three components:

Users or groupsNN

Roles, which are defined by a set of privilegesNN

Inventory objectNN

When these three components are combined, they create a permission that allows the user to interact with that object and potentially its children.

Configuring Access Control 225

Users and groups are used to specify who has access to certain objects. These users and groups are either local on the vCenter server or are imported from Active Directory. Using groups allows for easier permission assignment; also, if the group membership changes, you don’t have to do anything on the vCenter server side. If you assign permissions to indi-vidual users, then if the user becomes unavailable in Active Directory, they would be unable to interact with vCenter Server.

Roles are used to define a set of privileges that are then granted to users or groups for a specific inventory object. Based on the exact role, a user may be able to create and modify an object. In other cases, the role may be restrictive enough to only allow a user to see an object and its properties and tabs in the information panel.

Inventory objects are things like datacenters, clusters, folders, ESX hosts, and VMs. Once a user and role have been assigned to an inventory’s object, a permission is assigned to that object and any of its children by default. This means that if you assign a user and a role to a folder that organizes five virtual machines, this assignment is on the folder directly but would also include the VMs inside the folder.

When logging into vCenter with the vSphere Client, you must use a user account that had been assigned to inventory object or objects. Without that assignment, the user account will not be allowed to log in. The users used on vCenter Server come from Active Directory or are local to the vCenter server. There are no tools built into vCenter that allow you to manage, create, or modify users. Only Microsoft Windows tools can be used.

As users are imported and assigned to inventory objects, they are then given a role. This assignment allows them to log into vCenter with the vSphere Client or WebAccess client and see those objects. If vCenter servers are in a Linked Mode group, all users have the potential to see objects within all vCenter servers in that group.

A permission has three components: a user or group, a role, and an inventory object (see Figure 4.25). Using this user/role assignment to an inventory object, vCenter creates a per-mission. Here are the objects that can have a permission assigned:

DatacentersNN

ClustersNN

Resource poolsNN

FoldersNN

ESX hostsNN

Virtual machinesNN

TemplatesNN

vAppsNN

DatastoresNN

Networks (vStandard switches)NN

dvPort groupsNN


F I GU R E 4 . 25 The three components of a permission

User/Group

Object Role

By default, the local Windows Administrators group has permission to log into vCenter with the vSphere Client. This group includes the local Administrator account and the Domain Administrators group. The role of Administrator is assigned to the local Administrator group and allows full access. Only until other users or groups have been assigned roles on the root object or other objects will they be able to log in and perform tasks.

Exercise 4.8 illustrates the steps to create a permission on an inventory object.

E X E R C I S E 4 . 8

Creating a Permission in vCenter

1. Log into the vCenter server with the vSphere Client and click Host And Clusters in the Inventory section . From the Host And Clusters inventory view, right-click an inventory object (in this case, a VM) and then click the Permissions tab in the Informational pane .

2. On the Permissions tab, right-click a blank white space in that pane and select Add Permission from the context menu .



3. In the Add Permission dialog box, choose a role from the Assigned Role drop-down list . Then click Add in the lower-left corner to select a user or group .

4. In the Select Users Or Group dialog box, choose the domain you want to search from the Domain drop-down list . The easiest way to find a user or group is to type the name in the Search box . Once the name is displayed in the list, choose the user or group and click Add . Repeat this step if necessary . Click OK .



5. An optional step is possible . If the permission is to propagate to children objects, do not deselect the check box Propagate To Child Objects . Otherwise, deselect the check box so that the permission only applies to this object .

6. Review the steps and then click OK .


Creating and Modifying User Permissions in ESX ServerHost users are local to the ESX/ESXi server. By default, ESX/ESXi will only have the root account to log in with and provide administration. If the ESX/ESXi server has joined a vCen-ter server to be managed, an additional user, vpxuser, will be created and used by vCenter to communicate with the ESX/ESXi server.

Host users are only used when connecting directly to the ESX/ESXi server with the vSphere or WebAccess client. These accounts are not available in vCenter. If you log into the ESX hosts with the vSphere Client, you can create additional users or groups using the Users And Groups tab. As a best practice, creating one or two “regular” users will help protect the root account from being misused or used at all as some environments disallow root usage.

When assigning permissions when logged in directly to ESX/ESXi, you’ll see that the only inventory objects available to you are the ESX/ESXi server itself and any VMs run-ning on the server. Assigning permissions in this way requires two realities for the environ-ment: no vCenter and therefore no VMotion. If permissions were to be assigned at the ESX host level but the server is being managed from vCenter Server, the permissions may con-flict or have no real relevance. Of course, if permissions are assigned at the ESX host level and if VMotion moved the VM to another host, the permission would be moot.

Figure 4.26 shows the assignment of a permission using the vSphere Client connected directly to the ESX host.

F I GU R E 4 . 26 Assigning a permission when connected to ESX directly

Restricting Access to vCenter Inventory ObjectsMuch effort is made to assign permissions to inventory objects to give administrators access and privileges on those objects to do their jobs or follow through with their assigned respon-sibilities. Another aspect of access control is to hide or restrict access to inventory objects.

The best way to do this is to provide only enough privileges to a role to allow the admin-istrator to do their jobs and no more. Also, there are times when access to an object should


be tightly controlled or the object needs to be hidden from a user or group since they are not responsible for it. There are three ways to restrict access:

Define specific roles with only the needed privilegesNN

Assigned the No Access role to an object to remove any interaction with the objectNN

Assign roles lower down in the inventory so that objects are hidden from viewNN

The first technique is used frequently. You must take care to ensure that a role does not have too many privileges. This is usually in the context of creating a custom role where the vCenter administrator creates a role for a particular user or group. Testing will determine whether or not a role is exact enough to be used properly without allowing inadvertent access to features or functions not related to a user’s job responsibilities.

Figure 4.27 shows the Add New Role wizard and the selection of specific privileges.

F I GU R E 4 . 27 Creating a custom role

The second technique utilizes a role known as No Access. When this role is assigned to an object for a user or group, it revokes any privileges that user would have had otherwise. The object will become useless, and all tabs associated with the object will be blank. This role is useful in breaking inheritance on children objects when a role with privileges was assigned higher up in the inventory.


Figure 4.28 shows the result of adding No Access to an object, and Figure 4.29 illus-trates its effect on that object for a particular user.

F I GU R E 4 . 28 No Access assignment

F I GU R E 4 . 29 Result of No Access role

The third technique requires that role assignments be placed as low in the hierarchy as possible. This will hide peer objects from view. For example, if there were one datacenter, one cluster, and three resource pools in the cluster, assigning a user and role to one of the resource pools will hide the other two in the cluster from view. This approach is useful when multiple groups are responsible for different pools of VMs and the VMs outside their administrative influence should not be seen or otherwise manipulated.

Figure 4.30 shows the hierarchy with the role set too high on the inventory. Figure 4.31 shows an example of assigning the role on a lower object and what effect that has on the user’s view of the inventory.

F I GU R E 4 . 3 0 Role set too high in the inventory


F I GU R E 4 . 31 Role assigned lower on the inventory, hiding objects from the user or group

Defining vCenter Predefined Roles and Their PrivilegesRoles in vCenter have come a long way. In early editions there were only four roles. If they didn’t exactly fit your needs, you didn’t have any control over customizing them. Today, vSphere has several roles that are provided as samples and to give the administrator a start-ing point. These roles can also be cloned and customized to fit specific needs.

A role is a set of privileges that gives you, when logged into vCenter with the vSphere Client or with the web access client, the ability to create or manipulate inventory objects based on their job responsibilities. A role can be generous or it can be restrictive. The rule of thumb, as is in all information technology, is to provide just enough privileges on an object or objects for an administrator and nothing more. Otherwise, the potential for inad-vertent changes or deletions can create negative consequences.

The nine predefined rules give the beginning administrator a place to start. With these nine, you can create other custom roles that are more specific to your environment’s needs. Within these nine roles are two types: system and sample. The system roles are permanent roles that cannot be deleted, nor can they be modified. System roles are available for vCen-ter Server and ESX/ESXi hosts. Sample roles are intended to be cloned and/or modified to fit specific permission needs. Sample roles are not available to ESX/ESXi hosts. Table 4.9 lists the roles as well as their type and capabilities.

TA B lE 4 . 9 vSphere Default Roles

Role Type Capability

No Access System User cannot view or change an inventory object .

Read Only System User can view the state and details of an inventory object (not the Console tab) .


Role Type Capability

Administrator System User has all privileges for an object and its children .

Virtual Machine Power User

Sample Allows the user to modify the hardware of a VM and take snapshots .

Virtual Machine User Sample Allows the user to interact with the VM’s console and perform power operations . Cannot make modifications to hardware .

Resource Pool Administrator

Sample Creates and modifies child pools, but cannot modify the pool the permission was assigned . Allowed to assign permissions on child pools and virtual machines to child pools .

VMware Consolidated Backup User

Sample Role specific to VCB and used within that framework .

Datastore Consumer Sample Allows a user to consume space on a datastore when creating virtual disks or taking snapshots .

Network Consumer Sample Allows a user to assign VMs or hosts to a vSwitch, standard or distributed .

Creating, Cloning, and Editing RolesRole creation is a necessary task for most environments. The nine default roles can be used, but they may like specificity for a given group or user and their responsibilities. Depending on the complexity of your environment, you may need to create many roles. With the provided sample roles in vCenter, you can greatly reduce the amount of time needed to create a new role.

The ability to create a role is reserved for a user who has been assigned the Administrator role in vCenter. By default, this includes the local Administrator account and the Domain Administrators group. This can easily be changed so that the appropri-ate user in the environment has been assigned this role as well. Once logged into vCenter with the vSphere Client, you can create a role either from scratch or by cloning an exist-ing role.

Exercise 4.9 shows how to create a role from scratch. Exercise 4.10 shows how to clone an existing role to create a new role and edit that role to make it unique.

TA B lE 4 . 9 vSphere Default Roles (continued)


E X E R C I S E 4 . 9

Creating a Role from Scratch

1. Log into the vCenter server with the vSphere Client and click the Roles icon in the Management section . In the Roles panel, right-click a blank area within the panel and choose Add from the context menu .

2. In the Add New Role wizard, type a name for the role . Select the privileges that are necessary for the user’s or group’s job responsibilities; then click OK .


E X E R C I S E 4 .10

Cloning an Existing Role and Editing It

1. Log into the vCenter server with the vSphere Client and click the Roles icon in the Management section . In the Roles panel, right-click an existing role and choose Clone from the context menu .

2. vSphere creates a new role with the name “Copy of rolename .” Right-click this role and choose Edit from the context menu . In the Edit Role dialog box, type a new name for the role that is appropriate to the tasks or job responsibilities of that user or group . Next, select the privileges needed to achieve those tasks or job functions . Click OK when you’re done .


Assigning Roles to Users and GroupsAssigning roles to user or groups is the best way to ensure that the right people have access to their environment and that they can carry out their assigned job responsibilities. Assigning a role is quite easy, but be sure to create and/or edit the necessary roles first. Most objects in the inventory can have a permission assigned.

Assigning a role requires the Add Permission wizard. See Exercise 4.8 in the section “Creating and Modifying User Permissions in vCenter.”

Describing How Privileges PropagateThe Add Permission dialog box allows the permission being created to propagate to child objects. The option is enabled by default, as you learned earlier in step 5 of Exercise 4.8.

In vCenter, most objects inherit permission from at least one parent. In some instances, such as a virtual machine, multiple permissions may be inherited due to permissions being applied at different levels within the parent hierarchy. For example, a permission could be applied on the datacenter, then on the cluster, then on a resource pool, and finally on the virtual machine itself. The Permissions tab for the VM contains four permissions as long as there is a direct path to the VM and no explicit permissions have been applied overriding inheritance.

Understanding Permissions as Applied to User and Group CombinationsIn some environments, more than one permission may be applied to the same object. If you use groups when assigning roles to the same object or different objects, but in a direct line, the resulting permission for a group or a user that is a member of a group may be different from what you planned.

When you are assigning permissions to an object, a user or group can only have one role assigned for that object. Permissions that are applied explicitly on an object override inherited permissions for the same user or group from a parent object. If the user is a member of more than one group and each group has a different role, the resulting permission includes both roles. If the object has a user role assigned and a group role assigned in which the user is a member, the user role takes precedence, overriding any group permission for the same object.

Let’s look at three examples of how multiple permissions are handled for different situations.

First, here’s what happens when a user inherits multiple permissions. The context for this example is that two permissions are assigned to the same object for two different groups:

Role A can create virtual machines.NN

Role B can delete virtual machines.NN

Group A is assigned Role A on a resource pool and the permission is allowed to NN

propagate.

Summary 237

Group B is assigned Role B on the same resource pool, and the permission is allowed NN

to propagate.

User Brian is not assigned any specific permissions but belongs to both groups.NN

User Brian logs on. He will be able to create a virtual machine within the resource pool and delete the very same VM or any VMs already present due to inheritance of the permis-sions from the resource pool to the VMs.

In our second example, two permissions are assigned to two different groups for two different objects, but the objects are in a parent-child relationship:


Role B can delete virtual machines.NN


propagate.

Group B is assigned Role B on VM 1, already in the pool.NN

User Brian is not assigned any specific permissions but belongs to both groups.NN

Now when user Brian logs on, he will be able to create a virtual machine within the resource pool. He will only be able to delete VM 1 in the resource pool; he won’t be allowed to delete any of the ones he creates or that existed before. Explicit permissions on a child object override inherited parent permissions.

In the final example, two permissions are assigned to a user and a group on the same object. The user is a member of the group.



propagate.

User Brian is assigned the No Access role on the resource pool.NN

In this case, when user Brian logs on, he will not be able to create a VM within the resource pool, because the user permission overrides the group permission.

SummaryThis chapter focused on four topics dealing with vCenter: installation, vSphere Client plug-in management, vCenter Server configuration, and access control. By practicing the exercises, you will understand the various questions that the exam could ask about vCenter administration and vSphere Client configuration.

Calculating database size to allow for growth is a critical design consideration. In addition, providing high availability for vCenter can be accomplished in several ways. With the installa-tion of modules, vCenter can be augmented to provide additional functions and features.

Proper installation and use of vSphere Client plug-ins is essential. If you will be using more than one desktop or workstation to perform those duties, ensure that the proper plug-ins are installed at each location where vSphere Client is installed.


One of the most important considerations when deploying vCenter server is the proper configuration of the product to manage ESX hosts and their virtual machines. You must know how to organize inventory objects and use the built-in features and administrative tools. One of these tools is the Scheduled Tasks feature, which can be used to schedule tasks that need to occur on regular intervals, such as resource management for a virtual machine or resource pool. Also, using the maps for documentation purposes and identifying relationship problems between hosts, virtual machines, networking, and datastores will help in providing a consis-tent and reliable virtual infrastructure.

As a topic for study on the test, access control is a small but important subject. Understanding the various ways that permissions can be applied to an inventory object and how the permissions will be applied to a user or group cannot be emphasized enough. Working with the sample roles and cloning a role that is closest to what will be needed for a given situation can be a real timesaver. Although you can apply permissions in an ESX-only environment, this approach has major limitations and does not come close to the permis-sions and inventory structure available to you when using vCenter.

Exam Essentials

Know how to install vCenter Server. Be able to identify hardware requirements, configu-ration maximums, and availability requirements in a given situation. Know how to identify the appropriate vCenter Server edition and how to configure the vCenter database. Review the installation procedure for vCenter Server and know how to install additional modules, such as Guided Consolidation, Update Manager, and Converter. Review the use cases for vCenter Linked Mode Groups.

Know how to manage vSphere Client plug-ins. Be able to identify available plug-ins and determine the plug-ins you need for a module or application. Review the permissions needed to install and then enable a plug-in.

Be able to configure vCenter Server. Review the configuration maximum settings for vCenter in regard to managed ESX hosts and virtual machines. Know how to join an ESX server to vCenter for management. Practice the configuration for guest customization. Know how to use datacenter and folder objects to organize the vSphere environment. Know how to configure vCenter Server and Client settings.

Know how to configure access control. Know how to create and manage user permissions on both vCenter and ESX hosts. Know how to restrict access to vCenter inventory objects. Review the vCenter predefined roles and their privileges. Practice creating, cloning, and editing roles.


Review Questions

1. If you want to remove the Getting Started tabs from the display shown here, what would you do?

A. Change a vCenter server preference.

B. Change an ESX server preference.

C. Nothing; the Getting Started tabs only display when you are in evaluation licensing mode and automatically disappear when you properly license vCenter.

D. Change a vSphere Client preference.

E. Nothing; the Getting Started tabs cannot be removed.

2. Which of the following solutions will not provide high availability or failover in the event of a vCenter server crash?

A. vCenter Server Heartbeat

B. VMware FT

C. VMware HA

D. MSCS

E. Cold cloning the vCenter server


3. Which of the following is supported across multiple datacenter objects in the vCenter inventory?

A. VMotion

B. HA

C. Delegation of control

D. Deploying VMs via templates

E. FT

F. Distributed virtual switches

4. Which two of the following database products are not supported with vCenter 4.0?

A. SQL Server 2008

B. SQL Server 2000

C. IBM DB2

D. Oracle 11g

E. Oracle 9i

5. What is the maximum number of VMs per ESX 4.0 host?

A. 80

B. 128

C. 192

D. 256

E. 320

6. Which of the following are two reasons to join two vCenter servers via Linked Mode?

A. You want to be able to view inventory information across vCenter instances.

B. You want to use HA to fail over to an ESX host in another vCenter.

C. You want to manage vCenter 2.0 from a vCenter 4.0 server.

D. You want to exceed the maximum number of ESX hosts manageable by a single vCenter instance.

E. You need to connect 20 vCenter instances together.

7. A user has the No Access role assigned to the root object in the vCenter inventory. Further down in the inventory, this same user has the Administrator role assigned to a datacenter called QA. Assuming these are the only two permissions related to this user, when this user logs into vCenter, what level of access will he have in the QA datacenter?

A. None, because of the No Access permission

B. Administrator-level access, because of the Administrator role

C. He will not be able to log in because No Access at the root object prevents login access.

D. He will have Administrator access on the entire inventory as Administrator permission takes precedence over No Access permission.

E. vCenter will not allow you to define these sorts of conflicting permissions.


8. Using the vCenter sizing calculator, which of the following is shown to have the largest impact on the size of the vCenter database at the end of a year?

A. The number of physical hosts being managed

B. The number of virtual machines being managed

C. Changing the statistics level from 1 to 4

D. Changing the 5-minute interval duration from being saved for one day to five days

E. Disabling (by deselecting) the Save For 1-year statistics level

9. UserA is a member of GroupA. GroupA has been assigned the role Read Only applied to the datacenter Training in the vCenter inventory. In addition, UserA has been assigned the role VM Power User applied to the same inventory object, Training. When UserA logs into vCenter, what will she be able to do with the Training datacenter?

A. UserA will have Read Only role access.

B. UserA will have Administrator role access.

C. UserA will not be able to log into vCenter as she has conflicting user and group permissions.

D. UserA will have VM Power User role access.

E. UserA will only have access to the Training datacenter if she also has at least Read Only role access explicitly granted at the Training datacenter object’s parent object.

10. UserA is a member of two groups, GroupA and GroupB. UserA has no user-level permissions assigned in the vCenter inventory. Both GroupA and GroupB have permissions assigned to the same vCenter inventory object; GroupA is assigned the VM Power User role and GroupB the Read Only role. Which of the following describes what UserA will be able to do with the inventory object these group permissions have been assigned to?

A. UserA will get the least permissions: GroupB, Read Only.

B. UserA will get the most permissions: GroupA, VM Power User.

C. UserA will get the logical sum of the permissions of both GroupA and GroupB.

D. You cannot apply two different group permissions on the same vCenter inventory object.

E. UserA will not be able to log in as conflicting permissions are resolved by locking out a user’s access.

11. When you add an ESX/ESXi host to vCenter, you add it using its ________.

A. IP address

B. IPv4 and IPv6 addresses

C. Fully qualified domain name

D. Short hostname

E. Ethernet MAC address


12. Which of the following are default permissions on the root object of an ESX server that has not been added to vCenter? (Choose three.)

A. The dcui user has Administrator role access.

B. The Administrator user has Administrator role access.

C. The root user has Administrator role access.

D. The vpxuser user has Administrator role access.

E. The root user has Root role access.

F. The vpxuser user has Root role access.

13. You are deploying a Windows VM in vCenter by either cloning an existing VM or by deploying from a template. You would like to customize the VM during deployment. Which of the following is required to ensure a successful guest OS customization in the newly deployed VM?

A. You should download and extract the appropriate Sysprep files from Microsoft onto the vCenter server’s desktop.

B. You should download and extract the appropriate Sysprep files from Microsoft into the appropriate folder on the vCenter server.

C. You should download Sysprep from Microsoft and run the Sysprep installer on the vCenter server.

D. You will need to run Sysprep manually on the newly deployed VM.

E. You will need to run the sys-unconfig command in a command window on the Windows VM.

14. Which of the following features are unique to the VMware vSphere Enterprise Plus Edition? (Choose three.)

A. VMware HA

B. Third-party multipathing

C. Fault tolerance

D. Host profiles

E. Distributed switches

F. vShield Zones

15. Which of the following represents the maximum number of registered VMs supported by vCenter 4.0? (Choose two.)

A. 200 when using a 32-bit OS

B. 300 when using a 64-bit OS

C. 2,000 when using a 32-bit OS

D. 3,000 when using a 64-bit OS

E. 3,000 when using a 32-bit OS

F. 4,500 when using a 64-bit OS


16. What is the maximum amount of physical RAM supported on an ESX 4.0 host?

A. 64 GB

B. 128 GB

C. 256 GB

D. 512 GB

E. 1 TB

F. 2 TB

17. Which of the following are not tasks that can be scheduled in vCenter?

A. Implementing VMotion

B. Putting an ESX server into maintenance mode

C. Changing resource pool settings

D. Changing the power state of a VM

E. Scanning VUM

18. Which of the following is not a built-in role in vCenter?

A. No Access

B. Read Only

C. VM Power User

D. vCenter Power User

E. Resource Pool Administrator

F. Administrator

19. Which of the following represents the maximum number of ESX hosts that can be managed by vCenter 4.0? (Choose two.)

A. 200 when using a 32-bit OS

B. 300 when using a 32-bit OS

C. 200 when using a 64-bit OS

D. 300 when using a 64-bit OS

E. 2,000 when using a 32-bit OS

F. 3,000 when using a 64-bit OS

20. How is the downloading and installation of vCenter Server plug-ins controlled?

A. You define a custom role in vCenter with permissions to download and install vCenter Server plug-ins.

B. You must be a member of the VMAdministrators group.

C. Permissions are set in the Plug-in Manager GUI.

D. You need Administrator rights to the local machine where the vSphere Client is running.

E. You must log into the vCenter server as Administrator.

F. You must be a domain administrator.



1. D. The display of the Getting Started tabs is a preference set in the vSphere Client GUI. Each client user, therefore, can show or hide these tabs.

2. B. VMware FT, as of this writing, only supports single vCPU VMs and does not support physical servers at all. So, even assuming vCenter is running on a VM, FT won’t work because vCenter requires a minimum of two CPUs.

3. D. Deploying a VM using templates is the only option supported across multiple datacenters. Datacenters and their restrictions are important in the design of your vCenter inventory.

4. B, E. vCenter 4.0 requires SQL Server 2005 SP1 or better, or Oracle 10g Release 2 or better. IBM DB2 support is included as of vCenter 4.0 update 1.

5. E. With each ESX release, the maximum number of VMs supported on an ESX server has increased. At ESX 4.0 the current maximum is 320. Remember also, if you are running multiple vCPU VMs, the maximum number of vCPUs per ESX 4.0 host is 512.

6. A, D. VMware HA is not supported across multiple vCenter instances via Linked Mode. Linked Mode requires vCenter 4.0 or better and supports a maximum of 10 linked vCenter instances.

7. B. With conflicting user permissions defined at different levels in the inventory hierarchy, the lower-level permission overrides any higher-level permission. This is the case whether the lower-level permission grants more or less access than the upper-level permission. Grant con-flicting permissions with care!

8. C. Increasing the statistics level from level 1 (basic) to level 4 (all metrics supported by vCenter) has a significantly larger impact than any of the other factors. Of course, if you combine all of these options, the database can easily grow by over a factor of 10 from the default estimated size.

9. D. When user and group permissions collide on the same object, the user permission takes precedence.

10. C. When you have two groups, each with different permissions applied to the same vCenter inventory object, the permissions are logically added.

11. C. Although you can add ESX hosts to vCenter using either their short names or their IP addresses, using FQDNs is preferable. Some of the vSphere features require FQDNs or work better if you have added the ESX host using its FQDN. Get in the habit of adding ESX hosts to vCenter using their FQDNs.

12. A, C, D. By default, the root account (used by the vCLI, for example), the vpxuer account (used by vCenter), and the dcui account (used by the Direct Console Interface) have Administrator access set on the root object. There is no Root role defined by default.


13. B. Guest OS customization of new Windows VMs that have been cloned or deployed from template is accomplished by downloading Sysprep from the Microsoft website and extract-ing the Sysprep files into the appropriate folder on the vCenter server. If you are not sure which is the proper folder for the Sysprep files on the vCenter server, consult the VMware reference manual.

14. B, D, E. VMware vSphere Enterprise Plus Edition includes several features not available with the lower license tiers. These include third-party multipathing, distributed switches, and host profiles.

15. E, F. vCenter 4.0 supports 3,000 registered VMs when vCenter is running in a 32-bit version of Windows and 4,500 registered VMs when running in a 64-bit version of Windows. The 200 and 300 numbers represent the maximum number of ESX hosts supported by vCenter 4.0, and the other large numbers represent the maximum number of powered-on VMs supported by vCenter 4.0.

16. E. ESX 4.0 hosts now support a maximum of 1 TB of physical RAM.

17. B. vCenter Server allows you to schedule changing a VM’s power state, cloning a VM, deploying a VM, migrating a VM (using VMotion), creating a VM, making a snapshot of a VM, adding an ESX server to the inventory, changing a VM or resource pool’s settings, and checking ESX host profile compliance.

18. D. The other built-in roles are Virtual Machine User, VMware Consolidated Backup User, Datastore Consumer, and Network Consumer.

19. A, D. vCenter 4.0 can manage 200 ESX hosts when vCenter is running in a 32-bit version of Windows and 300 ESX hosts when it is running in a 64-bit version of Windows. The 2,000 and 3,000 figures represent the maximum number of powered-on VMs that vCenter supports.

20. D. There is no mechanism at this time for restricting who can install plug-ins. Local administrators on the system running the vSphere Client GUI are allowed to install and manage plug-ins. Although being a domain administrator gives you the ability to manage plug-ins, it is not a requirement as long as you have local administrator privileges.

Chapter

5Deploying and Managing Virtual Machines and vApps


Create and Deploy Virtual Machines.NÛ

Understand virtual machine hardware maximums .NN

Create a virtual machine .NN

Determine appropriate SCSI adapter .NN

Determine Virtual Disk type .NN

Install/Upgrade/Configure VMware Tools .NN

Create/Convert templates .NN

Customize Windows/Linux virtual machines .NN

Manage Customization Specifications .NN

Deploy a virtual machine from a template .NN

Deploy a virtual machine using VMware vCenter Converter NN

Enterprise .

Perform a Hot Clone .NN

Perform a Cold Clone .NN

Perform System Reconfiguration .NN

Deploy a virtual machine using Guided Consolidation .NN

Perform Discovery .NN

Analyze discovered virtual machines .NN

Consolidate selected virtual machines .NN

Clone a virtual machine .NN

Import a virtual machine from a file/folder .NN

Manage Virtual Machines.NÛ

Configure/Modify virtual machines .NN

Add/Hot Add virtual machine hardware .NN

Grow virtual machine disks .NN

Determine appropriate disk format .NN

Connect virtual machines to devices .NN

Configure virtual machine options .NN

General Options .NN

Advanced Options .NN

Power Management Options .NN

VMware Tools Options .NN

Configure appropriate virtual machine resource settings .NN

Deploy vApps.NÛ

Determine whether a vApp is appropriate for a given NN

situation .

Define Open Virtual Machine Format (OVF) .NN

Import/Export a Virtual Appliance .NN

Build a vApp .NN

Create/Add virtual machines to a vApp .NN

Edit vApp Properties .NN

Export vApps .NN

Clone a vApp .NN

In this chapter, we’ll explore four ways of working with virtual machines: creating a VM from scratch, converting a physical server, deploying from a template, or cloning an existing virtual

machine. The result of any of these methods is the creation of a new VM that can be used for a specific purpose.

Next, we’ll look at managing various aspects of the VM, such as understanding virtual disk sizing, applying a virtual disk format, and configuring resource settings for CPU and memory allocation.

Finally, we’ll introduce vApps and explain how to create and use them. Also, we’ll discuss the Open Virtual Machine Format (OVF) and how it is used when exchanging VMs between products and vendor platforms.

Creating and Deploying Virtual MachinesOnce you’ve put a vSphere infrastructure into place, the task of creating and deploying VMs to populate that infrastructure begins. But first, you need to develop a good under-standing of what a VM’s virtual hardware consists of and the maximum number of each device. Since VMs have virtual devices such as CPUs, memory, network interfaces, and SCSI devices, the ultimate make-up of a VM is driven by the needs of the application and the operating system.

This section covers 10 sub-objectives:

Understanding VM hardware maximumsNN

Creating a VMNN

Creating/converting templatesNN

Managing customization specificationsNN

Deploying a VM from a templateNN

Deploying a VM using VMware vCenter Converter EnterpriseNN

Deploying a VM using Guided ConsolidationNN

Cloning a VMNN

Importing a VM from a file or folderNN

250 Chapter 5 N Deploying and Managing Virtual Machines and vApps

Understanding VM Hardware MaximumsThe vSphere Maximums document is available on VMware’s website and is a highly recom-mended study aid. Go online and search for the term “vSphere maximums.” Table 5.1 lists a subset of these maximums.

TA B lE 5 .1 A Subset of vSphere Maximums

VM Hardware Maximum Configured Value

RAM The maximum amount of RAM that can be allocated to a VM is 255 GB .

CPUs The maximum number of CPUs in a VM is 8 .

SCSI adapters The maximum number of virtual SCSI controllers is 4 .

SCSI disks The maximum number of virtual SCSI disks per virtual SCSI controller is 15, for a maximum of 60 virtual disks per VM .

SCSI disk capacity The maximum SCSI disk size is generally reported as 2 TB; however, due to storage overhead, the true technical maximum is 2 TB minus 512 bytes .

IDE controllers The maximum number of IDE controllers is 1 .

IDE devices The maximum number of IDE devices (CD-ROMs or hard disks) per controller is 2 (master/slave), with a maximum of 4 per VM .

Floppy controllers There is a maximum of 1 floppy controller per VM, which can have a maximum of 2 floppy drives .

NICs The maximum number of virtual NICs per VM is 10 . Note: All virtual NICs are single port adapters . There is no differentiation between the various types of NIC emulation (for example, e1000 or VMXNET) . Network adapter emulation can be defined on a per-adapter basis .

Parallel ports The maximum number of parallel ports per VM is 3 .

Serial ports The maximum number of serial ports per VM is 4 .

Direct path devices The maximum number of direct path devices is 2 (per VM) . This includes any combination of NIC and or storage adapters . Note: In the initial release of vSphere, NIC support is limited to the Intel 82598 10 GB adapter as well as the Broadcom 57710 10 GB Ethernet adapter . Storage adapter support is Beta and is limited to the QLogic QLA25xx 8 GB Fibre Channel adapter and the LSI 3442e-R or 3801 3 GB SAS adapters .

Creating and Deploying Virtual Machines 251

Creating a Virtual MachineThe term hardware component is sometimes used to refer to the virtual hardware that VMkernel presents to the guest operating system. While creating a virtual machine, the components that make up the VM must be specified—from hard drives to NICs, we must select the components that will make up the VM.

As with all graphic interfaces, there are several ways to perform the same task. To create a new VM, you can press Ctrl+N, choose File New Virtual Machine, or right-click on your ESX host and select New Virtual Machine. The Create New Virtual Machine wizard opens. In Exercises 5.1 and 5.2, you’ll learn how to create a typical and a custom VM.


Creating a Typical New Virtual Machine

1. On the Configuration screen of the Create New Virtual Machine wizard, select Typical and click Next .

When creating a typical VM, the workflow is dramatically simplified because the wizard will configure most of the VM settings with defaults designed to optimize the performance of the selected operating system .

2. The next step in the wizard is to name the VM .



It is a best practice to avoid unusual characters, spaces, and punctuation when naming a VM because the name assigned here will exist in several places on the file system: all the files making up the VM as well as their parent folder will bear the name you provide at this screen . Although ESX/ESXi is efficient at dealing with Linux/Unix escape charac-ters, it is best to keep VM names simple to avoid future file system entanglements . Note that the name you assign your VM exists only in the vCenter inventory and is for your naming purposes . The name you select here has no relation to DNS unless you happen to choose a name for your VM that is consistent with its DNS name .

3. The next step is to designate a datastore for the VM . Bear in mind that VMware uses the term datastore to define any storage in which VMs reside . The following are considered datastores:

A local disk with a VMFS partitionNN

A SAN LUN with a VMFS partition (iSCSI or Fibre Channel)NN

An NFS exportNN

The vSphere Client will display a list of all the datastores available to this host so that one may be selected as the home of the new VM .

4. Once the datastore for the new VM has been selected, it is time to specify the oper-ating system that will be installed in the VM . This is an important step as many of the performance characteristics in the VMX file will be based on the OS specifica-tion . Once you choose the appropriate radio button under Guest Operating System (Microsoft Windows, Linux, Novell NetWare, Solaris, or Other), you must specify the version using the Version drop-down list .



5. The next screen prompts you to designate the VM hard drive . The default capacity is 8 GB, the minimum is 4 MB, and the maximum is 2 TB .

The options new to vSphere are thin provisioning and support for clustering features such as Fault Tolerance . These two features are mutually exclusive and the selection of either feature will directly affect how your VM is provisioned . If you select thin pro-visioning, disk space will be allocated on demand . To best explain this option, I’ll first describe the default behavior . Normally, if an 8 GB VM hard disk is selected, the -flat .vmdk file will be immediately provisioned and will be a full 8 GB in size . However, if the Thin Provision option is selected, the size of the -flat.vmdk file will increase as the amount of data written into this virtual hard disk (VMDK) increases, up to a maximum of the defined capacity of this VMDK . Thin provisioning will allow you to reduce wasted storage in a VM’s hard disk by not writing empty hard drive data . Historically, thin provi-sioning within the SAN infrastructure could not overcome the wasted and unused disk space in a provisioned but empty VM hard disk . That was because ESX allocated the entire VMDK file regardless of whether the guest OS wrote anything into the VHD .

When Support For Clustering Features is selected, thin provisioning is not possible; a “thick” disk is necessary .

6. The next screen summarizes the details of this new VM and allows you to commit and create it .

Creating a VM using custom settings allows for far more granular configurations. Exercise 5.2 walks you through creating a custom VM.

E X E R C I S E 5 . 2

Creating a VM Using Custom Settings

1. On the Configuration screen of the Create New Virtual Machine wizard, select Custom and click Next .

2. Name the VM, and then click Next .



3. Specify the datastore on which the VM’s files will be placed; click Next .

4. Specify the hardware version . This option is unique to the Custom installation . The option Virtual Machine Version: 4 refers to the VM hardware components from ESX 3 .x . If you have a mixed cluster with ESX 4 (vSphere) and ESX 3 .x servers, you must create machines with hardware version 4 . On the other hand, you must select Virtual Machine Version: 7 if you wish to take advantage of new vSphere features such as Fault Tolerance, hot-pluggable devices, thin provisioning, and direct path I/O .

5. On the next screen, select the OS you intend to install inside the new VM .

6. On the next screen, select the number of virtual CPUs or processors inside your VM . The number of processors is determined by licensing (virtual SMP = Symmetric MultiProcessing) as well as the total number of schedulable cores or hyperthreads in your ESX host . (This step is unique to the Custom installation .)

7. On the next screen, specify the amount of memory you wish to give your VM .



8. On the next screen, select the number of NICs in your VM, what networks they are attached to, and which type of network adapter they will have .

9. Select the type of SCSI controller . (This step is unique to the Custom installation .) The most common controller is LSI Logic Parallel; however, you may have reason to use the BusLogic Parallel controller . New in vSphere 4 are the LSI Logic SAS and VMware Paravirtual controllers .

10. Unlike in the typical installation, in which creating a new VM hard disk is assumed, when creating a custom VM, you have several options:

Create A New Virtual Disk This option is the same as using the wizard to create a VM .

Use An Existing Virtual Disk This option allows the mapping of a preexisting VMDK to the newly created VM .

Raw Device Mappings This option is used to attach directly to a SAN LUN, and allows that LUN to represent your VM’s hard disk .



Do Not Create Disk A VM can be created without a hard disk . This is useful in VMs that boot from and only use floppy (.flp) or CD/DVD (.iso) images .

11. Next, specify the size of the VM’s new hard disk, and specify whether it will be thin provisioned or capable of fault tolerance . Also specify whether the new VMDK will be placed with the VM (the default) or in another datastore . Click Next .

12. On the Advanced Options screen, you may choose to specify the SCSI address (within a SCSI chain) or the IDE address of your new hard disk . (vSphere 4 supports IDE hard drives in VMs .) By choosing Independent, you ensure that this new VMDK is unaffected by snapshots . You can then select Persistent or Nonpersistent . Nonper-sistent VMDKs will not retain any modifications to the drive once the VM is powered off . Effectively, a nonpersistent VM resides in a state of snapshot .

13. After clicking Next, review the details of the new VM and either click Finish to pro-ceed with the creation or go back to make changes .


Determining the Appropriate SCSI AdapterVMware VMs use SCSI hard drives. Which SCSI adapter you choose to use depends on what OS is being installed. When you’re creating a new VM, upon selecting the guest OS, the correct SCSI adapter is selected by default (as well as several other parameters required for the best possible operation of the selected OS). When installing a VM using Typical set-tings, either the LSI Logic or the BusLogic adapters will be selected.

In the physical world, these two storage adapters present more or less comparable per-formance and selections are made based on CPU impact and throughput under different conditions. In the virtual world, the selection is based simply on native support. Although manually installing drivers is possible, you should do so only if you desire the unique per-formance characteristics of a given driver in a particular situation.

When installing a VM using Custom settings, you have four controllers to choose from (see Figure 5.1):

BusLogic Parallel Natively supported by Windows 2000.

LSI Logic Parallel Natively supported by Windows 2003 and later.

LSI Logic SAS Serial attached storage (SAS) compatibility is introduced with vSphere 4; this controller is natively supported by Windows 2008.

VMware Paravirtual The PVSCSI controller is best suited to heavy I/O applications while having lower CPU impact on the guest. This controller is only compatible with Windows 2003, 2008, and RHEL 5.

F I GU R E 5 .1 Setting the SCSI controllers

Determining Virtual Disk TypevSphere 4 introduces the ability to thin-provision VM disks. In previous versions of ESX, when creating a new VM the -flat.vmdk file was monolithic and equal in size to the con-figured capacity of the new VM’s hard disk. However, thin provisioning allows for oversub-scription. While you can provision a large number of VM disks, the actual storage used will only reflect the amount of data present rather than the provisioned amount.


Table 5.2 illustrates how thin provisioning dramatically improves the effi ciency of storage utilization. However, this effi ciency does not come without a price: block-level fragmentation, which can signifi cantly impact performance.

TA B lE 5 . 2 Storage Consumption with Thick and Thin VMDK

Type of Virtual Disk Virtual Disk CapacityVolume of Data in the Virtual Disk

Space Used on ESX Datastore

Thick 100 GB 25 GB 100 GB

Thin 100 GB 25 GB 25 GB

The ability to specify the VMDK’s disk format is why there are a few new steps in the clone or deploy from template wizards—the type of disk on the newly created VM must be specifi ed.

As of this writing, fault-tolerant VMs cannot use thin-provisioned disks .

Figure 5.2 shows the Create A Disk screen of the Create New Virtual Machine wizard.

F I GU R E 5 . 2 Adding a virtual disk to a VM during creation

There are certain things to consider when it comes to virtual disk types:

Thin disks can be “inflated” to consume their full provisioned capacity.NN

Thin disks can be converted to thick disks via Storage VMotion, and thick disks can be NN

converted to thin disks via Storage VMotion.


The type of disk can be specified during the cloning of a VM or the deployment of a NN

VM from a template.

A VM with several disks can have a mix of thin and thick disks.NN

Installing, Upgrading, and Configuring VMware ToolsVMware Tools play a vital role with VMs; it is a best practice to always install VMware Tools, and they are supported in every OS supported in vSphere. Each of the following is installed in a VM when VMware Tools are installed, and each is essential in the VM’s proper functioning:

Device Drivers Virtual machine hardware is called hardware components, and just like with physical hardware, virtual hardware will work best with the correct device drivers. This is most clearly visible with the mouse performance once VMware Tools are installed and hardware acceleration is set. Additionally, VMware Tools can alter the behavior of the Power Off and Pause/Standby buttons when controlling a VM. Consider an ATX case: when the power button on a workstation is pressed, the OS will cleanly shut down rather than abruptly cut all power and potentially corrupt data. This too is an advantage of installing VMware Tools.

VM Monitoring In addition to monitoring ESX hosts, vSphere’s HA can monitor VMs for nonresponsiveness. Processes within VMware Tools allow the ESX host to monitor the VM and detect if the VM has become unresponsive or frozen. In this case, HA can reset the VM after a configurable nonresponsive duration, with a configurable minimum time between resets, and a configurable maximum number of resets over time or in total.

vmmemctl (Balloon Driver) One process installed with VMware tools is the VM Memory Control Driver (vmmemctl). This process operates in conjunction with and at the request of the VMkernel, by causing a VM to swap internally (for example, in Windows by populat-ing its pagefile.sys) in order to free up memory so that the ESX/ESXi host may reallo-cate it elsewhere.

The Ability to Pause a VM’s Disk Activity When the ESX/ESXi host attempts to make a snapshot, it must halt the VM’s disk activity for a fleeting moment while maintaining the integrity of the stored data. The same applies for the deletion or commitment or integration of snapshots into a VM’s VMDK files. This is made possible once again by the ESX/ESXi host interacting with the VM through VMware Tools.

Time Synchronization All VMs will lose time. This is a result of the guest seeing the actual CPU clock speeds of the ESX host, yet only receiving a percentage of total CPU time. As a result, one second in the VM will pass more slowly than in reality. The end result is the clock in a VM will fall behind. This happens with all VMs, without exception. Although time synchronization managed by VMware Tools is an option, the need for time synchronization is not. If the time synchronization feature in VMware tools is not used, you must set up an alternative—for example, using Active Directory to sync with a domain controller or using a Network Time Protocol (NTP) agent within the VM. It is often easiest to configure time


synchronization by checking the box in the Options tab of VMware Tools, which will allow the ESX/ESXi host to maintain the VM’s clock within +/– one second of the ESX host’s time. This is just one of the reasons why NTP time synchronization for the ESX host itself is critical. Figure 5.3 shows the check box for enabling time synchronization when adjusting the VMware Tools inside the VM.

F I GU R E 5 . 3 Setting Time Synchronization with VMware Tools

Installing the VMware Tools

In all VMs, you install VMware Tools by either right-clicking the VM in the vSphere Client inventory and selecting Install VMware Tools; or, from the VM menu at the top of the console, choose Guest from the drop-down menu, then the Install/Upgrade VMware Tools option. Either way, some administrative interaction is required.

In Windows, this action will mount the VMware Tools installation, which a typical Windows installation will Autorun. From this point, you can proceed with the installation, much like any other software.

In Linux, these actions will mount the VMware Tools installation as well; however, a Linux installation is less likely to automount the VMware Tools. You’ll probably have to mount the file system. You’ll then be presented with two options: you can install an RPM file or extract a TGZ tarball. If there is anything unusual or customized in the Linux installation, the savvy administrator may choose to extract the tarball in a temporary location where a Perl file can be executed to run the tools’ installation. This method is ideal for installing the enhanced network drivers. Whether or not enhanced network drivers are desired, it is advisable to do so from the console and not from a remote ses-sion into the VM—restarting the Linux VM’s network will sever a remote administration session. Additionally, should the Linux installation be nonstandard, VMware Tools will look for a GNU C Compiler (GCC) compiler and dev libraries in your user’s default path in an attempt to compile its drivers.


Upgrading the VMware Tools

The process to upgrade VMware Tools is necessary in several situations:

When ESX is upgraded, a VMware Tools upgrade is often necessary.NN

Altering the hardware version of a VM requires new VMware Tools as new hardware N

components are installed. This is encountered when moving from ESX 3.x to vSphere (ESX 4) because ESX 3.x uses hardware version 4 and vSphere uses hardware version 7.

When a VM is converted to operate on another virtualization platform (such as Fusion, NN

Workstation, or Server), an upgrade of VMware Tools is necessary because they will use alternate hardware versions as well.

The process to upgrade VMware Tools will simply consist of reinstalling them on top of an existing installation. In rare occasions you may choose to uninstall a previous version of the tools before installing the new version to ensure a clean installation. This is necessary, for example, when you’re using VMware Converter to convert a VMware VM with tools already installed into another VMware VM. As the old virtual hardware components are replaced, the old virtual hardware component drivers will have been removed; however, the other VMware Tools software will still be present. In this case, it is best to completely uninstall and then reinstall the VMware Tools for the target VMware platform.

VM FilesThe fi les that make up VMs, by default, are all put in the same folder, which resides in a datastore.

A datastore is defi ned as any storage mounted by your ESX host, visible either in the Datastore Browser or, from the Hosts And Clusters view, select the Confi guration tab, then Storage in the Hardware section. From the ESX server’s perspective, datastores are all mounted in the path /vmfs/volumes and are mounted as UUIDs. Each UUID will have a symbolic link (the Linux equivalent of a shortcut in Windows). The symbolic link will consist of a friendly name and point to the otherwise long and complex UUID. A datastore can be a mounted NFS share or a VMFS formatted on local storage, Fibre Channel, or iSCSI LUNs.

For more information about datastores, read Chapter 3, “Configuring ESX/ESXi Storage .”

Let’s say we add a new hard drive to an ESX host. We then boot the host, format the new volume with VMFS, and name the new datastore LocalDisk. Then, we create a new VM called Test01 and place it on this new datastore. vShpere automatically creates a folder called Test01 to contain the VM’s fi les.

The absolute path to the VM fi les in this case would be /vmfs/volumes/LocalDisk/Test01.

As with all Linux and Unix file systems, the ESX and ESXi file systems are case sensitive .


A VM’s fi les are contained by default in a single folder. Table 5.3 describes the VM fi le extensions.

TA B lE 5 . 3 VM File Extensions

Extension Description

.vmx VM configuration file

.vmdk VM disk meta file

-flat.vmdk VM disk file

.nvram VM BIOS state file

.vswp VMkernel swap file

.log Log files, which are automatically rotated

We will look at each of these in more detail the following sections.

The VM Configuration File

The VM confi guration (VMX) fi le is a text fi le, and is the most critical fi le for a VM. This fi le is so critical, in fact, that VMware offi cially says to never manually edit it.

If you decide to manually hack at the VMX file, always be sure to make a backup copy first . It’s much like wearing a seatbelt: you’ll probably never need it, but if you do you’ll be very happy you had it .

A quick search online will yield many how-tos with instructions on setting up nonstandard VMs for everything from unusual hardware configurations to unsupported OSs like BSD . They nearly all rely on manually modifying the VMX configuration file’s settings . This is because the VMX file is the DNA of your VM .

When you fi rst create a VM, you will need to specify what OS is being used. When you do so, the VMX fi le will be populated by many settings governing not only what virtual hardware is presented to and seen by the guest OS but also parameters needed to properly work with a particular OS, paths to other fi les that make up the VM, and paths to media mounted in the VM.

Although you can “inject” settings into the VMX fi le directly through the graphic vSphere Client interface, should you decide to manually edit the VMX fi le, it is best to do so only when the VM is completely shut down.


The VM Disk Meta File and Flat File

The VM disk (VMDK) files represent the VM hard disks and always come in pairs. The VMDK file contains metadata used by ESX/ESXi, describing the -flat.vmdk file that is the data file that represents the VM hard disk. In all versions of ESX, the -flat.vmdk files are monolithic. In versions of ESX prior to vSphere, VMDK files were provisioned in a “thick” format: if you created a 50 GB hard drive in your VM, your -flat.vmdk would be a 50 GB file. However, in vSphere 4 this file can be thin provisioned and its capacity can be dynami-cally increased. This allows storage to be used more efficiently by not wasting space with empty VM disk files. This topic will be discussed in greater detail later in this chapter in the section “Determining the Appropriate Disk Format.”

Every time you add a hard disk to your VM you will have a new pair (.vmdk and -flat.vmdk). The default location for these files is in the same folder as your VM; how-ever, you may choose to manually place a single VM hard disk on a separate datastore when creating it, or move it there later by using Storage vMotion.

The VM BIOS State File

This VM BIOS state (NVRAM) file binary file is created when the VM is created and repre-sents the BIOS of the VM. In addition to controlling the device boot order, you can manage several other components by pressing F2 during the VM post. You will notice how the amount of manageable features is far fewer than with a conventional physical machine.

The VMkernel Swap File

The VMkernel swap file (VSWP), or “vSwap” is a file that is used as memory when an ESX host does not have enough physical memory for all the VMs running on the host. Every VM has one, and it is created when your VM is powered on the first time. The VMkernel swap is what the ESX/ESXi host uses if it needs to swap the VM out of RAM. By default, this file is always equal in capacity to the amount of RAM configured for a VM. There is one exception to this rule: when a VM is given a memory reservation (which is a memory guarantee), the VSWP file will be reduced by the amount of that reservation. For example, if you give a VM 1024 MB of RAM and configure a reservation of 256 MB, the VSWP file will be 768 MB, because a VM reservation is a resource guarantee.

Managing VM Log Files

The log files are your audit trail and by default will grow to 5 MB in capacity before being rotated. Also by default, 10 generations of log files will be kept before being rotated out and deleted. The power cycling (not mere rebooting) of a VM will also incur the rotation of log files. The capacity of log files as well as the number of log files to keep in rotation can be configured by defining and configuring them in the VMX file by using log.rotateSize and log.keepOld, respectively. Alternatively, logging can be disabled by adjusting the logging option, or a specific logging file can be designated with the Log.filename option.


Creating and Converting TemplatesVM templates are an easy way to create a “rubber stamp” for the mass production of a VM. Templates can be created two ways: either convert a powered-off VM into a template, or clone a VM to a template. The advantage of converting a VM to a template is that the conversion is instantaneous; however, the VM will not be usable. Copying or cloning a VM to a template has the advantage of leaving the original VM intact, but it will require waiting for the entire capacity of the VM to be duplicated into the template’s files.

A template’s files are identical to a VM’s files in every way except one: the VMX file is renamed to VMTX and is identifiable in the vSphere Client by a unique icon of two sheets of paper with a folded corner.

Templates can also be created in a compact format, which just like thin-provisioned VM disks, eliminates the unused capacity in the -flat.vmdk files.

Templates are not recognized by a standalone ESX or ESXi server—they can only be managed through vCenter.

A template differs from a clone because new VMs are deployed from templates. In essence, a template can be a perfectly installed, configured, and patched VM designated to become the source for new VMs. Exercise 5.3 provides the steps for creating a template.

E X E R C I S E 5 . 3

Creating a Template

1. Log into the vCenter server with the vSphere Client and on the Home page, select VMs And Templates view from the Inventory section . Once the inventory is dis-played, choose a powered-off VM to be used as the template and right-click the VM . From the context menu, select Template Convert To Template .

2. Monitor the Tasks panel on the progress of the operation . Once the VM is converted, the icon in the inventory will change to a piece of paper with the lower-right corner upturned .



Customizing Windows and Linux VMsGuest OS customization will give you the ability to specify how the newly created VM will differ from the original (be it a clone or deployed from a template). Values such as network settings, hostname, product key, and administrator password are determined here. Obviously, certain details are specific to Windows.

Whether the new VM is created as a clone or by deploying from a template, you will have the following options (see Figure 5.4):

F I GU R E 5 . 4 Guest Customization screen

Do Not Customize This option is the default and will produce a carbon copy of the source.

Customize Using The Customization Wizard This option will launch several screens in which various aspects of the new VM can be customized. These customizations can be saved.

Customize Using An Existing Customization Specification This option will retrieve a saved customization and apply the configuration to the new VM.

There are some things to keep in mind. First, guest customizations are saved in the vCenter database and can be edited from a vCenter-connected vSphere Client by click-ing on View Management Customization Specifications Manager, or by pressing Ctrl+Shift+U (see Figure 5.5).


F I GU R E 5 .5 Customization Specifications Manager

The second and third options are not available (with Windows guests) unless Microsoft’s Sysprep files are saved on the vCenter server.

Microsoft’s Sysprep is a utility that allows the customization of Windows cloned system images. Sysprep adjusts the image so that there are no conflicts when creating new servers or desktops. Items that are adjusted include:

Generate A New SIDNN

New Product KeyNN

Domain MembershipNN

Administrator And User CredentialsNN

In the physical world, Sysprep would be installed on a physical machine and when run, the new values input by an administrator would then be injected in the Windows Registry and configuration files to modify the environment. In the VMware environ-ment, Sysprep is used by vCenter. Once the new VM is produced from its source, vCen-ter will boot the VM, inject the values from the customization specification by using Sysprep, and then reboot the VM. Every version of Windows requires a unique version of Sysprep to be downloaded, and the native Sysprep files must be inserted into the cor-rect folder in vCenter (except for Windows Server 2008 and Windows 7, where Sysprep is built into the OS).

Figure 5.6 shows the customization options; this dialog box will appear when you’re cloning a VM or deploying from a template. The second and third options will be grayed out if Sysprep is not present in the correct directory on vCenter.

There are some things to note regarding Sysprep:

The Application Data folder is not visible by default. Under View NN Folder Options, you must select Show Hidden And System Files.

Sysprep software belongs to Microsoft and therefore is not distributed by VMware. You NN

must download Sysprep for each version of Windows and manually install the files in the correct folder. vCenter will recognize what version of Windows is being managed and automatically look for the corresponding version of Sysprep in its directory. If it is avail-able, the options to customize are selectable; if Sysprep is not found, the customization options will be grayed out.

The tools for customizing Linux guests are open source and are built into vCenter.NN


F I GU R E 5 .6 Location in the vCenter Server’s file system where Sysprep files must be placed

Managing Customization SpecificationsEvery time a guest OS is customized during the clone or deploy from template process, the customization can be saved. All saved customizations are stored in the vCenter database, and they can be edited. When logged into vCenter, from the vSphere Client’s home screen, you’ll see in the Management panel an icon that lets you edit existing customization specifi-cations. Figure 5.7 shows the Home page and where to find the icon for the Customization Specifications Manager.

F I GU R E 5 .7 The Customization Specifications Manager icon


Deploying a VM from a TemplateOne of the quickest ways to create a new VM is to use a template. As discussed earlier, the creation of a template requires a VM with an OS already installed and any applications, patches, hotfixes, and Registry lockdowns already installed or applied. Once the newly created VM has been converted into a template, you can use the template as many times as needed to deploy new VMs with similar build requirements.

Exercise 5.4 provides the steps for creating a VM from a template.

E X E R C I S E 5 . 4

Deploying a VM from a Template

1. Log into the vCenter server with the vSphere Client and on the Home page, select the VMs And Templates view from the Inventory section . Once the inventory is dis-played, choose a template and right-click . From the context menu, choose Deploy Virtual Machine From This Template to begin the process .

2. On the Name And Location screen, provide a name for the VM . Also, from the Inven-tory view in the bottom panel, choose the folder to store the new VM . Click Next .



3. On the Host/Cluster screen, choose the appropriate host or cluster for the new VM to be hosted and registered . Click Next .

4. On the Resource Pool screen, choose the appropriate resource pool to organize the VM and provide CPU and memory resources . Click Next .



5. Next, on the Datastore screen, choose a datastore to store the VM’s files . Click Next .

6. The next screen, Disk Format, allows the user to choose the virtual disk storage format . You have the option of choosing the same format as the template, which can be stored in either Thick or Thin format . The other options allow the user to choose either Thick or Thin as the virtual disk storage format if the original format is unknown or needs to be changed . Once you choose one of the options, click Next .



7. The Guest Customization screen allows you to change several properties about the new VM so that it will not conflict with the original image or other VMs that have been deployed from the same template . For the purposes of this exercise, we will not choose to customize . Click Next .

8. On the Ready To Complete screen, look over the options . If anything is not correct, click the Back button as many times as necessary to correct the problem . Then use the Next button to return to the Ready To Complete screen . When you are satisfied that the VM will meet your needs, choose Power On This VM After Creation or Edit Virtual Hardware (to edit it before it is powered on the first time) . The last option allows you to add virtual hardware such as additional network interfaces or virtual disks to the VM to meet the needs of the application running in the VM . For the pur-poses of this exercise, choose neither . Click Finish .



9. Monitor the progress of the task in the Tasks panel . Once the task completes, the new VM will appear in the inventory .

Deploying a VM Using VMware vCenter Converter EnterpriseStarting with VirtualCenter 2.5, there was a noticeable evolution toward a single point of administration. The integration of Converter into vCenter gave us the ability to con-vert a physical machine into a VM remotely, through the vCenter interface. This was branded Enterprise Converter, and we had the ability to manage the conversion of VMs from within vCenter.

Enterprise Converter can be used to convert many different types of source images or physical servers. You can do the following tasks with Enterprise Converter:

Convert running physical machines into VMsNN

Import other VMware VMs from other products such as WorkstationNN

Convert third-party backup or disk images into VMsNN

Restore VMware Consolidated Backup (VCB) images to vCenter and managed NN

ESX/ESXi servers

Export VMs running on ESX/ESXi servers to other VMware product formats, such as NN

VMware Server

Reconfigure VMs being managed by vCenter, such as changing the virtual SCSI boot NN

controller to allow the VM to boot properly

Customize the VMs, such as changing network settingsNN

VMware vCenter Converter ComponentsWhen you’re using vCenter Converter, there are several components that need to be installed or used to convert a source machine or image. Some components are for hot


cloning of a running physical server, whereas other components are used in cold cloning a physical machine or image. The components are:

vCenter Converter Server Installed on the vCenter Server itself or on a separate server. This component is used when hot cloning a source machine or cold cloning a source image.

vCenter Converter CLI A command-line interface for scripting conversions. Can be installed on the vCenter Converter server or on a separate machine that can communicate with the vCenter Converter server.

vCenter Converter Agent Installed on a physical source machine to allow for remote or hot cloning of a “live” server.

vCenter Converter Client Installed on the machine running the vSphere Client as a plug-in.

vCenter Converter Boot CD Used for cold cloning a physical machine and does not involve the vCenter Converter server as the boot CD has the Converter environment.

Cloning ModesWhen using vCenter Converter, there are two cloning modes used to get a disk image: disk-based cloning and volume-based cloning. Disk-based cloning is used when cold cloning a physical machine and transfers all sectors of the source disk, including volume metadata, to get an exact image. This type of cloning preserves the volume type, either basic or dynamic volumes. Volume-based cloning can be used for hot and cold clones. The resulting virtual disk volume will become a basic volume regardless of the source volume type. Volume-based cloning is either a file- or block-level conversion, based on whether the new volume is smaller or larger than the source volume:

File Level If the new virtual disk will be smaller than the source volume

Block Level If the new virtual disk will be the same size or larger than the source volume

Performing a Hot CloneThis remote cloning of a machine is called a “hot clone” because the VM is produced in the background while the source machine is “hot”—which means it is on and performing its normal tasks. Hot cloning of a physical machine is possible for both Windows OSs (for Linux, vCenter Standalone Converter must be used) and has a few prerequisites:

Administrative privileges on the source machine (so the converter agent can NN

be installed).

Access to the source machine by vCenter on Windows networking ports.NN

Windows software mirroring must not be in place on the source machine.NN

Shadow-copy is leveraged to duplicate the source machine’s storage into the new VM.NN

Figure 5.8 shows the initial screen when you launch the Import Wizard.


F I GU R E 5 . 8 Import Wizard initial screen

Performing a Cold CloneLocal cloning of a machine is called a “cold clone” because the creation of a VM is the only task the server engages in. This option is for physical machines where hot cloning is not possible.

Cold cloning is also called “local cloning” because you must have physical access to the machine and must boot from a VMware converter CD. This cloning mode is managed from the console of the source machine and not from vCenter. Local cloning:

Is compatible with all guest OSs supported by vSphereNN

Requires a network route between the source machine and an ESX/ESXi vSphere hostNN

Requires administrative credentials on vCenter ServerNN

Requires a minimum of 264 MB of RAM on the source machine (preferably 364 MB NN

of RAM)

Loads into a RAM disk and copies storage blocks from the source hard drive into the NN

VM’s disk

Figure 5.9 shows a diagram of the cold clone process.

Performing System ReconfigurationOnce the source machine has been reproduced as a VM and the storage has been added to the VM, this final step involves the replacement of source machine hardware components and drivers with new VM hardware components.


F I GU R E 5 . 9 Cold cloning a physical server

Source Volumes

Network

Image inRAM Disk

vCenter ConverterBoot CD

Source MachineDestination

ESX/ESXi Host

Copy

This system reconfiguration step can also be followed by an optional customization phase where you can specify changes to the VM hardware, such as hard drive capacity, amount of RAM, and number of CPUs.

Deploying a VM Using Guided ConsolidationGuided Consolidation is an optional installation in vCenter, and is intended to facilitate the discovery and analysis of physical machines. Once performance metrics have been gathered, vCenter Converter will be engaged to produce VMs from the source machines.

Guided Consolidation operates in three phases:

The discovery of hostsNN

Analysis of physical hosts’ performanceNN

Consolidation and virtualization of selected hostsNN

Guided Consolidation requires at least one host being managed by vSphere, and you will need to provide logon credentials for the physical servers being analyzed. The Guided Consolidation server can be installed on the same vCenter server or on a separate server. Guided Consolidation works with Windows environments only.

Guided Consolidation ServicesThree services comprise Guided Consolidation:

vCenter Collector The service is responsible for discovering domains and the systems within the domain. It also collects performance data on those systems.

vCenter Provider This is a helper service responsible for communicating with the discovered systems; it passes data back to the vCenter Collector service.

vCenter Guided Consolidation This service saves the performance data and analyzes the data to provide recommendations for converting physical systems to VMs.


Performing DiscoveryThere are several ways to discover the physical systems to be analyzed and potentially convert:

Provide computer names or IPs for individual systemsNN

Provide a file with comma-separated lists of computer names or IPsNN

Provide Domain membershipNN

When providing an IP range, you cannot specify more than one IP subnet. In addition, you can only use one domain at a time. For large environments, there may be hundreds of systems discovered, but only 100 can be analyzed at one time.

Analysis of Newly Discovered Systems

Once a system has been added or discovered, it may take up to an hour for the status of the system to change on the Analysis tab . Remember, the length of time allotted for collection of performance data should be long enough for vCenter Guided Consolidation to provide a Confidence metric that is meaningful (a process that sometimes takes several days) .

Guided Consolidation will rescan for new or missed domains every 24 hours and will rescan for new or missed Windows machines every 30 minutes.

Analyzing Discovered Physical MachinesOnce candidates for virtualization are identified, Guided Consolidation will begin collecting Perfmon (Performance Monitor) metrics that span CPU, memory, disk, and network. Guided Consolidation uses its Data Collector to gather performance metrics from candidate source machines. These metrics will be harvested on an hourly basis from each machine. As the dura-tion of the analysis grows, Guided Consolidation will show a Confidence metric in the form of one through four stars.

The Analysis tab provides several performance-related columns and server descriptions to guide the user on the likelihood of converting the physical system. The columns used are:

Physical Computer The computer name

CPU Info The number of CPUs and clock speed

Memory Info The amount of RAM on the physical system

Status The progress of the analysis

Confidence A measure of how good a candidate the physical system is for conversion based on the data received

CPU Usage Average CPU usage of the physical system

Memory Usage Average memory usage of the physical system


The Confidence Metric

The Confidence metric is a function of the length of time data was collected . As many sys-tems vary in their peak usage from hour to hour or day to day, the Confidence metric can be misleading if the amount of data collected is for too short a time frame . The longer the col-lection period, the better the Confidence metric will be in providing guidance for a particular system . The best practice is to run the collection period for up to 30 days to allow for sys-tems that are busy at month end (or whenever they are busy during the month) .

Consolidating Selected Physical MachinesGuided Consolidation will determine if the current environment has the necessary capacity to run the designated machine once converted into a VM. The higher the Confidence Level, the better tuned to application needs Guided Consolidation’s recommended sizing of the VM will be. Once a satisfactory Confidence Level has been achieved, you can select the VM and initi-ate the conversion.

When you select the physical system’s name, a button called Consolidate is provided in the lower right corner that you can click to begin the conversion process using vCenter Enterprise Converter.

Cloning a VMCloning a VM is the creation of a carbon copy of a VM. The new VM will be identical to the original in every way except for the MAC address. ESX will automatically generate a new MAC address during the process.

Starting with ESX 3.5.3 and now in vSphere 4, vCenter can produce a “hot clone.” In other words, a running VM can be cloned provided there are no existing snapshots on that VM.

Cloning a VM is only possible in vCenter and is as simple as merely right-clicking on a VM in the vCenter inventory and providing a name and location for the new VM.

Prior to ESX 3.5.2, VMs needed to be powered off before they could be cloned; however, starting with ESX 3.5.2 and later (including vSphere), VMs can be cloned while they are run-ning. VMware will leverage snapshots to facilitate the cloning of a VM while it is powered on. It is worth noting that the system cannot create the snapshot that would facilitate this if the VM has existing snapshots.

Lastly, a clone is a carbon copy of the original. Therefore, when cloning a VM it is important to anticipate conflicts in every way except MAC addresses. vCenter will auto-matically generate new MAC addresses for the cloned VM; however, conflicts should be anticipated with hostnames, SIDs, as well as IP addresses if a static IP address is con-figured in the original VM (Guest Customization will provide a tool for resolving these conflicts).


Templating or Cloning: Which Should You Use?

Many new vSphere customers wonder about this question and which technique they should use when creating a new VM . The answer? Both! Either method creates a new VM that can be used for a new application or as an addition to an existing server farm . But why would a company choose one over the other?

Some companies like to create corporate standard server build images and expect new serv-ers to be built from these images . This cuts down on the number of inconsistencies between builds and ensures that security-related fixes and lockdowns are being applied . Using a template allows for this to happen seamlessly as the template begins life as a regular VM, and these security best practices are incorporated into the build process . The only challenge is keeping the template up-to-date with the latest security patches . Since a template cannot be powered on, it can be converted back to a regular VM and updated manually by someone who is responsible for their care, or it can be updated using vCenter Update Manager in a scheduled way .

The advantage to using templates is that they can be stored on inexpensive storage such as an NFS-based appliance as static files and updated only when necessary . They are not powered on and therefore you do not have to worry about file system corruption or open file issues . You can create as many templates as you need for variations in server builds or OS versions .

Other companies like to create servers that can be easily cloned whenever they need a new server . Some servers are part of large farms providing the same function or application . Cloning offers a way to create a copy of the original server with the customization needed to prevent conflicts with the original server . You can clone a running server or one that is powered off, but this will depend on the application running within the server and whether or not there are open files .

The advantages of using the cloning method are that you do not have to create servers that are static and not being used . Hot cloning is an option for many of these servers and does not waste space on the storage array or appliance . Since cloning a running server implies that the server is current with its security profile due to scheduled updates on regular intervals, the new server will have the same security profile . The downside to using cloning as an option is that some applications cannot be cloned while running due to file corruption or open file issues . These servers will have to be powered off briefly, cold-cloned, and then powered back on . In other instances, cloning is not applicable due to licensing requirements .

Managing VMs 279

So which technique should you choose? Use both, as each provides advantages . Use tem-plates for basic server builds that usually do not include applications . Update your templates with vCenter Update Manager to keep the images fresh and secure . Use cloning for those servers where you need an almost exact copy, including the application, with some addi-tional customization to prevent conflicts with the original . Using both methods ensures that you are provisioning a new server with the least amount of effort and ensures that the latest security patches, hotfixes, and lockdowns are already incorporated . And don’t forget, the VMware Tools will already be installed and will provide the best performance for your server and its application .

Importing a VM from a File or FolderUnless you’re importing an appliance by referencing an OVF file, you must upload a VM to a datastore. You can do this through the vSphere Client by browsing a datastore and clicking the appropriate icon to upload the VM’s files or an entire folder.

Once a VM’s files are located in a datastore, you can add a VM to inventory by right-clicking on the VMX file and selecting Add To Inventory (see Figure 5.10). After this, the VM can be powered on.

F I GU R E 5 .10 Adding a VM to the inventory

Managing VMsOnce created, VMs are easily manageable. In fact, they present many advantages over physical machines given how easy it is to manage and modify VMs.


Configuring and Modifying VMsIn general, modifying VM hardware follows the same rules as modifying physical machine hardware. Certain changes can be made while the machine is powered on, and for others the machine must be powered off. The basic rules are the same: CD-ROMs, floppy disks, and NS network connections can all be changed while both physical and VMs are powered on. Both must be powered off to change the amount of RAM or the number of CPUs, with a few exceptions.

Adding or Hot-Adding VM HardwareHard drives may be added to VMs while they are powered on. Once you perform hardware detection, a hard drive should be immediately available for partitioning, formatting, and use.

Windows 2003 (Enterprise and Datacenter editions) and 2008 (all editions) will allow the “hot addition” of RAM. In other words, RAM can be added to Windows 2003 and 2008 VMs without first having to shut them down. This feature requires hardware ver-sion 7 on vSphere.

Windows 2008 will allow the “hot addition” of CPUs, meaning CPUs can be added to a Windows 2008 server while it is powered on. Again, this feature requires hardware version 7 on vSphere.

Growing VM DisksIn vSphere 4, when using VMs with hardware version 7, you can edit the virtual disks of a VM while that VM is running and increase the drive capacity (see Figure 5.11). You can then use a partition-editing utility to enlarge an existing partition and take advantage of the full disk capacity.

VM hard disks cannot be shrunk this way; they can only be enlarged.

F I GU R E 5 .11 Growing a VM virtual disk

Determining the Appropriate Disk FormatA vSphere VM running hardware version 7 can have thick or thin disks. A thick disk will result in a -flat.vmdk residing in a datastore that is equal in size to the hard disk provisioned inside the VM. Previous versions of ESX could only create VM hard disks this way.

A thin disk is a thin-provisioned disk. When a new hard drive is added to a VM, it will see the full capacity of the new hard drive, as configured; however, the -flat.vmdk written

Managing VMs 281

by an ESX/ESXi host in the datastore will only be as big as the data contained on the new VM hard disk. A thin-provisioned disk in a VM will see its representative VMDK file grow as data is added to the VM’s hard disk. Thin-provisioned disks can grow but cannot be shrunk. Additionally, thin-provisioned disks are subject to fragmentation within the VMFS volume. Although there are no defragmentation tools, a datastore can be “cleaned up” by leveraging Storage VMotion and migrating the entire VMDK to another datastore. Doing this for all VMDKs on a datastore will effectively defragment the entire datastore.

You will be prompted to select a disk format when adding hard disks to a VM or when cloning or deploying a VM from a template.

Connecting VMs to DevicesBy editing the settings of a VM, you can manage all the connections of a VM. Some virtual device connections can be modified while a VM is powered on and others not. Parallel and serial port connections require a VM to be powered off; CD-ROM, floppy disk, and network connections can be made and modified while a VM is powered on.

Parallel and serial port connections will without exception anchor a VM to a given ESX host, and VMotion will not be possible.

CD-ROM and floppy disk connections can be made differently and therefore VMotion compatibility varies. When using the vSphere Client, the default setting for CD or floppy devices is to be connected to the physical workstation. In other words, inserting a CD into the workstation that is running the vSphere Client will connect the CD to the VM being managed. If this connection is in place, a VM cannot be VMotioned. Alternatively, if an ISO image can be accessed on a datastore mounted by the ESX host, the image can be mounted in the VM as if it were a CD. Provided this ISO image (and the datastore on which it resides) is accessible by all ESX hosts, the VM can be VMotioned. The same is true for FLP (floppy disk) images.

Virtual network adapters can be added or removed when a VM is on or off; their con-nections can be easily managed regardless of the VM’s state. Managing the connection of a virtual network adapter is the same as in the physical world—it can be connected or disconnected or moved from one port group to another at any time, whether the VM is on or off at the time.

Configuring VM OptionsWhen you’re editing a VM’s settings, most of your time is spent managing hardware and connections. However, it is often important to manage the behavior of a VM and this is done by right-clicking the VM, choosing Edit Settings, then selecting the Options tab.

General OptionsThis is the broadest category of VM options. This is one of several places where you can change the name of the VM. Doing so will modify the name of the VM as listed in the vCenter inventory and will have no bearing whatsoever on the guest OS’s hostname or configured DNS name.


Changing the Name of a VM

When you change the name of a VM while it is powered on, the names on the files that comprise the VM are not changed . This means that the new display name in the inven-tory of vCenter will be different than the names that are seen at the file system level . The easiest way to correct this issue is to use Storage VMotion to move the VM to another datastore . This process renames the files that are copied so that they match the display name of the VM .

Additionally, if the VM is powered off, the guest operating system can be modified. This refers to allowing ESX to know what guest OS is running inside the guest. A combination of this configuration and the resulting settings in the VM’s VMX file will attempt to optimize the operating environment for the guest OS. Figure 5.12 shows the General options.

F I GU R E 5 .12 General options for a VM

Advanced OptionsThe Advanced options (see Figure 5.13) comprise several different sections. Here’s a descrip-tion of each:

General This section allows you to control virtual hardware acceleration and logging.

If a VM is powered off, configuration parameters can be added (or modified) in the VM’s configuration file. VMware recommends doing so this way rather than actually editing the VMX file by hand.

CPUID Mask This section allows you to hide (or mask out) CPU instructions from the guest OS. This feature is initially useful when physical processors do not support BIOS-managed memory execution disabling (NX/XD). However, when using similar but not identical physical

Managing VMs 283

processors, specific CPU instructions can be “masked.” Although this feature is not available without the assistance of VMware support, it does lay the foundation for Enhanced VMotion Compatibility (EVC, a feature of Distributed Resource Scheduler), introduced in ESX 3.5.2. By masking out the CPU instructions that represent differences between similar processors, you soften the hard limitation of identical processors, and VMotion becomes possible between certain adjacent generations of CPUs provided a sufficient common baseline exists.

Boot Options This section allows you to specify an intentional delay when booting a given VM. A typical example of this feature’s use would be delaying the boot of an application server so that a database server has a chance to boot and spool up before the app server comes online.

The Force BIOS Setup option will configure a VM to go straight into the BIOS at the next reboot. This is convenient for when remote console windows don’t react quickly enough to pressing F2 to enter the BIOS during the VM boot process.

Paravirtualization Rather than scheduling the VM on physical hardware, a software-generated version of the physical hardware will be presented to the VM. In circumstances when the VM is paravirtualization capable, this can improve performance of the guest.

Fibre Channel NPIV When using raw disk mappings, virtual World Wide Names can be assigned.

Swapfile Location By default, a VM swap file is located in the same folder as the rest of the VM’s files; however, a swap file can be placed elsewhere, such as a host’s local file sys-tem. This is often done to avoid using expensive, high-performance storage for large and often unused swap files.

F I GU R E 5 .13 Advanced options

Power Management OptionsThese options allow you to determine how the VM will react when the guest OS goes into standby. There are two options:

Suspend the VMNN

Put the guest OS in standby mode and leave the VM powered onNN


Typically, we do not want the system to place itself into standby mode. The reason for this is that vCenter does not recognize the VM’s power state actually changing. You will need to ensure that the Wake On LAN For VM Traffic On Your VM Network check box is selected and that some other server can wake the VM when needed.

For many situations, a better alternative is to allow vCenter to put the VM in a suspended state in which it does have full control. This is especially true for virtualized desktops when using VMware View and creating desktop pools. This allows the suspended desktop to be resumed quickly when the user tries to connect to their virtual desktop. Figure 5.14 shows the Power Management Options screen.

F I GU R E 5 .14 Power Management Options

VMware Tools OptionsThe behavior of the stop, start, pause, and reset buttons can be modified if VMware Tools are installed in the VM. For example, rather than having a machine abruptly power down—as if the power plug was pulled from the wall—when the stop button is clicked, a VM can perform a graceful shutdown like when a real-world ATX power button is pressed. The execution of third-party scripts can be indicated, and time synchronization can be specified here as well.

The option to control time synchronization is useful when non-GUI OSs are used in the guest as this saves you from having to use more complicated command-line syntax. Finally, VMware Tools can be configured to check this version and even upgrade itself upon power-up. Figure 5.15 shows the VMware Tools Options screen.

Configuring VM Resource SettingsControlling a VM’s resource settings is similar to controlling resource pools, with a few important differences.

CPUOn the Resources tab for a VM’s properties, you have the ability to allocate host resources to the VM. You can adjust shares, reservations, and limits. The defaults are shown in Figure 5.16.

Managing VMs 285

F I GU R E 5 .15 VMware Tools Options

F I GU R E 5 .16 Default Resource settings for a VM

Shares are a method of designating priority. When there are not enough resources available, a VM with higher shares will receive more CPU time than a VM with lower shares. Therefore, the first important detail concerning shares is that they only come into effect when there is contention for resources; second, VMware recommends a shares ratio of 4:2:1 for High:Normal:Low shares. This translates directly to the following:

High VMs will have 2 times the CPU of Normal VMs. High VMs will have 4 times NN

the CPU of Low VMs.

Normal VMs will have half the CPU of High VMs. Normal VMs will have 2 times NN

the CPU of Low VMs.

Low VMs will have half the CPU of Normal VMs. Low VMs will have one quarter NN

the CPU of High VMs.


Reservations are a minimum guarantee. When a VM is powered on, the configured amount of CPU MHz will be allocated exclusively for the use of this VM. It may use less and it may use more. If more than the configured amount is used, the VM may have to compete with other VMs using its shares.

Limits are a maximum allowance. They can also be described as throttling the VM to never consume more than a preconfigured amount of megahertz.

MemorySimilar to how CPU time is allocated to a VM, memory has the same three mechanisms for allocating memory: shares, reservations, and limits.

Shares provide a 4:2:1 ratio and are a quick way to categorize which VMs should have a High, Normal, or Low priority when competing for memory. As memory is many times the first resource to be exhausted on an ESX/ESXi server, shares are used to ensure that a VM can compete effectively for what is available on the host. A big difference with memory is that the shares are based on the configured amount of memory for the VM. For example, if the VM is configured with 256 MB of memory, the Normal setting represents 10 shares for each megabyte of memory, or 2,560 shares. High would double that amount to 5,120 shares, or 20 shares for each megabyte. Low would be 5 shares for each megabyte, or 1,280 shares. You will need to watch both the configured amount of memory for a VM and the arbitrary shares setting to determine how effectively the VM will compete for memory.

Reservations are a guaranteed amount of memory in the ESX/ESXi server’s RAM. In other words, if a VM is configured with 1024 MB of memory and it is given a reservation of 768 MB, this guarantees that 768 MB of the VM’s memory must always be in ESX RAM and can never be swapped to file or ballooned to another VM. In this example, the VMkernel swap file will only be 256 MB because nothing more would ever be used due to the config-ured guarantee, or reservation.

Setting a limit on a VM for memory is not often used. Instead, merely reconfigure the VM with less RAM instead of forcing ESX to engage memory management techniques in order to restrict access to allocated memory. One example of using a limit is having to con-figure the VM with too much memory due to corporate standard considerations or expec-tations of the end user. By setting the limit to an amount the VM actually uses at peak intervals, which is less than the configured amount, you can more effectively deploy more VMs within your environment and use memory resources more efficiently.

DiskWhen a VM is powered off, disk shares can be managed. The arbitrary options are High, Normal, Low, or Custom. There is still a 4:2:1 ratio when using shares, but the number of shares are 2,000, 1,000, and 500, respectively. Disk shares are relative to other VM disks, and their shares located on the same ESX datastore.

Advanced CPUThere are two settings in this section. One allows the VM to be scheduled on a physical CPU using hyperthreaded cores, and the other allows the VM to be scheduled on specific CPUs or cores called affinity.

Deploying vApps 287

For newer server systems in use today, using hyperthreading can be advantageous as it allows the VMkernel more opportunities for scheduling a VM on a processor. With hyper-threading enabled in the ESX/ESXi host’s hardware BIOS, there are two scheduling opportu-nities for each core, potentially allowing two VMs to be scheduled on the same core. Use the Hyperthreaded Core Sharing section to select how core sharing can be managed. There are three settings:

Any Virtual CPUs of a VM can share physical CPU cores with other VM vCPUs or with vCPUs of the same VM.

None No core sharing is allowed, resulting in only one vCPU per physical CPU core.

Internal If a VM has two vCPUs to schedule, both can be on the same physical CPU core, but only when the VMkernel designates. The VM will not share a physical CPU core with other VMs. If the VM has more than two vCPUs, the setting is the same as None.

The other section is Scheduling Affinity, which lets you pin a VM’s vCPU(s) onto a single or selected number of physical CPU cores. By pinning a VM’s vCPU(s) onto the same core, the algorithms used by applications for fetching data can be more efficient and improve performance. The downside to setting this option is that it will break the VM’s ability to be moved with VMotion.

Deploying vAppsTo understand the role of vApps, we must first discuss appliances. With ESX 3.0 and VirtualCenter 2.0, VMware introduced the VM appliance; these are VMs exported into a portable format: all whitespace is removed from VMDKs and the overall footprint of the VM is much smaller than when actually installed. All these files can be packaged together in a zip file for easier downloading.

In vSphere 4, VMware has evolved to the next generation. Rather than packaging a single VM, now we can package several VMs. This can effectively package all the components of an application, hence the name: vApps. Imagine a database, app, and web server: three VMs packaged together as a vApp, with a single OVF descriptor file. In vApps, the OVF descriptor contains details used to validate the compatibility of the vApp with the virtual infrastructure, such as hardware requirements, deployment details, and runtime policies. vApps allow us to specify not only the names of the VMs, but also their resource settings, resource pool mem-berships, boot sequence, IP information, and much more.

Determining Whether a vApp Is Appropriate for a SituationAlthough the determination to use a vApp can be made based on the need for more than a single VM, vApps also allow the creator to designate and manage many more facets of the packaged VMs than is possible with a standard appliance. For example, say you decide that


your three-tiered application would be better suited if created as a vApp. A vApp allows for the powering on or off of the different tiers in the appropriate order and allows for resource allocation for the application as a whole.

In addition, there are two requirements for being able to create a vApp:

A ESX 3.0 host or laterNN

A DRS-enabled clusterNN

Defining Open VM Format (OVF)The Open VM Format (OVF) file format provides a VM file format that allows virtual appliances to be exchanged between different virtualization products or vendor platforms. The OVF file is a descriptor for an appliance or vApp, and it contains the name, identity, and configuration of the appliance or vApp.

Importing and Exporting a Virtual ApplianceVirtual appliances are VMs transformed into an easily importable, exportable, and download-able format. You may choose to create an appliance from a well-constructed and configured VM. Generally, appliances are provided by software vendors as an easy way to download their product, drop it into your environment, and immediately power it on without having to be concerned with configuring a VM, installing the OS, and setting up the software.

Appliances use OVF files as a core file type. The single OVF file references the entire VM appliance, and will specify the additional files to be loaded in order to completely populate the appliance.

OVF File

OVF files version 0 .9 must be used for backward compatibility with ESX/ESXi 3 .5 . OVF version 1 .0 is capable of describing an entire vApp and its component files .

vApps can only be recognized, and imported into or exported from vCenter. From the File menu, select the option to import or export; subsequent menus will prompt you to specify the appliance and relevant paths.

Building a vAppTo build a vApp, the first step is to create a vApp container. Begin by right-clicking on a folder or datacenter in the vCenter inventory; the option to create a vApp will be one of the options from the drop-down menu.

Deploying vApps 289

Once a name and location have been determined for the vApp, resource allocations must be specified. Similarly to a resource pool, an amount of available CPU and memory resources can be specified for a vApp. This information is used when importing a vApp to determine if the infrastructure can accommodate the vApp’s needs.

Creating and Adding VMs to a vAppVirtual machines can be added to the vApp by merely dragging them from elsewhere in the vCenter inventory and dropping them into the vApp. Otherwise, VMs can be created from scratch within the vApp.

The vApp can be customized by setting the characteristics of the vApp such as resource requirements, relationships between VMs within and outside of the vApp, network configu-ration information, and more. These customizations are recorded in the OVF descriptor. Although we are accustomed to seeing an OVF file for a single appliance, there is only one OVF descriptor file for an entire vApp, which may contain several VMs.

Editing vApp PropertiesThe entire vApp’s settings can be editing by right-clicking the parent vApp object. There are two tabs:

OptionsNN

Resources: CPU and Memory resources can be managed.NN

Properties: Title, version, and naming information can be entered here.NN

IP Allocation Policy: In addition to determining the IP information of the VMs NN

included in a vApp (fixed or dynamic), additional policies and scopes and IP protocol version compatibility can be defined.

Advanced settings allow additional details to be specified in Network and NN

General settings.

Start OrderNN

Much like the Boot Delay option with a standalone VM, the start order in a NN

vApp allows the creator or administrator to specify the order in which VMs in the vApp will boot as well as the delay before booting each individual machine. Shutdown options can also be specified.

In Exercise 5.5, we will show you how to build a vApp and edit its properties.

E X E R C I S E 5 . 5

Building a vApp and Editing Its Properties

1. To start, a vApp container must be created . To do this, right-click on the ESX host that will contain the vApp (or on the cluster inventory object if you have a cluster), and select vApp .



2. Using the New vApp wizard, define the name and resource allocations for your new vApp . You may only allocate CPU and memory resources .

3. The next step is to introduce VMs into the new vApp . This can be achieved either by manually creating new VMs or by dragging and dropping existing VMs into the vApp container . Note that vApps can be nested within vApps and there is no limit to the level of recursion; however, for organizational reasons, it is probably best to keep things as simple as possible .

Deploying vApps 291


4. The next step is the configuration and customization of the OVF descriptor . Right-click on the vApp and choose Edit Settings . There are two tabs: Start Order and Options .

Start Order Allows you to control the boot order of VMs in a vApp . You’ll find this useful when solving application and service dependencies when launching complex applications .

Options The settings on this tab allow you to configure network settings, resource allocations, and more . The vApp settings can be either static or dynamic depending on the environment in which the vApp will reside . Static settings control settings such as IP addresses or explicit resource allocations . Dynamic settings behave like macros that implement settings at runtime, such as relative resource allocations . On this tab, select IP Allocation Policy to open the following page:


This page controls the IP addresses allocated to VMs in vApps . VMs can receive their addresses in one of three ways: Static, DHCP, or Transient . The last option, Transient, will assign IP addresses to vApp machines from a preconfigured pool of IP addresses (controlled by a DHCP server) . Optionally, DNS information and HTTP proxy informa-tion can be specified .

Exporting vAppsExporting a vApp is as simple as selecting the vApp and choosing File Export. There are two choices: Web or Physical Media. If you select Web, a folder will be created containing all of the vApp files, including the OVF descriptor. The idea is that this entire folder would be published to a website and the entire vApp could be imported by supplying a link to the OVF descriptor file. The second option is to export the vApp to physical media. This will create an OVA (Open VM Archive) in TAR format. (The TAR format is a Unix/Linux file extension that stands for “Tape Archive.” A TAR file is very similar to the zip file in Windows—it is a binary file con-taining a directory structure and files; however, it does not use compression.)

Cloning a vAppThe process of cloning a vApp is similar to cloning a VM. Select the vApp object in the inventory and right-click. Choose the Clone option and follow the wizard. Figure 5.17 shows how to begin the process.

Summary 293

F I GU R E 5 .17 Cloning a vApp

SummaryThis chapter focused on managing VMs: although creating, deploying, and producing VMs is straightforward, it is important to understand their virtual hardware components and their limitations. Several methods for producing VMs exist: creating from scratch, cloning, deploy-ing from templates, and converting. Although each method is unique, the fundamental hard-ware components will govern the capabilities.

All VMs are made up of files, which typically all reside in the same folder. You can choose to put the swap (VSWP) file or individual virtual disk files (VMDK) on other datastores.

Guided Consolidation is a vCenter add-on that will help virtualize a small environment by enumerating physical (Windows) machines, analyzing their performance and engaging VMware Converter to produce VMs. Guided Consolidation uses a Confidence Level to indicate the reliability of performance analysis prior to conversion.

VM appliances are packaged VMs, condensed into a distributable format. They are installed using an OVF (open VM format) file, also called the OVF descriptor. VMs can be imported or exported using this format. vApps are appliances on a larger scale, where several VMs can be deployed at once, again with a single OVF descriptor. Unlike standalone appli-ances, vApps can be heavily customized in a variety of areas.


Exam Essentials

Know the files that make up a VM. Know the different files that make up VMs, their extensions, and the purpose of those files. Of particular importance are the VM configu-ration file and the VM disk files. In addition to being able to identify them, it is important to understand that VM disk files can be placed in other datastores, outside the original datastore containing the original VM folder and its files.

Know how to build a VM. For a simple VM, the Typical option will generally suffice; however, when finer control of a VM’s components is necessary, use the Custom option. It is important to know each step of the process—not for the sake of summarizing how to build a VM, but to understand the purpose behind each configuration option.

List the hardware components that make up a VM. In addition to knowing what hard-ware components can be included in a VM, it is important to know how many of each can be used. The vSphere Maximums document (available on VMware’s website) lists the maximum number of NICs, storage controllers, CPUs, IDE devices, serial ports, parallel ports, and maximum memory capacity in a VM.

Understand how vCenter Converter imports VMs. vCenter Converter will connect over the management network, routed to the VM network, and use Windows networking to connect to Windows machines. It will install an agent that will manage the creation and population of a VM from the physical or virtual source. It is important to know each step of the process.

Know the difference between vCenter Converter and VMware Converter. vCenter Converter is a module that installs independently of vCenter. Although it can be installed alongside or separate from vCenter, vCenter Converter must know where vCenter is and be able to communicate with it over the IP network. VMware converter is a bootable CD that will manage the conversion of a physical machine to a VM. This is the only option for con-verting a Linux machine to a VM.

Describe an appliance. Although simple in concept, there are a few important details sur-rounding appliances. The term compressed is often used, but there is no compression. When creating an appliance, unused storage in a VMDK (or whitespace) will be eliminated to reduce the overall size of an appliance. This is done to facilitate the transmission of an appliance over the network. Appliances consist of an OVF descriptor and “compact” VMDK files bundled in a single folder. Appliances can be exported by saving them from the vSphere Client. They can be imported by either referencing the OVF file on disk, from the vSphere Client, or via HTTP. In both cases, all component files for the appliance must be together with the OVF descriptor.

Define a vApp. Similar to an appliance, a vApp is a means for distributing prefabricated VMs; however, vApps allow for the distribution of multiple VMs simultaneously rather than individually.


Review Questions

1. Which of the following can be dynamically removed from a running VM?

A. CD-ROM devices

B. Floppy devices

C. Virtual NIC adapter connections

D. Virtual disks

E. Serial and parallel port connections

2. How often does Guided Consolidation check for new or missed domains?

A. Every 5 minutes

B. Once an hour

C. Once every 12 hours

D. Once every 24 hours

E. Once a week

F. Never

3. Which of the following Windows guest OSs do not require the installation of Sysprep files into vCenter?

A. Windows XP

B. Windows XP Pro

C. Windows Server 2000

D. Windows Server 2003

E. Windows Server 2008

F. Windows 7

4. Which of the following is not a part of a vApp OVF definition?

A. Application-specific configuration parameters

B. VM name and hardware

C. VM resource settings

D. Resource pool memberships

E. VM boot sequence

F. VM IP address information


5. Which of the following is the main configuration file for a VM named Test VM?

A. Test VM.config

B. Test VM.vmdk

C. Test VM.conf

D. Test VM.ini

E. Test VM.vmx

F. Test VM.log

6. Which of the following statements are true about a VM’s swap file?

A. The VSWP file always takes an amount of physical disk space equal to the VM’s RAM limit minus its reservation.

B. The VSWP file can be located on a local datastore for performance or space-saving reasons.

C. The location of the VSWP file is irrelevant to the proper functioning of VMotion.

D. The space consumed by the VSWP file is more than compensated for by use of thin provisioning.

7. You are deploying a VM from a Windows 2003 server template and want to have the new VM customized as part of the deployment process. Which of the following is necessary to allow for a customization of the new Windows server when deployed from this template?

A. You must install Sysprep files onto the ESX server where the VM is running.

B. You must install Sysprep files onto the VM.

C. You must install Sysprep files onto the vCenter server into the directory specified by Microsoft for Sysprep files.

D. You must install Sysprep files onto the vCenter server into the directory specified by VMware.

E. You must install VMware Tools into the VM before you convert it into a template.

8. What is the maximum number of direct path devices that can be added to a vSphere 4 VM?

A. 1

B. 2

C. 4

D. 8

E. 10

F. 16


9. Which of the following accurately describes the default number and size of VM log files?

A. 1 log file, 10 MB in size

B. 5 log files, each 5 MB in size

C. 10 log files, each 10 MB in size

D. 10 log files, each 5 MB in size

E. 20 log files, each 5 MB in size

10. For a VM that is in a DRS/HA cluster, which of the following VM resource settings are not dynamically updated?

A. CPU limit

B. RAM shares

C. CPU affinity

D. RAM reservation

E. Disk shares

11. Which of the following is not true about virtual appliances?

A. OVF v 0.9 can be used for backward compatibility with ESX 3.5.

B. Virtual appliances can only be imported into an ESX 3.5 or later server.

C. vApps require OVF 1.0 or later.

D. Virtual appliances store disks in a “thin” format (i.e., the unused space is not included in the appliance disks).

12. What is the maximum number of CPUs that can be allocated to a version 7 VM in vSphere 4?

A. 1

B. 2

C. 4

D. 8

E. 16

F. 32

13. Which of the following are not features of thin-provisioned virtual disks?

A. Disks are dynamically shrunk when possible.

B. Physical disk space is consumed as needed.

C. Thin provisioning is transparent to the VM.

D. Thin disks are dynamically defragmented as they grow.

E. Thin disks allow for physical disk overcommitment.


14. Assuming a Windows 2008 VM is at hardware version 7, which of the following cannot be done?

A. Hot-add CPUs

B. Hot-add RAM

C. Dynamically shrink a virtual disk

D. Dynamically grow a virtual disk

E. Convert a thin-provisioned disk to a thick-provisioned disk

15. You are trying to clone a VM and the clone operation is failing. Which of the following is a possible reason for the failure?

A. You cannot clone Linux VMs.

B. The VM has an open task in vCenter.

C. The VM is at version 4 hardware.

D. You have not installed the necessary Sysprep files onto the vCenter server.

E. You need administrator privileges on the VM being cloned.

16. Which of the following VM options require you select the Custom creation wizard (i.e., not the Typical creation wizard)?

A. Creating a Linux VM

B. Allocating over 64 MB of RAM to the VM

C. Using thin disk provisioning

D. Adding support for Fault Tolerance clustering to the VM at VM creation time

E. Specifying the VM’s hardware version

17. When creating a customization for use in deploying a VM from a vCenter template, you create a specific guest OS customization. Where is this customization stored?

A. In the VM

B. On the vCenter server’s local disk

C. In the vCenter database

D. On the ESX server hosting the VM

E. Within the VM’s template definition (VMTX) file

18. Which of the following benefits does not require installation of VMware Tools in a VM?

A. Virtual machine monitoring

B. Upgrading a VM to version 7

C. Use of the vmmemctl (balloon) memory driver

D. Keeping the VM’s clock synchronized

E. Pausing the VM’s disk activity when taking a snapshot


19. Which of the following statements about templates are not true?

A. With vSphere 4, you can now convert a running VM to a template.

B. Templates are not recognized by standalone ESX/ESXi servers as they are a vCenter feature.

C. A template’s virtual disks can be in “thick” or “thin” (compact) format.

D. A template can be recognized at the file level as its configuration filename ends in .vmtx (instead of .vmx as for a VM).

E. A template must have VMware Tools installed.

20. What is the size of a VM’s virtual swap (VSWP) file?

A. 1 GB

B. The RAM capacity of the VM as it was built

C. 10 GB

D. The VM’s memory reservation

E. The VM’s memory limit

F. The VM’s memory limit minus the VM’s memory reservation



1. C. Although vSphere has added support for hot-adding many new devices (RAM, CPU, disk), there is, in general, no support for hot removal of devices, with the notable exception of the connections used by virtual NICs.

2. D. Guided Consolidation checks for new domains every 24 hours and rescans for new or missing hosts every 30 minutes.

3. E, F. As Windows Server 2008 and Windows 7 come with the necessary Sysprep files installed, they do not require these Sysprep files to be installed onto the vCenter server, as was required by earlier Windows versions.

4. A. A vApp includes one or more VMs. Various VM parameters can be included in the vApp OVF definition, but parameters specific to the applications running within the VM are not part of the vApp definition.

5. E. The VMX file is the main configuration file for a VM containing the VM’s “parts list,” guest OS–specific configuration parameters, performance parameters, and so forth.

6. B. The VSWP file only takes up space when the VM is powered on. When powered off, the VSWP file is automatically deleted. Although thin provisioning saves disk space, it may not save disk space if the VM’s disks are 100 percent (or nearly 100 percent) full.

7. D. The Sysprep files you have downloaded from Microsoft’s website must be installed into a particular directory as specified by VMware. There is no requirement for VMware Tools to run Sysprep when deploying a new VM from a template.

8. B. This maximum of two direct path devices includes any combination of NIC and/or storage adapters.

9. D. By default each VM has up to 10 log files, each of which can grow up to 5 MB in size. This provides a reasonably limited amount of log history.

10. C, E. Changing disk shares requires the VM be powered off. All the other settings listed can be changed dynamically (i.e., while the VM is running) and take effect immediately if the VM is not in a DRS/HA cluster. For a VM in a DRS/HA cluster, CPU affinity cannot be set.

11. B. Virtual appliances, although they eventually wind up on an ESX server, are imported into and via vCenter.

12. D. vSphere 4 ups the maximum number of CPUs per VM to eight (the maximum for VMware Virtual Infrastructure 3 was four).

13. A, D. Thin provisioning supports dynamic growing of the underlying physical file on demand but not dynamic shrinking. In this case, Storage VMotion could be leveraged to effectively squeeze out unused space on a thin-provisioned virtual disk. VMware provides no fragmentation features in either thick- or thin-provisioned virtual disks.


14. C. Although there is now support for dynamically growing a virtual disk, there is still no support for dynamically shrinking a virtual disk on a running VM.

15. B. Cloning will not work with a VM that has an existing snapshot. In general, snapshots are best removed as soon as they are no longer required.

16. E. All the options except E are part of the Typical wizard. Specifying the VM hardware version (version 4 for backward compatibility with ESX 3.x, and version 7 for maximum compatibility with the new vSphere 4.0 feature set) is only done with the Custom wizard.

17. C. Guest OS template customization specifications are stored in the vCenter database and can be edited in vCenter via the vSphere Client.

18. B, D. VMware Tools provides additional and improved functionality in a VM. VMs can be installed or upgraded to virtual hardware version 7, however, even without VMware Tools. And although VMware Tools provide clock synchronization for the VM, you do not need VMware Tools to synchronize a VM’s clock—you can use an external time sync service like Active Directory or the NTP.

19. A, E. There is no support for (nor will the GUI interface even let you try to) convert a running VM to a template. You can convert a VM to a template without installing VMware Tools into the VM.

20. F. The VSWP file is set to the VM’s memory limit (which is by default set to the RAM capacity of the VM as it was built) minus the VM’s memory reservation.

Chapter

6Managing Compliance

VCP(VCP-410) EXAM OBjECTIVES COVERED IN ThIS ChAPTER:

Install, Configure, and Manage VMware vCenter NÛUpdate Manager.

Determine installation requirements and database sizing .NN

Install Update Manager Server and Client components .NN

Configure update manager settings .NN

Configure patch download options .NN

Create baselines .NN

Attach baselines to vCenter inventory objects .NN

Scan ESX hosts and virtual machines .NN

Remediate ESX hosts and virtual machines .NN

Stage ESX/ESXi Host updates .NN

Analyze compliance information from a scan .NN

Establish and Apply ESX Host Profiles.NÛ

Create/Delete Host Profiles .NN

Import/Export Host Profiles .NN

Edit Host Profile Policies .NN

Associate an ESX host with a host profile .NN

Check for Compliance .NN

Apply Host Profiles .NN

Analyze configuration compliance information from a scan .NN

This chapter explores the installation of VMware vCenter Update Manager (VUM) and shows you how to calculate data-base size. We’ll also discuss how to create and attach baselines

used for scanning VMs and hosts. Then, we’ll examine the reports generated after scanning against a baseline and show you how to interpret the data.

Next we’ll look at host profiles, which are used to adjust configuration settings en masse on a group of hosts. We’ll explain how to create, delete, and import a host profile. Finally, we’ll look at editing and applying a host profile.

Installing, Configuring, and Managing VMware vCenter Update ManagerThe VMware vCenter Update Manager (VUM) is a great tool for patching and updating ESX/ESXi servers and virtual machines along with many of their applications. This gives you a more centralized approach to patch management and change control that relates more effectively to the virtualized environment. Although many patch management systems are available, they do not effectively address the unique circumstances present when using virtual machines and the hosts they run on.

We cover eight subobjectives in this section:

Determining installation requirements and database sizingNN

Installing Update Manager Server and Client componentsNN

Configuring Update Manager settingsNN

Configuring patch download optionsNN

Creating baselinesNN

Attaching baselines to vCenter inventory objectsNN

Scanning ESX hosts and virtual machinesNN

Remediating ESX hosts and virtual machinesNN

Staging ESX/ESXi host updatesNN

Analyzing compliance information from a scanNN


Determining Installation Requirements and Database SizingThe installation of VUM requires careful attention to the hardware and database requirements. From a hardware standpoint, the requirements are similar to what you need to run vCenter. Depending on whether VUM is installed on the same server, the memory requirements will change. Table 6.1 shows the hardware requirements.

TA B lE 6 .1 Minimum Hardware Requirements

Hardware Requirements

Processor Two Intel or AMD processors or two cores, 2 GHz each .

Network 10/100/1000 NIC; Gigabit Ethernet is recommended .

Memory If VUM is by itself on the server, 2 GB of RAM .

If VUM and vCenter are on the same server, 4 GB of RAM .

VUM requires a database, and VMware recommends that you install the database on a separate server for inclusion with high-availability clusters and for proper backup of the database. You have three database options:

Microsoft SQL ServerNN

Microsoft SQL Server ExpressNN

OracleNN

Table 6.2 shows database products that can be used with VUM.

TA B lE 6 . 2 Database Formats and Versions

Product Driver

Oracle 10g Release 1 (10 .1 .0 .2)

Oracle 10g Release 2 (10 .2 .0 .3)

Oracle 11g Release 1 (11 .1 .0 .6 .0)

SQL Server 2005 SP1 SQL Native Client

SQL Server 2005 Express SQL Native Client

SQL Server 2008

306 Chapter 6 N Managing Compliance

Although using the Microsoft SQL Server 2005 Express database is supported, VMware only recommends it for use with small deployments of up to five hosts and 50 virtual machines. VMware provides a VUM sizing calculator (http://www.vmware.com/support/vsphere4/doc/vsp_4x_db_calculator_oracle.xls); just input the variables, and it will generate output that shows the following:

An initial size of the database tracking patch availabilityNN

Actual patch storage needsNN

Monthly estimates in growthNN

Figure 6.1 shows a sample output for a set of conditions.

F I GU R E 6 .1 The Update Manager Sizing Estimator

An interesting situation can arise when vCenter servers are being used in Linked Mode. When installing Update Manager, you must register that instance with a single instance of vCenter. Therefore, if you had three vCenter servers running in Linked Mode, you would need three separate instances of VUM because you won’t have an opportunity to register one VUM instance with multiple vCenter instances.

Installing Update Manager Server and Client ComponentsVUM installation requires that an instance of vCenter already exists. During the installa-tion, you will be asked to register the VUM instance with a vCenter Server instance. You will also need to gather other pieces of information about your environment before you begin the installation:

vCenter networking informationNN

IP addressNN

http://www.vmware.com/support/vsphere4/doc/vsp_4x_db_calculator_oracle.xls

http://www.vmware.com/support/vsphere4/doc/vsp_4x_db_calculator_oracle.xls


Username and password being used by the vCenter serviceNN

Ports being used (usually the defaults of 80 and 443)NN

Administrative credentialsNN

Username and password for the local installation that has local administrator rightsNN

ODBC DSN name; username and password to the databaseNN

If Windows Firewall is being used on the local system, the installer will open the neces-sary ports to allow proper communication between VUM, vCenter, and ESX/ESXi hosts. If external fi rewalls are being used, you will need to manually open the ports to allow com-munication between the various elements.

The installer will also check to see how much local storage is available. A minimum of 20 GB of storage is needed for the patches. This amount of storage is only what you need to get started—the patch repository may grow signifi cantly over time, depending on the num-ber of operating systems you’re managing and the baselines you’re creating.

In Exercise 6.1, we’ll practice installing VUM.

For Exercise 6 .1, you will need to create a database (and an ODBC connec-tion if you will be installing VUM on a different server) . In the exercise, you will install VUM using a separate database .


Installing VUM

1. On the Windows machine, insert the CD to launch the vCenter Installer . From the list of components, choose vCenter Update Manager .



2. On the next screen, choose the appropriate language and click OK . Once the Welcome page appears, click Next . Accept the EULA and click Next .

3. At this point, we’ll need to supply the credentials for the vCenter server . This screen populates the IP Address / Name and HTTP Port fields, so enter the username and password and then click Next .

4. On the Select Database screen, assuming that you created a separate database and set up the ODBC connection, choose Use An Existing Supported Database . From the Data Source Name (DSN) drop-down list, choose the ODBC DSN name that you cre-ated and click Next .



If you wanted to install a local SQL Server 2005 Express database, you’d choose Install A Microsoft SQL Server 2005 Express Instance .

5. On the next screen, provide the database credentials and click Next . (Of course, you do this only if you are using a separate database .)



6. On the VMware vCenter Update Manager Port Settings screen, be sure to choose the VUM name or IP address . Also confirm the ports, and if you have proxy settings, click the option that lets you configure your proxy settings . Click Next .

7. Next, choose the installation path and a download repository path for patches . Many times they are both local, but the patches location could be a separate drive with more space .



8. A dialog box may appear warning you that the size you specifi ed for the patches repos-itory is insuffi cient . VMware won’t stop the installation if your free space is less than 20 GB, but you should have at least that amount for a proper installation . Click OK .

9. The last screen gives you an opportunity to go back and change any settings that you may have incorrectly typed or chosen . Sadly, it’s not a summary screen displaying your selections . Click Install .

The next element to install is the client plug-in. Installing the VUM server portion is only half the setup process. Although the VUM service will be running, the only way to take advantage of its functionality is to install the vSphere Client plug-in, which we’ll do in Exercise 6.2.

Before you can proceed with Exercise 6 .2, you must be sure that VUM has been previously installed .


E X E R C I S E 6 . 2

Installing the Client Plug-in

1. On the Windows machine where the vSphere Client is installed, log into vCenter with the client . Once the client is presented, choose Plug-ins Manage Plug-ins .

2. Find the VMware vCenter Update Manager Extension in the Available Plug-ins section; in the Status column click Download And Install link .

3. Choose a language and click OK .



4. On the next screen, click Next to begin the installation . Accept the EULA and click Next . On the next screen, an informational message appears describing where the vSphere Client is installed and where the VUM client will be installed . Click Install to begin the installation .

5. The last step is to click Finish and then click Close in the Plug-in Manager . You will be prompted to accept the security certificate once again . You have the option to install the certificate by selecting the check box, or you can click the Ignore button (even if you select the check box, you will have to click the Ignore button), so choose one . Once the plug-in is installed, verifying the functionality is a simple process: on the Home page, in the newly created Solutions And Applications section, click the Update Manager icon .


Configuring Update Manager SettingsNow that both the server and client components have been installed, you can configure VUM for network connectivity (see “Configuring Patch Download Options” later in this chapter). You can also specify whether you want to take snapshots before remediating virtual machines and how you want VUM to respond to ESX hosts that will not go into Maintenance mode for remediation. In most cases, these “global” settings are used each time, but when using the wizards for VM and host remediation, you can change the settings for a particular situation on the fly.

VUM can be configured to take a snapshot of a virtual machine before it installs a patch or does an upgrade. This protects the VM from changes that may inadvertently break its functionality or disable it in some way. The ability to roll back changes quickly and efficiently is one of the great features of VUM, and it works by using the virtual machine snapshot technology.

You have two basic settings when choosing to take a snapshot of the VM before remediation:

Keep Snapshots IndefinitelyNN

Keep Snapshots For A Fixed Period Of TimeNN

With either method, you need to take the following into consideration:

If snapshots are kept indefinitely, the amount of disk space consumed could impact the NN

VM’s performance since more than one file is being used for the virtual disk and both the snapshot and the virtual disk will be competing for I/O.

If no snapshots are kept, this saves disk space and may speed up the remediation process, NN

but there would be no rollback option.

If snapshots are kept for a fixed time, this uses less disk space as the snapshots are NN

committed, usually in a short timeframe.

Exercise 6.3 provides the steps for choosing the snapshot policy when using VUM to update a VM.

E X E R C I S E 6 . 3

VUM Snapshot Policy Configuration

1. Log into the vCenter Server with the vSphere Client and select Update Manager in the Solutions And Applications panel .

2. Click the Configuration tab . Under Settings, choose Virtual Machine Settings .

3. If you want to take snapshots, select the “Snapshot the virtual machines before remediation to enable rollback” check box .



4. Choose whether to keep snapshots indefinitely or for a fixed period of time . If you choose a fixed period of time, you will need to decide how much time is warranted . There are two schools of thought:

Keep the amount of time short so that the likelihood of something other than NN

a patch landing in the snapshot is reduced and, therefore, a rollback will only remove the patch (typically because the patch was qualified earlier and the odds of having a rollback are small) .

Keep the amount of time longer to allow you time to qualify the patch and ensure NN

the virtual machine has not been harmed (typically because the patch was not qualified earlier and the odds of having a rollback are higher) .

5. Click Apply once you select the desired settings . These settings will now become the default behavior any time you need remediation for a virtual machine . You can override the settings when using the remediation wizard .

The other setting that may need attention is how VUM will respond to a host not going into Maintenance mode while preparing for an ESX host remediation. Two situations can arise that would prevent a host from entering Maintenance mode:

The host is not in a cluster and you have not manually moved the VMs to other hosts.NN

The host is in a cluster and vCenter, using VMotion, cannot move all the VMs to other NN

hosts within the cluster.

In either case, VUM will be unable to proceed with the remediation. VUM can respond to the situation in several ways:

Fail and alert the administratorNN

Retry as many times as defined by the administratorNN

Power off VMs and retryNN

Suspend the VMs and retryNN

Exercise 6.4 provides the steps for configuring the “Retry” policy when updating an ESX server with VUM.

E X E R C I S E 6 . 4

VUM ESX Server Retry Policy Configuration

1. Log into the vCenter server with the vSphere Client and select Update Manager in the Solutions And Applications panel .

2. Click the Configuration tab . Under Settings, choose ESX Host Settings .



3. From the Failure Response drop-down list, choose one of the following options:

Fail Task: Log the failure and do not proceed .NN

Retry: Wait a defined amount of time and retry, putting the host into Maintenance NN

mode a specified number of times .

Power Off Virtual Machines And Retry: Power off all VMs and retry, putting the NN

host into Maintenance mode a specified number of times . (VMs are not shut down gracefully)

Suspend Virtual Machines And Retry: Suspend all running VMs and retry, putting NN

the host into Maintenance mode a specified number of times .

4. If necessary, select the delay time and the number of retries .

5. Click Apply . These settings will now become the default behavior any time you need remediation for a virtual machine . You can override the settings when using the remediation wizard .

Configuring Patch Download OptionsOnce VUM has been installed and the vSphere Client plug-in has been installed, setting up VUM to download the necessary patch availability data and the patches is next. VUM will automatically contact https://www.vmware.com and https://xml.shavlik.com on ports 80 and 443 to find out about patches and to download the patch definitions. This will not rep-resent the patches themselves. Other ports used by VUM to communicate are as follows:

VUM to vCenter uses port 80.NN

ESX/ESXi servers connect to the VUM web server on port HTTP 9084 for host NN

downloads.

VUM connects to the ESX/ESXi hosts on port 902 for pushing patches and upgrade NN

files.

The VUM Client plug-in connects to the VUM SOAP server on port 8084 and connects NN

to the VUM web server on HTTP port 9087.

VMware recommends that during the installation of VUM you use the IP address of the VUM server. Although the name of the VUM server can be used, all ESX/ESXi servers will need to be able to resolve the VUM server by DNS as a part of the update and upgrade process for each host. VUM is also IPv6 compatible when scanning and remediating ESX/ESXi servers. IPv6 is not supported when scanning and remediating VMs.

Once the networking has been squared away, the next step is to choose a source to use to download the actual patches. VUM can use a connection to the Internet or a patch repository. By default, VUM will try to connect to the Internet to download patches, and you can add additional URLs to allow for third-party patches for ESX/ESXi servers.

https://www.vmware.com

https://xml.shavlik.com


The alternative is to use a shared patch repository. This technique requires the use of the Update Manager Download Service (which can be installed separately), and the patches can then be imported by the VUM server from a shared folder. The Update Manager Download Service (UMDS) is usually installed in the DMZ, and its sole function is to download patch content from external sources. The VUM server itself then imports the content from an accessible location, such as a shared folder or external USB or FireWire drive.

Exercise 6.5 shows the steps for setting up the patch download source.

E X E R C I S E 6 . 5

Setting Up Patch Download Sources

1. Log into the vSphere Client and navigate to Home Solutions And Applications Update Manager .

2. Click the Configuration tab; then under Settings, click the Patch Download Settings link .



3. In the Direct Connection To Internet section, check those boxes for the content that will need to be downloaded from VMware and/or Shavlik . If there are no ESX/ESXi 3 .x servers, deselect Download ESX 3 .x Patches . If you’ll be using a shared folder, select the Use A Shared Repository radio button and provide the path or URL to the shared repository . To add another source for third-party patches or updates, click the Add Patch Source link .

4. In the Add Patch Source dialog box, enter the URL you want to use and a brief description . Click Validate URL to check for accessibility . Then click OK .

5. Click Download Now to begin the VUM download process and watch this task in the Tasks section at the bottom of the vSphere Client .


At this point, we have looked at how to download patches directly to the VUM server by way of the Internet or a shared repository. But where do the patches come from when using a shared repository? They are downloaded using the UMDS. As we mentioned earlier, this service is a stand-alone product that allows high-security envi-ronments to download the same patches used with VUM but to a proxy server in the DMZ. This separation allows content to be collected and scanned before it enters the internal network.

The UMDS requires a database, so you must configure one in the same way that you would for VUM. If using Microsoft SQL 2005 Express, you install the database when you install UMDS. As for the space required for storing the patches, VMware recommends at least 50 GB for each year you patch ESX/ESXi servers and an additional 11 GB of space for each operating system. Additional space may be required for applications or for locale distinctions.

To install UMDS, be sure to uninstall any previous versions first. If patches need to be imported first, use the vmware-updateDownloadCli.exe utility to facilitate the import. However, this tool is not supported in UMDS 4.0.

Exercise 6.6 will show the steps in setting up the Update Manager Download Service.

E X E R C I S E 6 . 6

Installing the Update Manager Download Service

1. On the Windows server that will host UMDS, insert the vSphere CD and browse to the umds folder .



2. Find the VMware-UMDS.exe file and run the program . Select the language for the installation and click OK . Click Next at the Welcome screen; then accept the EULA and click Next .

3. On the Select Database screen, choose Install A Microsoft SQL Server 2005 Express Instance .

4. On the next screen, enter the UMDS proxy settings, if any, and click Next .



5. On the Destination Folder screen, if the default paths selected for the installation and the download of the patches are correct, click Next .

6. On the next screen, click Install to begin the installation .


Once UMDS is installed, you need to set up what will be downloaded to the patch repository. This is done through typed commands because there is no graphical interface for this task. Once you’ve selected the updates for download, run the appropriate command to start the downloads. This command can be run as a scheduled task in Windows.

Exercise 6.7 shows the commands that need to be executed to select and then download the patches on the UMDS server.

E X E R C I S E 6 . 7

Specifying Patches and Updates; Then Exporting and Importing

1. Log into the Windows server where UMDS is installed . Open a command prompt session and change to the umds directory . The default location is c:\Program Files\VMware\Infrastructure\Update Manager .

2. Next, type the command that best specifies the patches that are required .

To download only ESX host patches, type this:

C:> vmware-umds --set-config --enable-host 1 --enable-win 0 --enable-lin 0

To download only Windows patches, type this:


To download only Linux patches, type this:


To download all updates, type this:


3. Once you’ve specified the updates you want to download, execute the following com-mand to begin the download process:

C:> vmware-umds --download

4. If patches need to be downloaded again, you can specify the start and end times to select the patches that should be downloaded:

C:> vmware-umds --re-download --start-time 2009-01-01T00:00:00

--end-time 2009-01-31T23:59:59

5. Depending on security policies, you can export the patches to a web server for shared access or to a portable media device . To export the patches, run the following command:

C:> vmware-umds -E --export-store export_directory_path

6. To import the patches, use the Shared Repository setting in Update Manager instead of using the Internet by specifying the removable media device or specifying the URL of the web server where the patches are stored .


Now that VUM has access to the patch availability data and can download patches for the ESX/ESXi hosts, Windows, and Linux VMs, we can move on to creating baselines.

Create BaselinesBaselines are the key to successfully updating or upgrading your ESX/ESXi hosts, Windows, and Linux VMs and virtual appliances (VAs). Baselines contain one or several patches, secu-rity fixes, updates, and service packs or can even update the VMware tools in a VM or VA. Baseline groups are a collection of baselines or may contain a single upgrade baseline type. When ESX/ESXi hosts or VMs/VAs are scanned, a report is created that provides information on the compliance of those entities in relation to the baseline. If a patch is missing in a VM, the report will show noncompliance.

If you are responsible for keeping a vSphere infrastructure up to date, you must have baseline permissions to manage the creation and modification of the baselines and baseline groups. Permissions are delegated as a part of the access control included with vSphere and must be at the vCenter level and with a registered Update Manager.

There are four default dynamic baselines and four upgrade baselines that cannot be edited or deleted. Additional baselines or groups can be created that are tailored to a specific group of VMs, templates, Vas, or ESX/ESXi servers. As shown in Figure 6.2, the default baselines are as follows:

Critical VM Patches Checks Windows and Linux VMs for all critical or import patchesNN

Non-Critical VM Patches Checks Windows and Linux VMs for all optional patchesNN

Critical Host Patches Checks the ESX/ESXi hosts for all critical patchesNN

Non-Critical Host Patches Checks the ESX/ESXi hosts for all optional patchesNN

VMware Tools Upgrade To Match Host Checks VMs for the installation of the latest NN

Tools version for ESX/ESXi 4.0 hosts

VM Hardware Upgrade To Match Host Checks the VMs for the latest hardware NN

version (7.0) on ESX/ESXi 4.0 hosts

VA Upgrade To Latest Checks the virtual appliance to see if it is the latest appliance NN

version

VA Upgrade To Latest Critical Checks the virtual appliance to see if it is the latest NN

critical appliance version

F I GU R E 6 . 2 The various default baselines used with VMware VUM for hosts


To create a new patch or upgrade baseline, use the New Baseline wizard in VUM. Baselines are created as one of two types: Host or VM. The next choice to make is whether a baseline will be dynamic or fixed. Dynamic baselines are broad in their definition—All Critical Updates, for example. Fixed baselines are defined by you, the administrator, and can contain one or more patches. Baselines created on one VUM server and paired with a vCenter server are only available to that VUM/vCenter pair. Therefore, vCenters in Linked Mode will not be able to share baselines between them.

The steps for creating a dynamic baseline are similar, and you also have the ability to subtract or add patches with dynamic baselines. Fixed baselines are completely customized and will normally need to be edited from time to time to keep them from becoming stale. In Exercise 6.8, the process for creating a fixed baseline is explained.

E X E R C I S E 6 . 8

Creating a Fixed Baseline

1. Log into the vCenter server with the vSphere Client; in the Solutions And Applica-tions section of the Home page, choose Update Manager .

2. Click the Baselines And Groups tab, and in the top-right corner, click the Create link .

3. In the Baseline Name And Type screen of the New Baseline Wizard, type a name and description for the baseline . Then, in the Baseline Type box, choose what type of baseline to create; for this exercise, choose VM Patch . Click Next .



4. On the next screen, you can choose either Fixed or Dynamic baseline . For this exer-cise, choose Fixed . Click Next .

5. Next, on the Patches screen, click the Filter button to open the Filter Patches dialog box . Here you have the opportunity to “filter” out patches that are not relevant to your search . By entering specific text, you can search for a text string . In the Product list box, choose from hundreds of products, both applications and operating systems . In the Severity list box, choose the criticality of the patch . In the Released Date section, pro-vide a date range; your options are On Or After or On Or Before . If you use the Released Date section, there is a good chance you will need to edit your baseline from time to time to keep it fresh . For this exercise, we chose Internet Information Services 7 .0 for Windows Server 2003 as the product, and for the Released Date, we selected the On Or After check box and chose the date of September 1, 2009 . We left all other options at their defaults .



6. Back on the Patches screen, in the top section, select the updates that you want included in the baseline . Then click the down arrow to move them into the Included Patches section . Any items that show up in the bottom section will be a part of your baseline . Click Next .

7. The final screen allows you to double-check your work . If anything looks incorrect, click the Back button to edit your baseline . Otherwise, click Finish .



Fixed Baseline Maintenance

Company “B” wants to consolidate its patch management objectives into a single prod-uct within its vSphere infrastructure . It sees the use of VUM as a way to create a fixed baseline and apply the baseline to an object, such as a VM, which can be easily done with the vCenter Update Manager interface . The company realizes that it will need to assign someone the responsibility and ownership of updating the baselines on a timely basis . As many baselines are time sensitive, they become stale and are no longer valid . Similar to virtual machine templates becoming stale when not powered on periodically, baselines have the same update requirements .

Since there is no automated process for updating a baseline with patches or updates that have been recently released, Company “B” will need an administrator to edit the existing baselines so that they include the newest patches and the possible removal of older patches or updates . How often this needs to be done will depend on the variety of fixed baselines used, the number of operating systems and applications being scanned, and the frequency of released patches by a given vendor .

A good rule of thumb for Company “B” is to update the fixed baselines every two weeks for most virtual machine operating systems and every month for fixed baselines for applications .

Many customers will have several OS versions and applications that will need patching. How many fixed or dynamic baselines will be needed depends on many factors. They key is to manage what is created and update the ones that can become stale or delete any that have become obsolete.


Attaching Baselines to vCenter Inventory ObjectsOnce the baselines have been created, the way to activate them is to attach them to specific objects in your vCenter inventory. Since you have two basic kinds of baselines, ESX hosts or VMs/VAs, you will usually choose a folder, cluster, or individual ESX/ESXi hosts or VMs/VAs as a way to attach the baseline. If the object, such as a folder, has child objects, the baseline is attached to each of the child objects as well. In this way, you can create just a few attached baselines in similar fashion when assigning permissions to folders. These per-missions are in turn applied to all subfolders or files.

In Exercise 6.9, we’ll attach a baseline to an object.

E X E R C I S E 6 . 9

Attaching a Baseline to an Object

1. Log into the vCenter server with the vSphere Client and select an object in the Inventory view, either in Hosts And Clusters view or VMs And Templates view . Click the Update Manager tab for that object .

2. In the top-right corner, click the Attach link . This will bring up the Attach Baseline Or Group dialog box . Choose your baseline type: Patch or Upgrade . You can select one or more baselines for the object if necessary . Select a baseline and click Attach .



3. You will now see the baseline in the Attached Baselines section of the Update Man-ager tab . In the far-right corner, you will see the compliance summary . In this case, compliance is Unknown since the objects have not been scanned against the base-line . In the bottom of the Update Manager tab, you will see which objects will be included with the baseline for scanning or remediation .

Scanning ESX Hosts and Virtual MachinesAfter the baselines have been attached, you have the option to scan the object immediately or schedule the scan for later. Scanning the ESX hosts or VMs/VAs against the baseline will provide you with information about compliance, such as whether or not the object has been patched or whether the object has been upgraded. In Figure 6.3, this VM is noncompliant because it does not contain the patch that the baseline provides.

F I GU R E 6 . 3 VM compliance information


Since the number of VMs can be great, scheduling the scans for a night run is often done. When you return to work, the compliance reports are waiting for you. In Exercise 6.10, we’ll schedule a scan of an object in the inventory.

E X E R C I S E 6 .10

Scanning an Object in the Inventory

1. Log into the vCenter server with the vSphere Client and click Scheduled Tasks in the Management section of the Home page .

2. Click the New icon in the top-left corner . A dialog box will appear that allows you to choose the task you wish to schedule . In this case, choose Scan For Updates; then click OK .

3. On the Scheduled Task Type screen, under Scan Type, select Virtual Machines And Virtual Appliances or ESX/ESXi Hosts . Click Next to continue .



4. On the Select Entity screen, open the hierarchy and choose the object that you wish to scan . This can be a folder, cluster, host, or VM . Click Next .



5. On the Update Types screen, choose to scan for patches, VM hardware upgrades, VA upgrades, or VMware Tools upgrades if the object was a VM/VA or a folder con-taining VMs/VAs . If the object was a cluster or an individual ESX/ESXi host, you can choose from Patches or Upgrades . Once you’ve selected an item, click Next .

6. On the Schedule Task screen, give the task a name and a brief description, and spec-ify what time or how often to run the task . Click Next .



7. On the Notification screen, you can choose “Send email to the following addresses when the task is complete” to have vCenter email you once the task has completed . After you provide the email address, click Next .

8. On the Summary screen, double-check your work and then click Finish if all is well .


When scanning or remediating a host, VUM uses port 80 or, if there is a conflict, opens ports in the 9000–9100 range to communicate with the ESX/ESXi server. When a VM is scanned, an agent will be installed (if it has not already been installed). Many times, the outcome of a scan is finding that either your hosts or your VMs/VAs are noncompliant. This leads to remediating the objects to bring them into compliance. The next section will show you the process.

Remediate ESX Hosts and Virtual MachinesRemediation of ESX hosts brings them into compliance with either patch or upgrade base-lines. The process for patching and upgrading ESX servers with a baseline group requires that the upgrade be installed first, then the patches within the baseline group. ESX host baselines that contain more than one patch are handled in one of three ways:

If the installation of one patch depends on the installation of another patch, VUM NN

detects this dependency and installs the patches together in the proper sequence.

If a patch conflicts with another patch, the conflicting patch may not get installed or NN

staged. If one patch conflicts with another patch but a third patch resolves that con-flict, VUM recognizes the sequencing and installs the patches in the correct sequence to resolve the conflict.

If there are several versions of a patch, VUM installs the latest version and will not NN

install earlier versions.

For ESX 3.5x servers, patch remediation consists of cumulative rollups and updates. A rollup could contain more than one patch, in which case the ESX host is noncompliant until all patches contained in a rollup are installed.

For ESX 4.x servers, patches are now included in files known as vSphere installation bundles (VIBs). These installation bundles can contain a single patch or several and are published as vSphere bulletins. If the installation of one bundle requires the installation of prerequisite bundles, even though the baseline may contain only one bundle, the prerequi-site bundles will be staged and installed in addition to the bundle defined in the baseline.

In the case of an ESX host upgrade (3.5 to 4.0), VUM runs a script to verify that the upgrade can be installed, and if so, VUM pushes the upgrade to the ESX server in the for-mat of an ISO file. The ESX server, in Maintenance mode, will reboot and run the installer. This creates a service console virtual disk, esxconsole.vmdk, and installs the packages into the new esxconsole.vmdk virtual disk. If anything fails during the upgrade process, the server can be rolled back to its original state.

For ESXi hosts, the updates are included in the boot image. ESXi servers store two copies of the ESXi image: one for active booting and one as a standby image. VUM cre-ates a new boot image by merging the standby image with the patch or patches. This becomes the new active boot image. Once the ESXi server is rebooted, it boots from the newly patched image, and the old “active” image becomes the new standby image.


When upgrading ESXi servers, the standby image is replaced with the new ESXi version. This then becomes the new active boot and standby boot images. Rollback is achieved by reverting back to the previous boot build as each ESXi server stores two build copies: the boot build and the standby build, which represent the previous ESXi build.

If the ESX hosts are a part of a cluster, only one host is remediated at a time. If the remediation of one host in a cluster fails, the process halts and will not continue. This can leave a cluster in a mixed state, where some hosts have been remediated and others have not.

Exercise 6.11 shows the steps used to remediate a host with a patch baseline.

Before you can proceed with Exercise 6 .11, you will need to attach a patch baseline to the host or an object that contains hosts .

E X E R C I S E 6 .11

Remediating a host with a Patch Baseline

1. Log into the vCenter server with the vSphere Client and click the Hosts And Clusters icon in the Inventory section . Right-click any ESX server in the inventory list and choose Remediate .



2. Choose the baseline you wish to update the ESX host with from the Baselines section and click Next .

3. On the Patches screen, select or deselect any patches from the list you require . Click Next . If you deselected any patches, you are given another opportunity to go back and select them . Otherwise, click Next .

4. On the Host Remediation Options screen, provide a task name and a brief descrip-tion . Then under Remediation Time, select the Immediately or At Time radio button . If you choose At Time, select a date and time from the drop-down list . Under Failure Options, choose Retry from the Failure Response drop-down list, and specify 30 min-utes for the retry delay and 3 for the number of retries . Click Next .



5. On the Ready To Complete screen, double-check your selections and then click Finish .


Virtual machine or virtual appliance remediation requires that a baseline or baseline group be attached to a folder or individual VM or VA. Both VMs and VAs can be updated within the same container object, such as a folder, datacenter, or vApp. If both VMs and VAs are in the same container, only virtual machine baselines will be applied to VMs and only virtual appliance baselines will be applied to VAs.

In Exercise 6.12, you will remediate a VM with a patch baseline.

Before you can proceed, you will need to attach a patch baseline to a vir-tual machine or an object that contains VMs .

E X E R C I S E 6 .12

Remediating a VM with a Patch Baseline

1. Log into the vCenter server with the vSphere Client and click the VM And Templates icon in the Inventory section . Right-click any VM in the inventory list and choose Remediate .

2. Next, choose the baseline you wish to update the VM with from the Baselines section and click Next .



3. On the Patches screen, select the patches you wish to install and click Next .



4. On the Schedule screen, type a task name and a brief description . Then specify whether you want to remediate a powered-on, powered-off, or suspended VM, and either choose Immediately or choose At Time and schedule the remediation for a later time .

5. Next, on the Rollback Options screen, choose whether you want to take a snapshot before the remediation, automatically delete the snapshot at a specified time or man-ually, and whether the snapshot should include the memory state of the VM . Once you’ve entered the snapshot name and a brief description, click Next .



6. On the Ready To Complete screen, double-check your selections and then click Fin-ish . Monitor the progress of the patch installation for any errors .

Staging ESX/ESXi Host Updates

The staging of patches for ESX/ESXi hosts can speed up the remediation task because NN

the patches are stored locally on the hosts. You can stage patches while the ESX/ESXi hosts are fulfilling normal activities, thus reducing downtime. The process is only sup-ported with ESX/ESXi 4.0 hosts.

In Exercise 6.13, you’ll learn how to stage patches for remediation.NN

E X E R C I S E 6 .13

Staging Patches on ESX Server

1. Log into the vCenter server with the vSphere Client and click Hosts And Clusters in the Inventory section . Right-click a host and select Stage Patches from the context menu .

2. Select the baseline that contains the patches to be staged and select the ESX hosts that should download the patches . Click Next .

3. If any patches should be excluded, deselect them now . Otherwise, click Next .

4. Verify that patches that have been selected are correct and then click Finish . Monitor the progress of downloads for errors in the Task pane at the bottom of the vSphere Client .


Analyzing Compliance Information from a ScanWhen VUM scans inventory objects for compliance, it creates a report detailing which objects are compliant and which are not. Compliance information can be viewed for a single object or for a group of objects, such as VMs within a folder or ESX hosts within a cluster.

Baselines are used to find if a single object or a group of objects are compliant. Here are the ways baselines interact with inventory objects:

A user must have at least read-only permissions on an object to view compliance data.NN

Compliance data is refreshed each time a user views the compliance of an object.NN

An object must have a baseline attached to view compliance data.NN

The compliance data is specific to the virtual machine OS and the baselines that apply NN

to that OS.

The compliance data for a host with a fixed baseline that contains obsolete and new NN

patches will only show compliance information for the old patches, but the remediation process will install the new patches.

Exercise 6.14 describes the steps to view compliance information for an inventory object.

E X E R C I S E 6 .14

Viewing Baseline Compliance Data

1. Log into the vCenter server with the vSphere Client and select Host And Clusters or VMs And Templates in the Inventory section .

2. Select an object from the inventory such as a cluster, folder, host, VM, template, or virtual appliance .

3. Click the Update Manager tab and view the compliance information for the object .

Reviewing the information listed on the Update Manager tab will provide you with a wealth of information. Some of these items include:

When was the last scan performedNN

Total number of compliant, noncompliant, or unknown objects as they relate to NN

the baseline

Total number of compliant and noncompliant patches or upgradesNN

Total number of patches for each baseline that need to be applied to a particular VM NN

or host

Exercise 6.15 shows the steps used to review compliance of inventory objects with attached baselines.

Establishing and Applying ESX Host Profiles 343

E X E R C I S E 6 .15

Viewing Compliance Data for Inventory Objects

1. Log into the vCenter server with the vSphere Client and click Hosts And Clusters or VMs And Templates in the Inventory section . Select a cluster, host, folder, virtual machine, or virtual appliance and click the Update Manager tab .

2. Select the baseline or baseline group or select All Groups And Independent Baselines .

3. In the Compliance pane, select a status that is appropriate for your object (All Applicable, Non-compliant, Incompatible, Unknown, or Compliant) .

4. In the Virtual Machines And Virtual Appliances Or Hosts pane at the bottom of the Update Manager tab, review the status of those objects .

5. Click the link for compliant, noncompliant, or unknown state in the Patches column, and a Patch Details dialog box appears providing additional information on the state of patches .

On many of the Update Manager screens, you can review additional information. Depending on the object selected—whether it’s a baseline, baseline group, or upgrade—output will be seen that is specific to the state and type of patch or upgrade. With vSphere, even old or obsolete patches contained within a baseline are either ignored or shown only until a newer patch supersedes it. The level of detail is elegant and provides you with information you need when making decisions about server compliance.

Establishing and Applying ESX Host ProfilesThe ability to use host profiles to maintain consistent configuration of multiple ESX/ESXi servers is a welcome new addition to the vSphere feature set. The ability to use them, how-ever, is limited to customers who purchase the Enterprise Plus license, as many of the poli-cies that can be configured require distributed switches, also only available with Enterprise Plus license. Even with the licensing restrictions, host profiles may become one of the best features released for vSphere.

Similar to how VUM scans for compliance of ESX/ESXi hosts and VMs/VAs against baselines or baseline groups, ESX servers can be checked against a host profile for any dis-crepancies in its configuration as it is compared against a reference host’s configuration.

This section covers seven subobjectives:

Create/delete host profilesNN

Import/export host profilesNN


Edit host profile policiesNN

Associate an ESX host with a host profileNN

Check for complianceNN

Apply host profilesNN

Analyze configuration compliance information from a scanNN

Creating/ Deleting Host ProfilesCreation of a host profile (see Figure 6.4) starts with a reference host. A reference host has its configuration for the following elements already configured and will be duplicated on each subsequent host built:

Memory Reservation ConfigurationNN

Storage ConfigurationNN

Networking ConfigurationNN

Date and Time ConfigurationNN

Firewall ConfigurationNN

Security ConfigurationNN

Service ConfigurationNN

Advanced Configuration OptionNN

User ConfigurationNN

User Group ConfigurationNN

The easiest way to administer host profiles is to click the Host Profile icon in the Management section of the Home page. On the resulting page you can create, edit, attach, or delete profiles. Host profiles can only be applied to ESX/ESXi 4.0 hosts. You cannot apply them to older versions of ESX hosts.

Exercise 6.16 steps through the process of creating or deleting a host profile.

F I GU R E 6 . 4 Elements of a host profile


E X E R C I S E 6 .16

Creating or Deleting a host Profile

1. Log into the vCenter server with the vSphere Client and click the Host Profiles icon in the Management section of the Home page . On the Host Profiles screen, click the Create Profile icon in the top-left corner to launch the Create Profile Wizard . You will be given a choice: Create Profile From Existing Host or Import Profile . Choose Create Profile From Existing Host and click Next .

2. On the Specify Reference Host screen, browse to the host you want to use as the ref-erence host . This host will have all the settings and configuration that will be used on all hosts to which the profile will be applied . Click Next .



3. On the Profile Details screen, give the profile a name and brief description . Click Next .

4. On the Ready To Complete The Profile screen, check your work and then click Finish .



5. To delete a profile, right-click it and choose Delete Profile .

6. You are given a last chance to keep the profile . Click Yes to confirm .

Importing/Exporting Host ProfilesImporting or exporting a host profile is a straightforward process. Importing a profile could save you time. In real-world scenarios, using one profile as a template is possible but probably only in environments that have several clusters and the configuration of the hosts in all clusters is similar. Even if you import a profile being used on a different cluster, you can edit the profile to provide specific settings for the new cluster. Using the Host Profiles administration screen, you begin by clicking the Create Profile button. A host profile can also be exported; save it as a VMware Profile Format (VPF) file.

Exercise 6.17 steps through the process of importing or exporting a host profile.

E X E R C I S E 6 .17

Importing or Exporting a host Profile

1. Log into the vCenter server with the vSphere Client and click the Host Profiles icon in the Management section of the Home page . On the Host Profiles screen, click the Create Profile icon in the top-left corner to launch the Create Profile Wizard . You will be given a choice: Create Profile From Existing Host or Import Profile . Choose Import Profile .

2. On the Import Profile screen, browse to the folder that contains the profile and select it for import .

3. The next screen gives you the opportunity to name the profile and give it a brief description . Once you do, click Next .



4. On the Ready To Complete The Profile screen, double-check your selection and click Finish .

5. To export a profile, choose the profile from the list, right-click the profile name, and choose Export Profile .

6. The Save As dialog box appears; name your profile and save it in VPF format .

Editing Host Profile PoliciesThere will be times when an existing host profile needs editing due to a configuration change that must be applied to all the hosts in a group or cluster. The most common change is any type of distributed switch setting or network setting in general that provides the virtual machines with network connectivity. Each host profile is made of subprofiles that have an impact on a specific group of settings.

Table 6.3 shows the subprofiles that are possible to edit.

TA B lE 6 . 3 Subprofiles and Settings

Subprofile Example Settings

Memory reservation configuration Service console memory reservation

Storage configuration NFS storage configuration

Networking configuration vSwitch

Virtual machine port group

Host port group

Service console port group

DNS configuration

IP route configuration

Service Console IP route configuration

Physical NIC configuration

vNetwork Distributed Switch

Service console virtual NIC (vNetwork Distributed

Host virtual NIC)


Subprofile Example Settings

Date and time configuration Time settings

Time zone

Firewall configuration Default blocking policy

Ruleset configuration

Security configuration

Service configuration Ntpd

Sshd

vmware-vpxa

vmware-webAccess

Advanced configuration option

User configuration

User group configuration

Given that environments change over time, you will undoubtedly have to edit an existing host profi le. Exercise 6.18 shows you the steps.

For Exercise 6 .18, you will have to create a host profile before you can edit it .

E X E R C I S E 6 .18

Editing a host Profile

1. Log into the vCenter server with the vSphere Client and click the Host Profi les icon in the Management section of the Home page . Choose the host profi le you wish to edit and right-click the profi le; then choose Edit Profi le .

TA B lE 6 . 3 Subprofiles and Settings (continued)



2. Expand the host profile and choose the subprofile you wish to edit . In some cases, the policies will also need to be expanded so you can edit specific settings . Click a setting . On the Configuration Details tab, you can select a setting or drop-down box to adjust the configuration to be used by all the hosts . In some cases, a particular pol-icy will need to be enabled for a compliance check . For those, click the Compliance Details tab and verify that the option has a check box for enabling compliance . If you need to disable the policy, deselect the check box . When you are finished creating or providing settings, click OK .

Once you’ve edited the host profile, you can apply it to a host or a group of hosts. In the next section, we’ll look at how this is done.

Associating an ESX Host with a Host ProfileOnce you’ve created a host profile, attaching it to a container or an individual ESX/ESXi host is the next step (see Figure 6.5). After the profile has been attached—a process that is similar to how you attach a baseline or baseline group in VUM—you can check for compli-ance of the hosts against the profile. There are four ways to attach a profile:

From the Host Profiles view, click the Attach Profile button in the top-left corner.NN

Right-click the host and choose Host Profile from the context menu.NN

Right-click the cluster object and choose Host Profile from the context menu.NN

Select the cluster’s Profile Compliance tab in the informational panel.NN


In Exercise 6.19, you’ll attach a host profi le using the cluster’s Profi le Compliance tab.

F I GU R E 6 .5 Attaching the host profile using the host’s context menu

You must create a cluster and add at least one host to it before attempting Exercise 6 .19 .

E X E R C I S E 6 .19

Attaching a host Profile

1. Log into the vCenter server with the vSphere Client and click Hosts And Clusters in the Inventory section . Click a cluster object, and then click the Profi le Compliance tab in the informational panel . At the top of the screen, there will be a Click Here link for attaching a profi le to the cluster . Click this link .

2. A dialog box appears, giving you the opportunity to choose a profi le to attach . Click one of the profi les and then click OK .

Checking for ComplianceNow that the profi le has been attached, checking for compliance is as simple as clicking the Check Compliance Now link. Figure 6.6 shows the Profi le Compliance tab on the cluster object and the link in the top-right corner.

If you are checking for compliance for an individual host, right-click the host and choose Host Profi le and then click Check Compliance. Once the scan has been performed, the hosts listed in the cluster will be shown as either compliant (with a green check mark) or noncompliant (with a red X). Figure 6.7 shows an ESX server that is noncompliant.


F I GU R E 6 .6 Profile Compliance tab

F I GU R E 6 .7 Compliance information for a single host

Applying Host ProfilesApplying the host profile to a host is also straightforward. One step to remember is to put the host in Maintenance mode. You can select the Profile Compliance tab on a cluster and click the Apply Profile link in the top-right corner, or you can right-click the host, navigate


to the Host Profile menu option, and then choose Apply Profile from the sub-menu. Once the profile has been applied, if there were no errors, the Host Profile Compliance column should show a green check mark. Figure 6.8 shows the Profile Compliance tab and where to find the link for applying a profile.

F I GU R E 6 . 8 Applying a host profile on the Profile Compliance tab

Analyzing Configuration Compliance Information from a ScanIn many environments, the cluster will be the object used to attach the host profile. In these situations, hosts may be in differing states of compliance. Nothing is stopping you from making manual changes to a host’s configuration. Periodically scanning a cluster against the same profile is a good idea in case the hosts have changed over time due to manual changes.

The reverse of this may be true as well. There will be times when a new change needs to be incorporated into the profile and then applied to the cluster. We covered editing the existing profile earlier. Once those changes have been added to the profile, applying those changes is necessary to bring the hosts back into compliance or to a newer configuration state. When you’re applying the profile, a dialog box will appear showing which configura-tion changes were applied (see Figure 6.9).

F I GU R E 6 . 9 Applying a profile to a cluster


During the process of applying a profile, if there are any settings that have to be made manually, the dialog box shown in Figure 6.10 appears and lets you make those settings.

F I GU R E 6 .10 Inputting manual settings for a profile

If a host is noncompliant, it is helpful to see what settings are not currently in sync. In Figure 6.11, you can see these discrepancies in the Host Compliance Failures section at the bottom of the Profile Compliance tab.

F I GU R E 6 .11 The discrepancies after scanning a host against a profile

When analyzing host compliance, remember that some configuration changes will need to be added manually when the profile is being applied due to hosts having different IP addresses for ports or settings that are host specific. Also, since configuration changes may occur independently, using profiles to maintain a consistent setup periodically may be necessary.

Exam Essentials 355

SummaryIn this chapter, we have discussed and practiced using two features of vSphere: vCenter Update Manager and host profiles. VUM is a patch and upgrade management tool. Host profiles help manage ESX/ESXi host configurations. Using both will simplify host and VM updates both in terms of security and in consistency of configuration.

Using VUM, you can centralize your patch and upgrade management into one product. Although many environments already have patch management infrastructure, VUM will allow a more holistic approach as it was architected from the ground up for virtual infra-structure and not any one particular operating system. A good example of this approach is the ability to update templates. No other patch management system has the ability to take a VM template and update the operating system or application within that template due to its being in an “off” state. Also, as customers import and use virtual appliances, their need to be upgraded to include new features or fix issues will become necessary, and VUM can provide virtual appliance management.

With host profiles, the configuration management of the ESX/ESXi servers is provided to ensure that a group or cluster of hosts maintain their consistency. Due to the strict setup rules for VMotion, HA, FT, and other features, host profiles can apply a set of policies that provides a consistent setup for each host. If you need to make a change to all hosts in a group or cluster, you can make that change once to the profile and then apply it to all the hosts one at a time using Maintenance mode.

Applying patches or configuration changes has become one of the strongest reasons for adopting vSphere.

Exam Essentials

Know how to install, configure, and manage VMware vCenter Update Manager. Be able to identify installation requirements and know how to perform database sizing. Know how to install, configure, and create baselines. Be able to attach, scan, and remediate an ESX/ESXi host or VM/VA. Know how to analyze compliance information and use that information to make decisions on remediation. Knowing how to stage and add third-party URLs to the download server is also important.

Be able to create and apply host profiles. Know how to create and delete a host profile. Be able to import and export profiles. Attaching a profile and checking for compliance are also important. Review applying a host profile and analyzing compliance information.


Review Questions

1. What is the correct order of operations when using host profiles?

A. Create reference profile, edit profile, attach profile, apply profile, check for compliance

B. Check for compliance, create reference profile, attach profile, apply profile

C. Install reference host, create reference profile, attach profile, check for compliance, apply profile

D. Import profile, create reference host, apply profile, attach profile, check for compliance

E. Install reference host, create reference profile, attach profile, apply profile, check for compliance

2. Which of the following is not a valid VUM setting?

A. Take a snapshot of a VM before patching and keep it indefinitely

B. Take a snapshot of a VM before patching and keep for a fixed period of time

C. Power off VMs on an ESX server if the ESX server fails to go into Maintenance mode

D. Automatically rollback a snapshot after a fixed period of time

E. Suspend VMs on an ESX server if the ESX server fails to go into Maintenance mode

3. Host profiles require which of the following?

A. ESX 2.5 Update 2 or better

B. ESX/i 3.0 or better

C. ESX/i 3.5 Update 4 or better

D. ESX/i 4.0 or better

E. ESX/i 5.0 or better

4. What are the two main types of VUM baselines you can create?

A. ESX/VM

B. Windows/Linux

C. Update/Upgrade

D. Patch/VMware Tools

E. Fixed/Dynamic

F. Full/Incremental


5. Which of the following describes how VUM handles ESXi updates?

A. VUM does not update ESXi. You should manually save the ESXi settings, install from an updated ISO installer, and restore the saved settings.

B. ESXi updates are installed by merging patches from an update boot image with the ESXi active boot image. The old pre-patch boot image becomes the standby boot image.

C. VUM places the ESXi server in snapshot mode, applies the updates, and performs an auto-rollback if the update fails.

D. The ESXi server is removed from the DRS/HA cluster during patching and readded only if the patch was successfully applied.

E. VUM mounts the ESXi system disk as an image file, applies the patch to the mounted image file, tests the patch, and reboots the ESXi server only if the patch is successful.

6. Which of the following statements about VUM baselines is true?

A. You should craft baselines carefully as you can only attach one to any given vCenter inventory object.

B. You can attach baselines to just about any inventory object in either the Hosts And Clusters or VMs And Templates views.

C. Baselines operate more efficiently when you combine VM and ESX patches in a single baseline.

D. Any given baseline can only be attached to a single vCenter inventory object.

E. The default built-in baselines are not functional but only serve as templates for creating your own baselines.

7. Which of the following functions cannot be performed by VUM? (Choose two.)

A. Check a VM’s hardware version

B. Install VMware Tools

C. Put an ESX server into Maintenance mode

D. Apply new virtual switch definitions

E. Change ESX firewall port settings

8. You have decided to set up a separate download server for VUM to use when retrieving patches. After installing the Download Service, you want to manually force the download-ing of all patches for ESX servers, Windows VMs, and Linux VMs. Which command will accomplish this?

A. vmware-cmds –set-config –enable-downloads all

B. vmware-cmds –set-config –enable-host 1 –enable-win 1 –enable-lin 1

C. vmware-cmds –set-downloads all

D. vmware-downloads –set all

E. vmware-downloads –enable-downloads all


9. Which of the following are not required for proper VUM operation?

A. vCenter

B. VUM database

C. Download server

D. VUM server access to the Internet

E. VUM plug-in

10. ESX host profiles are generated from which of the following?

A. Any ESX host running ESX 3.5 Update 2 or later

B. A reference host

C. A template

D. The profile generator GUI

E. An ESX server’s installation profile log

11. Staging VUM patches for ESX servers requires which of the following?

A. ESX 2.5 Update 2 or better

B. ESX 3.0 or better

C. ESX 3.5 Update 4 or better

D. ESX 4.0 or better

E. ESX 5.0 or better

12. Which databases are supported for a VUM server? (Choose three.)

A. MySQL

B. SQL

C. Sybase

D. Oracle

E. SQL Server Express

13. Which of the following does not describe a way in which VUM baselines interact with inventory objects?

A. Patches with an “unknown” status can be updated via remediation.

B. Every time you view the compliance information for an object, the current compliance status is updated.

C. Linux VMs do not show compliance information for Windows VMs and vice versa.

D. There is no compliance information for objects that do not have baselines attached.

E. New patch compliance information is automatically shown as the new patches are downloaded to the patch download server.

F. Compliance information requires a minimum of read-only permissions on an object.


14. By default, which of the following URLs does VUM access for patch download information? (Choose two.)

A. https://update.microsoft.com/

B. https://www.vmware.com/

C. https:/www.kernel.org/

D. https://xml.shavlik.com/

E. https://patches.linux.org/

15. You have three vCenter servers operating in Linked Mode. How many VUM servers will you have to install to support this configuration?

A. 1

B. 2

C. 3

D. 4

E. VUM is not supported with vCenter servers operating in Linked Mode in vSphere 4.0

16. Which of the following describe features of staging patches for ESX/ESXi hosts? (Choose three.)

A. Patches must be staged for security reasons.

B. Staging patches can speed up remediation.

C. Staging patches can be done during normal ESX/ESXi operations.

D. Staging patches reduces the amount of disk space required to store patches on the download patch server.

E. Maintenance mode downtime is reduced when staging patches.

F. Staging patches eliminates the need for the download server to have an Internet connection.

17. Which of the following is not included in a host profile by default?

A. Firewall ports

B. Date/time

C. Virtual switches

D. Storage

E. The host’s FQDN

F. User information

https://update.microsoft.com/

https://www.vmware.com/

https://www.kernel.org/

https://xml.shavlik.com/

https://patches.linux.org/


18. Which of the following is vSphere 4.0’s VUM not capable of doing? (Choose two.)

A. Patching ESXi hosts

B. Patching ESX 2.5 hosts

C. Patching ESX 3.5 hosts

D. Patching ESX 4.0 hosts

E. Upgrading an ESX 2.5 host to ESX 4.0

F. Upgrading an ESX 3.5 host to ESX 4.0

19. You want to install VUM in an environment with 10 ESX hosts and 100 virtual machines. Which of the following database options would not be supported in this environment? (Choose two.)

A. Oracle 9i (Release 2)

B. Oracle 10g (Release 2)

C. SQL Server 2005 (SP1)

D. SQL Server 2005 Express

E. SQL Server 2008

20. When remediating ESX hosts where you have multiple patches to install and there is a con-flict of some sort, which of the following applies? (Choose two.)

A. If a patch in the baseline depends on another patch not in the baseline, you will be asked to install the other, required patch, first.

B. If two patches conflict, the oldest patch is installed first and the newer patch is installed last, guaranteeing the newer patch contents override the older patch contents.

C. If there are several versions of the same patch, VUM will install only the most recent (i.e., latest) version.

D. If a patch is marked as “obsolete,” the baseline will remove the patch.

E. If multiple patches conflict but another patch resolves the conflict, VUM will install the patches in the correct sequence to resolve the conflict.



1. C. You must have an installed ESX server (the reference host) to start the process. From this server a reference profile is generated and attached to a vCenter inventory object (an ESX server or a cluster). The ESX server(s) is scanned for compliance, and if desired, you can then apply the profile to the ESX server(s).

2. D. VUM can take snapshots before patching VMs and keep them indefinitely or for a fixed period of time. VUM can either power off or suspend VMs on ESX servers that fail to go into Maintenance mode (typically because one or more VMs fail to properly move, using VMotion, to another ESX server). Although you can manually roll back a VUM snapshot, VUM will not automatically do so.

3. D. Host profiles were introduced with ESX 4.0 and are not backward compatible with prior versions of ESX. ESX 5.0 does not exist as of this writing.

4. E. Fixed baselines contain patches selected from a list, are static in nature, and must be manually kept up to date. Dynamic baselines are generated by VUM and automatically kept up to date as patches are released by vendors.

5. B. ESXi servers maintain an active (for the current boot) and standby (for rollback) system boot image. VUM merges patches with (older) standby image, creating a new active boot image. If anything goes wrong, this provides you the opportunity to boot the old standby image and have a working system.

6. B. Multiple baselines can be attached to any appropriate vCenter inventory object. Baselines can be attached to most objects in the vCenter inventory, including individual VMs, individual ESX hosts, folders, clusters, resource pools, data centers, and so forth. Individual baselines consist of VM or ESX patches but not both. Baselines can be attached to as many vCenter inventory objects as you need, and the default, built-in baselines are entirely functional.

7. D, E. VUM can check VMs to see if they are at the latest VM hardware version (7.0), can install the latest version of VMware Tools, and will put an ESX server into Maintenance mode (so as to evacuate all VMs off the ESX server) when patching an ESX server. The last two answers are functions of host profiles, not VUM.

8. B. Each separate set of patches to be downloaded is set with its own flag (a flag value of 1 enables downloading whereas a flag value of 0 disables downloading).

9. D. The VUM server does not require access to the Internet, but the download server does. Even if the download server happens to be the same as the VUM server, it is still technically the download server, which needs Internet access (for accessing the patch download servers at VMware and Shavlik).

10. B. Profiles are generated from an ESX 4.0 host, referred to as a “reference host.”

11. D. Patch staging was introduced with ESX 4.0.


12. B, D, E. VUM is only supported with Oracle, SQL, or SQL Server Express (with the correct and supported versions, of course). The VCP test notwithstanding, you should always check the manual to make sure you are looking at the list of currently supported databases.

13. E. New compliance information is only guaranteed by performing a remediation. The mere act of downloading new patches does not update compliance report information, but would, in fact, generate more “unknown” hits in the compliance report.

14. B, D. By default, VUM obtains patches and patch information for ESX servers from vmware.com and for Windows and Linux VMs from shavlik.com. Additional URLs can be configured for third-party patches.

15. C. When you have vCenter servers in Linked Mode, you must register separate instances of VUM with each vCenter server.

16. B, C, E. Staging (copying patches from the download server to an ESX/ESXi server) during normal ESX/ESXi operations time speeds up remediation and reduces Maintenance mode downtime. There is no security requirement or benefit in staging patches. During the staging process, disk storage for the patches is temporarily increased as the patch resides on both the download server and the ESX server being patched. As the stages patches come immediately from the download server, the download server still must be able to contact the patch servers on the Internet.

17. E. Host profiles, by default, do not configure every single setting on an ESX server. You will still need to make sure you set (usually outside of a host profile) the server’s FQDN and IP information, for example.

18. B, E. VUM will do all of these except patching ESX versions earlier than 3.5 and so, by implication, will not upgrade an ESX 2.5 host to ESX 4.0. If you manually upgrade an ESX 2.5 host to ESX 3.5, then VUM can upgrade that host to ESX 4.0

19. A, D. Oracle 10 is the oldest release of Oracle supported for VUM in vSphere 4.0. SQL Server Express is supported only for installations with a maximum of 5 ESX servers and 50 virtual machines.

20. C, E. If a patch depends on another patch, VUM will automatically install the other required patch as well. If two patches conflict (and there is not another patch that resolves the conflict), neither of them is installed. VUM is intelligent enough to install only the most recent version when multiple versions of the same patch are present.

Chapter

7Migrating, Backing Up, and Restoring Virtual Machines


Migrate Virtual Machines.NÛ

Identify compatibility requirements .NN

Cite the three methods of virtual machine migration .NN

Understand/Apply .NN

Determine migration use cases .NN

Compare and contrast migration technologies .NN

Migrate a virtual machine using VMotion .NN

Migrate a virtual machine using Storage VMotion .NN

Cold migrate a virtual machine .NN

Backup and Restore Virtual Machines.NÛ

Describe different backup/restore procedures and strategies .NN

Create/Delete/Restore Snapshots .NN

Install Backup and Recovery Appliance .NN

Install VMware Data Recovery plug-in .NN

Create a backup job with VMware Data Recovery .NN

Perform test and actual restores using VMware Data Recovery .NN

This chapter describes the migration capabilities of vCenter Server. Our first task is to identify the compatibility require-ments for migration. We’ll then examine the three methods

of a virtual machine migration. Next, we’ll look at the processes used for each method and then determine use cases for each, comparing the reasons to use one migration over another. We’ll then migrate a VM using VMotion, Storage VMotion, and cold migration.

The rest of the chapter delves into backing up and restoring virtual machines. We’ll examine several backup and restore techniques. An important consideration when doing a backup is being able to take snapshot of the VM, so we’ll look at creating, deleting, and restoring snapshots. Next we’ll look at the VMware Data Recovery appliance. You’ll learn how to install the appliance, install the plug-in, create a backup job, and practice a restore of a VM.

Migrating Virtual MachinesThere are many situations where moving a VM to another ESX/ESXi host is necessary. One situation might involve load balancing; another might involve facilitating scheduled ESX host maintenance. Whatever the reason, migrating VMs to other hosts has become one of the hallmark features of VMware vSphere 4.0. Knowing which migration method to use for a given situation is also important—one method does not fit all scenarios.

With the migration technologies comes prerequisites for their use. Understanding what is needed from a hardware and implementation standpoint is critical to the success of a migra-tion. This section will look at both hardware and setup requirements for successful migra-tions. Understanding a particular scenario will also help in determining the right migration technique. Practice using each type of migration will help you identify situations for their use.

This section covers eight subobjectives:

Identifying compatibility requirementsNN

Cite the three methods of virtual machine migrationNN

Understanding/applying migration methodsNN

Determining migration use casesNN

Comparing and contrasting migration technologiesNN

Migrating a virtual machine using VMotionNN

Migrating a virtual machine using Storage VMotionNN

Cold-migrating a virtual machineNN

Migrating Virtual Machines 365

Identifying Compatibility RequirementsWhen using one of the three methods of migration—cold migration, VMotion, or Storage VMotion—you must ensure that all hosts that are possible source and destination targets meet compatibility requirements. Each migration method has a separate list of requirements to satisfy before you can move a VM successfully. Of the three methods, VMotion has the largest number of compatibility requirements, whereas a cold migration has the fewest. This is due to the power state of the VM.

Cold MigrationCold migrations have the fewest restrictions or requirements to be successful due to the virtual machine being in a powered-off state. Cold migrations offer the ability to move a VM’s registration to another host or move the files that encapsulate the VM to another datastore or both. Shared storage is not necessary and CPU compatibility is not a concern.

VMotionA successful VMotion requires many elements of the vSphere infrastructure to be compatible and consistently implemented. For a VMotion operation to work, the host needs to be con-figured properly. These elements include:

Each host must be licensed.NN

Each host must have shared storage.NN

Each host must have shared access to networks.NN

On the storage side, the source and destination hosts must have identical visibility to the datastores where the VMs are stored. On the networking side, the source and destination hosts must have the same access to the networks that the VMs are configured to use. The VMotion network uses a Gigabit Ethernet network between VMotion hosts.

The next subsystem that needs to be compatible consists of the processors. VMotion requires that the processors that a VM is exposed to provide the same instruction set on the source and destination hosts. CPU compatibility can be summed up as follows:

The ESX hosts must use processors from the same CPU family.NN

NX/XD features need to be consistently masked or exposed on all hosts.NN

SSE3/4 instructions must be consistent between hosts.NN

Using Enhanced VMotion Compatibility (EVC) will provide a baseline of features that each host in a cluster can support. This eliminates the need for manually masking features away from the VMs and provides a consistent CPU feature set that ensures VMotion success. To use EVC, make sure you meet the following requirements:

You must be using vCenter 2.5 Update 2 or later.NN

To enable EVC for the cluster and to ensure proper consistent VM exposure to the CPU NN

feature set, all VMs need to be migrated out of the cluster or powered off.

Each host must have a processor from a single vendor.NN

366 Chapter 7 N Migrating, Backing Up, and Restoring Virtual Machines

Each host must be running ESX/ESXi 3.5 Update 2 or later.NN

Each host must be managed by the same vCenter serverNN

Each host must have AMD-V or Intel VT instructions enabledNN

Each host must have a supported processor.NN

In addition to the host requirements, there may be VM requirements. In the case of VMotion, the VMs have to meet several configuration requirements:

The VM cannot be using raw disks for clustering (physical compatibility mode).NN

The VM cannot have a CD or floppy device mapped to a location to which the destina-NN

tion host does not have access.

The VM cannot have a connection to an internal virtual switch.NN

The VM cannot have CPU affinity set.NN

Storage VMotionStorage VMotion allows the files that encapsulate a VM to be migrated from one datastore to another while the VM is powered on. This type of migration does not move the VM to another host. It does allow for the virtual disks to be converted from thick to thin provi-sioning, or vice versa. The requirements for Storage VMotion for hosts and VMs are:

VMs cannot have snapshots.NN

VM disks must be persistent.NN

RDMs can be migrated or converted if you’re using virtual compatibility mode, but if NN

physical compatibility mode is used only the mapping file can be migrated.

Migration of a VM while the VMware tools are being installed is not supported.NN

The ESX host must have a license.NN

The ESX host must have access to both the source and destination datastores.NN

A single host can be involved in up to two Storage VMotion migrations at a time (this NN

is the default; four is the maximum).

Table 7.1 lists the three migration methods and a summary of their requirements.

TA B lE 7.1 Migration Methods and Requirements

Method Requirements

Cold VM must be powered off .

ESX/ESXi hosts must be able to communicate with each other .

RDM must be in virtual compatibility mode to convert the virtual disk to a thick- or thin-provisioned disk .


Method Requirements

VMotion Processors of the source and target ESX hosts must allow for the equivalent instructions to be executed .

Processors must come from the same vendor, AMD or Intel, and use compatible instructions .

Shared storage must be used .

Shared access to networking must be used .

Storage VMotion The VM must have no snapshots

Virtual disks must be in persistent mode .

You must have a Storage VMotion license .

The host must have access to the source and destination datastores .

Citing the Three Methods of Virtual Machine MigrationMigrations come in three flavors: VMotion, Storage VMotion, and cold migration. VMotion moves the running state of a VM from one host to another without incurring downtime for the VM. Storage VMotion moves the files that constitute a VM from one datastore to another while the VM is powered on. A cold migration can move the files to another datastore and/or move the host registration of the VM to another host while the VM is in a powered-off state.

Two of the migration methods have a set of licensing requirements that must be met before the migration can succeed, as you learned in the previous section. For VMotion or Storage VMotion, a license must be purchased that includes these options (Advanced, Enterprise, or Enterprise Plus). Cold migrations can be done with any version of a license, but the VM must be powered off. Once the requirements are met, you can then proceed with the migration.

Understanding/Applying Migration MethodsOnce you know the requirements and configuration needs for each migration method, choosing the right method depends on two questions. What is it that you want to move? Can downtime be tolerated? By answering both questions, you’ll find that the method of migration will become clearer. Table 7.2 provides a guide to these questions and helps you determine which migration method should be used.

TA B lE 7. 2 Determining Which Migration Method to Use

Moving What? Downtime Tolerated? Migration Type

Virtual machine running state No VMotion

TA B lE 7.1 Migration Methods and Requirements (continued)


Moving What? Downtime Tolerated? Migration Type

Virtual machine registration, powered off

Yes Cold migration

VM files No Storage VMotion

VM files, powered off Yes Cold migration

VM files and registration Yes Cold migration

Tolerating Downtime

Company “A” wants to limit the amount of downtime of an application to the very least possible . They have decided to use VMware server virtualization as a way to reduce the number of downtime events for their servers and the applications they run . Due to the portable nature of a VM due to its encapsulation into files, moving the VM becomes a function of moving the running state of the server operating system and its application (mostly memory, VMotion) or moving the files of the VM (Storage VMotion) .

Over the years, VMware has provided tools and/or features designed to limit the amount of downtime a VM must endure . VMotion has been around for several years and is well known to Company “A” for moving VMs to another ESX/ESXi host without an interrup-tion in application service . The latest option, Storage VMotion, allows for a VM’s files to be moved to another datastore without incurring downtime for the VM itself . Company “A” sees this technology as a way to move away from an older storage array and onto newer storage technologies . Both tools allow for hardware maintenance activities on the hosts themselves or the storage without incurring downtime for the VM .

Company “A” wants to achieve a four “9’s” uptime for most of its servers and applications . In fact, without virtualization, the odds that it could achieve such high uptimes for a server and its application are almost unattainable without spending extreme amounts of money, which the company does not have in its budget . VMware provides the infrastructure for attaining such numbers more easily without the complex hardware or administrative costs . Company “A” also wants to provide zero downtime for several of their mission critical appli-cations, and a feature such as VMware Fault Tolerance (FT) fits their needs . The only impedi-ments to high application uptime are now the operating system or application itself . If the operating system needs to be restarted due to a patch on the OS or application, the time needed for these restarts will be the biggest consumer of your downtime percentages .

TA B lE 7. 2 Determining Which Migration Method to Use (continued)


Determining Migration Use CasesWith a good grasp of the three migration methods, let’s take a look at three use cases for each.

VMotionVMotion is probably the best choice when you’re moving a virtual machine from one host to another but downtime cannot be tolerated. Why would a VM need to be moved to another host? There are two primary reasons for doing so: load balancing and sched-uled maintenance.

There are times when a particular host may become overwhelmed by the workloads of the VMs it is hosting. If too many VMs compete for resources on this host, they may become sluggish or unable to meet service levels required of them. The best way to alleviate this condition is to VMotion one or more VMs to other hosts that have spare capacity. This can be done manually or by using VMware Distributed Resource Scheduler (DRS). A best practice is to take VMs that utilize a particular resource heavily, such as CPU, and spread them across all the ESX hosts so that they do not compete with each other on the same host. This can be done with VMotion without powering off the VM.

Another reason to use VMotion is to facilitate scheduled maintenance. There will be times when a particular ESX host will need to have some type of physical maintenance per-formed on it, such as replacing a power supply or adding additional memory. When these maintenance activities occur, VMotion can be used to evacuate the host, either manually or with DRS. In both cases, the ESX host cannot be put into Maintenance mode until all VMs have either been powered off or moved to other hosts with VMotion. Once the ESX host has entered Maintenance mode, the ESX host can be powered off or the software upgraded and then rebooted. After the maintenance has been completed, the ESX host can exit Maintenance mode and VMotion can be used to bring back the VMs it was hosting.

Storage VMotionStorage VMotion is used to move the files of a VM to another datastore. There are several reasons why this may be necessary:

Storage Tiering The use of more than one storage technology based on performance and space requirements

Storage Retirement Involves replacing an older storage array with a newer one

Load Balancing Involves moving VMs to other datastores to reduce competition for disk I/O

Changing Virtual Disk Provision Type Converts a virtual disk from thick-provisioned to thin-provisioned, or vice versa.

Reorganization of Storage When LUN resizing or recycling of storage space is needed to optimize a storage array’s resources.

Each of these reasons may require that the virtual machine’s files move to another data-store. With Storage VMotion, the VM does not have to be powered off.


Cold MigrationWith the two migration methods just discussed, the VM does not have to powered off. With cold migration, the VM is either powered off or was already off. There are several reasons to use cold migration instead of the other two methods:

The VM is incompatible with VMotion; for example, it’s part of a Microsoft cluster.NN

The ESX host that the VM is running on is incompatible for VMotion with another host.NN

You want to move the VM to another host and datastore at the same time.NN

When the VM is powered off, moving the host registration or the files of the VM is relatively easy. Once completed, the VM can be powered on.

Comparing and Contrasting Migration TechnologiesKnowing the criteria for a given migration type helps in determining which type would be appropriate. Table 7.3 compares the migration types.

TA B lE 7. 3 Migration Comparisons

Migration Type Power StateChange Host/Datastore

Shared Storage

CPU Compatibility

Migrate Across Datacenters

VMotion On Host Yes Yes No

Storage VMotion

On Datastore No N/A No

Cold Off Host, datastore, or both

No Different CPUs allowed

Yes

Suspended VM Suspended Host, datastore, or both

No Yes Yes

The migration wizard that is used with vSphere 4.0 takes into account these questions and criteria, providing only the options that make sense. Figure 7.1 shows an example of the migration wizard with the virtual machine powered on.

Migrating a Virtual Machine Using VMotionUsing VMotion to migrate a VM from one host to another is straightforward. Using the Migration wizard simplifies the process and alerts you of any incompatibilities with the environment. Exercise 7.1 steps you through the VMotion wizard.


F I GU R E 7.1 The different default baselines used with VMware vCenter Update Manager for hosts

E X E R C I S E 7.1

VMotioning a VM

1. Log into the vCenter server with the vSphere Client and select a VM in the Inventory view, either from Hosts And Clusters view or VMs And Templates view . Right-click the VM and choose Migrate .

2. Select Change Host from the three options and click Next .


E X E R C I S E 7.1 ( c ont inue d )

3. On the Destination screen, choose a host or cluster depending on what is presented . If a cluster is presented first, choose the appropriate cluster . Then choose the host within the cluster . If there are any compatibility issues after choosing a host, they will appear in the Compatibility panel at the bottom of the wizard . Any “red” messages will require immediate attention and will have to be remedied before the wizard can continue . If “yellow” messages appear, read them carefully, but they will not prevent the VMotion from continuing . Click Next .

4. If there are resource pools, the wizard will ask if the VM should move to one of them . Choose a resource pool and then click Next .

5. Select the migration priority level from the two options . High Priority will reserve resources on both the source and destination ESX hosts to perform the VMotion and ensure the VM is available throughout the migration process . Low Priority does not reserve resources on either host, and the VM may become briefly unavailable if there are not enough resources on both hosts during the migration .


6. On the Ready to Complete screen, click Finish .

Migrating a VM Using Storage VMotionUsing the same Migration wizard, you can choose Storage VMotion if your intent is to move the files of the VM. In Exercise 7.2, the process for migrating with Storage VMotion is shown.

E X E R C I S E 7. 2

Moving a VM to Another Datastore with Storage VMotion



E X E R C I S E 7. 2 ( c ont inue d )

2. Select Change Datastore from the three options and click Next .

3. If resource pools are being used, select a pool and click Next .

4. From the Choose Datastore screen, choose a datastore from the list . (If you want to move individual virtual disks of the VM, click Advanced and select which virtual disks are to be moved and which datastore to move into .) Click Next .



5. The next screen allows you to choose a disk format for the virtual disks . The options are Same Format As Source, Thin Provisioned Format, and Thick Format . Click Next .

6. On the Ready To Complete screen, click Finish .


Cold Migrating a Virtual MachineIf the virtual machine is in a powered-off state, a cold migration can be used. This allows for a host and/or a datastore change.

Exercise 7.3 shows the steps used to cold-migrate a VM.


Cold-Migrating a VM


2. Next, you’ll select one of the three options: Change Host, Change Datastore, or Change Both Host And Datastore . Then click Next .



3. The next screen will depend on which option you selected on the previous screen . If you chose Change Host, then the next screen will allow you to select a host or cluster/host . If you chose Change Datastore, then the next screen will let you select a datastore . If you chose Change Both Host And Datastore, then both screens will appear to allow you select a host or cluster/host and a datastore .

4. If any errors appear in the Compatibility panel, you will have to investigate and fix the errors before the wizard will allow you to continue .

5. If you chose either Change Datastore or Change Both Host And Datastore earlier, the option to select a disk format will be next . This will allow the conversion of a virtual disk to another format if desired . Click Next .



6. Review the Ready To Complete screen and then click Finish .

Backing Up and Restoring Virtual MachinesBacking up virtual machines is one of the most critical tasks an administrator provides. The use of snapshots in facilitating backups is emphasized in this section. We’ll focus on the VMware Data Recovery appliance, a new backup solution from VMware for backing up and restoring virtual machines.

This section will look at the backup needs of the Service Console and how to back up an ESXi host’s configuration. We’ll also look at how to install the VDR appliance and its plug-in. Next we’ll cover the backup process and how to restore a virtual machine using this solution.

This section covers six subobjectives:

Describing different backup/restore procedures and strategiesNN

Creating/deleting/restoring snapshotsNN

Installing Backup and Restore ApplianceNN

Installing the VMware Data Recovery plug-inNN

Creating a backup job with VMware Data RecoveryNN

Performing test and actual restores using VMware Data RecoveryNN

Describing Different Backup/Restore Procedures and StrategiesThere are several elements in a vSphere infrastructure that may require a backup strategy. The configuration of the ESX/ESXi server can be saved for use in recovering a failed host or

Backing Up and Restoring Virtual Machines 379

to revert to a previous boot image in the case of an ESXi server. The virtual machines are the primary focus for any backup strategy and can be implemented in a number of ways.

One backup strategy that can be used for backing up VMs is to use legacy agent tech-nology and back up the VMs over the network. This has the potential disadvantage of overwhelming the virtual switch and its associated uplinks. Another way to back up a VM is to install a supported agent onto the Service Console of an ESX host and back up the files that make up a VM from the VMFS file system. The primary disadvantage to using this method is that it creates a load on the Service Console that competes for resources against the VMs running on that host.

VMware has two technologies for backing up virtual machines. Their first attempt at a backup technology was called VMware Consolidated Backup (VCB). This method usually involves installing the VCB framework on a stand-alone physical server that has the same access to the shared storage that the ESX hosts have. Virtual disks can be mounted for file-level backups of Microsoft Windows virtual machines or full VM image backups of any supported guest operating system.

VMware’s second technology, introduced with vSphere 4.0, is called the VMware Data Recovery (VDR) appliance. This appliance can back up a full VM image or can back up incremental changes to the VM. The VDR appliance also has the ability to restore VMs.

On the virtual machine side, VMware recommends that the VMs be built with separate virtual disks for booting and for storing data. One strategy for backing up the VM is to use VCB to back up the full image of the VM at a point in time and use an agent inside the VM to incrementally back up data. This allows you to restore the VM from its backup image (you can use vCenter Converter) and then restore data through the agent to bring the VM close to the point of when it failed or became unusable.

Table 7.4 compares the various backup strategies.

TA B lE 7. 4 Comparisons of Backup Strategies

Method Backup Type Notes

Backup agent in VM File-level backup Potential bottleneck on vSwitch

Backup agent on Service Console

VM image backup Creates load on ESX server

VMware Consolidated Backup

File and full image File-level backup only for Windows

VMware Data Recovery Full and incremental VM image backup

Backup and Restore with Retention policy


Creating, Deleting, and Restoring SnapshotsUsing snapshots in vSphere captures the state of the virtual machine: memory state, settings, and disk state. Snapshots allow the virtual machine to be rolled back to a previous point in time. This allows you to test different OS or application changes or updates/upgrades and then revert to the previous state for further tests from the same starting point. Snapshots can also be used to roll back changes to a virtual machine if the update has a negative impact on the VM. In some cases, multiple snapshots can be taken on the same virtual machine to trap changes at specific points in their installation.

Snapshots trap changes as they are written to a delta disk. The delta disk accumulates changes at a file level. If the same file is changed more than once within the same snap-shot, the file will reflect all changes. The snapshot has no mechanism to revert to an earlier version of the file within the delta disk as there is no transaction log. The only way to approximate versioning of a file or files is to take another snapshot each time before the change is implemented.

The basics of a snapshot can be described like this:

1. The running VM has a snapshot taken using the Snapshot Manager.

2. A disk-write-buffer is created that begins to accumulate disk changes. This buffer is a delta disk with a relationship with the original virtual disk. The original virtual disk is now read-only.

3. The VM administrator installs a patch, upgrade, service pack, or some other type of change that requires disk writes. These changes are written into the delta disk.

4. If the change installed has a negative impact on the VM, the snapshot can be reverted without committing the accumulated changes. If the changes contained in the snapshot need to be merged with the original virtual disk, the snapshot can be deleted, this time committing the changes.

Snapshots can be taken off of one another, creating a parent-child relationship, or branch. Figure 7.2 shows a virtual machine, using the Snapshot Manager, with the original virtual disk and three snapshots taken.

Each snapshot taken creates a separate delta file, trapping changes from that point for-ward. Any snapshots above the last snapshot are read-only with the bulls-eye (“You are here”) hanging from the last snapshot in the branch. The bulls-eye informs you as to which snapshot is currently being written to. The bulls-eye can be moved, therefore bypassing a lower snapshot and any changes it has accumulated. The state of the VM will now be at an earlier time. Any snapshot below the bulls-eye will be orphaned and can be deleted without committing changes.

A snapshot can be taken with a virtual machine in a powered-on, powered-off, or suspended state. If any of the disks are in independent mode, the virtual machine will have to be powered off to take a snapshot. Exercise 7.4 shows the steps for taking a snapshot.


F I GU R E 7. 2 Snapshot Manager


Taking a Snapshot

1. Log into the vCenter server with the vSphere Client and click on VMs And Templates from the Inventory section . From the VMs And Templates view, select a powered-on VM and right-click . Select Snapshot Take Snapshot .



2. In the Take Virtual Machine Snapshot dialog box, type a name for the snapshot and type a description for it . If the memory state should be included with the disk snapshot, select the Snapshot The Virtual Machine’s Memory check box . To quiesce the VM before the snapshot is taken, select the Quiesce Guest File System (Needs VMware Tools Installed) check box . Click OK .

3. Monitor the progress of the snapshot in the Recent Tasks pane at the bottom of the vSphere Client . Right-click the VM, and choose Snapshot Snapshot Manager .

4. From the Snapshot Manager, verify that the previous snapshot is visible and review the description .



Once the snapshot has served its purpose, it can be deleted. VMware recommends that snapshots be deleted as soon as reasonable. If a snapshot is allowed to linger, it can accumu-late more changes than anticipated. If a rollback is desired, this may mean losing not only the changes that were planned for but also losing additional information that is pertinent.

You’ll have two options when deleting a snapshot: commit the changes or revert to an earlier point in time. If you want to keep the changes that have accumulated in a snapshot, choosing the Delete button will not only commit the changes to the next parent above, but also delete the delta disk. If you don’t want the changes, you must adjust where the current changes are to be written. Do so by selecting a previous snapshot or the parent virtual disk higher up in the branch and using the Go To button to revert the state of the VM. Once the bulls-eye (You are here) has moved to above the unwanted snapshot, it can be deleted with-out fear of committing those changes to the parent disk.

Exercise 7.5 outlines the steps to delete a snapshot and commit the changes to the parent disk.


Deleting a Snapshot

1. Log into the vCenter server with the vSphere Client and click on VMs And Templates from the Inventory section . From the VMs And Templates view, select a powered-on VM and right-click . Select Snapshot Snapshot Manager .



2. From the snapshot view, select the snapshot to be deleted . Click the Delete button at the bottom of the interface to commit the changes within the snapshot and delete the delta disk . If there is more than one snapshot and all are to be deleted, click the Delete All button to commit all snapshots and delete all delta disks (Delete All will sequentially delete each snapshot working from the bottom to the top) .

4. Click Yes to confirm the deletion .



To restore the virtual machine to a previous state, use the Go To button. This ability allows the rollback of a snapshot in case the changes written to the delta disk have nega-tive consequences to the VM’s operation or are not wanted. Exercise 7.6 shows how to restore a snapshot.


Restoring a Snapshot

1. Log into the vCenter server with the vSphere Client and click VMs And Templates from the Inventory section . From the VMs And Templates view, select a powered-on VM and right-click . Select Snapshot Snapshot Manager .



2. From the snapshot view, select the parent above the snapshot that is not wanted and click Go To .

3. Click Yes to confirm the restoration .


Installing Backup and Recovery AppliancesThe installation of the VDR appliance requires the use of vCenter Server and vSphere Client. It will not work with earlier versions of either server or client. ESX/ESXi hosts must be version 4.x—earlier versions do not support changed block tracking functionality. Backups can be stored on a virtual disk, which is a second or possibly a third virtual disk added to the appli-ance or on a Common Internet File System (CIFS) share.

Storage requirements will vary based on several factors:

The amount of de-duplication achievedNN

The number of operating systems being backed up, which increases the amount of N

storage needed

Frequency of backupsNN

Retention policiesN

Number of VMsNN

The installation of VDR involves obtaining the Open Virtualization Format (OVF) fi le, either by importing it directly from VMware or downloading the appliance separately and then deploying it when ready. Exercise 7.7 provides the steps to install the VDR appliance.

You will have to download the VDR appliance before beginning Exercise 7 .7 .


Installing a VDR Appliance

1. Log into the vCenter server with the vSphere Client . From the vSphere Client, select File Deploy OVF Template .



2. Select the method to import the appliance . If the OVF template was downloaded previously, then choose the top option and browse to the location off the template . If the appliance needs to be imported, choose the bottom option . For this exercise, choose the top option, browse the location where it is being stored, and select the file . Click Next .

3. Review the details of the template . Click Next . Give the VDR appliance a name; then click Next .



4. Review the details of the template . Click Next . Give the VDR appliance a name; then click Next .

5. On the Inventory Location screen, choose a folder as a home for the appliance . Click Next

6. On the Host/Cluster screen, choose the appropriate cluster, if there is one, and then the appropriate host . Click Next .



7. Next, on the Datastore screen, choose a datastore for storing the appliance . Click Next .

8. The next step is to choose the network for the appliance to use . Using the drop-down menu, choose the appropriate network and click Next .

9. On the Ready To Complete screen, click Finish . A dialog box will appear showing the progress of the import . When this task completes, click Close .



10. Verify the installation of the VDR appliance by navigating to the folder you selected in the wizard and viewing the appliance in the inventory .


Now that the appliance has been installed, there is some more work to be done. The appliance by itself is not much use. For the appliance to store virtual machine backups, it must have a storage virtual disk added to the configuration or a CIFS share configured. Exercise 7.8 steps through the adding of a virtual disk to the appliance.


Adding a Virtual Disk to the Appliance

1. Log into the vCenter server with the vSphere Client . From the vSphere Client, click VMs And Templates, then navigate to the VDR appliance, right-click, and select Edit Settings .

2. On the Add Hardware tab, click Add and select Hard Disk; then click Next .



3. Select Create A New Virtual Disk from the options and click Next .

4. On the Options screen, specify the disk size needed to store several VMs . You may select a different datastore to house the virtual disk that will be storing the VM’s backups in the Location section . Otherwise, click Next .



5. On the Advanced Options screen, there is no need to change anything . Click Next .

6. Review the summary information; then click Finish .

7. If the VDR appliance was powered-on during the addition of the storage virtual disk, the appliance will need to be rebooted so that its storage can be recognized and eventually formatted .


Installing the VMware Data Recovery Plug-inThe VDR appliance has a plug-in that will need to be installed. Unlike other plug-ins that are available from the Manage Plug-ins manager in the vSphere Client, the VDR plug-in will have to be installed as a separate installation with its own installation file. In addition, the plug-in uses port 22024 to communicate with the appliance. Be sure to open a firewall port if a firewall exists between the vSphere Client and the appliance.

Exercise 7.9 provides the steps to install the VDR plug-in.


Installing the VDR Plug-in

1. On the vCenter server, locate the installation file, VMwareDataRecoveryPlugin.msi, and double-click the file to begin the installation . On the Welcome screen click Next . On the License Agreement screen, select I Agree and click Next . On the Confirm Installation screen, click Next and on the Installation Complete screen, click Close .

2. Log into vCenter using the vSphere Client on a machine where you have administrative privileges . Navigate to the Plug-ins menu along the top of the client and select Manage Plug-ins from the menu .



3. Verify that the Data Recovery plug-in is installed and has been enabled . Click Close after the review .

After these three exercises have been completed, the VDR appliance is almost ready for use. One last step involves formatting the second virtual disk so that it can receive the VM images it is backing up. Exercise 7.10 outlines the steps for preparing the second disk to receive VM images.

E X E R C I S E 7.10

Formatting the Second Disk of the VDR Appliance

1. Log into vCenter with the vSphere Client . Navigate to the Solutions And Applications section at the bottom of the client and select VMware Data Recovery . This will begin the initial configuration of the appliance .

2. In the Data Recovery dialog box, verify that the appliance appears in the Virtual Machine Name/IP Address field . Click Connect . Provide the login password (the initial configuration will use the username that was used to log into the vSphere Client) and click OK . The Getting Started wizard will appear .

3. On the Credentials page, supply the password once again and click Next . From the Backup Destinations page, select the second disk from the list . Click Format . The for-mat dialog box will appear . Click OK to begin the format operation . When completed, the disk should appear as scsi0:1 . Click Next .

4. On the Configuration Complete screen, deselect the Create A New Backup Job After Completion check box and click Close .


Creating a Backup Job with VMware Data RecoveryWith the VDR appliance all set up, it can now be used to back up a VM. A single appliance can schedule and back up to 100 virtual machines. If more than one appliance will be used, each will have separate logins and can schedule 100 virtual machines for backup separately. VDR appliances that do not share information and backup schedules will have to be main-tained and modifi ed separately.

Each backup job has four components:

Which VMs will be backed upNN

Where the VMs will be storedN

The schedule for backupNN

The retention policyN

You can specify which VMs to backup by selecting different objects in the Backup Job wizard. These objects can be datacenters, resource pools, folders, a host, or a single VM. If a VM is selected, all disks are backed up. If the VM is moved to another location or organi-zational container that is not included in the Backup Job, it will not be backed up.

The destination is next part of the Backup Job to select. Virtual disk or RDMs may be used. In either case, they have to be formatted to be eligible to receive VMs. Formatting these volumes creates a de-duplication store. This de-duplication store saves room by not writing duplicates of data within the store. If the same operating system is used in the VMs that are being backed up, the space savings can be signifi cant. Currently, the de-duplication store can be up to a one terabyte in size.

The default backup window for VMs is Monday through Friday in the evenings, and anytime on Saturday or Sunday. The backup window can be altered for any backup job. If a backup is in progress but the backup window closes, the backup job will stop and will commence the next time the window is open. Any VM that may have been missed in the previous backup window will get a higher priority on the next backup window.

Data Recovery can retain VM backups for a specifi ed period of time. The administra-tor will have to create a retention policy that stipulates how long to hold onto a particular backup. If the retention policy is set to keep backups for longer periods of time, then the amount of storage needed will increase. Also, the retention policy can be used to automati-cally delete backups as they age. This makes room for newer backups

Once these four elements have been reviewed, a backup job can be created. Exercise 7.11 provides the steps necessary to back up a VM.

You will need to confi gure the VDR appliance before scheduling a backup job .



Creating a Backup job

1. Log into the vCenter server with the vSphere Client . From the vSphere Client, on the Home page, select VMware Data Recovery in the Solutions And Applications section .

2. From the Data Recovery pane, click the Backup tab .

3. Click the New link and the Backup Job wizard appears .



4. On the Virtual Machines screen, browse the hierarchy and select a container or single VM to back up . In this exercise, choose a single VM to back up . Click Next .

5. Next, the Destination screen is presented . Select the store that is to be used for the backup and click Next .

6. The Backup Window screen is next . The default window will not back up a VM during the day (Monday through Friday) . If the time the exercise is run is during this time, choose Select All and then click Next .



7. On the Retention Policy screen, accept the defaults and click next .

8. The Ready To Complete screen is presented . Review and then click Finish .

9. Verify the backup begins in the Backup pane . If Creating Virtual Machine Snapshot appears, the job has started .



10. The backup job can be monitored using the Reports tab and selecting the report labeled Running Tasks .


Performing Test and Actual Restores Using VMware Data RecoveryA backup of a VM won’t be helpful if the restore of that VM is not tested and completes successfully. You can specify which VM or VMs need to be restored. The Data Recovery appliance also provides for restore rehearsals to test whether a restore will be successful. For either actual restores or rehearsals, the Restore Virtual Machine wizard is used.

The first step is to select a source for restoration. The wizard allows you to filter objects so that you can restore only a specific VM or a container of VMs. In many cases, there may be multiple restore points for a single virtual machine. The most recent restore point will be used in most cases.

The next step is to select a destination for the restore. By default, the original location of the VM within the vCenter hierarchy will be selected, but if the hierarchy is different, a new location can be chosen. Also, there are reconfiguration options that can be used such as:

The datastore to be usedNN

The option not to restore the configuration of the VMNN

Should the VM’s NIC be connectedNN

Should the VM be powered onNN

Exercise 7.12 restores a virtual machine using the Restore Virtual Machine wizard.


Restoring a VM

1. Log into the vCenter server with the vSphere Client . With the vSphere Client, from the Home page select VMware Data Recovery in the Solutions And Applications section .



2. Log into the appliance and click the Restore tab . Click the Restore link to launch the wizard .

3. On the Source Selection screen, select a source backup to restore a virtual machine and click Next .

4. The Destination Selection screen is displayed . You can specify configuration changes if necessary . Click Next



5. On the Ready To Complete screen, review and click Restore .

SummaryIn this chapter, we looked at two topics from the test: migrations and backups. Migrations come in several flavors, and backups can be accomplished using VMware’s new backup product, the VMware Data Recovery appliance.

When it comes to migrations, identifying what prerequisites are needed is the first step in ensuring that a particular migration method will succeed. The use cases for each method provide some context when determining which method will work the best for a given situa-tion. Knowing the differences between the three methods will also help you know when to use one over another. Practicing each method will help you understand the processes and situations when any migration is performed.

Backing up virtual machines is an important topic, both for the exam and in the real world. The most important technique to learn when backing up VMs is taking snapshots of VMs. This feature allows the VM to be backed up while it continues to run. This chapter looked at the process for installing the VMware Data Recovery (VDR) appliance and its plug-in for vSphere Client. Although there are many ways to back up virtual machines, using the new VDR appliance is a simple way to back up VMs, both fully and incrementally.

Exam Essentials 405

Exam Essentials

Know how to migrate virtual machines using any of the three methods. Be familiar with the requirements for each migration method, cite use cases for each, and understand and apply that knowledge. Comparing methods is also necessary for a full understanding of when to use one over another. Practice each type of migration: VMotion, Storage VMotion, and cold migration.

Know how to back up and restore virtual machines using the VMware Data Recovery appliance. Practice using snapshots, creating, deleting, and restoring. Practice the installation of the VDR appliance and its plug-in. Know how to create a backup and restore a VM.


Review Questions

1. Which of the following vCenter inventory items cannot be set as a backup object with the VDR appliance?

A. Individual VMs

B. Folders

C. Resource pools

D. DRS/HA clusters

E. Datacenters

2. Which of the following would prevent a successful Storage VMotion?

A. You are attempting to move the VM’s files from a fiber SAN to the ESX server’s local storage.

B. The VM is running Linux as its guest OS.

C. The ESX server is in the 60-day evaluation licensing mode.

D. VMware Tools are being installed on the VM.

3. In which of the following conditions can you not take a snapshot of a VM? (Choose two.)

A. The VM is powered on with a disk in dependent mode.

B. The VM is powered off.

C. The VM is powered on with a disk in independent mode.

D. The VM is suspended.

E. The VM is in template format.

4. Which of the following make compelling arguments in favor of using VMotion to move a VM? (Choose three.)

A. You want to meet service level agreements (SLAs).

B. All of your ESX servers are severely underutilized.

C. A SAN LUN is under heavy load.

D. VMware has released an ESX patch.

E. You want to update VMware Tools in your VMs.

5. You would like to create a backup of the important configuration changes made on an ESXi server. Which of the following would best help accomplish this?

A. Install a supported backup agent in a VM.

B. Install a supported backup agent in the Service Console.

C. Use the vMA appliance to back up the ESXi configuration.

D. Use VMware Consolidated Backup.

E. Use the VMware Data Recovery Manager plug-in.

F. Create a vCenter template.


6. Which of the following are allowed for suspended VMs? (Choose two.)

A. Using VMotion to move to another ESX server

B. Using cold migration to move to another ESX server in the same processor family

C. Using cold migration to move to another ESX server in a different processor family

D. Using Storage VMotion to move the VM’s files

E. Using cold migration to move the VM to a different vCenter datacenter

7. You have just purchased a new SAN to replace your old, aging SAN. Which of the following would be the most efficient way to move running VMs from the old SAN to the new SAN?

A. Storage VMotion

B. Cold migration

C. VMotion

D. SAN LUN replication

E. Manually copying the VM’s files to the new SAN LUN

8. When moving a VM or its files, you must decide whether to use VMotion, Storage VMo-tion, or cold migration. Which of the following considerations would inform your decision? (Choose two.)

A. VM downtime

B. Storage type

C. ESX server CPU speeds

D. Crossing vCenter datacenters

E. Thick- vs. thin-provisioned VM disks

9. What is the maximum number of simultaneous VMotion migrations per host supported in vCenter 4.0?

A. 1

B. 2

C. 5

D. 7

E. 10

10. Which of the following represent potential negative aspects of having a VM in snapshot mode? (Choose two.)

A. Snapshots can prevent VMotion migrations.

B. Snapshots can prevent cold migrations.

C. Snapshots can prevent VCB from backing up a VM.

D. In time, the VM’s disk I/O performance can suffer.

E. A VM with snapshots cannot be cloned.


11. Which of the following would not be helpful in backing up a VM?

A. Install a supported backup agent in the VM.


C. Use the vMA appliance command line to back up the ESXi configuration.

D. Use VMware Consolidated Backup.

E. Use the VMware Data Recovery Manager plug-in.

F. Create a vCenter template.

12. Which of the following is not an option when restoring a VM from a backup made with the VDR appliance?

A. Specifying the datastore to be used for restoration

B. Opting not to restore the VM’s configuration (i.e., customizations stored in the VM’s .vmx file)

C. Choosing whether or not to have the VM’s NIC connected

D. Choosing whether or not to have the VM powered on after the restore

E. Scheduling the restore for a later time to minimize the impact on your virtual infra-structure

13. Which of the following is not possible when taking a snapshot of a virtual machine?

A. Rolling back to a previous memory state

B. Rolling back an individual file to a previous version

C. Rolling back a virtual disk to a previous state

D. Reverting a VM’s settings to a previous state

14. You have purchased the Advanced Edition vSphere license. Which of the following migration technologies can you use to move a VM or its files? (Choose two.)

A. VMotion

B. Storage VMotion

C. Cold migration

D. Template deployment

E. Storage Migration

15. You are having a problem getting a VM to successfully VMotion from one ESX server to another. Which of the following is likely the reason for this?

A. You have not set up a dedicated Gigabit Ethernet VMotion network.

B. Your ESX servers have been configured with the same IP address on the VMotion network.

C. DNS is not properly configured.

D. The router connecting the two ESX servers on the VMotion network is down.

E. You have defined the VMotion network on a standard virtual switch and VMotion requires distributed virtual switches


16. You would like to create a backup of the important configuration changes made on an ESX server. Which of the following would best help accomplish this?

A. Install a supported backup agent in a VM.


C. Use VMware Consolidated Backup.

D. Use the VMware Data Recovery Manager plug-in.

E. Create a vCenter template.

17. The VMware Data Recovery (VDR) appliance has which of the following requirements? (Choose two.)

A. The VDR is a stand-alone appliance and needs no other virtual infrastructure support.

B. vCenter 4.0 and the vSphere Client

C. vCenter 2.0 or greater and the vSphere Client

D. ESX/i 4.0

E. ESX/i 3.5 or greater

18. You have just purchased a new ESX server to replace an old server that has been exhibit-ing intermittent system board failures. The new system is VMotion compatible with the old system, and you would like to move all the running VMs off the old system to the new system with a minimum of disruption. Which of the following would be the best way to accomplish this?

A. Using Storage VMotion

B. Using cold migration

C. Using VMotion

D. Deploying a new VM from template and copying the old VM’s data file to the new VM

E. Backing up and restoring the VM using the VDR appliance

19. Which of the following is not a VMotion requirement for physical ESX hosts? (Choose three.)

A. You cannot be using the ESX server in the 60-day evaluation licensing mode.

B. The storage used for the VM’s files must be presented to all ESX servers that might want to VMotion.

C. All virtual switches used by the VMs must be consistently named across all the ESX servers.

D. Each ESX server must have AMD-V or Intel VT instructions enabled.

E. You must be running ESX 3.0 or later.


20. You are moving a VM’s files and ESX server simultaneously using cold migration. When you work through the Cold Migration wizard, which of the following options are not pre-sented? (Choose two.)

A. Selecting the destination ESX server

B. Selecting the destination datastore

C. Selecting the destination DRS/HA cluster

D. Changing the VM’s disk format from thick to thin

E. Changing the VM’s virtual switch

F. Specifying the VM power-on after the cold migration



1. D. The VDR appliance can be set to back up VMs in a variety of vCenter inventory objects, but DRS/HA clusters are not included in the vCenter inventory objects the VDR appliance will back up.

2. D. Storage VMotion is not supported when VMware Tools are being installed into a VM. Storage VMotion works, in general, with any supported guest OS, with any supported storage, and with the 60-day evaluation license.

3. C, E. You can’t take a snapshot of a VM when it is powered on with a disk in independent mode. It is also not possible to take a snapshot of a VM while it is a template.

4. A, B, D. VMotion, in general, is used to facilitate shifting loads and preparing for mainte-nance activities. Shifting loads can help with things like meeting SLAs and reducing power consumption with severely underutilized ESX servers (via DPM). Finally, installing a patch on an ESX server is an example of using VMotion for maintenance purposes.

5. C. The vMA appliance vicfg-cfgbackup command can both create a backup of an ESXi server’s configuration and restore the configuration. ESXi does not support installed backup agents as it has no Service Console interface. VMware Consolidated Backup and Data Recovery are used to back up and restore VMs, not ESX servers. Finally, templates are VM-only features and so would not work for backing up ESX/ESXi servers.

6. B, D. Suspended VMs must resume on an ESX server in the same CPU compatibility group; therefore, you cannot use cold migration to move a suspended VM to an ESX server in another processor family. VMotion is not supported on suspended VMs. Storage VMotion is allowed on suspended VMs, and suspended VMs can be moved to different datacenters within vCenter.

7. A. Storage VMotion can move a running VM’s files from the old SAN to the new SAN with minimal (essentially zero) disruption to the VM. Cold migration requires the VM be powered off, VMotion only moves the VM’s memory state (and so would not be helpful in moving to a new SAN), SAN LUN replication would not update the VM’s vmdk and other infrastructure files correctly, and you would not be able to manually copy a running VM’s files due to vmdk file locking.

8. A, D. If you have no tolerance for downtime, cold migration is out of the question. In gen-eral, all of the migration technologies don’t care about the storage type but rather the storage location (i.e., shared vs. local). For VMotion, ESX server CPU speeds are not a concern as long as the CPUs on the ESX servers are in the same processor compatibility group. None of the migration technologies listed are impacted by thin vs. thick disk provisioning. Fault tol-erance requires thick-provisioned disks but was not listed in the question.

9. B. VMware supports up to two simultaneous VMotion migrations within a single vCenter instance.

10. C, D. Snapshots are not compatible with VCB because VCB needs to take its own (exclusive) snapshot. Snapshots are not done for disk performance reasons—when the snapshots get large, I/O performance can suffer.


11. C. There are several methods that are helpful in backing up a VM. Notably, with respect to backup functionality, the vMA appliance is generally only used for backing up an ESXi server’s, not a VM’s, configuration.

12. E. The VDR restore wizard has no provision for scheduling restoration.

13. B. Snapshots capture a VM’s disk state, settings, and (optionally) memory state. The granularity of the disk delta does not include the ability to roll back to previous versions of files if the files are repeatedly changed.

14. A, C. Advanced Edition licensing supports both VMotion and cold migration. Storage VMotion requires Enterprise Edition or Enterprise Plus Edition licensing. Template deploy-ment is not considered a method of moving a VM or its files, and VMware has no technol-ogy known as “Storage Migration.”

15. B. VMotion, although requiring a Gigabit Ethernet network, does not require a dedicated Gigabit Ethernet network. Each ESX server on the VMotion network must have a unique IP address, and they must be numbered on the same subnet. VMotion does not require DNS, but in general, your life will be a lot easier if you have DNS fully configured for your ESX/vCenter environment. As VMotion is currently supported only on a single network, a router connect-ing VMotion networks would be moot, and the VMotion virtual switch works equally well whether the switch is a standard or a distributed one.

16. B. As ESX servers still have a Service Console for management, a backup agent can be installed in the Service Console, facilitating backing up of either the entire Service Console (which includes all the ESX configuration files) or any set of important files you desire. VMware Consolidated Backup and Data Recovery are used to back up and restore VMs, not ESX servers. Finally, templates are VM-only features and so would not work for back-ing up ESX/ESXi servers.

17. B, D. The VDR appliance requires vCenter 4.0 and ESX/i 4.0 or later.

18. C. VMotion can be performed while the VM is running with no disruption to running applications. Cold migration (although it would work in this case) requires the VM first be powered off, generally a less than ideal solution. Storage VMotion, in this case, would not be helpful as the VM’s files would not necessarily need to be moved. Deploying from tem-plate and performing a backup/restore, although theoretically possible, would be much less efficient than using VMotion.

19. A, D, E. The 60-day evaluation licenses are fully functional, including VMotion. All ESX servers must see the storage used by the VMs being VMotioned. The virtual switch naming requirement only applies to virtual switches with outbound adapters (VMs with internal-only switches cannot be VMotioned). The AMD-V and Intel VT instructions are a require-ment of Enhanced VMotion Compatibility (EVC) and not VMotion itself. Finally, VMotion precedes ESX 3.x and is—for VMware—a mature technology.

20. E, F. When simultaneously changing ESX server and storage via cold migration, you can specify (obviously) the destination ESX server and VM datastore. You can also specify a destination DRS/HA cluster and disk format change (from thin to thick or vice versa). No form of migration allows you to change the VM’s virtual switch or have the VM power on after the migration has completed.

Chapter

8Managing and Creating VMware Clusters


Create and Configure VMware Clusters.NÛ

Create new cluster .NN

Add ESX/ESXi hosts to a cluster .NN

Configure High Availability basic/advanced settings .NN

Enable/Configure VM Monitoring .NN

Configure Distributed Resource Scheduler basic/advanced NN

settings .

Configure Distributed Power Management .NN

Configure Enhanced VMotion Compatibility .NN

Configure swap file location .NN

Analyze HA host failure capacity requirements .NN

Analyze HA admission control .NN

Determine use cases for DRS automation levels and migra-NN

tion thresholds .

Determine use cases for DPM policies .NN

Enable a Fault Tolerant Virtual Machine.NÛ

Identify FT restrictions .NN

Evaluate FT use cases .NN

Set up an FT network .NN

Verify requirements of operating environment .NN

Enable FT for a virtual machine .NN

Test an FT configuration .NN

Upgrade ESX hosts containing FT virtual machines .NN

Create and Configure Resource Pools.NÛ

Determine Resource Pool requirements for a given situation .NN

Evaluate appropriate shares, reservations, and limits in a NN

given situation .

Evaluate virtual machines for a given Resource Pool .NN

Create Resource Pools .NN

Set CPU resource shares/reservations/limits .NN

Set memory resource shares/reservations/limits .NN

Define Expandable Reservation .NN

Add virtual machines to pool .NN

Describe resource pool hierarchy .NN

This chapter investigates all aspects of VMware clusters that are covered in the VCP-410 exam. We’ll describe the basics and prerequisites for VMware clusters and show you how to

create a cluster. We’ll also dive into the topic of VMware High Availability (also called VMware HA). We’ll also introduce you to a new feature, VM Monitoring, which lets you manage the restart of failed or unresponsive virtual machines.

Distributed Resource Scheduler, which leverages VMotion to distribute the load of virtual machines throughout the ESX hosts in a cluster, is the next topic. We’ll examine how to activate DRS and manage several important aspects of DRS behavior. We’ll then explore Distributed Power Management (DPM) and discuss its configuration and man-agement as well as hardware and physical infrastructure requirements.

Another feature of a DRS cluster, Enhanced VMotion Compatibility, allows VMotion between ESX hosts powered by different processors. We’ll discuss the advantages and limitations of this feature. Next, we’ll discuss the virtual machine’s VMkernel swap file location and how to manage it through the cluster. We’ll then explore the purpose, con-figuration, and functionality of VMware Fault Tolerance.

Finally, we’ll focus on resources pools, one of the most versatile inventory objects in VMware inventory.

Creating and Configuring VMware ClustersThe majority of advanced management features that separate VMware from other virtual-ization products are activated and managed in the VMware cluster. vCenter (the component formerly known as Virtual Center) is a prerequisite; in order to have a VMware cluster, the environment must consist of a vCenter server (either physical or virtual) and at least two ESX hosts.

This section covers 12 subobjectives:

Creating a new clusterNN

Adding ESX/ESXi hosts to a clusterNN

Configuring High Availability basic/advanced settingsNN

Enabling/configuring VM monitoringNN

Configuring Distributed Resource Scheduler basic/advanced settingsNN

416 Chapter 8 N Managing and Creating VMware Clusters

Configuring Distributed Power ManagementNN

Configuring Enhanced VMotion CompatibilityNN

Configuring swap file locationNN

Analyzing HA host failure capacity requirementsNN

Analyzing HA admission controlNN

Determining use cases for DRS automation levels and migration thresholdsNN

Determining use cases for DPM policiesNN

Creating a New ClusterAs discussed in Chapter 4, “Installing and Configuring vCenter Server,” vCenter’s inventory is extensive and presents many more objects than a standalone ESX host. The Datacenter object is a prerequisite for the cluster: a cluster may only be created under a datacenter in your vCenter inventory.

The creation of a cluster is a simple process. Right-click on the to-be cluster’s parent object (either a datacenter or a folder within a datacenter) and from the drop-down menu, select New Cluster (see Figure 8.1). The wizard will prompt you for a name. As always, it is a best practice to keep the names of inventory objects simple by avoiding the use of punc-tuation or special, nonstandard alphanumeric characters.

F I GU R E 8 .1 Creating a cluster

Once the cluster has been created, it will appear alongside and at the same indentation of all other objects in the vCenter inventory (resource pools or ESX hosts). Although a cluster object has been created, it does not contain anything yet.

It is important to understand that once ESX hosts are added to a cluster, they are no longer considered standalone entities running their own VMs. Once members of a cluster, all ESX host CPU and memory resources are added to the collective cluster resources. VMs no longer appear on their individual ESX hosts. Rather, they all appear as members of the cluster. This is best understood by comparing Figures 8.2 and 8.3.

Creating and Configuring VMware Clusters 417

F I GU R E 8 . 2 Two ESX hosts, each with its own VMs prior to being absorbed into a cluster

F I GU R E 8 . 3 The cluster with both ESX hosts and all VMs, organized collectively

The inventory will now present all VMs as members of the cluster. Which actual ESX host the VM runs on is not important, especially because this can change as DRS will leverage VMotion to move the VMs around within the cluster as it load-balances CPU and memory consumption across all the ESX hosts in the cluster.

It is easy to see which ESX host VMs happen to be on at any given moment: first, the cluster must be selected by clicking on it in the inventory. As with all objects, once selected in the inventory, the tabs in the right frame of the vSphere Client will provide options relative to the selected object. In this case, locate the tab Virtual Machines and click it. A list of all VMs in the cluster will be displayed, and one of the sort columns will indicate the ESX host on which any given VM is running (see Figure 8.4).


F I GU R E 8 . 4 Virtual machines in a cluster

Adding ESX/ESXi Hosts to a ClusterThe process of adding an ESX host to a cluster could not be simpler: in the vSphere Client, select Hosts And Clusters in order to display the vCenter inventory, left-click on an ESX host to select it, and then drag and drop the host onto the cluster object (see Figure 8.5).

F I GU R E 8 .5 Grafting vs . importing an ESX host into a cluster

vCenter will ask:If the ESX server and its virtual machines are to be imported into the cluster and all

resource pool configurations are to be dropped—this is the default option and best practice.If the ESX host should be grafted into the cluster. If you choose this option, a new

resource pool is created. When “grafting” is chosen, the standalone ESX host’s resource pools will be preserved as nested resource pools under the new “grafted from name of ESXhost” resource pool.

Grafting can be a useful tool. For example, suppose a standalone ESX host is to be integrated into a cluster while performance-related service level agreements (SLAs) are pre-served. This new grafted resource pool can be assigned a reservation or shares to achieve a variety of performance guarantees to satisfy the SLA while also affording the VMs all the benefits of being in a cluster, which are discussed in this chapter. It is, therefore, a way to achieve the best of both worlds.


Removing ESX hosts from a cluster is not as quickly accomplished. Now that the VMs are members of the cluster and no longer belong to any specific ESX host, the goal of the cluster is to keep VMs running at all costs. Therefore, in order to extract an ESX host from a cluster, the VMs must be cleared off the target host. This can be done manually or by leveraging Maintenance Mode. In either case, the hosts must have no VMs running or they cannot be gracefully extracted from a cluster. VMs must either be VMotioned off the host or shut down. To remove a host with its own VMs, those VMs must be powered off as the ESX host is removed from the cluster. Optionally, VMs can be storage-VMotioned to an ESX host’s local storage to ensure the cluster doesn’t move the VMs to another ESX host in the cluster.

In Exercise 8.1, we will walk through the steps of creating a cluster.


Creating a Cluster

1. In your vCenter inventory, configure two ESX hosts, each with several resource pools and VMs .

2. Create a new cluster by right-clicking a datacenter or a folder within a datacenter and selecting New Cluster . Give it the name of your choosing .

3. Next, we’re going to introduce ESX hosts into the cluster as directed:

For the first host, accept the default recommendation to drop resource configura-NN

tions and introduce the host and all its VMs into the cluster .

For the second host, graft the ESX host into the cluster .NN

4. Notice how the VMs from the first ESX host are now part of the cluster and appro-priately indented in the inventory . Also, notice how a resource pool, called Grafted, was created from the second host . Essentially, an SLA was created, equal in capacity to the second ESX host, and the resource pools from that standalone ESX host are now child pools in the grafted pool . Additionally, the entire organization of VMs and resource pools has been preserved in the grafted resource pool .

Configuring High Availability Basic/Advanced SettingsIn the IT industry, uptime is a metric used to describe the percentage of time that services are available over a given period. For example, Google’s Gmail service, although free, has a professional paid option that guarantees 99.9 percent uptime per year. While this seems very good, this guarantee allows for as much as 0.1 percent downtime per year, which is 8 hours, 45 minutes, and 20 seconds. Although this is a very small amount of time on a yearly scale, it can potentially be an eternity spent waiting for a critical email during an outage.


This is just an example and in no way is intended to comment on Gmail’s reliability .

The goal of VMware’s virtual infrastructure is to leverage VMware software and its management of the physical hardware infrastructure to improve virtual machine uptime. Initially, VMotion was introduced with ESX2 and allowed you to migrate virtual machines away from a host preemptively, before scheduled or anticipated outages. However, it wasn’t until ESX3 that a virtual infrastructure could react to an outage with the introduction of VMware High Availability (HA). VMware HA will restart VMs should an ESX host fail and take down the VMs it was running. The cause of the physical host failure is irrelevant to HA’s behavior and, therefore, can result from any of the following: hardware failure, loss of SAN or network connectivity, and power failure, among other causes.

HA is a licensed, distributed feature in a vCenter cluster. In the following sections, we will:

List the HA prerequisitesNN

Discuss HA heartbeatsNN

See how host isolation response worksNN

Explain why you sometimes see that network redundancy nag-screenNN

Look at the cluster-wide settingsNN

Show you how to activate HANN

VMware defines distributed features or services as HA, VMotion, DRS, and DPM .

HA PrerequisitesThere are two fundamental prerequisites in order to guarantee HA’s functionality:

First, all VMs must be able to boot on every ESX host. This implies a few con-NN

figuration details: VM files must be on shared storage, which must be configured, accessible, and read/writable on every ESX host. All ESX host networking must be configured identically so that services running in VMs will be accessible regardless of the ESX host on which the VM ends up running. It is impossible to test HA without disruption; however, it is easy to verify that all VMs can be VMotioned. Since the standard for VMotion is much more stringent than that of HA, VMotion (if avail-able) should be used preemptively as a test to verify the “HA recoverability” of every virtual machine. If the virtual machine can successfully VMotion, the HA standards for configuration have been surpassed.

Second, all ESX hosts must have some spare and unused capacity, reserved for the NN

eventual need to restart VMs.


HA HeartbeatsWhen setting up an HA cluster, one of the first questions asked in the real world is: Can vCenter be a virtual machine? vCenter does not manage the restart of VMs. vCenter will only implement the HA configuration within the cluster. ESX hosts manage the restart of VMs autonomously. So yes, vCenter can be a VM because once HA is configured, it does not need vCenter.

Each ESX and ESXi host will send and receive heartbeats over the management network. For ESX, the Service Console port is used for heartbeats. For ESXi, the VMkernel ports used for management are used for heartbeats.

In vSphere4, the default heartbeat timeout for HA is 12 seconds, which is a compromise between reacting as quickly as possible to failures without being so aggressive as to cause false positives. You can adjust the heartbeat timeout based on your needs and the perfor-mance of your environment.

Host Isolation ResponseIn an HA cluster, ESX hosts exchange heartbeats along the management and Service Console network. When an ESX host loses contact with the management network, it will become isolated from its peers, which will in turn see that host as having failed. Let’s assume a cluster of three hosts: A, B, and C. If host A has lost contact with the management network, hosts B and C will assume that host A has crashed, and they will attempt to start host A’s VMs, unsuccessfully. As long as host A is still running these VMs, it will maintain file locks on the VM’s constituent files, thereby preempting any other host’s attempt to take ownership of the virtual machines.

By definition, the host isolation response is when this situation occurs, and once a host is isolated from its peers, it shuts off its VMs so that its peers in the HA cluster will succeed in their attempt to take control of and boot the VMs.

Clearly, it is also possible for an ESX host to become isolated from its peers along the management/heartbeat network without suffering a critical failure or even a failure that would disrupt operational VMs. Therefore, other ESX hosts in an HA cluster may not restart VMs until the ESX host they’re running on elects to shut them down.

Invariably, host isolation is caused by a failure on the management network, switch port, or ESX host NICs. What if the VMs are still operational and providing services to their data networks in the midst of a management network outage? The default host isola-tion response will still occur: the disconnected ESX host will proactively shut down its VMs in anticipation of its peers rebooting these VMs. This will cause an interruption in VM services because the host isolation response is determined solely by heartbeats and connectivity along the management network, regardless of VM connectivity to or activity on any other network.

This host isolation response can be particularly dangerous in the event of a network switch failure. All ESX hosts could potentially shut down their VMs in the anticipation that their peers will be restarting VMs.


There are two confi gurable failsafe measures:

Configure the cluster-wide host isolation response to leave VMs powered on.NN

Configure a redundant heartbeat network.NN

Heartbeat Network RedundancyHeartbeat network redundancy can exist either in the physical network or the virtual network. For physical network redundancy, a team of two NICs, working with multiple physical switches, will provide management and heartbeat network redundancy.

If there is no redundancy in the physical management network, heartbeat network redundancy can be confi gured by adding a Service Console port to another network, such as the VMotion network.

If there are two Service Console ports (preferably on separate IP subnets), when HA is activated a new fi le is created: /etc/HA_HOSTS. This fi le contains the IP information of each ESX host in the HA cluster. Since there will be two IP addresses for each ESX host, there will effectively be round-robin resolution for each ESX host. In essence, if contact is lost with a host along the management network, its peers will look for it on a secondary network.

The ESX Service Console port (or in ESXi, the VMkernel enabled for manage-ment) is the entry point into an ESX host, and as such it must be protected . It is for this reason that the management network should be isolated and that ports for a redundant heartbeat network, if configured, be placed on another isolated network without routes—for example, the VMotion network . As a security precaution, it is imperative that the VM’s data networks not be used for management or for network redundancy . In other words, never place a Service Console port on the same network as VMs . Doing so could poten-tially expose the ESX host’s administrative interface to a hostile network .

From the vCenter perspective, if we lose contact with a host on the management network but that host has network redundancy, the host and its VMs will be gray and italicized and indicate Disconnected; however, the VMs will continue running and will not fail over (see Figure 8.6).

F I GU R E 8 .6 Network redundancy allows an ESX host to not enter Isolation mode even if heartbeats are lost on the management network .


Cluster-Wide SettingsThere are two cluster-wide settings:

The host isolation response can be left at the default (to power off VMs if an ESX host NN

becomes isolated), or VMs can be left on. Before ESX 3.5 and Virtual Center 2.5, each VM had to be configured. Obviously in the enterprise, this can be a daunting task. The introduction of a cluster-wide setting makes it possible to reconfigure the behavior of all VMs with a single administrative action.

The Restart Priority setting can be configured cluster-wide or on a per-VM basis. NN

Arguably, being able to differentiate between high-, medium-, and low-priority VMs is more of a per-VM configuration rather than a cluster-wide setting. If you decide to override the default admission control behavior, we recommend that you configure VM restart priorities. Doing so will restart VMs in order of importance, thereby ensuring that the highest-priority VMs don’t fail to start due to insufficient host capacity. An additional option is to simply leave a VM powered off: should the VM be lost due to an ESX host outage, simply leave it off, thus leaving the capacity for other VMs.

Activating HATo activate HA, in the vSphere Client, right-click on the cluster and select Edit Settings. The Cluster Settings window will present two check boxes: one to activate DRS and the other to activate HA. Once the HA check box is selected, several additional options to manage HA’s behavior become available.

Figure 8.7 shows the initial cluster settings screen for HA and DRS check boxes.

F I GU R E 8 .7 Initial Cluster settings screen


Once HA has been enabled, select VMware HA for the HA confi guration screen (see Figure 8.8).

F I GU R E 8 . 8 VMware HA settings

HA detects ESX host failures by leveraging heartbeats along the management network. Deselect the Enable Host Monitoring check box if you plan any network maintenance or interruptions in connectivity; doing so will avoid false positives (the erroneous detection of an ESX host failure and subsequent attempts to restart virtual machines that are already running).

We will discuss heartbeat network redundancy later in this section .

Enabling and Configuring VM MonitoringThe ability for HA to monitor VMs is a new HA feature with vSphere 4. This feature is dependent on having HA licensed and activated. This feature is enabled alongside HA’s cluster features. VM Monitoring allows vCenter to reboot a VM that has frozen or become unrespon-sive. Once you activate HA, you can control how aggressively a VM will be rebooted, either with default settings or with custom settings governing the following options (see Figure 8.9):

Failure Interval How long a VM is nonresponsive before being rebooted

Minimum Uptime The minimum amount of time before HA can force a nonresponsive VM to reboot


Maximum Per-VM Resets The maximum number of times a VM can be reset. This value can be absolute or it can be customized to apply over x number of hours.

Additionally, VMware Tools running inside the VM is a required component, and this feature can be disabled on a per-VM basis. Figure 8.9 shows the monitoring option with VMware Tools in the VM.

F I GU R E 8 . 9 VM Monitoring administration screen

Configuring Distributed Resource Scheduler Basic and Advanced SettingsA fundamental prerequisite for VMware’s Distributed Resource Scheduler (DRS) is VMotion, which must be configured and operational before DRS can work properly. The goal of DRS is to evenly distribute VMs and their workload across all nodes in a VMware cluster. vCenter monitors all VMs and ESX hosts by polling performance data every 20 seconds and record-ing these metrics in the vCenter database. That way, vCenter and the DRS function will always have an up-to-date tally of the resources being consumed and the workload through-out the cluster.

DRS applies logic in two areas: initial VM placement and dynamic balancing. An automation level will determine which forms of logic are applied without administrative intervention and which tasks will wait for an administrator.

Figure 8.10 displays the DRS automation screen from within Edit Cluster Settings.

Initial VM PlacementWith multiple ESX hosts in a cluster, when powering on a VM, which host should be used? Under partially and fully automated settings, DRS will automatically determine which host will be used to power on a VM. Only with the manual setting will DRS recommend and wait for the administrator to designate which host will be used to power on a VM.


F I GU R E 8 .10 The DRS automation screen

Dynamic BalancingAlso known as VMotion, dynamic balancing is managed by the DRS cluster. In manual and partially automated settings, DRS will not move a VM without administrator approval. With Fully Automated settings, DRS will automatically VMotion VMs as it sees fit in order to balance the workload across all ESX hosts in a cluster.

Migration ThresholdThe Migration Threshold setting can be called DRS’s propensity for engaging in VMotion activities. There are a total of five settings ranging from Aggressive to Conservative; the default is the third, middle setting. This default setting is evenly split between both aggressive and conservative extremes.

With the most aggressive setting, DRS will attempt to VMotion by redistributing VMs throughout the DRS cluster immediately when the slightest imbalance occurs. With the most conservative setting, DRS will not VMotion a VM until a significant imbalance occurs. In order for vCenter to engage in a VMotion, there will be a need to resolve CPU or memory resource constraints within a VM. Both the degree of the resource constraint and the extent of the resource imbalance in the cluster are explained in the form of migra-tion recommendations.

To see this feature in vSphere 4 (vCenter combined with ESX(i) 4.0), click on the cluster in your vCenter inventory and select the DRS tab (see Figure 8.11). Migration recommenda-tions will appear when an imbalance has been calculated.


F I GU R E 8 .11 The DRS Recommendations tab

DRS provides recommendations based on priority levels. A priority 5 level recommenda-tion indicates a very low recommendation to VMotion and would trigger with the most aggressive Migration Threshold setting (with the slider all the way to the right). A priority 1 recommendation indicates a severe VMotion recommendation and will trigger a VMotion even with the most conservative Migration Threshold setting (with the slider all the way to the left).

VMware recommends that a new environment use the default setting and that Migration Threshold be tuned based on the environment: an average low-utilization environment can be configured to VMotion aggressively; however, an environment that sustains an elevated level of utilization should be more conservative. From a resource consumption perspective, VMotion is not free. In fact, it is quite costly: memory manipulation, the VMotion network, and CPU will all see a surge in activity to accomplish the time-critical task of migrating a virtual machine from one host to another. While the goal of DRS is to reduce resource contention between VMs and balance the load across ESX hosts, we also do not want to aggravate a contentious situation without actually improving on the status quo. There is no generic recommendation here: all environments are unique, and each must be tuned in such a manner as to balance the need to move VMs around with doing so in a manner where the task itself won’t negatively impact the environment.

Configuring Distributed Power ManagementAlso a feature managed in a DRS cluster, Distributed Power Management (DPM) will leverage vCenter’s knowledge of host and VM performance metrics to determine if utili-zation decreases to the point where it can leverage VMotion to migrate all VMs to fewer hosts than normal and then throttle down physical hosts, putting them into standby mode. The goal is to conserve electricity during off-peak hours by “powering down” idle server capacity. Figure 8.12 shows the DPM administration screen.

The premise behind DPM is that an idle server will consume as much as 60 percent of the electricity it will consume during peak utilization. In environments that see little utili-zation outside of business hours, enabling this feature can conserve a significant amount of power and ultimately save a lot of money.


F I GU R E 8 .12 DPM administration screen

DPM has the following policies:

Prior to VMotioning VMs off a host so that DPM may power down a host, DPM will NN

look at a 40-minute performance history average.

Prior to powering on a host and redistributing VMs onto this new host, DPM will NN

consider a 5-minute history, during which the load will indicate that the added capacity is needed.

DPM targets a 63 percent utilization. In other words, the average overall load on the NN

ESX hosts in a DPM enabled cluster will be 63 percent. If this average load is much lower, ESX hosts may be powered down; if the average load is significantly higher, ESX hosts may be powered up to take some of the work from other hosts.

DRS and VMotion are prerequisites for DPM to work.NN

DPM can also leverage Intelligent Platform Management Interface (IPMI), Integrated NN

Lights-Out (iLO), and Wake-on-LAN (WOL) protocols to manage the cycling of hosts.

Configuring Enhanced VMotion CompatibilityTo properly explain Enhanced VMotion Compatibility (EVC), it is important to under-stand certain limitations with setting up VMotion. When a VM boots up, it will enumer-ate all available CPU instructions. Therefore, when a VM is migrated from one ESX host to another, ESX must present the same CPU instructions to the VM regardless of the ESX host to which the VM is migrated. The difficulty arises when hardware is bought several months or even years apart and CPUs may have slight variations despite being the same


brand and family. If there is any difference, no matter how trivial, by default VMotion will not be possible between these now dissimilar hosts. There has long been an advanced feature where an administrator could “mask out” CPU instructions on a per-VM basis. Starting with ESX 3.5 Update 2, EVC automates the masking out of dissimilar instructions as a cluster feature.

Simply create a cluster, enable EVC, and introduce ESX hosts into the cluster by drag-ging and dropping them onto the cluster icon.

Note that the hosts cannot have running VMs during this task .

EVC will scan the available CPU instructions in each host and fi nd a common baseline. Subsequently, EVC will mask out all nonuniversal CPU instructions, after which time VMs may be powered on in the cluster. Should a host be too dissimilar, it will be rejected from the EVC enabled cluster.

Guest Operating Systems must respect the CPUID method of instruction masking to ensure EVC compatibility . Failure to respect this standard for host CPU enumeration can result in VMs configuring themselves for CPU instructions outside the established EVC baseline . This would likely result in the VM crashing once VMotioned to another host .

The EVC requirements include:

ESX host CPUs must be either AMD (Opteron Generation 1, RevE or newer) or Intel NN

processors (Core 2 generation or later).

ESX hosts must be version 3.5 Update 2 or later.NN

ESX hosts must be managed by a vCenter server.NN

ESX host processors must have VT (Intel) or AMD-V (AMD) enabled.NN

Memory execution prevention (a BIOS feature) must be engaged.NN

Guest Operating Systems must respect the CPUID method for processor instruction NN

masking.

Configuring Swap File LocationIn Chapter 5, “Deploying and Managing Virtual Machines and vApps,” one of the top-ics discussed was the ability to edit VM settings. Specifi cally, we discussed the VMkernel swap fi le (VSWP), which is by default in the same directory as the rest of the VM’s fi les. In the interest of best managing storage, you may choose to move fi les around; for example, if a VM is located on a datastore backed by a very high-performance SAN, there is usually a higher associated cost per gigabyte than for regular storage. Rather than waste countless gigabytes of expensive/ high-performance storage with (hopefully unused) swap fi les, you


can elect to place the VMkernel swap file on local storage. That way, the VM’s files will reside on the presumably more expensive shared datastores, backed by SAN, and the VM’s VSWP swap file will reside on local (and presumably less expensive) storage. Figure 8.13 shows swap file management at the VM level by editing the settings of the VM and choosing the Options tab.

F I GU R E 8 .13 SWAP file management from the VM

In Chapter 5, you also saw how moving this VMkernel swap file to local storage can be managed by modifying the VM’s settings. However, doing so will anchor the VM to that ESX host. Remember one of the fundamental requirements for VMotion: all files must be visible to all ESX hosts (i.e., on shared storage); otherwise the VM cannot be VMotioned. In this case, moving the VSWP file by editing the VM’s setting will break a fundamental VMotion dependency. However, the location of VM swap files can be managed through the DRS cluster settings. When swap file management is controlled by the cluster, the VM can still be VMotioned. Figure 8.14 shows the swap file management from the DRS cluster level.

F I GU R E 8 .14 Swap file management from the DRS cluster

As part of the VMotion operation, the cluster will migrate the swap file from the source to the destination ESX host in addition to migrating the running VM. This will signifi-cantly increase the time it takes for VMotion to complete as the default VSWP size is equal to the provisioned memory for the VM, thereby potentially doubling the amount of data to be migrated over the VMotion network and VMkernel ports.


Analyzing HA Host Failure Capacity RequirementsThe maximum host failover capacity is four. This is dictated by the fact that there are a maximum of five primary hosts in an HA cluster. Although a VMware cluster can have a maximum of 32 hosts, VMware HA operates with combinations of primaries and secondar-ies. It is the primaries that keep an inventory of which VMs are on which ESX hosts as well as manage heartbeats. Primaries manage the restart of VMs, and if a primary host fails, only another primary can promote a secondary host to become a primary.

The maximum of five primaries in a cluster is in place because more primaries would logarithmically increase the network utilization to a potentially unsustainable level. It is also for this reason that HA can’t support more than four hosts’ failover capacity.

Host failover capacity can be managed with an absolute percentage of total cluster capacity (configured by the administrator), or an entire ESX host can be dedicated to the task of being a hot standby. Lastly, the de facto size of a VM can be managed. Much like commercial aviation calculates the weight of an aircraft and an average weight for passen-gers is used, some will be lighter and some will be heavier. Here, VMware does the same with its Slot Size setting, which determines the average memory and CPU capacity of a VM. This can be modified in Advanced HA settings.

Say we have three hosts: A, B, and C. If Host Failover Capacity is set to one host, this means that the cluster must be able to accommodate the loss of a single ESX host. As a result, Admission Control (backed by vCenter’s performance metrics) will limit the entire cluster load to two thirds (or 66 percent). Each ESX host will be used at two-thirds of its capacity so that if host A crashes we will be able to recover its VMs on hosts B and C, each of whom has one-third spare capacity.

Given 10 hosts, if Host Failover Capacity is set to one host, each ESX host will be limited to 90 percent of its capacity. Should a single host running at 90 percent capacity fail, there will be 9 hosts, each with 10 percent available, on which to restart these VMs.

Analyzing HA Admission ControlThe default setting leverages Admission Control to maintain enough unused capacity on each ESX host in a cluster in order to guarantee that, should any single host fail and take down its VMs, the other hosts will have enough unused capacity to run those VMs. Admission Control will look at the required resources to run a VM and also look at the available resources in a resource pool or on a host. If there are not enough available resources, the VM will not be started. In the case of HA, the administrator will specify how much failover capacity the HA cluster should have. vCenter will enforce the required amount of unused capacity.

The default setting is for Admission Control to enforce ESX host CPU and memory availability and not to allow the powering on of VMs if doing so would compromise the ability for HA to start VMs lost during a physical ESX host failure. This feature should be disabled only as an “executive decision,” where the VMware infrastructure administrator is assuming responsibility for host capacity availability. In this circumstance, the administra-tor must ensure there is enough CPU and memory capacity for all VMs to power on in the event of infrastructure (ESX host) failure.


Regardless of which host failover capacity method is employed, the Cluster Summary tab will display the actual cluster usage as well as failover capacity.

In Exercise 8.2, we will test HA.

E X E R C I S E 8 . 2

Testing high Availability

Before you begin this exercise, please set up two ESX hosts, each with a few VMs . Also set up a vCenter server and introduce your ESX hosts into the vCenter inventory .

1. Set up an HA cluster with the two ESX hosts:

a. Create a cluster .

b. Introduce your ESX hosts into the cluster by dragging and dropping them into the cluster .

c. Power on all VMs .

d. Edit the cluster’s settings, and check the box to activate HA . Observe the prog-ress meter at the base of your vSphere Client and notice the steps taken by vCenter to activate HA: from opening firewall ports to activating the HA agent on each ESX host .

2. Once HA has been properly activated, in your vCenter inventory, select your cluster, and then select the Virtual Machines tab . Locate your vCenter server (if it’s a VM and not a physical machine) and take note of which ESX host vCenter is on .

3. Next, manually power down the ESX host that is not currently running your vCenter .

4. Observe what happens in the vSphere Client:

The powered-down host appears gray and italicized, as do the VMs that were run-NN

ning on that host .

Moments after, the VMs change from gray, italicized to black as they are powered on .NN

VMs that are not on shared storage will not be restarted as the remaining host will NN

not “see” or be able to assume control of these VMs .

VMs that were powered off at the time of an HA event will not be powered on as NN

part of the recovery .

5. Power on the ESX host that was turned off .

6. Once the power-cycled ESX host boots up and is recognized by vCenter, if you have DRS enabled and fully automated (explained later in this chapter), you might see your VMs migrate, if there is a sufficient workload among the VMs .

7. The ESX host running vCenter can be power-cycled as well; however, your vSphere Client will be disconnected, and you won’t be able to observe the stages of recovery . But vCenter will be recovered by HA as the restart of VMs is managed by HA primaries within the ESX host infrastructure and not by vCenter . It is for this reason that vCenter can be virtualized .


Determining Use Cases for DRS Automation Levels and Migration ThresholdsDRS provides three levels of automation. The first, the Manual mode of operation, will only provide recommendations for where a VM should be powered on and where to VMotion a VM if the cluster has an imbalance. The second, Partially Automated, will automatically calculate the best host that a VM should be powered on, but will not VMotion the VM if the cluster has an imbalance. The last level, Fully Automated, will calculate where a VM should be powered on and VMotion the VM if the cluster has an imbalance without any input from the administrator. DRS will not provide recommen-dations in Fully Automated mode.

Use cases for each depends on your comfort level and the types of VMs and applications that are running in the cluster. In some cases, you want to control the number of VMotions in the cluster or where VMs are placed. In this context, Manual mode works best as it does not provide any automation and allows you to make all the decisions regarding VM placement and load balancing. There are two drawbacks to using Manual mode. First, the power-on of a VM will require you to specify which ESX host to use. Second, you will have to monitor for recommendations and apply them to load-balance the cluster.

In some cases, you will use Partially Automated so that as new VMs are added and powered on, DRS will automatically place the VM on the appropriate host, based on which host has the least load. This mode will not use VMotion to move VMs to achieve load bal-ance. It will provide recommendations to you, but you can choose to ignore or apply those recommendations. The biggest drawback to using Partially Automated is that you will have to monitor the recommendations and apply them to load-balance the cluster.

The last automation level, Fully Automated, will allow DRS to make all the decisions as they relate to where a VM is powered on or for moving VMs to other hosts to achieve load balancing. You will not receive recommendations. When you are using this automation level, the interface provides a slider for adjusting how aggressive or conservative the DRS cluster will be in load balancing. There are five positions for the slider, with all the way to the right being fully aggressive and all the way to the left being the most conservative. Each position represents a calculation of imbalance based on a standard deviation. See Chapter 10, “Performing Basic Troubleshooting,” for more information on the calculation used for load balancing. If too many migrations occur within a certain timeframe, move the slider to the left for a more conservative setting. Figure 8.15 shows the slider and the default posi-tion: in the middle.

F I GU R E 8 .15 DRS’s Migration Threshold slider


Each position of the slider represents a priority level. All the way to the left is a pri-ority level of 1, representing the highest recommendation and, therefore, the greatest calculated level of CPU and memory imbalance or the breaking of a cluster affinity or anti-affinity rule. The middle position represents a priority level of 3. The far-right posi-tion is a priority level of 5, or not much calculated imbalance, and is the most aggres-sive setting. You will have to decide what you are comfortable with when choosing how aggressive you want DRS to be in achieving load balance in the cluster. Each VMotion represents some cost in resources to move a VM to another host. The more VMotions that occur, say in an hour’s timeframe, the more resources are used to just move VMs around the cluster.

Determining Use Cases for DPM PoliciesSimilar to DRS, DPM uses automation levels to reduce the amount of interaction by the administrator if that is what is wanted. There are three modes of automation for DPM: Off, Manual, and Automatic. Using the Off mode won’t allow DPM to put any host into Standby mode, nor will it calculate recommendations. Manual mode will provide recommendations based on the loads it has calculated. If the cluster’s overall load drops below the need to have all ESX hosts powered on, it will recommend that a host be put in Standby mode or powered off. Automatic mode will allow DPM to calculate cluster load and automatically put ESX hosts into Standby mode. It will also power ESX hosts back on as the load in the cluster increases beyond a predetermined percentage: 63 percent utilization.

If the customer does not wish to use DPM, the Off mode should be used. The drawback in this situation is that many times the overall load in a cluster will fall significantly, thereby reducing the need to have all ESX hosts powered on and wasting power and increasing electric utility usage and costs.

If you use Manual mode, recommendations will be calculated and presented. It will be up to you to apply those recommendations to power off (Standby) or power on an ESX host. The largest drawback to this approach is that you will have to monitor for the recommendations. In many cases, these recommendations will be in the evening when the load drops the most or early in the morning when no one is around to apply them.

When you use Automatic mode, DPM will calculate overall CPU and memory load in the cluster. If all the VMs can be moved to fewer hosts, completely evacuating a host or hosts, those empty hosts will automatically be put in Standby mode (powered off). A slider is provided to give you some control as to how aggressive DPM should be when consolidat-ing VMs onto fewer hosts. Moving the slider all the way to the right will allow for higher CPU and memory utilization rates on the remaining powered-on ESX hosts. Moving the slider to the left allows each remaining powered-on ESX host to have more CPU and mem-ory spare capacity, and, therefore, more hosts will remain powered on. Figure 8.16 shows the DPM Threshold slider.

Enabling a Fault-Tolerant Virtual Machine 435

F I GU R E 8 .16 DPM Threshold slider

Enabling a Fault-Tolerant Virtual MachineThe main purpose of VMware’s Fault Tolerance (FT) feature is to provide application and operating system failover for virtual machines. Fundamentally, VMware Fault Tolerance is an alternative to using Active/Standby clusters in the operating systems of the guests.

In this section, we will discuss the intended use of the FT feature and how to enable it. We will also discuss the limitations associated with enabling FT as well as issues that will prevent FT from being enabled.

This section covers seven subobjectives:

Identifying FT restrictionsNN

Evaluating FT user casesNN

Setting up an FT networkNN

Verifying requirements of operating environmentNN

Enabling FT for a virtual machineNN

Testing an FT configurationNN

Upgrading ESX hosts containing FT virtual machinesNN

Identifying FT RestrictionsFault Tolerance requires additional network connections and will impose several limita-tions on the configuration and flexibility of FT-enabled VMs. These are the trade-off for providing truly zero downtime for a VM.

Fault Tolerant VMs:

May only have a single virtual processor.NN

Must reside in an HA cluster.NN

Must reside on shared storage, visible to all hosts that will run the FT VMs.NN


May not have thin-provisioned virtual disks—they must be thick.NN

May not be backed by physical compatibility mode raw device mappings (RDMs). NN

Virtual compatibility mode RDMs are supported.

Must run on ESX/ESXi hosts with identical or compatible processors (Enhanced NN

VMotion Compatibility is not sufficient).

Do not support hot-adding devices, memory, or CPU.NN

Do not support MSCS.NN

Do not support NPIV.NN

Do not support Storage VMotion.NN

Do not support snapshots.NN

Do not support Direct Path I/O.NN

Do not support paravirtualization.NN

Do not support the older NN vlance virtual NIC hardware. vlance is the name of the legacy default network adapter. This adapter must be replaced in the VM with a more advanced virtual network adapter if Fault Tolerance is to be used.

Must have hardware virtualization enabled in the BIOS.NN

Evaluating FT Use CasesLet’s discuss why an active/standby cluster would be used with the guest operating system in the first place: for critical applications where a few minutes of downtime (as would be the case with HA) is not acceptable. By having two VMs, each on a separate ESX host in an active/standby relationship, we can have vastly improved business continuity due to essentially immediate failover should the primary VM fail. This setup would require the administrator of this environment to know how to create and manage clusters in the guest operating system.

VMware Fault Tolerance provides the same immediate recovery or failover without requiring the advanced administration of guest operating systems necessary to implement clusters. To enable Fault Tolerance, you create an extra VMkernel port, right-click on a VM, and select Fault Tolerance Turn On Fault Tolerance (see Figure 8.17).

F I GU R E 8 .17 Selecting Turn On Fault Tolerance


When Fault Tolerance is enabled on a VM, the VM becomes known as a “primary.” The “secondary” VM is provisioned on another ESX host, and the real-time state of the primary VM is kept synchronized in the secondary VM by actively keeping the RAM footprint of the secondary VM perfectly in sync with that of the primary VM. This syn-chronization is done via VMkernel ports; additionally, heartbeats are sent over this same channel. Should the primary disappear or go offline, the secondary will immediately go live and become the new primary. A new secondary will be provisioned on another ESX host, and the process of maintaining the secondary VM in sync with the primary begins all over again.

Applications that cannot experience downtime are prime candidates for Fault Tolerance. Examples of such applications are:

Mission-critical applicationsNN

Applications with long-lasting or stateful connectionsNN

Applications not compatible with conventional clusteringNN

Setting Up a Fault-Tolerant NetworkTo implement Fault Tolerance, you need to do the following:

Set up a fault-tolerant logging network. When creating or editing a VMkernel port in vSphere 4, notice there are two check boxes in ESX: one to enable VMotion and the second to enable FT Logging (see Figure 8.18). (ESXi has a third: to use the VMkernel port for management.)

F I GU R E 8 .18 Configuring FT logging

When implementing Fault Tolerance, we recommend that you have a separate and indepen-dent network with separate and independent VMkernel ports dedicated to FT, because of the criticality of synchronizing the RAM footprint of the primary VM to the secondary. Latency in this synchronization can prevent FTs from functioning properly. Although FT can be enabled to share existing VMkernel ports with IP storage and also with VMotion, we don’t recommend this approach.


Verifying Requirements of the Operating EnvironmentTo use VMware FT, certain requirements must be met within the vSphere infrastructure, including clusters, hosts, and VMs. Let’s take a look at each object and what requirements must be met.

Cluster RequirementsThe fi rst object, the cluster, has its own set of requirements:

VMware HA must be enabled, and host monitoring should also be enabled.NN

Host certificate checking must be enabled on all hosts in the cluster.N

All hosts must have both a VMotion and fault-tolerant logging NIC configured.NN

All hosts must be at the same version and patch level.N

All hosts must have the same VM datastore and network access.NN

When using FT in an HA-enabled cluster, the FT secondary VMs are included in HA’s calculations for spare capacity . If Host Failures Cluster Tolerates admission control policy is used, the FT secondary uses one of the slots that are calculated for VM restarts . If Percentage Of Cluster Resources admission control policy is used, the FT secondary VM’s resource usage is accounted for when calculating spare capacity .

Host RequirementsListed here are the host requirements for using FT:

A host must use a compatible processor (see VMware KB article 1008027).NN

A host must be on the hardware compatibility list and certified by the hardware manu-N

facturer as FT capable.

The host must have Hardware Virtualization (HV) enabled in the BIOS.NN

VM RequirementsListed here are the VM requirements for using FT:

VMs must be on shared storage.NN

VMs must use thick (eager zeroed) disks or RDMs using virtual compatibility mode.N

VMs must be using a supported operating system (see VMware KB article 1008027).NN

Enabling FT for a Virtual MachineOnce the fault-tolerant logging network is confi gured and Fault Tolerance is licensed, the feature can be activated by simply right-clicking on a VM and selecting the option to


activate Fault Tolerance from the drop-down menu (see Figure 8.19). A VM with Fault Tolerance enabled will appear dark blue.

F I GU R E 8 .19 Fault Tolerance enabled on a VM

Once active, the latency of fault-tolerant logging can be monitored in real time. Latency as high as tenths of a second is considered unsatisfactory.

The Fault Tolerance configuration can be tested by right-clicking on a Fault Tolerance–enabled VM and selecting the option to test FT. This will, in fact, cause a failover. During this process, the secondary will become primary and a new secondary will be provisioned.

Testing an FT ConfigurationOne way to test the cluster’s configuration for using VMware FT is to use the Profile Compliance tab to check for compliance of each host (see Exercise 8.3). Once the cluster has been created, networking required for FT has been configured, and hosts have been added to the cluster, you can check for compliance.

E X E R C I S E 8 . 3

Checking FT Compliance

1. Log into the vCenter server with the vSphere Client .

2. Select the cluster object in the Hosts And Clusters view, and then click the Profile Compliance tab in the informational panel on the right .

3. Click the Check Compliance Now link to run compliance checking .

4. After the test runs, review the results of the tests at the bottom of the client .

Upgrading ESX Hosts Containing FT Virtual MachinesOne of the requirements for FT VMs is that they must run on ESX hosts at the same ver-sion and patch level. If you need to upgrade your hosts, how can you continue to protect the VMs using FT? The scenario for doing so requires careful planning and execution.


The ideal scenario includes at least four ESX hosts in the cluster and spare capacity to allow for two hosts to be evacuated.

The process for upgrading the ESX hosts without impacting the VMs is outlined in Exercise 8.4.

E X E R C I S E 8 . 4

Upgrading ESX hosts with FT VMs


2. Use VMotion to evacuate the first two ESX hosts in the cluster, including any FT VMs .

3. Upgrade the two evacuated hosts to the same new version or patch level .

4. Disable FT on the primary VMs .

5. Use VMotion to migrate the disabled FT VMs to the two newly upgraded ESX hosts .

6. Reenable FT on the FT VMs just migrated .

7. Once all ESX hosts have been upgraded, use VMotion to distribute the FT VMs across the cluster (VMware recommends only four to eight FT VMs per host) .

Creating and Managing Resource PoolsResource pools are a multipurpose VMware inventory object; although their primary purpose is to manage the performance of VMs, resource pools can be used as an object to which permis-sions are tethered, or they can simply be used to organize VMs. Resource pools can be nested within other resource pools and can exist on standalone ESX(i) hosts, or they can span entire DRS clusters. There are a variety of situations where a resource pool can be used in VMware inventory; the most common is to organize the performance of groups of VMs.

In this section, we will discuss the purpose of resource pools as well as the process of creat-ing and then administering them. It is critical to understand the purpose of reservations, limits, and shares for the performance management of VMs as well as resource pools.

This section covers nine subobjectives:

Determining resource pool requirements for a given situationNN

Evaluating appropriate shares, reservations, and limits for a given situationNN

Evaluating virtual machines for a given resource poolNN

Creating resource poolsNN

Setting CPU resource shares, reservations, and limitsNN

Creating and Managing Resource Pools 441

Setting memory resource shares, reservations, and limitsNN

Defining expandable reservationNN

Adding virtual machines to poolNN

Describing resource pool hierarchyNN

Determining Resource Pool Requirements for a Given SituationThere are many benefits to taking advantage of resource pools in a vSphere environment. At the very least, they can be used as containers for organization and delegation of privilege. They also can provide resources to the VMs in a significantly more managed way instead of allowing all VMs to compete against each other equally.

Resource pools can provide the following benefits:

Flexibility in organizing the VMsNN

Ability to isolate various groups of VMs by department, function, or other criterion NN

used by the administrator

Ability to provide for access control and delegation of privileges by assigning only NN

those administrators who require access to fulfill their duties

Ability to provide resource management that is independent of the hardware resources NN

of a single ESX host (if used with DRS clusters)

Ability to group virtual machines to provide a multitier serviceNN

One of the best ways to use resource pools effectively is to allocate CPU and memory resources to each pool separately as a way to manage resource allocation at the host or DRS cluster level. This allocation then provides you with a mechanism for fine-tuning how much CPU and memory are given to any group of VMs without having to take into account where the VMs are running or which VMs they are competing against on the same host. DRS cluster resource pools are not bound to a single ESX host and, therefore, can distribute the pool’s VMs across all the hosts in a cluster.

Figure 8.20 shows the allocation of resources to two resource pools to allow one pool (Engineering) more resources, and the other (Finance) fewer resources in terms of CPU and memory.

Evaluating Appropriate Shares, Reservations, and Limits for a Given SituationYou’ll have some work to do when figuring how much CPU or memory resources are allocated to a resource pool. Many times, the initial values for these resources are based loosely on the needs of the VMs. Another example would be in the case of a hosting pro-vider allocating resources to the pool based on how much the customer has subscribed.


Similar in concept to cable TV or cell phone subscriptions, the customer purchases a plan that allocates or limits a certain amount of CPU and memory resources to the pool they work within. This allows the hosting provider to publish an SLA with the customer; if the customer doesn’t use all of their resources, they are not penalized, nor does the hosting pro-vider have to worry about the customer impacting other customers within the same cluster.

F I GU R E 8 . 20 Resource allocation with two pools

In some environments, the allocation of resources is based on an aggregate value of the VM’s needs within the cluster. If there are three VMs in the cluster and each has a 250 MHz reservation, the resource pool will need to reserve from the parent object at least 750 MHz of reservation to cover the individual reservations of each VM. In addition, the VMkernel will need to reserve memory to virtualize the VMs contained within the resource pool, and that will have to be included in the pool’s reservation calculation.

In almost all cases, a pool will need to be limited to a maximum CPU or memory allocation so that it will not negatively impact other resource pools on the host or within the DRS cluster. Although, by default, there are no reservations or limits on a resource pool, using both mechanisms will allow for predictable behavior.

Evaluating Virtual Machines for a Given Resource PoolAs is the case often in the world of IT, there are many variables that have to be considered when designing a system or architecture that will allow for flexibility and efficiency. When designing resource pools, there are many ways to design a hierarchy that fits for a particu-lar environment. Which VMs are placed in certain resource pools can be as easy as deter-mining who administers them and creating pools for each administrative group. Or it can be as complex as looking at actual resource consumption per VM and creating a hierarchy that groups high-consumption VMs in a pool and low-consumption VMs in another pool.

Once the VMs are placed into the pool, you will need to evaluate their performance and track their ability to satisfy their end users. There are at least a couple of ways to look at VM resource consumption and resource pool utilization as a result of the VMs running within. The Resource Allocation tab for a resource pool provides a great way to analyze overall utilization, both for reservations and overall CPU or memory utilization in the top section and individual VM settings within the pool in the bottom section. Figure 8.21 shows the Resource Allocation tab for a resource pool.


F I GU R E 8 . 21 Resource Allocation tab

In addition, the resource pool has a Summary tab that will show overall usage and utiliza-tion rates for CPU and memory and other values for memory, such as swapping, ballooning, and shared memory. Although not broken down by VM, tracking usage will show whether the VMs are near their pool’s limits and are having a negative impact on the VM’s performance.

Creating Resource PoolsResource pools are created and managed from the Hosts And Clusters view in the vSphere Client inventory by simply right-clicking on an ESX host or a cluster icon and choosing New Resource Pool from the context menu. Upon creation, a resource pool must be given a name (see Figure 8.22). Additionally, for both CPU and memory, reservations, limits, and shares can be managed.

F I GU R E 8 . 22 Create Resource Pool dialog box


Resource performance can be managed on a per-VM basis or in pools with the reserva-tions, limits, and shares (see Figure 8.23). These metrics apply to both CPU as well as memory.

F I GU R E 8 . 23 Resource Allocation screen

Setting CPU Resource Shares, Reservations, and LimitsBy default, resource pools have no resource allocation configurations—they are merely an object for organizing VMs. However, in the first of two quadrants, CPU settings can be implemented.

A CPU reservation defines the total reserved CPU capacity available in the resource pool. In other words, all the VMs in the pool will have this amount of CPU available to meet any VM reservations defined on a single VM without having to compete for those CPU resources. In most cases, CPU limits are used when expandable reservations are defined on the resource pool. This prevents a resource pool from monopolizing CPU resources on the parent object and taking resources away from other legitimate consumers.

CPU shares in a resource pool identify the priority VMs in this resource pool will have relative to other resource pools in the event there is contention for CPU cycles in the parent environment. The parent of a resource pool can be another resource pool, an ESX host, or an entire cluster of ESX hosts.

The concept of shares lends itself to confusion often because a unit of measurement or com-parison is sought. This is a mistake. Instead, simply view the number associated with shares as a value relative to other shares’ values. VMware recommends a shares ratio of 4:2:1. In other words, when there is contention for CPU resources, VMware recommends establishing three priorities: High, Normal, and Low. The ratio of resources distributed will be as follows:

High will have twice the resources of Normal and four times the resources of Low.NN

Normal will have half the resources of High and twice the resources of Low.NN

Low will have one quarter the resources of High and half the resources of Normal.NN

To better understand how shares will control the performance of virtual machines, con-sider the following example. Three people wish to sit on a single chair. The person with Low


privilege gets to sit on the chair for one second. The person with Medium privilege can sit for two seconds, and the person with High privilege can sit for four seconds. Now, rather than people sitting in a chair, imagine VMs receiving CPU time; clearly, the VMs with more CPU time will get more work done than those with less CPU time.

The key to understanding how VMs compete with each other for resources in a pool, or how child resource pools compete with each other for the resources of a parent, is to under-stand how peers will compete for the resources of the parent. Shares will determine which peer receives more resources and which will receive fewer.

Here’s the most important concept to remember about shares: they will only be enforced if there is contention for resources.

Setting Memory Resource Shares, Reservations, and LimitsAs with CPU, by default resource pools have no resource allocations for memory. In the second quadrant, memory allocations can be managed.

A memory reservation is the reserved capacity provided to the VMs for any individual reservations they may have configured, or for overhead.

Memory shares in a resource pool define how RAM will be delegated in the event there is contention for this resource. This concept is more abstract than CPU cycles. To properly grasp this, we must consider the resource in question: ESX RAM. If the finite amount of ESX RAM for VMs is consumed, which VMs will ultimately be swapped by ESX? VMs with low shares will lose the battle for RAM.

In the case of shares ratios in RAM, the actual values are represented as memory quantities; however, the recommended ratios still apply.

Defining Expandable ReservationThe concept of an expandable reservation can best be defined in terms of what it is not: it is not a way of creating concrete resource allocations to satisfy SLAs. Instead, an expandable reservation is a way of saying, “If the VMs in this resource pool need more resources, they can go claim them from the parent object of that resource pool if it’s available.”

There are two ways VMs will claim additional reservation from their resource pool. The first way is if the VM has its own reservation increased or initially set higher than zero. If the resource pool has exhausted its predefined reservation, this forces the resource pool to request additional reserved resources from its parent, a cluster or host. If the additional resources are available at the parent level, then the resource pool can claim them in a “first come, first served” manner.

The other way a resource pool may need to expand its reservation is if another VM is powered on. Each VM has a reserved amount of memory set aside by the VMkernel to virtualize the VM and is considered overhead. This overhead memory does count against the resource pool’s reservation, and if the predefined amount of reservation has been


exhausted, the pool can expand its reservation on behalf of the new VM being powered on. The method of claiming more reservation resources from the parent is the same as the fi rst method above.

Rather than using extremes (hard SLAs or no resource allocations whatsoever), you can defi ne resource allocations as follows. A group of VMs, represented as a resource pool, will have no less than 2000 MHz of CPU (reservation), and if the pool needs more, it can request additional resources as a function of growing the existing reservation (expand-able reservation), but only up to a maximum of 3000 MHz (limit). In confi guration terms, this means that a resource pool would have an initial reservation of 2000 MHz, which is expandable, and a limit to the expansion of 3000 MHz.

Adding Virtual Machines to a PoolOnce a resource pool is created, existing VMs can be inserted into the pool by simply drag-ging and dropping them into the pool. VMs in a resource pool will be indented in relation to the parent resource pool. Also, new VMs can be created within a resource pool.

If a VM had an individual reservation or limit, those will remain after the VM is moved into the resource pool. If the VM had a high, normal, or low shares value assigned before joining the pool, it will still have shares assigned, but they will be adjusted to refl ect the pool’s overall total shares as a percentage. If the shares were assigned using Custom, those values stay the same once the VM is a member of the pool.

When you add a VM to a resource pool, the vSphere Client may ask you to change the shares on the VM to maintain consistency and propor-tions within the pool . A warning may appear that informs you that the VM may have a very large or very low percentage of shares within the pool .

If the VM has its own reservation, this will be shown in the resource pool’s Resource Allocation tab and will be added to the pool’s total reservation being used.

Describing Resource Pool HierarchyThe creation of a resource pool results in a parent-child relationship. For instance, if a resource pool is created from an ESX host, the resource pool becomes a child of the ESX host. The same is true for a DRS cluster, with the pool becoming a child of the cluster. In some cases, nesting resource pools is needed for more granular administra-tion and for providing suballocations for CPU and memory within the same parent pool. Figure 8.24 shows this arrangement of nesting pools, creating a parent-child relationship between pools.

Exam Essentials 447

F I GU R E 8 . 24 Resource pool nesting

SummaryThe underlying theme in this chapter has been the performance of VMs. Whether defining the performance of individual VMs or defining resource pool attributes for grouping VMs together, the goal has been to control how VMs perform and to mitigate contention for resources.

VMotion is used to move the CPU and memory consumption of a VM from one host to another. Storage VMotion is used to migrate the component files of a VM, improving perfor-mance by eliminating contention for storage bandwidth along individual storage paths.

Once a cluster is configured, DRS can automate resource management and perform VMotions (CPU and memory load distribution) automatically. DPM can help reduce power consumption by powering down unused ESX host capacity.

A second theme in this chapter has been data availability: by maintaining infrastructure availability, application fault tolerance, and backups, the idea is to keep services as highly available as possible while also maintaining data integrity.

Exam Essentials

Understand how to configure and manage reservations, limits, and shares for VMs and resource pools. Be clear on the subtle differences between the definition of reservations and limits in VMs and the definition of reservations and limits in resource pools.

Remember that Enhanced VMotion (EVC) will automatically mask out some CPU differences in a nonhomogeneous environment. However, processors must be closely related within a given brand (Intel or AMD). EVC also requires that applications respect the CPUID method of processor enumeration.


Understand why it may be desirable to control the location of a VM’s VMkernel swap file. Also, you should know the limitations of controlling this from a VM’s properties as opposed to managing this feature from within a DRS cluster.

Be aware that High Availability (HA) will restart VMs if an ESX host fails and causes VMs to fail as well. Be able to explain the three methods HA uses to maintain spare capacity on each ESX host, as well as the ESX infrastructure configuration requirements for HA to function properly. Be able to enumerate HA’s dependencies.

Understand that Fault Tolerance exists as an alternative to guest operating system clus-ters. It does so by providing zero-downtime fault tolerance within the VMware infra-structure. However, Fault Tolerance has many dependencies. In addition to being able to list these, understand how Fault Tolerance logging maintains the secondary VM in sync with the primary as well as how Fault Tolerance fails over.


Review Questions

1. Which resource pool setting would be most closely associated with a service level agreement (SLA)?

A. Reservation

B. Limit

C. Shares

D. Expandable

2. Which of the following VMware technologies would help you maximize VM uptime in the event of a catastrophic ESX server hardware failure?

A. VMotion

B. Distributed Resource Scheduler (DRS)

C. VMware High Availability (HA)

D. Storage VMotion

E. Resource pools

3. Which of the following is not a limitation of VMware Fault Tolerance (FT)?

A. Uniprocessor VM

B. HA

C. Shared storage

D. RDMs in virtual compatibility mode

4. Which Service Console file is populated with the IP addresses of each ESX server in an HA cluster when you configure redundant heartbeat HA networks?

A. /etc/HA_HOSTS

B. /etc/hosts

C. /etc/vmware/hosts

D. /etc/HA/HOSTS

5. Distributed Power Management (DPM), before making a decision to take a host out of Standby mode, averages cluster resource use over what period of time?

A. 5 minutes

B. 20 minutes

C. 30 minutes

D. 1 hour

E. You have to configure the parameter value first.


6. Which of the following does not apply to HA VM monitoring?

A. VMware tools are not required in the VM for HA to monitor individual VMs.

B. You can configure the failure interval: how long a VM must be nonresponsive before being rebooted.

C. You can configure the number of times per hour HA will attempt to reset a nonrespon-sive VM.

D. VMs can have their restart priority (high, medium, low, disabled) individually set.

7. What is the default resource pool reservation for memory?

A. 1000MB

B. 500MB

C. No reservation

D. The maximum allowed on that host

8. An ESX server in an HA cluster finds itself isolated from the rest of the HA cluster. What is the default isolation response?

A. Do nothing

B. VMotion VMs to other ESX servers

C. Reboot

D. Power down all VMs

9. What is the maximum number of failover hosts allowed in an HA cluster?

A. 1

B. 4

C. 5

D. 7

E. 8

10. When using EVC, what level of compatibility cannot be attained?

A. Intel hosts compatible with AMD hosts

B. Compatibility between Intel processors in the same family

C. Compatibility between AMD processors in the same family

D. Compatibility between RISC processors


11. Which of the following protocols are used by DPM to manage the cycling of hosts into and out of Standby mode?

A. PowerSave

B. IPMI

C. WOL

D. DiPM

E. iLO

F. ESave

12. What are the three automation levels possible when configuring a DRS cluster?

A. Fully Automated

B. Semi-Automatic

C. Manual

D. Partially Automated

13. You want to configure an ESX server to store its VMs’ swap files in a separate local directory. When you try to change this setting via the ESX server’s Virtual Machine Swapfile Location properties form, you notice the Edit link is grayed out and not selectable. What, if anything, can you do to enable the Edit button so that you can configure an alternative location for the VMs’ swap file location?

A. This is not possible once an ESX server has been added to a DRS cluster. The VMs’ swap file must now stay in the same folder as the VMs’ other configuration files.

B. You have to edit the DRS cluster Swapfile Location setting to allow the VMs’ swap files to be stored in directories other than their own configuration file directory.

C. You need to remove the ESX server from the DRS cluster to change this setting.

D. Storing VMs’ swap files in alternate locations is not supported in vSphere.

14. Which of the following VMware technologies is disruptive in the operation of a virtual machine?

A. HA

B. DRS

C. VMotion

D. Fault Tolerance

E. Storage VMotion

15. An ESX host with existing resource pools is to be added to a DRS/HA cluster. As you add the ESX host to the cluster, what can happen with the existing resource pools?

A. They can be removed.

B. They can be merged with existing pools, if the existing pools are identically named.

C. They can be placed under a new top-level resource pool called “Grafted from.…”

D. You cannot merge ESX hosts with resource pools—the existing resource pools must first be removed.


16. What is a cluster’s target utilization used by DPM?

A. 50 percent

B. 63 percent

C. 67 percent

D. 75 percent

17. VMware Fault Tolerance (FT) currently has several restrictions. Which of the following is not a restriction of FT?

A. The VM must not be running Linux.

B. The VM must not be in an MSCS cluster.

C. The VM must not be using paravirtualization.

D. You cannot use thin-provisioned disks on an FT VM.

18. What are the three admission control policies that can be used with an HA cluster?

A. Host Failures Cluster Tolerates

B. Number Of VMs Tolerated

C. Percentage of Cluster Resources Reserved As Failover Spare Capacity

D. Specify A Failover Host

19. How do you determine which ESX server a particular virtual machine is running on if the ESX server is part of a DRS/HA cluster?

A. Select the Hosts And Clusters view and observe the indentation. VMs will always be indented under the ESX server they are running on.

B. Select the VMs And Templates view and observe the indentation. VMs will always be indented under the ESX server they are running on

C. In the VMs And Templates view, select the VM and then click the Summary tab.

D. In the Hosts And Clusters view, select the cluster and then select the Virtual Machines tab.

E. In the Hosts And Clusters view, select the ESX server and then select the Summary tab.

20. Distributed Power Management (DPM), before making a decision to put a host into Standby mode, averages cluster resource use over what period of time?

A. 5 minutes

B. 40 minutes

C. 30 minutes

D. 1 hour

E. You have to configure the time first.



1. A. The reservation is a minimum guarantee and so most closely ties to SLAs. Since the Limit value is a best-effort delivery mechanism and shares only have meaning in the context of a VM or resource pool contending for resources, they would not be the best mechanism for providing an SLA guarantee. Making a resource pool expandable, although it allows for the “borrowing” of resources from a parent pool, is no guarantee the resources will be available at the time of borrowing.

2. C. VMotion, DRS, and Storage VMotion are all anticipatory technologies. You perform them ahead of an anticipated downtime/maintenance window. HA reacts to ESX server failures, rebooting VMs quickly. Resource pools are used to assign resources to VMs in a fair manner and are not directly involved with hardware failures.

3. D. The current FT implementation only supports uniprocessor VMs, must run within an HA cluster, and requires the VMs have all their files on shared storage. VMs with RDMs in physical compatibility mode are not allowed, but RDMs in virtual compatibility mode are fine.

4. A. The /etc/HA_HOSTS carries the IP addresses of all ESX HA network interfaces in the HA cluster and is used by the HA hosts to implement redundant heartbeat. The presence of this file guarantees heartbeat will work even in the event of DNS failure.

5. A. DPM takes a rolling 5-minute resource usage average before making the decision to pull an ESX server back out of Standby mode. Do not confuse this with the 40-minute average time to make the decision to put a host into Standby mode.

6. A. VMware tools are required in a VM for HA to monitor them individually.

7. C. Once a resource pool has been created, it will not have any reservations or limits for memory or CPU. It is up to the administrator to set those values as necessary.

8. D. The default isolation response is to power down all VMs so that the remaining ESX servers can successfully restart them. If the VMs are not powered down, other ESX servers would not be able to restart them as the running VMs’ virtual disk files remain locked.

9. B. HA clusters allow for a maximum of four simultaneous host failures. There must be a maximum of five primary hosts in an HA cluster, one of which must always be running.

10. A, D. EVC can only provide compatibility between Intel and AMD processors, but the cluster has to use one or the other manufacturer. VMware does not support RISC processors.

11. B, C, E. DPM can utilize IPMI (Intelligent Platform Management Interface), WOL (Wake-on-LAN), or iLO (Integrated Lights-Out) technologies.

12. A, C, D. A DRS cluster can provide Manual mode for administrators who want complete control of where a VM is powered on and whether a VM is VMotioned to another host. Partially Automated allows the VM to be powered on a host of the cluster’s choosing, but will not VMotion the VM for load balancing. Fully Automated will do both actions with-out input from the administrator.


13. B. Once you have added an ESX server to a DRS cluster, the DRS cluster by default controls the allowable location of VMs’ swap files. If you want to store VMs’ swap files in alternate locations, you must first configure this in the cluster Swapfile Location setting; then you can configure the specific swap file store on a per-ESX host basis.

14. A. Only HA is disruptive, reacting to either a failed ESX server or a failed VM, rebooting the VM as quickly as possible after detecting the failure. DRS, VMotion, FT, and Storage VMotion all operate without disrupting the real-time operations of virtual machines.

15. A, C. Existing resource pools can be removed or added to a top-level “grafted” resource pool.

16. B. The average overall load on a cluster is targeted at 63 percent by the Distributed Power Management engine. If the cluster load falls significantly below this value, hosts may be put into Standby mode; if the load rises significantly above this value, hosts may be pulled back out of Standby mode.

17. A. FT works with any supported guest OS.

18. A, C, D. VMware HA currently has three Admission Control polices. Each one has a differ-ent method for reserving spare capacity in case of a host failure. If using Host Failures Cluster Tolerates, a slot size must be calculated based on the largest CPU or memory reservations of a VM in general. If no reservations are being used, then the slot size is 256MHz for CPU and the highest memory overhead value for a VM in the cluster. If the administrator uses the Percentage of Cluster Resources Reserved As Failover Spare Capacity policy, then a value is calculated by the administrator that will allow for at least one host’s capacity to be lost. If “Specify A Failover Host” is selected, then one host is set aside as a passive node in case a host fails to provide a traditional N+1 cluster.

19. C, D. There are several ways to find out which ESX server a VM is running on when you are looking at a DRS/HA cluster. In addition to the correct answers here, you can also select an ESX server and then select the Virtual Machines tab. Of course, in this last case you may have to “fish around” various ESX servers until you find the one with the VM of interest. The answers in this question are generally more efficient ways at solving this problem.

20. B. DPM takes a rolling 40-minute resource usage average before making any decisions. The idea is to not move VMs and put hosts into Standby mode needlessly as there is a significant amount of overhead and time involved in going into and back out of Standby mode. Contrast this with the 5-minute average interval used to pull an ESX server back out of Standby mode.

Chapter

9Alarm Management


Create and Respond to vCenter Connectivity Alarms.NÛ

List vCenter default connectivity alarms .NN

List possible actions for connectivity alarms .NN

For a given alarm, analyze and evaluate the affected virtual NN

infrastructure components .

Create a vCenter connectivity alarm .NN

Relate the alarm to the affected components .NN

Create and Respond to vCenter Utilization Alarms.NÛ

List vCenter default utilization alarms .NN

List possible actions for utilization alarms .NN

For a given alarm, analyze and evaluate the affected virtual NN

infrastructure resource .

Create a vCenter utilization alarm .NN

Relate the alarm to the affected resource .NN

Monitor vSphere ESX/ESXi and Virtual NÛMachine Performance.

Identify critical performance metrics (e .g ., CPU ready, queue NN

depth, etc .) .

Explain memory metrics (ballooning, shared, etc .) .NN

Explain CPU metrics (ready/wait time, etc .) .NN

Explain network metrics (usage, packet drops, etc .) .NN

Explain storage metrics (latency, queuing, etc .) .NN

Compare and contrast Overview and Advanced Charts .NN

Create an Advanced Chart .NN

Determine host performance using guest Perfmon .NN

This chapter explores the various connectivity alarms provided by vSphere. You’ll learn about the possible actions that can be used once a connectivity alarm has triggered. For each of the

connectivity alarms, we’ll look at the affected components, and analyze and determine the consequences. We’ll even practice creating a connectivity alarm.

Next, this chapter describes the default alarms dealing with utilization in vCenter. We’ll analyze the effects on a resource that an alarm may provide insight to, and again, we’ll practice creating this type of alarm.

Finally, we’ll look at monitoring virtual machine performance. We’ll explore the many different metrics that are available in vCenter and explain their use. We’ll also compare the two types of charts used with the Performance tab and create an advanced chart. In addition, we’ll look at the new virtual machine Performance Monitor objects for Microsoft Windows operating systems.

Creating and Responding to vCenter Connectivity AlarmsWhen you’re using vCenter 4.0, you’ll find many new alarms provided by default that are very useful. Of these, the Connectivity alarms provide a way to monitor resource and host connections. With past versions of VMware Infrastructure, if there was a loss of network or storage resources, the only way the product could alert the administrator was if a virtual machine was impacted. With vSphere, if there is an outage for either a network or storage resource, a built-in alarm can alert the administrator and a response can be chosen quickly. The host-based connection alarm is still there and will provide an alert if vCenter loses its connection with the host.

This section discusses five exam subobjectives:

Listing vCenter default connectivity alarmsNN

Listing possible actions for connectivity alarmsNN

For a given alarm, analyze and evaluate the affected virtual infrastructure componentsNN

Creating a vCenter connectivity alarmNN

Relating the alarm to the affected componentsNN

Creating and Responding to vCenter Connectivity Alarms 457

Listing vCenter Default Connectivity AlarmsThe default connectivity alarms are new to vCenter. These alarms will alert you if there is a loss of network, storage, or host connectivity. Table 9.1 lists the alarms and what they monitor.

TA B lE 9 .1 Default Connectivity Alarms

Alarm What It Monitors

Cannot Connect To Network Network connectivity on a vSwitch

Cannot Connect To Storage Host connectivity to a storage device

Host Connection And Power State Host connection and power state

Host Connection Failure Host connection failures

With the addition of these new alarms, you are able to monitor connectivity issues. Figure 9.1 shows the Host Connection and Power State alert if vCenter loses its connection to the host.

Once the alarm has been triggered, you will be notified by email or SNMP trap that there is a problem with the virtual infrastructure. By default, the alarms are defined but not their actions. Also, each alarm has a set of triggers that will be used. The network and storage alarms, as well as the Host Connection Failure alarm, are event based. The Host Connection And Power State alarm is condition based.

F I GU R E 9 .1 Alarm for Host Connection lost

458 Chapter 9 N Alarm Management

A condition-based alarm looks for certain resource thresholds to be met or object state changes before triggering. A good example of this type of trigger is creating an alarm that triggers if a VM uses more than 50 percent of its memory resource configuration, or if the VM is powered off. An event-based trigger looks for events that may happen to a managed object, vCenter, or the License Server.

Table 9.2 lists the triggers for each alarm.

TA B lE 9 . 2 Possible Triggers for Each Connectivity Alarm

Alarm Possible Triggers

Cannot Connect To Network Lost Network Connectivity

Lost Network Redundancy

Network Redundancy Degraded

No IPv6 TSO Support

Vprob.net.migrate.bindtovmk (ESX Advanced config for binding VMotion to a specific vmknic)

Cannot Connect To Storage Lost Storage Connectivity

Lost Storage Path Redundancy

Degraded Storage Path Redundancy

Host Connection And Power State Host Connection State

Host Power State

Host Connection Failure Cannot Connect Host - Incorrect CCAgent

Cannot Connect Host - Network Error

Cannot Connect Host - Time-out

Host Connection Lost

Listing Possible Actions for Connectivity AlarmsWhen using the Connectivity alarms, you must define the actions that an alarm can use. The list of possible actions is the same for any alarm. For the event-based alarms, the


default action is to send a notification trap. For the Host Connection and Power State alarm (which is conditional), there is no default action. You will have to decide what is appropri-ate. Table 9.3 lists the actions possible for each type of alarm.

TA B lE 9 . 3 Possible Actions for an Alarm

Alarm Type Possible Actions

Host Send A Notification Email

Send A Notification Trap

Run A Command

Enter Maintenance Mode

Exit Maintenance Mode

Enter Standby

Exit Standby

Reboot Host

Shutdown Host

Virtual Machine Send A Notification Email


Run A Command

Power On VM

Power Off VM

Suspend VM

Reset VM

Migrate VM

Reboot Guest On VM

Shutdown Guest On VM


Alarm Type Possible Actions

Virtual Switch Send A Notification Email


Run A Command

Datastore Send A Notification Email


Run A Command

In many situations when using connectivity alarms, you will need to be notified of the outage. Of the actions that are possible, email and SNMP traps are most often used for this type of alarm. This will allow you to determine the reason for the outage and implement the appropriate solution.

Analyzing and Evaluating the Affected ComponentsEach alarm provides information as to what may be wrong with the virtual infrastructure. Once an alarm has been triggered, you will need to identify which alarm has sent the alert and then investigate what has been lost. As seen in Table 9.1, each alarm is specific to net-work, storage, or host connectivity loss.

If the alarm was Host Connection And Power State, Table 9.2 lists the reasons for this based on the triggers being used. For example, if the ESX host was rebooted or shut down, an alarm will notify you of the loss of connectivity to the host (see Figure 9.2). To learn why, check out the Task & Events tab to discover whether the server was shut down or rebooted, as shown in Figure 9.3.

F I GU R E 9 . 2 An alarm has been triggered .

TA B lE 9 . 3 Possible Actions for an Alarm (continued)


F I GU R E 9 . 3 The Task & Events tab describes what was done and by whom .

What’s very nice about this is that the person responsible is shown in the Initiated By column. Auditing of these kinds of tasks is necessary in many environments, and docu-menting which account was used to initiate certain tasks is shown in vSphere Client.

If the alarm was Cannot Connect To Network, the affected components will be network related. There are five possible triggers:

Lost Network ConnectivityNN

Lost Network RedundancyNN

Network Redundancy DegradedNN

No IPv6 TSO SupportNN

Vprob.net.migrate.bindtovmkNN

If the alarm was Cannot Connect To Storage, the affected components will be storage related. There are three possible triggers:

Lost Storage ConnectivityNN

Lost Storage Path RedundancyNN

Degraded Storage Path RedundancyNN

If the alarm was Host Connection Failure, the affected components will be the ESX/ESXi hosts themselves and the inability for vCenter to communicate with the host. There are four possible triggers:

Cannot Connect Host - Incorrect CCAgentNN

Cannot Connect Host - Network ErrorNN

Cannot Connect Host - Time-outNN

Host Connection LostNN

The trigger will help identify the actual problem in many cases. In other cases, the trigger might be off target. With storage connectivity loss, if iSCSI or NFS is being used, there could be network-related outages that would also impact the host’s ability to communicate with the back-end storage. The trigger may indicate datastore loss, but the reason is network related.

Creating a vCenter Connectivity AlarmCreating a vCenter connectivity alarm is not much different than creating other alarms. The difference is that many alarms are looking at resource utilization, but connectivity


alarms are looking for a loss of a resource such as networking, storage, or a host. Since the alarms are included with vCenter, the only real setup involves defining the action that needs to happen. Exercise 9.1 shows the steps to creating a connectivity alarm for loss of a host.


Creating a Connectivity Alarm for a host

1. Log into the vSphere Client and on the Home page, in the Inventory section, click the Hosts And Clusters icon .

2. Click the vCenter object at the top of the hierarchy . In the informational panel, click the Alarms tab . Locate the Host Connection And Power State alarm, right-click it, and choose Edit Settings .

3. Take a look at the General tab . All the information that is necessary is there, but it never hurts to review the settings . The Alarm Type section shows that this alarm is a “condition” alarm .



4. Click the Triggers tab . This will show the two triggers that are used for this connec-tivity alarm . The first is the Host Connection State trigger . This is set to Alert if the condition is equal to Not Responding . Also, there is a trigger for Host Power State . This trigger is monitoring the state of the ESX/ESXi host; if the state is anything other than Standby, the alert will trigger . Lastly, looking at the bottom of the Triggers tab, note that the “Trigger if all of the conditions are satisfied” radio button is selected . This means that both triggers have to be met before an alert is triggered .

5. Click the Reporting tab . This tab allows you to specify that you want to repeat a trig-gered alarm based on a specified range or frequency . Of these two settings, the default alarm uses a frequency value of 5 minutes .



6. Click the Actions tab . When you do so, it becomes apparent that the alarm does not have any actions to use . There are typically two actions used in these scenarios: send an email to the administrator responsible for ESX/ESXi hosts or send an SNMP trap to a monitoring system that may then alert the same administrator or page someone who is responsible for that system . Click Add to choose one of these actions .

7. A new action, Send A Notification Email, is added to the list . It is not completely set up, though . By clicking in the Configuration field in the list, you can specify the email address to send the alert . If an SNMP trap is to be sent, you will also need to set up one or more monitoring receivers for the traps . There is no configuration setting for the alarm itself, so you will have to define the receivers using the Administration menu at the top of the vSphere Client . Click OK once the alarm is finished .


It is very important to provide some action for connectivity alarms. New users are many times unaware that the connectivity alarms will show an alert in vCenter by default, but will not notify anyone if they are not currently logged into the vSphere Client.

Relating the Alarm to the Affected ComponentWith connectivity alarms, knowing which alarm has triggered and what component is affected will depend on which object the alarm shows. For instance, if there has been a host outage, the alarm will appear on the host affected. If there has been a datastore con-nectivity outage, the alarm will show for that datastore. In addition, alerts will appear in the top-right corner of the vSphere Client (if the vCenter or datacenter object has been selected), just below the Search bar. Figure 9.4 shows in the top-right corner of the vSphere Client the number of alerts in vCenter that have triggered.

F I GU R E 9 . 4 Monitoring the number of alarms in vCenter

If the alert appears in the top-right corner of the vSphere Client, clicking the alert icon will take you directly to the alerts that have been triggered in vCenter. This provides a quick way to see all alarms and investigate which resource or host is experiencing an outage. Figure 9.5 shows the Alarms tab for the vCenter object and which alarm has triggered.

Depending on the view you’ve chosen, you may not see an alarm that has triggered. For instance, if you select a VM in the inventory in either Hosts And Clusters view or VMs And Templates view but the alert that has triggered is for a network outage, the alarm will not be seen nor will it be obvious. This is why defining an action for a connectivity alarm is so important. By having the vCenter server send an email or SNMP trap, no matter what view you may be in, you will still receive some communication that an alert has triggered.

F I GU R E 9 .5 Investigating triggered alarms


To ensure that vCenter can communicate an alarm to the appropriate administrator, you must define an email server to receive the alarms that have an “email” action. As an alterna-tive for some environments, an SNMP trap can be defined (you could do both, but usually an email or SNMP trap is defined exclusively). Exercise 9.2 provides the steps to define an email server to receive the alarms that have an email action.

E X E R C I S E 9 . 2

Setting Up an Email Server for vCenter

1. Log into the vSphere Client .

2. Click Administration vCenter Server Settings .

3. Choose Mail from the list on the left to display two fields: SMTP Server and Sender Account . Enter the appropriate information in both fields, and then click OK .

4. At this point, for any alarm that has an email action, vCenter will send the alert to the email server, which will then route the message to the administrator responsible .

Each alarm provides information on what object was affected and which trigger or trig-gers the alert uses. With this information, you can then investigate where the problem lies and potentially what needs to be done to correct the outage.

Creating and Responding to vCenter Utilization Alarms 467

Creating and Responding to vCenter Utilization AlarmsUtilization alarms are your best friend when monitoring an object’s usage of a particular resource. Without the alarms in vCenter, you would have a difficult time determining when a VM or host is unable to perform satisfactorily, without feedback from the end user of the server. Getting feedback from the end user when a VM is underperforming is not ideal in most environments. A proactive way to monitor resource usage should be implemented so that resource bottlenecks can be avoided and client satisfaction can be maintained.

With the use of utilization alarms, you can proactively monitor many different objects simultaneously and receive alerts either by email or SNMP traps when a particular alarm has triggered. If you are logged into the vSphere Client, these alarms will display for each object.

This section covers five exam subobjectives:

List vCenter default utilization alarmsNN

List possible actions for utilization alarmsNN

For a given alarm, analyze and evaluate the affected virtual infrastructure resourceNN

Create a vCenter utilization alarmNN

Relate the alarm to the affected resourceNN

Listing vCenter Default Utilization AlarmsThe number of default utilization alarms has been expanded with vSphere 4.0. Most of these alarms are for hosts and VMs. The one alarm that does not deal with hosts or VMs monitors datastore usage. Each of these default alarms are defined on the vCenter object and are inherited by the appropriate child objects further down in the hierarchy.

Table 9.4 lists the utilization alarms and what they monitor.

TA B lE 9 . 4 Default Utilization Alarms

Alarm Monitors

Datastore Usage On Disk Disk usage

Host CPU Usage CPU usage

Host Memory Usage Memory usage

Virtual Machine CPU Usage CPU usage

Virtual Machine Memory Usage Memory usage


With these five default alarms, vCenter can immediately monitor for these conditions. Each alarm has default setting for triggers, warnings, and alerts. In many cases, the default settings for the host and VM alarms that are included with vCenter are not appropriate for a customer’s environment. In such cases, you can adjust the default alarms to fit the environ-ment, or you can delete the alarms and create custom ones for specific hosts or VMs. As we saw with most connectivity alarms (the “condition” ones), each utilization alarm has no action associated. It is up to you to define an action or actions for each alarm.

Listing Possible Actions for Utilization AlarmsOnce a particular utilization alarm has triggered, an action is usually needed to either alert you of the condition or to respond to the condition in a proactive fashion. As we saw with the connectivity alarms, sending an email or SNMP trap is possible and is the approach used most often. Since this type of alarm is monitoring actual resource usage, there is usu-ally no need to provide any other action (such as the restart of a host or VM). With some misbehaving VMs that have runaway processes or that consume too much CPU or memory resources, a reboot of the VM may be necessary to correct the issue.

For a list of actions that are possible with a utilization alarm, please see Table 9.3 earlier.

For a Given Alarm, Analyzing and Evaluating the Affected Virtual Infrastructure ResourceWhen using utilization alarms, analyzing what is affected is again easy to ascertain. Since four of the alarms deal with CPU and memory usage, knowing which resource is being affected is obvious. Looking at Table 9.4, you’ll see that there’s one alarm that doesn’t relate to a host or VM: the Datastore Usage On Disk alarm. These default alarms give you a starting point for monitoring a host, VM, or datastore. The downside with these alarms is that they are not specific to a given customer’s environment. In many cases, you will dis-able the default alarms and create new ones that more closely align to thresholds (triggers) that are specific to your datacenter.

The Datastore Usage On Disk alarm triggers for a given datastore when the amount of free capacity has fallen below 25 percent for a warning or 15 percent for an alert. Figure 9.6 shows the default trigger settings for this alarm. This alarm is usually sufficient for all data-stores, but you can modify the default alarm to better monitor a specific environment’s needs. If some datastores are using thin-provisioned virtual disks, you can disable the default alarm and create a custom alarm that monitors spare capacity for each datastore’s particular utiliza-tion requirements.

There are two host usage alarms: Host CPU Usage and Host Memory Usage. These two default alarms provide you with a starting point for monitoring these two resources for each host. The default CPU alarm is set to monitor for CPU usage above 75 percent for a warning and 90 percent for an alert. These thresholds must be persistent for a period of 5 minutes for each setting to reduce false positives and can be adjusted to as little as 0 seconds to 60 min-utes. These settings may be sufficient, but in some environments, maybe not. In the latter case,


adjusting these settings may be necessary. The default memory alarm is set to monitor for memory usage above 90 percent for a warning and 95 percent for an alert. Again, these thresh-olds must be persistent for a period of 5 minutes for each setting to reduce false positives and can be adjusted to as little as 0 seconds to 60 minutes. Again, you can modify these settings to better align with your particular datacenter’s needs. Figure 9.7 shows the default triggers for the CPU alarm and Figure 9.8 shows the default triggers for memory.

F I GU R E 9 .6 Default trigger settings for datastore usage alarm

F I GU R E 9 .7 Default host CPU alarm trigger settings

F I GU R E 9 . 8 Default host memory alarm trigger settings


The last two default alarms are Virtual Machine CPU Usage and Virtual Machine Memory Usage. These two alarms monitor for generic resource utilization for these two resources. The downside to the CPU alarm in particular is that most VMs will not reach such high utilization values, 75 percent for a warning and 90 percent for an alert (these thresholds must be persistent for a period of 5 minutes for each setting to reduce false positives and can be adjusted to as little as 0 seconds to 60 minutes). The reason for this is that many VMs rarely use more than 10 percent of a processor. It would be a better practice to disable the default alarm that would be applied to all VMs in the vCenter server; you could then create custom alarms for specific folders, resource pools, or even the VMs themselves that monitor for usage that more closely aligns with a group of VMs or a single VM. In any event, the default alarm can monitor for heavy CPU usage.

For the memory alarm, the default settings may be of use or can be modified to fit more closely to an environment. In many cases, VMs are configured with the least amount of mem-ory necessary to still achieve a service level agreement (SLA) or meet an application owner’s approval. The default settings for this alarm are 85 percent for a warning and 95 percent for an alert. These thresholds must be persistent for a period of 10 minutes for each setting to reduce false positives and can be adjusted to as little as 0 seconds to 60 minutes.

F I GU R E 9 . 9 Default VM memory alarm trigger settings

Creating a vCenter Utilization AlarmSince the default usage alarms are sometimes too generic in a very complex and hetero-geneous environment, creating a custom utilization alarm may be necessary. As you saw with the default usage alarms, they monitor for high utilization for CPU and memory resources or high disk usage on a datastore. In many environments, a more specific trig-ger for a given alarm will need to be used that more closely monitors actual host or VM behavior. In addition, the default alarms are defined on the topmost object in the inven-tory hierarchy and therefore are being applied to every relevant object. This does not allow for one-off situations, nor does it allow for monitoring of an individual object’s circumstances or application behavior.

By creating custom usage alarms, you can set specific triggers that allow for monitoring specific conditions for a given host or, more likely, a VM. The process for creating the alarm is outlined in Exercise 9.3.


E X E R C I S E 9 . 3

Creating a Utilization Alarm for a VM

1. Log into the vSphere Client and on the Home page, in the Inventory section, click the VMs And Templates icon .

2. Click on a folder or VM and select the Alarms tab . Click the Definitions button in the top of the pane, just below the tab itself, and check to see what alarms are currently being applied to the object . Right-click on the blank space below the alarms and choose New Alarm from the context menu .

3. On the General tab, provide a name and a description that gives an indication of what is being monitored . You can be specific with the description so that another adminis-trator will know exactly why the alarm was created and what application or behavior is being monitored . Under Alarm Type, make sure Virtual Machine is selected from the Monitor drop-down list and that the “Monitor for specific conditions or state…” radio button is selected . If the alarm will be immediately used, leave the Enable check-box selected; otherwise, deselect the check box .



4. Select the Triggers tab . A new custom alarm will not have a trigger, so by clicking the Add button in the bottom right of the screen, you add a default trigger that will monitor CPU usage . If this is what you want to monitor, move on to the other col-umns to adjust their settings . Otherwise, click twice on the trigger name and click the pull-down menu . This will allow you to select the exact trigger needed for the alarm, either CPU or memory usage, in this case .

5. On the same tab, you will need to choose whether or not you are monitoring for usage that is above or below a certain threshold . Most alarms are monitoring for Is Above conditions . However, if you want to monitor for a condition when the VM has dropped below a certain threshold, then select Is Below in the Condition column . Next, provide the thresholds for a Warning or Alert and for how long those thresh-olds must be persistent before the alarm is triggered .

6. Select the Reporting tab . If you wish to define how often an alarm can repeat, in the Range section enter a percentage in the Repeat Triggered Alarm When Condition Exceeds This Range field . Alternatively, you can use the Frequency section to specify a number of minutes in the Repeat Triggered Alarm Every field .



7. Select the Actions tab to provide an action that the alarm can act on once the trigger(s) have been met . Clicking the Add button adds a default action, Send a Noti-fication Email, to the alarm . If this is the appropriate response, then supply an email address in the Configuration column . You can also choose which condition warrants the action by using the Green-to-Yellow, Yellow-to-Red, Red-to-Yellow, or Yellow-to-Green columns to provide specific conditions for the action and whether to act only once or to repeat .

8. If all is good with the settings that have been used and the alarm is ready to be put in play, click OK .

Relating the Alarm to the Affected ResourceAs you saw in Figure 9.5, vCenter will indicate if an alarm has triggered. If you click either the vCenter or the Datacenter icon at the top of the inventory hierarchy, the vSphere Client


will show the number of alarms that have been triggered in the top-right corner of the infor-mation panel. Click the alarm icon, and the vSphere Client will change to the Alarms tab for the particular object generating the alarm.

If the vSphere Client is in the Host And Clusters or VMs And Templates view, the affected object will display an alarm icon. If the alarm was issued for a datastore, you will need to be in Datastores view to see the affected datastore. You will not see alarms for objects outside a particular view’s definition. For example, if the client is in the Host And Clusters view and a host has been selected in the inventory, you will not see alarms for data-store usage anywhere in the vSphere Client.

Once you see an alarm and display the Alarms tab for that object, you can easily see the resource for the host or VM that triggered the alarm.

Monitoring vSphere ESX/ESXi and Virtual Machine PerformanceThe ability to monitor the performance of an ESX/ESXi host or a VM is of great importance. Sharing of resources between VMs can be intensive on a host. Without the proper tools for monitoring this sharing, many server owners and datacenter managers would become disen-chanted with virtualization. Thankfully, VMware has supplied more than one tool from the beginning to analyze resource usage and performance metrics.

You will need to be able to work with several important performance metrics related to ESX hosts and VMs. Using more than one tool is also required to get a complete picture of resource contention or performance bottlenecks. The two tools in particular are the vCenter Performance tabs and the esxtop CLI tool. In this section we will review those tools and the metrics that you can monitor.

This section covers eight exam subobjectives:

Identify critical performance metricsNN

Explain memory metricsNN

Explain CPU metricsNN

Explain network metricsNN

Explain storage metricsNN

Compare and contrast Overview and Advanced chartsNN

Create an Advanced chartNN

Determine host performance using guest PerfmonNN

Identifying Critical Performance MetricsEvery administrator has the task of making sure the VMs under their control are achieving their best results. This is a balancing act, though, due to the number of VMs running on


the same host. In the past, dedicating one physical server to an application made this task relatively easy, but with virtualization, there are many applications running in separate vir-tual machines and sharing the same host. This sharing leads to contention among the VMs, especially when more than one VM is competing for the same resource or the host has too many VMs.

There are many tools used to examine resource contention, but the two VMware tools most often used are the Performance tabs for inventory objects in the vSphere Client and the esxtop CLI tool. With these two tools, you can analyze many performance metrics, both in real time and over defined intervals to identify bottlenecks or resource contention.

Table 9.5 lists several of these metrics that are considered critical to performance. Due to some differences in the two tools, the metrics are sometimes loosely affiliated (Some metrics are used in one tool but not the other, or, in some cases, the metric in one tool is approximately analogous to a metric in another tool.)

TA B lE 9 .5 Performance Metrics for esxtop and Performance Tabs

esxtop Performance Tab Description

%RUN CPU Usage Physical CPU scheduling as a percentage or CPU usage in MHz

%RDY CPU Ready Percentage of time the VM was ready to do work, but was not scheduled on a physical CPU, or the time in milliseconds between being scheduled

%CSTP Time VM spent waiting for more than one CPU for scheduling (only applicable for SMP VMs)

MEMCTL Memory Balloon (Host) Sum of memory pages that have been reclaimed by balloon driver

SWAP Memory Swapped Used Sum of swapped memory pages

KAVG Kernel Disk Command Latency

Average amount of time spent by the VMkernel on a SCSI command (less than 2–3ms for best performance)

DAVG Physical Device Command Latency

Average amount of time for a SCSI command to complete with the physical device (less than 10–20ms for best performance)

MbTX/s Network Data Transmit Rate

Network throughput transmitted in MB

MbRX/s Network Data Receive Rate

Network throughput received in MB


With the metrics listed in Table 9.5, accessing performance for a host or VM is fairly easy.

Performance Metrics: Ready Time

Many times, the performance of a virtual machine depends on the number of VMs com-peting for the host’s resources . One metric that can show the amount of competition and verify that the VM could be doing more work is a metric called Ready Time . This counter can be observed in either esxtop or the Performance tab in vCenter .

Suppose a customer has an ESX host with 10 virtual machines . Two of the VMs are report-ing issues with performance from their respective server owners . Both VMs use CPU resources heavily, but there are only four processors on the host . This situation has created a condition where the two CPU-heavy VMs are competing against themselves and the other eight VMs, plus the Service Console of the host . How can we verify this condition?

By opening esxtop on the host’s Service Console, we can look at the CPU metrics for each VM running on that host . Specifically, we can look at the two VMs reporting per-formance problems . What we find is that the column labeled %RDY is showing numbers over 40 percent and sometimes spiking to 60 percent . This indicates CPU contention and that the VMs could be doing much more work if they could be scheduled more often .

The best way to prioritize these two VMs is to give them reservations that allow them to grab enough CPU scheduling to satisfy their respective owners . This setting may need to be adjusted a couple of times to find the right balance . Also, if the two VMs with reservations do not allow the other eight VMs to do their work, then moving one of the heavy-CPU VMs to another host may be necessary .

Keeping an eye on the %RDY column can help make these determinations . Every VM is different; what is considered high for one VM may not be for another . Once the complaints come in, that settles the question .

Explaining Memory MetricsOf all the resources on an ESX/ESXi server, memory is usually the one resource that a host may run out of the quickest. In addition, memory is used by the VMs individually, by the VMkernel, by the Service Console, for overhead (memory used by the VMkernel to virtualize the VM), and by other processes needed for virtualization in general. Keeping track of how memory is being used, shared, ballooned, and swapped is a critical aspect of any administrator’s job in ensuring that all components and VMs are able to perform at a sufficient level.


Table 9.6 lists several of these metrics. Due to some differences in the two tools, the met-rics are sometimes loosely affiliated.

TA B lE 9 .6 Memory Metrics for esxtop and Performance Tabs


PMEM Total, Service Console, VMkernel, and other, including VMs

VMKMEM Memory Used by VMkernel Memory managed by VMkernel, memory used by the VMkernel, reserved or unreserved memory

COSMEM Memory free, swap size, swap used, read and written

PSHARE Memory Shared (Host), Memory Shared Common

Sum of guest memory being shared on host, sum of memory that is in common across all worlds, amount of memory saved on host (esxtop)

MEMSZ Configured guest memory

MCTLSZ Memory Balloon Memory reclaimed by balloon driver

SWCUR Memory Swapped Guest physical memory swapped to the swap file

SHRD Memory Shared (Guest) Memory shared between VMs by the Transparent Page-Sharing mechanism

OVHD Memory Overhead Memory used by the VMkernel to run VM

Explaining CPU MetricsWhen you’re working with CPU metrics, overall usage and a virtual machine’s specific use should be analyzed. In some cases, you’ll watch the overall utilization numbers so that loads on one ESX server do not become too heavy. Overutilization of an ESX server causes other resources to become sluggish. This is due to the VMkernel not having available CPU cycles to work with I/O requests.

The Performance tab provides several metrics that are not available in esxtop, and vice versa. Using both tools is essential in getting a clear picture of CPU utilization and deter-mining which VMs are the heaviest consumers.



TA B lE 9 .7 CPU Metrics for esxtop and Performance Tabs


PCPU(%) CPU Usage (Host) CPU utilization per physical CPU

LCPU(%) Logical CPU utilization when hyper-threading has been enabled

%RUN CPU Usage Physical CPU scheduling as a percentage

%Used Equal to the sum of %USED+%SYS-%OVRLP

%SYS CPU System Percentage of time the system commits to a VM or the time in milliseconds

%OVRLP CPU time spent on system services on behalf of VM group

CPU Usage in MHz Amount of CPU utilization (either host or VM)

Explaining Network MetricsNetworking metrics are easy to follow and analyze. In particular, pay attention to the transmit and receive rates for throughput and bandwidth consumption. Also, the number of dropped packets in either direction will have a significant impact on performance for the VM’s network service level, and potentially, the host’s storage performance when using iSCSI or NFS storage.

Table 9.8 lists several of these metrics. Due to some differences in the two tools, the metrics are sometimes loosely affiliated.

TA B lE 9 . 8 Network Metrics for esxtop and Performance Tabs


SPEED Speed of network adapter

FDUPLX Duplex of network adapter

PKTTX/s Network Packets Transmitted

Number of packets transmitted



PKTRX/s Network Packets Received

Number of packets received

%DRPTX droppedTx Percentage or number of transmit packets dropped

%DRPRX droppedRx Percentage or number of receive packets dropped

Explaining Storage MetricsThe storage metrics most often used are in two groups: throughput and queue lengths. Each type of metric provides insight into performance and utilization. Typically, you will analyze the READ/s and WRITES/s for throughput service levels and the latency and queue lengths as impediments to performance.


TA B lE 9 . 9 Storage Metrics for esxtop and Performance Tabs


READS/s Disk Read Requests Number of read requests (either host or VM)

WRITES/s Disk Write Requests Number of write requests (either host or VM)

MBREAD/S Disk Read Rate Rate at which data was read (either host or VM)

MBWRTN/s Disk Write Rate Rate at which data was written (either host or VM)

AQLEN Storage adapter queue depth

LQLEN LUN queue depth

QUED Queue Command Latency

Number of VMkernel commands currently queued or time spent queued

TA B lE 9 . 8 Network Metrics for esxtop and Performance Tabs (continued)


Comparing Overview and Advanced ChartsWith the new vSphere Client, you have new ways to work and view performance-related data in vCenter. The new default view when working with the Performance tab for an inventory object is the Overview chart. This new chart provides an at-a-glance view of all four resource types on one page. With this view, it is easy for you to get a feel for how the VM or host is currently loaded. If you want a more detailed view of how a particular resource is being used, click the Advanced button on the Performance tab to view one resource at a time.

The Overview button on the Performance tab displays information on the following resources: CPU, Memory, Disk, and Network. Figure 9.10 shows an example of this view.

F I GU R E 9 .10 Overview charts for a host

The counters that are presented are the ones many administrators use to analyze perfor-mance and utilization on an ESX/ESXi host. The charts displayed for hosts are:

CPU Usage as a percentage, usage in MHz

Memory Ballooning in MB, swap rate in/out, usage as a percentage

Disk Milliseconds in latency, usage in KB/s

Network Usage in MB/s

The charts displayed for VMs are similar:

CPU Usage as a percentage and ready time, usage in MHz

Memory Ballooning in MB, swap rate in/out, usage as a percentage


Disk Usage in KB/s

Network Usage in MB/s

VM’s Host Summary Charts

The charts are fairly easy to understand, but for each chart, there is an Info button in the top-right corner that provides the following information:

Chart label and descriptionNN

Chart analysisNN

Performance analysis adviceNN

With this information, you can make informed decisions about host or VM utilization and determine whether or not some type of intervention is needed. In many cases, no inter-vention is necessary, but knowing how a host or VM is performing helps you develop a baseline for normal activity in case issues in the future require analysis and remediation.

Creating an Advanced ChartThe Overview charts are good for at-a-glance information, but there are times when you will need more information. In these cases, you can click the Advanced button in the top-left corner to bring up a single chart for a single resource, which by default is the CPU view. Figure 9.11 shows this view.

F I GU R E 9 .11 Default Advanced view for a host


As you can see, the chart is larger, easier to read in some cases, and allows you to view more than one counter. Along the top right of the chart are icons that let you print, refresh, save, or open the chart into a separate window. This latter feature allows you to place multiple charts on different monitors or view them side by side.

At the bottom is the chart legend with the objects and counters listed using a variety of colors to help differentiate one counter from another. If this default view is not presenting the information that you need, at the top of the chart is a link labeled Chart Options. Click this link to see a multitude of options for customizing the chart to meet your needs. Figure 9.12 shows the dialog box and the options for a host object.

F I GU R E 9 .12 Customization of a performance chart

Some of the items that can be changed or chosen in the customization dialog box include the following:

Resource CPU, Disk, Network, Memory, System (host view)

Interval Realtime, Past Day, Past Week, Past Month, Past Year, Custom

Chart Type Line Graph, Stacked Graph, Stacked Graph Per VM (host only)

Objects CPU (both virtual and physical), hosts, VMs, physical and virtual devices


Counters These include the following:

CPU Usage%, Usage MHz, Used, Ready, Wait

Disk Read Rate, Write Rate, Usage, Kernel Command Latency, Physical Device Command Latency

Memory Memory Used By VMkernel, Swap Used, Active, Balloon, Shared Common, Usage

Network droppedTx, droppedRx, Data Receive Rate, Data Transmit Rate, Usage, Packets Received, Packets Transmitted

With the level of customization possible, it is easy to find a bottleneck on any resource or observe utilization for a host, VM, or other object. Exercise 9.4 will go through the pro-cess of creating an Advanced chart.

E X E R C I S E 9 . 4

Creating an Advanced Chart

1. Log into the vSphere Client and on the Home page, in the Inventory section, click the VMs And Templates icon .

2. Click on a VM, then click the Performance tab . Once the Overview chart is dis-played, click the Advanced button in the top-left corner of the chart view; then click Chart Options .



3. Under Chart Options, click to expand CPU and choose Real-time . This will give you many options to choose from for counters . Under Chart Type, leave the Line Graph radio button selected; then under Objects choose virtual CPU “0” and the virtual machine name .

4. Next, under Counters, choose CPU Usage and CPU Ready . If any other counters are selected, deselect them .

5. Click OK and the new Advanced chart will appear .



6. With Advanced charts, you can show only two units of measurement at a time . In this case, we chose CPU Usage, which is measured as a percentage, and CPU Ready, which is measured in milliseconds . If we wanted to also see the Usage in MHz, we would have to go back into Chart Options and deselect one of our counters and then add the new counter with the new unit of measurement . Also, in the Legend pane, you can click on one of the colors to emphasize that counter in the chart .

7. Once you are done with that particular chart, you can print, save, or display the chart in a separate window so that you can move on to another task or chart .

Determining Host Performance Using Guest PerfmonWith the introduction of vSphere, there is now a way to monitor guest performance using metrics provided by the ESX/ESXi host inside the guest operating system. By installing the latest version of VMware Tools into a Windows VM, you install two new perfor-mance objects used with Performance Monitor (Perfmon) as well: VM Processor and VM Memory. With these two objects, several counters are provided that give you an accurate picture of the virtual machine’s performance and how it could be impacting the host, albeit indirectly. Figure 9.13 shows Performance Monitor open and the drop-down menu with these two new options.

With these two objects and the attending counters, the server administrator as well as the host administrator can see the same performance counters for the VM that are used in vCenter. If the host is heavily used for either CPU or memory resources, using the Perfmon


counters such as Effective VM Speed In MHz can show that the VM is not getting what it needs to effectively work through a load. If the VM has no limit for CPU or memory but it is only getting an amount that is less than what a physical processor can provide or less than what the VM is configured for in memory, then there may be too much competition for resources on that host.

F I GU R E 9 .13 Performance Monitor in a Windows VM

The best way to meet service levels is to give the VM a reservation or increase its shares. Once these changes have been made to the VM’s settings, Performance Monitor should show an improvement in the VM’s ability to get the resources it is requesting.

SummaryIn this chapter, we showed you how to create connectivity and utilization alarms as well as monitor virtual machine performance. By using this information, you will be better informed of the performance of your hosts as well as resource utilization. Without these alarms and metrics, it would be nearly impossible to properly diagnose and remediate conditions that are having a negative impact on the virtual infrastructure.

Using connectivity alarms provides you with critical information about the loss of a resource and how it impacts the virtual infrastructure. Losing network or datastore con-nectivity has significant consequences and must be dealt with immediately once the alarm has been triggered. We explored the actions associated with this type of alarm as well.

Exam Essentials 487

The utilization alarms give you the information needed to monitor resource usage and any negative consequences overutilization can cause with any resource. Overutilization of any resource must be monitored so that an appropriate response can be implemented. vSphere provides enhanced versions of these alarms that are more effective in monitoring usage conditions.

Using the metrics provided by vSphere, you can easily monitor virtual machine perfor-mance. We looked at the various metrics for memory, CPU, network, and storage resources. The two different charts available, Overview and Advanced, provide insight into perfor-mance trends and utilization. With the latest version of VMware Tools, the Perfmon objects and counters that can be seen inside a Microsoft Windows VM give you greater insight into the resource access and usage for a given VM.

Exam Essentials

Know how to create and respond to connectivity alarms. List the various connectivity alarms and possible actions for each. Practice the creation of a connectivity alarm. Be able to describe the relationship between the alarm and the resource.

Know how to create and respond to vCenter Utilization alarms. List the different utiliza-tion alarms and possible actions for each. Practice the creation of a utilization alarm. Be able to describe the relationship between the alarm and the resource.

Know how to monitor ESX/ESXi and virtual machine performance. Be able to identify different performance metrics for memory, CPU, network, and storage resources. Be able to compare the use of the Overview and Advanced charts for ESX/ESXi and virtual machines. Practice the creation of an Advanced chart.


Review Questions

1. Which of the following is a network metric?

A. READ/s

B. LQLEN

C. %RUN

D. %DRPTX

2. You suspect a VM is suffering from performance issues due to the physical server having insufficient CPU for all of the collective VMs’ needs. Which of the following CPU metrics would best help determine which VMs are waiting on physical CPUs?

A. CPU Usage

B. CPU Ready

C. CPU Wait

D. CPU Usage (Host)

E. CPU System

3. Which of the following is not a reason to create a custom alarm in vCenter? (Choose two.)

A. You want to define a specific SNMP trap receiver.

B. You want to limit the VMs an alarm applies to.

C. You need DRS/HA cluster-specific alarms.

D. You need a VM memory alarm to apply to your entire inventory.

E. You want to specify an alarm icon color change.

4. The new Perfmon objects installed when you install the latest vSphere VMware Tools into a Windows VM include which of the following? (Choose two.)

A. VM Disk

B. VM Memory

C. VM Network

D. VM Processor

E. VM USB


5. Which of the following is a default vCenter connectivity alarm?

A. Host Processor Status

B. Virtual Machine Error

C. Cannot Connect To Storage

D. Host Storage Status

E. Migration Error

6. Which of the following is not a disk performance metric?

A. READ/s

B. LUN_LATENCY_QUEUE_DEPTH

C. AQLEN

D. LQLEN

7. The default virtual machine memory usage alarm is set to trigger an alert at?

A. 85 percent usage for 5 minutes

B. 85 percent usage for 10 minutes

C. 95 percent usage for 5 minutes

D. 95 percent usage for 10 minutes

E. 50 percent usage for 5 minutes

8. An ESX server suffers a host failure. You have configured the vCenter alarm Host Connec-tion And Power State to generate an SNMP trap. You are not receiving any SNMP traps indicating the ESX host failure. What is the likely cause of this?

A. You have not defined an SNMP trap receiver in the Administration vCenter Server Settings SNMP properties.

B. You have not defined an SNMP trap receiver in the Administration Custom Attri-butes properties.

C. You have not enabled the SNMP agent in the Service Console.

D. You have not installed the SNMP vCenter plug-in.

E. You have suffered a failure in the Service Console virtual switch.

9. Which of the following are not valid actions for virtual machine alarms?

A. Send A Notification Email

B. Run A Command

C. Migrate VM

D. Reboot Host

E. Enter Maintenance Mode


10. When you attempt to create an advanced performance chart (see the following graphic), you receive an error. What is happening to generate the error?

A. You can only graph two discrete data points at a time with Advanced graphs.

B. You can only graph one rollup type at a time with Advanced graphs.

C. You can only graph two discrete units at a time with Advanced graphs.

D. In fact, you will not receive an error; the graph will be produced as expected.

11. A custom alarm you have created repeatedly triggers on the same event every minute. As the trigger sends out an email, you would like to avoid having to deal with the extra redundant email messages every minute. What could you do to help eliminate these redundant email messages? (Choose two.)

A. Uncheck the Enable This Alarm option in the alarm’s General preferences tab.

B. Increase the trigger condition length in the alarm’s Triggers preferences tab.

C. Increase the Repeat Triggered Alarm Every… Minutes value in the alarm’s Reporting preferences tab.

D. Increase the Repeat Triggered Alarm When Condition Exceeds This Range in the alarm’s Reporting preferences tab.

E. Change Repeat to Once in the color change box of the alarm’s Actions preferences tab.

12. You receive a Host And Connection Power State alarm. In order to further diagnose why this alarm was triggered, where might you look next?

A. The vSphere Client log

B. The Service Console log

C. The Tasks & Events tab

D. The alarm detail window (brought up by right-clicking the specific alarm message entry)


13. You have several VMs running on an ESX server, none of which are remotely close to 100 percent CPU usage. The ESX server itself is also not remotely close to 100 percent CPU usage. Despite this, you notice all of the VMs are accumulating a lot of CPU Ready time. What might be the underlying cause of this?

A. The VMs are I/O bound.

B. The VMs are network bound.

C. You have masked out NX/XD for the VMs.

D. The VMs have multiple virtual CPUs but are only actively using a small fraction of a single CPU’s cycles.

E. Several VMotion migrations are occurring.

14. Looking at CPU Usage for an ESX host, you notice the physical processors are being overutilized. Looking at CPU Usage for all the VMs running on the same ESX server, you notice none of the VMs are overutilized. Several users are complaining, however, that their VMs seem sluggish. What could be the underlying cause?

A. You have not enabled hyperthreading on your ESX server.

B. You have enabled hyperthreading on your ESX server.

C. The VMs are filling the physical NICs with network traffic

D. The VMs have CPU reservations that are set too low.

E. You have VMs unnecessarily configured as multiprocessor servers.

15. You suspect your VMs are suffering from a physical memory shortage on your ESX or ESXi server. Which of the following metrics would be your best first-shot at determining you have a physical memory shortage on your ESX server(s)?

A. MEMCTL

B. SWAP

C. VMKMEM

D. MEMSZ

E. PMEM

16. You receive a Cannot Connect To Storage alarm in vCenter. Which of the following may indicate the reason for this alarm? (Choose two.)

A. Lost network connectivity

B. Incorrect CCAgent

C. Lost storage connectivity

D. Host connection lost


17. Which of the following is not specified when creating a new, custom alarm in vCenter?

A. Enabling the alarm

B. Trigger condition length

C. Reporting interval

D. Color change

E. Alarm type

18. You are setting up a virtual machine notification alarm. You want to trigger on the virtual machine’s CPU usage. When the alarm triggers, which of the following triggers are not valid?

A. Send A Notification Email

B. Send A Notification Trap

C. Suspend The VM

D. Migrate The VM Using VMotion

E. Change The VM’s CPU Resource Limit

19. The default Host CPU Usage alarm is set to trigger an alert at:

A. 75 percent CPU for a period of 5 minutes

B. 75 percent CPU for a period of 10 minutes

C. 90 percent CPU for a period of 5 minutes

D. 90 percent CPU for a period of 10 minutes

E. 50 percent CPU for a period of 5 minutes

20. What is the default action for a vCenter connectivity event-based alarm?

A. Send A Notification Trap

B. Run A Command

C. Enter Maintenance Mode

D. Enter Standby Mode

E. Reboot Host

F. Shutdown Host



1. D. READ/s and LQLEN are disk metrics measuring the number of read requests (host or VM) per second and the LUN queue depth respectively. %RUN is a CPU metric measuring CPU scheduling as a percentage. %DRPTX is the percentage of transmitted packets dropped.

2. B. The very definition of the Ready number is a VM ready to run but waiting on a physical processor to become available.

3. A, D. You can define a trap receiver on any of the built-in alarms by simply filling out the trap receiver information in vCenter, and so no custom alarm is needed there. The default built-in alarms apply to the entire inventory, so a custom alarm would not be needed in that case either.

4. B, D. The new Perfmon extensions include processor and memory virtual statistics. This allows you to see some of the virtual statistics from within the VM itself. Depending on whether or not you actually want the administrator of a VM to see these sorts of virtual statistics, this can be a good or a bad thing.

5. C. The default vCenter connectivity alarms are Cannot Connect To Network, Cannot Connect To Storage, Host Connection And Power State and Host Connection Failure.

6. B. READ/s is the number of read requests (host or VM) per second, AQLEN is the storage adapter queue depth, and LQLEN is the LUN queue depth. Option B is entirely made up.

7. D. The 85 percent threshold is for a warning and the 95 percent threshold is the level for an alert. Virtual machine memory usage defaults are all based on 10-minute duration.

8. A. In addition to specifying the SNMP alarm action in the Action tab of the alarm’s properties, you need to specify the SNMP trap receiver’s IP address in the Administra-tion vCenter Server Settings properties.

9. D, E. The incorrect answers apply to ESX hosts, not VMs. The valid actions for VMs are Send A Notification Email, Send A Notification Trap, Run A Command, Power On VM, Power Off VM, Suspend VM, Reset VM, Migrate VM, Reboot Guest On VM and Shutdown Guest On VM.

10. C. Advanced graphs only support two discrete units at a time. So, although you can graph more than two data points, they must consist of, at most, two units (percent, mil-lisecond, MHz, etc.).

11. C, D. Alarms have two general mechanisms for preventing repeated triggering and they are both found in the alarm’s Reporting preferences tab. For numeric alarms, option D will keep an alarm from retriggering until the initial trigger value goes up by this amount. Also, an alarm will not retrigger within the time interval specified in the Repeat Triggered Alarm Every box (option C).

12. C. The Tasks & Events tab will contain information as to who initiated the shutdown (assuming the shutdown was not the result of a power failure or some other acute problem).


13. D. When you build a VM with multiple vCPUs, all of the vCPUs must be simultaneously scheduled onto physical CPUs regardless of whether the VM is actively using its allotted vCPUs. In this case, you would notice a lower than expected physical CPU utilization on the ESX server due to the multiple idle vCPUs. VMs that might otherwise be able to run will be accumulating Ready time, waiting on the physical CPUs to become available.

14. C. Remember, high virtual network activity can generate a significant CPU load. Sending and receiving network packets, from a CPU standpoint, is not free.

15. A. MEMCTL indicates VM memory ballooning—that is, the VMkernel is trying to reap-portion physical RAM among the VMs due to a shortage of physical memory. SWAP is used after MEMCTL has hit its useful limit and so is a secondary indicator. VMKMEM is the amount of memory used by the VMkernel and does not directly relate to VM memory shortages. MEMSZ represents the configured guest memory and also does not necessarily indicate a memory problem with VMs. Finally, PMEM is the total physical memory used by the Service Console, VMkernel, and VMs.

16. A, C. Losing storage connectivity may be caused (in addition to the more obvious option C) by losing network connectivity if the storage is IP based, such as NFS or iSCSI.

17. C. Alarm definitions include a check box for enabling the alarm, the trigger length (how long the alarm condition must persist before the alarm triggers), the icon color change, and the type of alarm (host or VM). Although there is a report frequency in the Reporting tab, there is no report interval field anywhere in the alarm definition preferences.

18. E. Changing VM’s resource values are not part of an alarm’s allowed actions.

19. C. The 75 percent threshold is for a warning and the 90 percent threshold is the level for an alert. Host CPU alarm defaults are all based on 5-minute duration.

20. A. By default, vCenter connectivity alarms are set to send an SNMP notification trap.

Chapter

10Performing Basic Troubleshooting


Perform Basic Troubleshooting for ESX/ESXi Hosts.NÛ

Understand general ESX Server troubleshooting guidelines .NN

Troubleshoot common installation issues .NN

Monitor ESX Server system health .NN

Understand how to export diagnostic data .NN

Perform Basic Troubleshooting for VMware FT NÛand Third-Party Clusters.

Analyze and evaluate VM population for Maintenance mode NN

considerations .

Understand manual third-party failover/failback processes .NN

Troubleshoot Fault Tolerance partial or unexpected failover .NN

Perform Basic Troubleshooting for Networking.NÛ

Verify VM is connected to the correct port group .NN

Verify port group settings are correct .NN

Verify that the network adapter is connected within the VM .NN

Verify VM network adapter settings .NN

Verify physical network adapter settings .NN

Verify vSphere network management settings .NN

Perform Basic Troubleshooting for Storage.NÛ

Identify storage contention issues .NN

Identify storage overcommitment issues .NN

Identify storage connectivity issues .NN

Identify iSCSI software initiator configuration issues .NN

Interpret Storage Reports and Storage Maps .NN

Perform Basic Troubleshooting for HA/DRS and VMotion.NÛ

Explain the requirements of HA/DRS and VMotion .NN

Verify VMotion functionality .NN

Verify DNS settings .NN

Verify the Service Console network functionality .NN

Interpret the DRS resource distribution graph and NN

target/current host load deviation .

Troubleshoot VMotion using topology maps .NN

Troubleshoot HA capacity issues .NN

Troubleshoot HA redundancy issues .NN

This chapter will explore the basics of general troubleshooting of an ESX server. We’ll also discuss common troubleshooting steps for ESX/ESXi installations. Next, we’ll look at monitoring

ESX/ESXi server system health and how to export diagnostic data in case problems arise.We’ll also discuss troubleshooting various cluster scenarios. We’ll consider VMware FT

specifically and other third-party clusters generally. Also, we’ll analyze virtual machine loads and see how they impact Maintenance mode usage.

This chapter includes an in-depth look at troubleshooting networking issues that may arise on ESX hosts. Networking, using vSphere 4.0, is a complex array of virtual switches, port group settings, policies, uplink adapters, and virtual adapters, all of which can be used incor-rectly. Several command line–based tools will be explored to help you identify what is wrong.

We also examine storage-related troubleshooting. Since several technologies can be used for storage, connectivity and contention issues are primarily what can go wrong. In addition, we’ll look at various reports and storage-related maps used to help diagnose problems.

Finally, this chapter investigates various problems that can impact proper HA/DRS and VMotion activities. Some problems are network related; others issues can result from incorrect settings. We’ll also look at the many graphs, reports, and maps used in helping troubleshoot datacenter-centric operations.

Performing Basic Troubleshooting for ESX/ESXi HostsBasic troubleshooting of an ESX/ESXi server is necessary for most administrators. As nice as the vSphere Client is, it is not a great troubleshooting tool. Many times, you’ll have to use command-line tools to identify and correct problems dealing with network-ing or storage. In addition, knowing which logs to view and export is also helpful in finding and correcting problems.

This section covers four subobjectives:

Understanding general ESX server troubleshooting guidelinesNN

Troubleshooting common installation issuesNN

Monitoring ESX server system healthNN

Understanding how to export diagnostic dataNN

498 Chapter 10 N Performing Basic Troubleshooting

Understanding General ESX Server Troubleshooting GuidelinesIn a perfect world, administrators wouldn’t have to troubleshoot misbehaving products or applications. In the real world, problems related to an ESX/ESXi server sometimes happen, although not frequently. To know the appropriate response for a problem, you must have expe-rience using the product under various conditions or situations. At the very least, you will need to assess where the problem lies and then use the available tools to remediate the problem.

ESX hosts have a management side, the Service Console, and a virtualization side, the VMkernel. Depending on the problem, you can many times pick one side or the other as a basis for troubleshooting. For example, if someone is having trouble logging into the ESX server at the console or with ssh, then the problem may lie with the user accounts created and stored locally on the Service Console. If a user is trying to power on a VM and is receiving a “resource not available” error, the problem may lie with the VMkernel.

The tools that are available for troubleshooting these problems are both graphical and com-mand line oriented. Troubleshooting with the vSphere Client connected to ESX/ESXi server can sometimes help you identify problems with configuration, networking, or storage. Other problems are hard to identify with the vSphere Client and require using command-line tools. This is due to connectivity issues or problems that are not easily shown in the graphical cli-ent. Here’s an example: if the Service Console networking fails, logging into the physical local console and using command-line tools are all that can be used. An example of a command-line tool that could help address this problem is esxcfg-vswif -l; this command identifies the Service Console port and tells you whether or not it is configured properly and functioning.

Many problems are difficult to identify without some additional context or information. ESX/ESXi hosts have several log files that can shed light on a variety of problems. If the server is an ESX host, common log files that can be searched or analyzed are /var/log/messages, /var/log/vmkernel, /var/log/vmkwarning, and /var/log/secure. If the host is an ESXi server, the logs can be accessed using the vSphere Client or using the “Technical Support Mode” command line to view them. The logs are available on ESXi or /var/log/messages and /var/log/vmware/hostd-x.log.

Connecting to ESX/ESXi servers and using command-line tools can also be accomplished using the vCLI environment or the vMA appliance. Either environment provides the ability to run a variety of commands to troubleshoot various problems on a host.

Troubleshooting Common Installation IssuesThe installation of an ESX host has been streamlined over the years to avoid presenting too many challenges to the administrator. That’s not to say that an installation will not have its challenges, but the chances of incorrectly installing ESX or ESXi have been lessened. There are three main areas that can present challenges to the installer:

Hardware compatibilityNN

Partitioning or installation volume locationNN

IP and hostname informationNN

Performing Basic Troubleshooting for ESX/ESXi Hosts 499

Most people today recognize that installing ESX is not the same as installing a popular operating system when it comes to hardware choices. VMware must develop and write specific drivers or modules so that the VMkernel can interact with various hardware devices. Given that there are almost infinite possibilities for hardware combinations, VMware provides a Hardware Compatibility portal on their website to guide the end user with choices from many vendors on particular systems and hardware devices that are compatible with ESX/ESXi serv-ers. Be sure to choose hardware that is published on this portal.

In most instances, when installing ESX/ESXi, a choice is made where to install the software. Local storage for the installation is many times used, but can sometimes be complicated during the installation by connecting the ESX/ESXi server to the SAN and allowing the storage array volumes to be seen by the installer. One best practice is to disconnect the ESX/ESXi server from the SAN while performing the installation so that local storage is all that is presented.

If a boot-from-SAN scenario is preferred, many times for blade architectures, then ensure that the storage array only presents to the ESX installer the one LUN for installing and boot-ing the ESX server. This LUN has to be private and not shared between other ESX servers.

The next area of the installation that can be a source of problems is the IP address, hostname, and physical network interface to be used for management. It’s vital that you enter the proper values for the IP address, subnet mask, default gateway, and DNS servers. In addition, you must select the correct physical NIC to be used for communication. You may have to do some research to identify on the back of the server which NIC is to be connected to the management network and then correlate this device to the PCI address given in the installation. Using a test server and the command esxcfg-nics -l can help in identifying a NIC’s PCI address and its location on the back of the server. Disconnect one adapter at a time, and this command will show the network interface “down” and help in identifying the proper PCI address. Figure 10.1 shows an example output from this command.

As mentioned earlier, there are fewer problem areas that require troubleshooting the installation of an ESX server. Review Chapter 1, “Planning, Installing, and Upgrading VMware ESX/ESXi,” for more information on the installation particulars and proper setup procedures.

F I GU R E 10 .1 Identifying NIC adapters and their associated PCI address


Monitoring ESX Server System HealthOne of the best features to be added in vSphere 4.0 is a fairly detailed hardware monitoring function. Previously, the user would have to install an agent locally on the ESX host to moni-tor for hardware problems, but no more. Today, vSphere provides hardware health monitoring as a part of the standard vCenter product. Depending on the hardware being used and what sensors are built in, vCenter can monitor a whole range of hardware components. These hard-ware components are:

ProcessorNN

MemoryNN

FanNN

VoltageNN

TemperatureNN

PowerNN

NetworkNN

BatteryNN

StorageNN

Cable/interconnectNN

Software componentNN

WatchdogNN

OtherNN

These hardware components can be monitored by connecting the vSphere Client directly to the ESX/ESXi host or to the vCenter server. Alarms can also be configured that alert you when hardware health faults. Exercise 10.1 lists the steps to view the hardware health status.

E X E R C I S E 10 .1

Viewing the hardware health Status


2. On the Home page, in the Inventory section, click the Hosts And Clusters icon . Click on one of the ESX hosts to select it in the inventory .

3. In the informational panel, select the Hardware Status tab .

4. On this tab are a few options . Along the top are several tab-specific operations such as Update, Reset Sensors, Print, Export, and Refresh Page . Next, there is a drop-down box to select what you are interested in monitoring, such as Sensors (the default), Alerts And Warnings, and System Event Log . If you leave the default Sensors option, you can view the various hardware components that are available on that server . If there is a sensor for that component, you will see its current state in the Status column .

Performing Basic Troubleshooting for ESX/ESXi Hosts 501


5. By expanding each hardware component, you can dive into the specifics of the component and how it is operating, either acceptable or beyond normal limits .

Understanding How to Export Diagnostic DataThere will be times when you need to collect log files and other support information when troubleshooting an ESX/ESXi server. The easiest methods for collecting the log files are using the vSphere Client or running commands locally on the ESX server. Each method provides a bundle of files that can be easily exported for analysis locally or by VMware. Both vCenter and ESX/ESXi have the ability to export these log file bundles, but this sec-tion will only discuss how to do so for an ESX server.

The safest and easiest way to export the log file bundle for an ESX/ESXi server is to use the vSphere Client functionality. There are two ways to access this functionality. You can highlight the ESX host in the inventory and export the diagnostic bundle from the File menu, or navigate to Administration System Logs on the Home page and click Export System Logs. The former only exports a log bundle for that host; the latter can export not only the host bundle, but also the client and vCenter diagnostic bundles. Exercise 10.2 pro-vides the steps for exporting the ESX host log bundle using the vSphere Client.

E X E R C I S E 10 . 2

Exporting the ESX Diagnostic Bundle


2. On the Home page, in the Administration section, click the System Logs icon .

3. On the System Logs screen, in the top-left corner, click the Export System Logs button .

4. In the Export System Logs dialog box, expand the hierarchy and check the host for which you wish to collect data . This will automatically check all the boxes between the host and the vCenter server, thus creating all three diagnostic bundles . If you did not want the vCenter and vSphere Client bundles, deselect the “Include information from vCenter Server and vSphere Client” check box . You also need to choose a loca-tion for the saved files either by typing a path or browsing to the correct path .

5. Monitor the status of the bundle task at the bottom of the vSphere Client in the Recent Tasks section . When completed, a Downloading System Logs Bundles dialog box will open, showing the status of the bundle task and whether there were any errors . Click Close if the bundle was saved properly . Browse to the location where the diagnostic bundle was saved to verify its creation .


Another way to capture the same log bundle is to log into the ESX server’s console and run the vm-support script. This script will create the same host bundle, but it will be stored locally on the ESX server. It would be up to you to move the file off the ESX host. The file format for the ESX host’s diagnostic bundle is TGZ, which will require that you use a pro-gram that is compatible with that file format if you save the bundle on a Windows machine. If still stored on the local server, use the tar command to extract and create a directory to view the files that make up the log bundle.

Performing Basic Troubleshooting for VMware FT and Third-Party ClustersWith the addition of VMware Fault Tolerance (FT), you have one more option to provide a highly available infrastructure for your VMs and their applications. In the past, there were only two options: VMware HA or Microsoft Cluster Service (MSCS). These two options have their place, but neither option covers all expectations or service levels for all applica-tions. For instance, although MSCS can provide high availability and prevent data loss in case of hardware or operating system failures, only cluster-aware applications work with this solution completely.

VMware FT provides another option that provides you with the best solution for appli-cations that cannot tolerate downtime due to hardware or operating system failures. Unlike VMware HA, which restarts a VM if the ESX host fails or if the VM operating system fails, VMware FT provides full high-availability with no data loss, allowing the VM to continue to run. Troubleshooting FT and Microsoft clusters is the focus of this section.

This section covers three subobjectives:

Analyze and evaluate VM population for Maintenance mode considerationsNN

Understand manual third-party failover/failback processesNN

Troubleshoot Fault Tolerance partial or unexpected failoverNN

Analyzing and Evaluating VM Population for Maintenance Mode ConsiderationsMaintenance mode is a feature that allows you to take an ESX host offline for maintenance. This means that no virtual machine activity can occur on that host. You will either have to power off or shut down the VMs or move them (via VMotion) to other ESX hosts. Once the server is empty or not running any VMs, it is then able to go into Maintenance mode.

You must take two factors into account when trying to place an ESX host into Maintenance mode. First, determine which VMs can be moved to other hosts to help evacuate the mainte-nance host. Second, determine whether there is enough spare capacity on the remaining hosts to receive the VMs that VMotion can move off the maintenance host. Let’s take the first consideration.


In most environments, shutting down many VMs to facilitate a maintenance outage for an ESX host is not practical. Ensuring that most of your VMs can be VMotioned is critical so that the server can be properly evacuated. Some VMs will not be able to be VMotioned, such as VMs that are not running from shared storage. Those will have to be shut down and will require some form of change management.

The second consideration is whether or not the environment has enough spare capacity so that one server can be completely evacuated by using VMotion to move the VMs to other hosts. There are several ways to calculate this. If the servers are in a DRS cluster, DRS tracks each host’s CPU and memory usage and provides an at-a-glance chart to see if there is enough spare capacity on the other hosts. In addition, if VMware HA has been activated in the clus-ter, by default it monitors whether or not there is at least one server’s worth of spare capacity in case it needs to restart at least one host’s VMs on the remaining hosts. The side effect cre-ated is that there should also be at least one server’s worth of spare capacity for VMotioning the VMs off the maintenance host onto the other hosts in the cluster.

If a DRS cluster is not in use, you will need to manually reserve some percentage of CPU and memory capacity on each host that equals at least one server of CPU and memory. For example, if you had four ESX hosts, you would need to reserve at least 25 percent of CPU and memory capacity on each server so that you could evacuate the maintenance host com-pletely by using VMotion to move the VMs to the remaining three hosts. Each ESX host’s Summary tab shows CPU and memory resources being used and the capacity of that server. It’s an easy calculation to see if you have enough spare capacity to facilitate Maintenance mode. A good rule of thumb is to always have at least one server’s worth of spare capacity across your ESX server group.

Understanding Manual Third-Party Failover/Failback ProcessesVMware has for a long time supported using MSCS inside a virtual machine. This gives you a high-availability option when there are no other options. Today we can use VMware HA, FT, or MSCS. MSCS is the only third-party high-availability option supported by VMware.

There are three scenarios when using MSCS:

Single host, VM-to-VM cluster (sometimes called a “cluster in a box”)NN

Two hosts, VM-to-VM cluster (cluster across ESX hosts)NN

VM-to–physical server cluster (virtual-to-physical cluster)NN

With these three scenarios, you can use MSCS for test, development, and production networks. To provide high availability in case of hardware failure, you should use the latter two scenarios. But in what use case would it be beneficial to use MSCS? In reality, there are only a few applications that will work elegantly with this form of high availability. Microsoft Exchange and SQL Server applications were written to be “cluster aware.” This means that if the active node running the application were to fail, the passive node can take over after a failover interval without data loss and without you having to restart the application. Applications that are not “cluster aware” will have to be restarted on the second node. Given


that, there is no compelling reason to use MSCS for those servers where an application needs to be restarted; you would be better served using VMware HA or FT.

The “cluster in a box” scenario is great for simple lab and test environments to test the functionality of the applications running inside a Microsoft cluster. Only one ESX server is needed, the VM’s virtual disks can be stored on local storage, and internal virtual switches are used. The downside to this scenario is that it does not protect the application from a hardware failure as both nodes of the cluster are running on the same ESX host. Figure 10.2 shows the basic build for this scenario.

F I GU R E 10 . 2 Cluster in a box

BA

vmdk

ESX

The “cluster across boxes” scenario is the most common method used. This allows one VM on an ESX host to cluster with another VM on a different ESX host. This protects the appli-cation against ESX hardware failures in addition to operating system failures or application failures. This scenario also uses RDMs to allow the two nodes to share a LUN where the data resides, and the networking has to be set up with virtual switches with outbound connectivity, unlike the cluster in a box. The build process for this is depicted in Figure 10.3.

The last scenario, called a virtual-to-physical cluster, allows the application running on a physical server to be clustered with a virtual machine. If the physical server fails or needs to be shut down or rebooted due to maintenance, the application can fail over to the passive node, the VM, to maintain uptime. This requires that the RDM being used for the data volume be running in “physical compatibility” mode. Additionally, both the “public” network and the “heartbeat” network have to use vSwitches that have outbound connectivity. Figure 10.4 shows the basic layout and build process for this scenario.

In this scenario, if you choose, a failback policy can be used so that the application returns to the physical server once MSCS resumes on that node. In many cases, the physical node will provide better performance and is considered the preferred node in this type of cluster.


F I GU R E 10 . 3 Cluster across boxes

SAN

LUN

LUN

ESX 1

A B

ESX 2

Third-Party high-Availability Scenarios

When you have the ability to use VMware HA, you should use HA as your primary high-availability strategy for most of your VMs . This is practical as there is much less setup and configuration for the ESX servers and VMs within the cluster . For VMs that are running applications such Microsoft Exchange or Microsoft SQL Server, the preferred method within vSphere environments is using a Microsoft cluster since these applications are cluster aware and can take advantage of the features for that cluster technology .

With the release of vSphere, there is another high-availability feature that needs care-ful consideration: VMware Fault Tolerance . This new zero-downtime feature will provide even more applications with an option they have never had before . Although FT has a pretty heavy set of requirements and restrictions at this time, for those VMs that meet the requirements, it will become the preferred method for providing highly available applica-tions . With its ease of management, many administrators will begin to favor this technol-ogy over other technologies .

As of this writing, one ESX server can host four to eight FT VMs . Multiply that value by the number of nodes in the HA cluster and suddenly the applications that provide a high-priority value with zero-downtime become largely the rule and not the exception .

As this feature evolves, in conjunction with select systems from hardware vendors, the ability to provide high availability will expand further .


F I GU R E 10 . 4 Virtual-to-physical cluster

SAN

LUN

LUN

ESX Physical Server

Troubleshooting Fault Tolerance Partial/or Unexpected FailuresThe VMware FT functionality is helpful and provides a robust high-availability option for VMs that require the highest uptime and strictest service-level agreements. The basic func-tionality resembles a two-node cluster. One node, the primary running on one ESX host, runs the application. The second node, running on a separate ESX host, mirrors the activity on the primary node. Unlike a Microsoft cluster where there is an active node doing all the processing and a passive node waiting to take over if the active node fails, FT mirrors the primary nodes activity on the second node. This is done by way of a private logging network between the two ESX servers. The technology that provides this functionality is called vLockstep.

VMware FT GuidelinesFT guidelines that will help the feature work as advertised and with stability are:

Do not use more than four FT VMs on the ESX host, either primary or secondary. NN

Busy VMs could reduce that number.

If using NFS as the shared storage, use a dedicated appliance with Gigabit Ethernet NN

connectivity.

Resource pools need to have memory reservations that exceed the configured memory NN

value of all fault-tolerant VMs within the pool. Overhead memory needs to be consid-ered a part of the reservation of the pool.

Do not use more than 16 virtual disks with a FT VM.NN

The cluster needs to have at least three ESX hosts to accommodate the creation of a NN

new secondary VM.


Troubleshooting VMware FTThere are some conditions or circumstances that can force FT to fail over a virtual machine to its secondary unexpectedly. Or perhaps the secondary fails to create a new secondary VM, even if the host has not failed. These conditions can be analyzed and corrected in most situations. The good news is that the VM’s ability to remain online and execute the application has not been compromised, but failover or redundancy may be temporarily offline.

Here are some of the conditions that may impede FT functionality:

Partial Storage Hardware Failure If one host loses connectivity to storage, or access has become much slower (usually the host with the primary node), the two hosts will not be able to keep in sync, causing a failover to the secondary node. Correcting the slow or miss-ing storage access requires analyzing the VMkernel logs for storage-related entries and using tools like esxtop to find the problem.

Partial Network Hardware Failure If the logging network goes offline, failover to the secondary node can occur. The best way to correct this condition is to dedicate a separate NIC for FT traffic and VMotion and provide redundancy using a NIC team.

Logging Network Congestion This situation usually occurs when there are too many FT virtual machines on a host. Disperse FT VMs across as many hosts as possible.

VMotion Failures Due to VM Activity Levels VMotion migrations can sometimes fail on FT VMs due to a high level of activity inside the VM. Consider performing VMotion activities when the VM is less active.

FT Failovers Due to VMFS Activity Due to file system locking events such as VM power on/off, snapshot creation or growth, or VMotion migrations on a single VMFS volume, FT may fail over to the secondary VM due to disk latency. This condition can be avoided by not creating too many snapshots, VM power on/off operations, or VMotion migrations within the same volume.

Insufficient Space on VMFS for Secondary VM Startup Check to see how much free space is available on the VMFS volume where the VM is stored. Move the VM or grow the volume if necessary.

Other Troubleshooting ProblemsOther issues can arise if the hardware platforms have not been set up properly or if there are incompatibilities between hosts. FT does require hardware that supports this feature, and you should pay attention to the CPU model to check for highest compatibility. Other issues that can impact VMware FT include:

On each host, hardware virtualization (HV) must be available on the processor or NN

enabled in the BIOS.

If the host where the secondary VM is located becomes overcommitted, the primary NN

node may have to slow down so that the two nodes can remain in sync. Consider using CPU reservations to correct this problem.


Large VMs (15 GB of memory or larger) may have difficulty with VMotion or FT, NN

especially if the memory is changing at a faster rate than the VMotion operation. If a VMotion cannot perform the switchover within 8 seconds, consider increasing the timeout window to 30 seconds (ft.maxSwitchoverSeconds=30).

In some cases, the CPU activity for the secondary VM may look higher than the primary NN

node. This is due to the replay mechanism on the secondary and requires some additional CPU cycles.

VMware FT, using vLockstep technology, is the newest high-availability feature pro-vided by vSphere. As with VMotion, pay careful attention to the setup and requirements for this feature to work consistently and with stability.

Performing Basic Troubleshooting for NetworkingTroubleshooting networking issues, both on the ESX/ESXi host and for the virtual machines, requires the use of the vSphere Client and potentially command-line tools. Verifying network settings usually involves using the vSphere Client to look at the properties for the various network components. On the ESX server, there may be a need to use command-line tools to verify settings.

Given that many features or components require some type of networking, verifying that the network setup is correct and working properly is very important. This section will show you how to confirm those settings.

This section covers six subobjectives:

Verifying VM is connected to the correct port groupNN

Verifying port group settings are correctNN

Verifying that the network adapter is connected within the VMNN

Verifying VM network adapter settingsNN

Verifying physical network adapter settingsNN

Verifying vSphere network management settingsNN

Verifying VM Is Connected to the Correct Port GroupEvery virtual machine that needs to communicate with other network nodes or servers must be connected to the correct port group, which represents a specific subnet, IP network, or VLAN. To ensure that the VM is connected to the correct port group, look at the VM’s net-work settings. To do this, with the vSphere Client, edit the settings of the VM in question and select its network adapter from the hardware list. In the Network Connection section, verify

Performing Basic Troubleshooting for Networking 509

that the virtual adapter is connected to the correct port group in the drop-down menu. If it is currently connected to the wrong port group, change the connection. The VM may have to be rebooted or the network configuration restarted to pick up the correct IP address, especially for desktop VMs. For server VMs, that may not be necessary as their IP addresses are usually statically assigned.

Verifying That Port Group Settings Are CorrectWith the release of vSphere, we now have two kinds of virtual switches: vNetwork standard switches and vNetwork distributed switches. These two types of virtual network devices are not very helpful to the VMs if there is no way for them to connect to the switch. That connectivity is known as a port group. Using standard vSwitches requires the creation and configuration of a port group so that the VMs have a place to connect their virtual network adapters. Using distributed vSwitches, you can create distributed port groups for all connec-tion types, including Service Console and VMkernel ports.

Verifying that a particular port group’s settings are correct is easy. For the standard vSwitch, you just click its call-out icon to the left. To navigate to this call-out icon, select the host you are interested in, click its Configuration tab, and then click the Networking link in the Hardware section. Figure 10.5 shows where this is located when viewing the standard vSwitch, which is to the left of the specific port group.

F I GU R E 10 .5 Verifying the vNetwork standard vSwitch port group settings

Once you have clicked the call-out icon for that port group, you will be presented with a dialog box that shows the policies that are currently configured. If you need to make a change, close the dialog box and click the Properties link to the right of the vSwitch.


In the same view for the standard vSwitch, there is a Distributed Virtual Switch button at the top of the informational panel. Click this button to display the distributed vSwitch along with any port groups that have been created on the vSwitch. By clicking the “info” bubble to the left of the vSwitch but to the right of the name of the port group, you’ll open a dialog box (see Figure 10.6) that lists the policies that have been configured, similar to the standard vSwitch’s port group dialog box.

F I GU R E 10 .6 Verifying the vNetwork distributed vSwitch port group settings

If you need to make a change, you will have to change your view. This is a big dif-ference when compared to standard vSwitches. Change your view to Inventory, and Networking will then present the distributed vSwitches and their respective distributed port groups. From here, you can right-click the port group, choose Edit Settings, and then make adjustments. Figure 10.7 shows the dialog box for editing a distributed port group’s policies or properties.

F I GU R E 10 .7 Editing the vNetwork distributed port group settings

Verifying That the Network Adapter Is Connected Within the VMA virtual machine cannot communicate with other devices if its virtual network adapter is not connected. If the virtual machine’s operating system is not able to communicate on the network and you notice the disconnected network icon in the system tray, you may need to verify that that virtual adapter is connected to the vSwitches port group. To do this, select


Edit Settings for the affected VM and select the network adapter. Look in the top right of the dialog box and find the Connected check box. If this check box is deselected, click once to select this option. Figure 10.8 shows this check box.

F I GU R E 10 . 8 Verifying the network adapter is connected in the VM

Once you select the check box, you may need to restart the VM’s network services or perform a full reboot of the VM to allow IP configuration settings to be applied.

Verifying VM Network Adapter SettingsEven though the server is running as a virtual machine, the virtual network adapter will need the same setup as a physical network adapter. How would you check a physical adapter’s network settings? Typically, you would run a command, such as ipconfig or ifconfig, to list the network adapter’s configuration. This would include the IP address, the subnet mask, default gateway, and DNS servers. A virtual machine is no different; you would run the same commands for the appropriate operating system.

With the vSphere Client, you have another option: to verify the IP address. Select the Summary tab for a VM, and the IP address will be listed in the General section of the screen (see Figure 10.9). This view will not show you the other settings.

F I GU R E 10 . 9 Verifying the virtual network adapter’s settings


Verifying Physical Network Adapter SettingsThe ability to verify the physical network adapter’s settings hasn’t changed with vSphere. On the Configuration tab of a host, you can select the Network Adapters link in the Hardware section. This will present a list of the adapters installed on the ESX host. For each adapter listed, the following information is provided:

Device Provides the vendor and VMkernel device name

Speed The negotiated speed of the adapter and duplex setting

Configured The maximum speed and duplex the adapter can negotiate

Switch The vSwitch that the adapter is assigned

MAC Address The hexadecimal address of the adapter

Observed IP Ranges The IP network the VMkernel has observed using this adapter based on broadcast packets received

Wake On LAN Supported Allows the ESX server to come out of Standby mode when using Distributed Power Management (DPM)

If the speed and duplex settings need to be changed, you will have to click the Networking link in the Hardware section and either open the properties for standard vSwitches or click Manage Physical Adapters for distributed vSwitches (see Figure 10.10).

F I GU R E 10 .10 Verifying physical adapter settings

Verifying vSphere Network Management SettingsYou may have to verify management network settings for an ESX/ESXi server because you entered an incorrect setting during installation or made a change on the IP network. There are some minor differences in how you check an ESX server’s settings compared to settings for an ESXi server. This is because, for management, the ESX server uses a Service Console port and the ESXi server uses a VMkernel port. Another distinction is whether the server is using a standard vSwitch or distributed vSwitch.


To verify the management network settings for an ESX server using a standard vSwitch, navigate to the Networking link on the Configuration tab. Click the Properties link of the vSwitch that contains the Service Console port and then click the Service Console item. On the left side of the dialog box will be the settings for the management interface. If any of the settings are incorrect, click the Edit button and make the appropriate changes. Figure 10.11 shows the properties for the Service Console port on a standard vSwitch for an ESX server.

F I GU R E 10 .11 Verifying Service Console settings

The verification process for an ESXi server using standard vSwitches is similar, but ESXi uses a VMkernel port for management. In the Properties dialog of the standard vSwitch is a port called the “Management Network.” This is the VMkernel port. You can verify the settings for this port in a similar way, but with one difference: you must select the Enabled check box for the Management Traffic option on the General tab for the port to operate as a management port, as shown in Figure 10.12.

F I GU R E 10 .12 Verifying VMkernel port settings


When working with Service Console and VMkernel ports that are used for manage-ment with distributed switches, you can verify the settings for these ports by clicking the Networking link on the Configuration tab. Then click the Distributed Virtual Switches button, and the Manage Virtual Adapters link becomes available. Click this link to open a view of the ports. Select the management port, and the right side of the dialog box will dis-play the current settings for that port. Figure 10.13 is an example of viewing the VMkernel port on an ESXi server being used for management.

F I GU R E 10 .13 Verifying VMkernel port settings on a distributed vSwitch

Based on the examples given, the key is to stay on the ESX/ESXi Configuration tab and click the Networking link in the Hardware section. Then it’s just a matter of selecting the vSwitch type and vSwitch where the port is configured.

Performing Basic Troubleshooting for StorageThe ability for an ESX host to interact with storage efficiently can sometimes be impacted by a number of issues, ranging from adapter queue depths to array caching. This section covers some of the basic problems that can arise when accessing and using various types of storage technologies.

Five subobjectives are explored in this section:

Identifying storage contention issuesNN

Identifying storage overcommitment issuesNN

Identifying storage connectivity issuesNN

Performing Basic Troubleshooting for Storage 515

Identifying iSCSI software initiator configuration issuesNN

Interpreting storage reports and storage mapsNN

Identifying Storage Contention IssuesStorage contention can present itself in several ways. No matter the reasons for the conten-tion, it may have an adverse impact on virtual machines and the applications running inside them when large amounts of data need to be analyzed or queries are submitted. Identifying what is causing the contention usually involves looking at the number of workloads in a particular volume.

First, let’s discuss contention from a workload perspective. With many vSphere environ-ments, storage becomes another effective way to pool resources. Storage arrays today allow one server to access a LUN or many servers to share a LUN. With sharing comes contention. As more hosts access a LUN, the number of I/O requests increases substantially. In most cases, each ESX/ESXi host will be hosting many different VMs, requiring the ESX host to make many requests to storage on behalf of the VMs they host.

One way to see if the contention is on the ESX host side is to look at the adapter queue depth to see if the ESX server is having difficulty keeping pace with the number of requests coming from the VMs it is hosting. A device driver queue depth larger than 32 is not often necessary, but with fewer, higher I/O VMs, increasing the queue depth may help. By using esxtop and pressing U to see storage devices, you can check device queue length. The com-mands for looking at the current device drive characteristics and queue are as follows:

vmkload_mod -l | grep qla2xxx

or

vmkload_mod -l | grep lpfcdd

If the queue depth needs to be increased, the commands for increasing the depth are as follows:

esxcfg-module -s ql2xmaxqdepth=64 qla2300_707

or

esxcfg-module -s lpfco_lun_queue_depth=64 lpfcdd_7xx

For the test, knowing the right command is what is important to remember, not the exact syntax.

The other form of contention that may need to be analyzed is the number of VMs running within the same VMFS volume. With just a few VMs in the same datastore, there are usually no problems. But since storage is another way to pool resources, consolidat-ing multiple VMs into the same datastore raises the possibility of VM contention for that volume. If one VM within the datastore is making far more requests than the other VMs, the other VMs can be at a disadvantage when putting in requests. One way to somewhat


equalize VM access to the volume is to use an advanced setting. Adjusting the storage set-ting Disk.SchedNumReqOutstanding may help.

Another issue that can arise is that with a large number of ESX/ESXi hosts accessing the same shared volumes, if hosts issue too many LUN locking commands (usually to do metadata updates), the performance for the VMs degrades. This is due to how LUN lock-ing works. When an ESX server issues a SCSI reservation, it locks the LUN so that it can make a metadata update. This reservation prevents the other ESX servers from accessing the LUN. Some operations that cause these reservations to be used include:

Any update to a file, such as powering on a VM, thus placing a lock on the files for NN

that VM

Snapshot creationNN

Growth of a virtual disk or snapshotNN

Deletion of filesNN

If there are too many of these operations being employed, the locking creates contention issues between the hosts themselves. Check the VMkernel log to see if there seems to be an excessive number of reservations for a datastore.

Identifying Storage Overcommitment IssuesStorage overcommitment issues center on using thin provisioning with the creation of the virtual machine’s virtual disks. Thin-provisioned disks only take up the space needed for the files that have been created or stored for the VM. If the disk was created and sized to be 10 GB but the operating system’s files only take about 2.5 GB of space, a thin-provisioned disk will only use about 2.5 GB of storage space on the array and in the VMFS volume. The problem that can arise is that if many of the VMs being stored in the same volume use thin provisioning, the LUN may become overcommitted.

Figure 10.14 shows three virtual disks being stored in the VMFS volume. The first disk is thick provisioned, which means that when you create the disk file, in this case 20 GB, the file uses 20 GB of storage space. The other two virtual disks have been created using thin provisioning. Both are using 10 GB of storage, but they can grow to 20 GB. The LUN is only 50 GB in size and creates a situation where it is overcommitted.

F I GU R E 10 .14 Provisioned storage on a VMFS volume


The best way to identify overcommitment issues is to build an alarm to monitor a VMFS volume for a certain level of overcommitment and free capacity within the volume. You can use two new triggers when defining the alarm: Datastore Disk Usage and Datastore Disk Overallocation (see Figure 10.15).

F I GU R E 10 .15 Alarm triggers when using a VMFS volume

Identifying Storage Connectivity IssuesStorage connectivity, like networking connectivity, is crucial to a properly performing vSphere infrastructure. Not only do you need to monitor capacity and usage, but you also have to monitor access to storage. ESX/ESXi hosts can use various storage technologies, many of them external to the host itself. Fibre Channel, iSCSI, and NAS/NFS storage require constant access to ensure the virtual machines can access files and write data.

One simple way to monitor storage access is to use a predefined alarm that comes with vCenter. The Cannot Connect To Storage event-based alarm has several triggers that monitor access to storage. The three triggers used are:

Lost Storage ConnectivityNN

Lost Storage Path RedundancyNN

Degraded Storage Path RedundancyNN

If you set up the action to send an email or SNMP trap, a response to an outage can occur more quickly. In particular, if multiple paths to storage are being used and a path becomes unavailable due to hardware failure, the alarm can alert you of the condition before a disastrous event such as a total loss of access occurs. Another predefined alarm is Datastore Usage On Disk. This alarm can alert you well in advance if a volume becomes full and goes offline.


Identifying iSCSI Software Initiator Configuration IssuesSeveral issues can prevent the iSCSI software initiator from functioning properly. Many of these problems involve the networking configuration or the CHAP authentication scheme. One way to help diagnose the problems with an iSCSI is to connect the vSphere Client to the ESX server directly and verify the setup of the software initiator and CHAP configu-ration. Let’s break down the setup of the iSCSI software initiator and then take a look at where problems can arise at each step.

One of the first things you must do is create the networking for the communication between the ESX server and the iSCSI appliance. In many situations, a single vSwitch is cre-ated and the proper redundancy needs to be incorporated into the design of the vSwitch. This is accomplished by using NIC teaming for the uplinks and two VMkernel ports, each with their own IP address. Using vmkping on the Service Console or vCLI, make sure the ESX server can communicate with at least one target address of the iSCSI appliance. In addition, in most situations, VMkernel port binding is recommended for proper iSCSI multipathing. Figure 10.16 shows a standard vSwitch with two NICs and the two VMkernel ports.

F I GU R E 10 .16 Example of the networking for the iSCSI software initiator

Next, enable the software initiator. You can do this by using the vSphere Client, discussed in Chapter 3, “Configuring ESX/ESXi Storage.” Depending on the hardware used, the soft-ware initiator may show in the vSphere Client as vmhba32. It may show as a higher adapter number, but this does not affect the initiator’s functionality. Once the software initiator has been enabled, the IQN address for the host will be generated. Take care in documenting this address as ESX appends a hexadecimal value to the end of the address to ensure uniqueness. In some cases, you may not want this hexadecimal value beaded, and you can strip it off, making it easier to set up the correct masking on the iSCSI appliance. A mismatch or incor-rect IQN address will prevent the ESX host from properly seeing any LUNs on the appliance.

The next step is to set up the port binding for each uplink using the esxcli command. This technique is discussed in Chapter 3. There should be a 1:1 map between the VMkernel


ports and the uplinks. You can view this binding in the vSphere Client using the Paths view, with one path showing vmhba32:C1:T1:L0 and vmhba32:C2:T1:L0. Once port binding has been set up, proper multipathing should occur if an uplink were to fail.

If jumbo frames are to be used, for standard vSwitches the esxcfg-vswitch -m <MTU> vSwitch_name command can be used to enable this functionality where the value for -m is 9000. Ensure that the uplinks and physical switch support jumbo frames. VMware recom-mends that dedicated uplinks be used and that the iSCSI traffic remain on a local subnet for best performance.

The next step doesn’t usually create problems for iSCSI setup, but you have to decide whether to use dynamic discovery or static discovery. With either method, if an incorrect IP address is used in specifying a particular target, communication will be impacted. Using vmkping to test connectivity to all the target IPs will help troubleshoot issues with commu-nicating with the iSCSI appliance.

An optional, but sometimes required step in the configuration of iSCSI that can be implemented incorrectly is CHAP authentication. With the release of vSphere, bidirectional CHAP is supported and per-target CHAP is supported. Given that CHAP uses a shared-secret approach, ensure that the password to be used has been decided and documented. Although you can choose among several security levels, if you plan to use CHAP, you’re likely to want to select the security level Use CHAP on both the ESX host and the iSCSI appliance, as shown in Figure 10.17.

F I GU R E 10 .17 Selecting the CHAP security level

Interpreting Storage Reports and Storage MapsThe new storage reports and storage maps are a great way to see the relationships between ESX hosts, VMs, storage, adapters, and the datastores themselves. The Storage Reports button, on the Storage Views tab for an inventory object, provides a list of dif-ferent reports for looking at various aspects of the relationship with storage. Each object


has a different list of reports available. Here is the list of reports that may be available for various inventory objects:

Show All Virtual MachinesNN

Show All DatastoresNN

Show All HostsNN

Show All Resource PoolsNN

Show All ClustersNN

Show All Virtual Machine FilesNN

Show All SCSI Volumes (LUNs)NN

Show All SCSI PathsNN

Show All SCSI AdaptersNN

Show All SCSI Targets (Array Ports)NN

Show All NAS MountsNN

The various inventory objects (except networking) have similar listings, but may not list them all due to relevance. Using the various reports gives you more information about storage usage or relationships. One example is the Show All Datastores report, shown in Figure 10.18.

F I GU R E 10 .18 The Show All Datastores report

What is very nice about this report is the ability to see capacity and free space for each datastore. Also, a requested feature that is included in this version of the vSphere Client is the ability to see how much space is being consumed by snapshots. It’s easy to miss the abil-ity to turn off certain columns or turn others on. If you right-click a column header, a list of possible columns appears, and you can turn them on or off (see Figure 10.19). Two items to pay attention to are the Swap Space and Disks columns.

If you want to know which VMs are located in a specific datastore, you could start with the Show All Datastores report and click on the relevant datastore, and a new report appears that shows which VMs are stored there. This ability to drill down in some reports is handy for documenting the environment and finding details about current usage.

The Storage Views tab has another button of great use. The Maps button allows the user to build and manipulate various storage maps and the relationships between the vari-ous inventory and storage objects. Depending on the inventory object selected, the map will show the various storage objects related to the parent selected. In Figure 10.20, we’ve selected the datacenter and are looking at a high-level map. By selecting the controls on the


left of the map, we can turn different relationships on or off. In some cases, the maps can get very busy, so turn on only what you need.

F I GU R E 10 .19 Adding additional report columns

F I GU R E 10 . 20 The Maps view

Another very nice feature when using the maps is the ability to move the objects around, enlarge them, zoom in, or export the map into various file formats, including Microsoft’s Visio. These abilities are not possible (except zoom) with the views presented on the Maps tab; those formats are static and cannot be exported to Visio.


Performing Basic Troubleshooting for HA/DRS and VMotionTroubleshooting HA/DRS clusters takes some experience, and you have to pay careful atten-tion to detail. In particular, HA requirements are similar to VMotion requirements with the added need for name resolution between hosts on the network side. HA also requires spare capacity across the cluster to ensure that VMs that need to be restarted will have the resources they need.

DRS requires that the VMs within the cluster be able to VMotion to other hosts. This allows DRS to load-balance the cluster properly. Troubleshooting VMotion or DRS issues specifically requires looking at the VMs and sometimes the ESX/ESXi server configurations to ensure successful migrations.

This section covers eight subobjectives:

Explaining the requirements for HA/DRS and VMotionNN

Verifying VMotion functionalityNN

Verifying DNS settingsNN

Verifying the Service Console network functionalityNN

Interpreting the DRS resource distribution graph and target/current host load deviationNN

Troubleshooting VMotion using topology mapsNN

Troubleshooting HA capacity issuesNN

Troubleshooting HA redundancy issuesNN

Explaining the Requirements of HA/DRS and VMotionThe best way to ensure that a DRS/HA cluster will perform correctly and with the best results is to meet all the requirements for both features. There are two sets of requirements, both host and guest. Host requirements for a DRS cluster are:

Shared storage—either shared VMFS or NFSNN

CPU compatibilityNN

Identical network visibility for VMsNN

Meet VMotion requirementsNN

Host requirements for HA are:

Shared storage—either shared VMFS or NFSNN

Identical network visibility for VMsNN

Redundant heartbeat networkingNN

Performing Basic Troubleshooting for HA/DRS and VMotion 523

Guests need to have the ability to be VMotioned, which requires the VMs to meet their own set of requirements. They are:

VMs cannot use RDMs using Physical compatibility mode.NN

VMs cannot be connected to virtual devices that are mapped to physical devices on NN

the host.

VMs cannot be connected to virtual devices that are mapped to client devices.NN

VMs cannot have a connection to an internal-only switch.NN

VMs cannot use CPU affinity.NN

Let’s explore these requirements in more detail.DRS clusters require that VMotion be working correctly for the majority of the VMs

that reside in the cluster. Although there may be exceptions to this rule, some VMs can-not be VMotioned due to the configuration. One example would be a VM using a virtual disk on local storage. This will not allow the VM to be VMotioned. If there are other VM exceptions that cannot be moved with VMotion, spread them over several hosts within the cluster so that one host is not overly burdened with VMs that are not able to move.

To meet VMotion requirements on the host, the CPUs must be compatible for VMotion. Ideally, all of the CPUs being used by the nodes in the cluster will be identical. This can be challenging when ESX hosts are purchased over time and minor variations appear within the same CPU family. Enhanced VMotion Compatibility (EVC) can help lessen the impact of these variations. See Chapter 7, “Identifying Compatibility Requirements,” for the full list of CPU requirements.

The next requirement involves networking. Again, ideally, the ESX servers need to be configured to use and see all VM networks. No internal-only networks can be used. If VLANs are used, the identical configuration must be configured on each host in the cluster. Virtual switch names have to be consistent throughout the cluster. Also, the VMotion net-work should be correctly configured so that the VMkernel ports being used are enabled for VMotion and connected to the same local subnet.

HA requirements are much the same as for DRS. One addition to the DRS requirements is the ability to provide redundancy for the HA heartbeat. This is accomplished by configur-ing each server with NIC teaming for the vSwitch that will communicate the heartbeat, or by providing two ports on different vSwitches. On ESX servers, the port used is a Service Console port or vswif0, and on ESXi servers the port used is a VMkernel port.

As for the VMs themselves, they must be configured so that they can access any resource from any host. This includes networking and shared storage for the VMs’ files. This also includes not setting CPU affinity as some hosts may have differing numbers of cores or hyperthreading CPUs. One way to ensure that CPU affinity won’t be an issue is to set the DRS cluster in Fully Automated mode. That way, the option to set CPU affinity becomes unavailable.

Another configuration to stay away from is any virtual device that is mapped to a local device, such as serial or parallel ports and local CD or client devices. The preferred method for CD devices is to use ISO files on shared storage seen by all ESX nodes in the cluster.


Verifying VMotion FunctionalityTesting VMotion functionality is straightforward. Right-click the VM that you wish to move and choose Migrate from the context menu. Select Change Host and then verify the host you wish to move the VM to is valid. If the destination host is incompatible, the wizard will pro-vide a reason for the incompatibility. If a CPU problem arises due to incompatibilities in fea-tures or instructions, the wizard will guide you in correcting the problem. If the destination host is valid, the wizard will proceed.

A good tool to use to ensure that all the ESX servers have compatible CPUs is called cpuid. You can download this tool from VMware’s website and create a boot CD. When you boot the ESX server with this CD, the tool presents the current CPU characteristics, allowing you to compare each server for identical CPU features. This type of comparison is sometimes needed if the servers to be used are being repurposed as ESX servers and the owner does not know the exact CPU details of the hardware being considered. Figure 10.21 shows sample cpuid output.

F I GU R E 10 . 21 Viewing the cpuid output

Verifying DNS SettingsThe easiest way to verify DNS settings is to use the vSphere Client. Navigate to an ESX server’s Configuration tab and choose the DNS And Routing option in the Software panel. If any of the settings are incorrect, click Properties and adjust the setting. Figure 10.22 shows a sample DNS And Routing screen.

To test that the ESX server can resolve names to IP addresses (which is very important for several features to work correctly, most notably VMware HA), log into the console of


an ESX server and ping another host by its name. If DNS has the correct entries, the name should be resolved to an IP address and the ping should work correctly.

F I GU R E 10 . 22 DNS And Routing

Verifying the Service Console Network FunctionalityThe best way to verify that the Service Console has proper network connectivity is to use the ping command to see if the server can communicate with other hosts on the network. There are three possible IP addresses that can be used during this process:

The Service Console’s IP addressNN

Another host on the same subnetNN

The default gatewayNN

By pinging each of these addresses, you can verify local subnet and remote network com-munication. If you suspect that the Service Console port is not functioning properly, use the ifconfig vswif0 command to see if the local Service Console port has an IP. Figure 10.23 illustrates testing for Service Console connectivity.

F I GU R E 10 . 23 Testing Service Console connectivity


Interpreting the DRS Resource Distribution Graph and Target/Current Host Load DeviationEach cluster object has a Summary tab that can provide additional information about the cluster’s ability to load-balance workloads represented by the various VMs. Two pieces of information that can be used on this tab are the Resource Distribution Chart link and the load standard deviation metrics.

The resource distribution chart is a good way to see the overall CPU and memory utiliza-tion on any host. The information is presented in a horizontal histogram with percentage of utilization from left to right. If the cluster is being properly load-balanced, the bars for each host should be fairly similar in length. Each bar also represents the VMs running on that host. Each box making up the utilization bar is a VM consuming resources. If those resources are entitled to a VM, such as shares or reservations, the color of the histogram will move in the direction of the color green as shown in the legend. This entitlement is computed based on the VM’s shares and reservations as well for any resource pool of which the VM is a member. If the VM is not entitled to resources, the color will move in the direction of the color red.

On the Summary tab are two values that can also provide insight as to the load imbal-ance in the cluster. The first is called Target Host Load Standard Deviation and the other is Current Host Load Standard Deviation. These two metrics are calculated to see if the cluster is reaching balance and are calculated every five minutes. The target standard deviation is a calculation based on the current migration threshold of the cluster that the vSphere Client represents as a slider with five positions (Fully Automated mode). The current host standard deviation is a calculation of the load on each host in the cluster; the values of all hosts are averaged and then the standard deviation is calculated. If the current host standard deviation is greater than the target host migration threshold, DRS will use VMotion to move one or more VMs to other hosts to lower the current host standard deviation (bringing the average load for each host in the cluster closer to each other). Once the current host standard devia-tion calculation is lower than the target host standard deviation, balance has been achieved.

Troubleshooting VMotion Using the Topology MapsWhen VMotion is working incorrectly, the topology maps can be used to help troubleshoot why the VM is unable to migrate. The maps highlight two key relationships:

Each host needs to share visibility with all VM datastores.NN

Each host needs to provide identical VM network access.NN

If either of these two relationships is not met, the maps will graphically show you the problem. For instance, using a virtual machine topology map, if a VM is on a datastore that only one ESX host has access to, the topology map for that VM will show that a relationship exists for that datastore on the current ESX server the VM is running on but that no relationship exists with the other ESX host. This is highlighted on the map with a green “halo” for the ESX server with the proper datastore and networking relationship and a red “halo” for the ESX server that does not have the same datastore or networking relationship. Figure 10.24 shows this condition.


F I GU R E 10 . 24 VM topology map showing a problem with the datastore relationship

A more holistic approach is to use the topology map for the cluster. Turn on the Host To Datastore relationship, and it will become obvious if an ESX server is missing a relationship with a particular datastore. Turn on the Host To Network relationship to identify problems with ESX servers that do not have the same network configurations. Figure 10.25 presents the cluster’s topology map for troubleshooting datastore and network relationships.

Troubleshooting HA Capacity IssuesOne of VMware HA’s primary responsibilities is to ensure that enough spare capacity exists in the cluster in case of a node failure. HA has three Admission Control policies in vSphere to allow for this spare capacity:

Host Failures Cluster ToleratesNN

Percentage Of Cluster Resources ReservedNN

Specify A Failover HostNN

F I GU R E 10 . 25 Cluster topology map for datastores and networking


No matter the policy used, one way to ensure that the cluster will have enough spare capacity is to always use the Admission Control option “Prevent VMs from being powered on if they violate availability constraints.” This option could prevent several actions from being taken if they would put the cluster in a condition of not having enough spare capacity. Three such actions are:

Powering on a VMNN

Increasing the size of a CPU or memory reservation of a VMNN

Migrating a live VM to a host within a clusterNN

If any of these actions were to cause the cluster to not have enough spare capacity to restart existing powered-on VMs, the action is disallowed. If you receive an error message stating that there are insufficient resources for a particular task, look to see if the cluster has reached its HA threshold. The best way to do this is look at the Resource Allocation tab for the cluster and check to see how much Unreserved capacity is available. Then correlate this information with the Admission Control policy to see if you are near the maximum usage of memory or CPU resources for the cluster.

For example, if the cluster consists of three ESX servers, each with 12 GHz CPU and 32 GB of memory capacity, then with the Admission Control policy of Host Failures Cluster Tolerates of one host, the cluster will reserve about one-third of the cluster’s capacity to restart VMs from the failed node. Any attempt to use more than two-thirds of the cluster will fail. Using the Resource Allocation tab will show you the total capacity and unreserved capacity, and then it’s an easy calculation to see if you are close to that spare capacity threshold.

Troubleshooting HA Redundancy IssuesVMware HA utilizes “heartbeat” communication between the primary nodes and the sec-ondary nodes as a way to identify a failing node in the cluster. If the heartbeat is not returned by a node in the cluster, the other nodes will then begin the process of restarting the VMs on the failing node. With vSphere, VMware HA looks to see if the heartbeat communication has more than one network path to reach another node in the cluster. If only one path is found, the cluster will present a warning, which can be seen at the top of the Summary tab of the cluster in the vSphere Client. Figure 10.26 shows this alert on the cluster.

F I GU R E 10 . 26 An alert generated when HA does not have redundant paths for the HA heartbeat

If the node is an ESX server, the redundant network path can be implemented two ways. First, if there are sufficient physical network interfaces, NIC teaming can be used on

Summary 529

the vSwitch that has the vswif0 Service Console port. This provides a fault-tolerant solu-tion for communicating the heartbeat in case one NIC fails. Another solution is to create another Service Console port on another vSwitch. This will allow the HA agent running on the ESX server to use a secondary network pathway for heartbeat communication.

For this second method to work correctly, you must add two advanced parameters to the HA’s configuration by clicking the Advanced Options button for the HA configura-tion. Figure 10.27 shows adding two new parameters, das.isolationaddress and das.isolationaddress2, to give the HA agent an alternative network address to commu-nicate the heartbeat.

F I GU R E 10 . 27 Advanced options for HA network path redundancy

On an ESXi server, the two previous methods can be used with one difference: rather than adding a second Service Console port, you would add a second VMkernel port on another vSwitch. In addition, be sure to select the Use This Virtual Adapter For Management Traffic check box so that HA will identify this network as a possible heartbeat pathway.

If you believe that the network paths are configured improperly—such as a bad IP address or possible link failure—two command-line tools are available that can assess network connectivity. The first is the ping command to test to see if the Service Console port can com-municate with other Service Console ports on other ESX servers. The second is the vmkping command, which tests network connectivity of VMkernel ports that are used on ESXi servers.

SummaryThis chapter is devoted to providing troubleshooting techniques and processes for vSphere infrastructure. With environments becoming increasingly complex and with VMware provid-ing more and more features, basic troubleshooting is sometimes necessary to ensure proper functionality and the use of correct settings for many of these same features.

Many of the troubleshooting processes revolve around working with ESX hosts. Several guidelines can be used when remediating ESX hosts and give insight to the dependencies within the product. Most data needed to effectively troubleshoot ESX hosts can be found using several of the charts, graphs, and maps provided in the vSphere Client. Other data will need to be accessed using command-line tools as a way to verify certain network and local host settings.

Basic troubleshooting for ESX host settings, VMware FT, host networking and storage, and the datacenter features of HA/DRS and VMotion are integral to your virtualization


toolkit. With experience, many issues that do arise can be dealt with quickly and efficiently. Learning the basics when working with a VMware virtualization environment will provide the basis for a more stable and cost-efficient datacenter.

Exam Essentials

Know how to perform basic troubleshooting of ESX hosts. Study the basic troubleshoot-ing guidelines and how to address common installation problems. Know how to monitor ESX server health and export diagnostic data

Be able to perform basic troubleshooting of VMware FT. Learn how to analyze and assess VM loads on a host and how this may impact using Maintenance mode. Practice using third-party clustering, such as Microsoft Cluster Service in VMs.

Know how to perform basic network troubleshooting. Using the vSphere Client, verify vSwitch, port group, and VM network settings and policies. Be able to verify VM network adapter, physical, and network management settings. Practice using the command-line tools discussed in this chapter.

Know how to perform basic storage troubleshooting. Be able to evaluate and assess storage contention and overcommitment issues. Learn how to remediate connectivity issues as they relate to storage. Be able to identify iSCSI configuration issues. Practice using the storage reports and maps.

Know how to perform basic HA/DRS and VMotion troubleshooting. Learn the requirements for HA/DRS and VMotion. Be able to verify VMotion functionality, DNS settings, and Service Console network connectivity. Know how to use the DRS tab to check load distribution and load deviation. Practice using the VMotion topology maps. Be able to identify capacity and redundancy problems when using HA.


Review Questions

1. You are planning on using the built-in vCenter alarm, which warns of lost storage connec-tion problems. After you lose connectivity to a particular iSCSI array, you notice the alarm never sent you any indication. Why?

A. This built-in alarm is not enabled by default.

B. There is no default action specified for this alarm.

C. The default action (send email) requires you set up vCenter Mail settings.

D. The default action (send a notification trap) requires you specify at least one SNMP trap receiver.

2. Which of the following is not monitored by the new ESX hardware health function?

A. CPU

B. Fan

C. Battery

D. Monitor

E. Temperature

3. Where would you verify/change the network settings for the management network on an ESXi server?

A. The Service Console port group on vSwitch0

B. The Management Network port group on vSwitch0

C. The VM Network port group on vSwitch0

D. The VMkernel port group on vSwitch0

4. You have put an ESX server into Maintenance mode so that you can perform periodic hard-ware maintenance. Although the ESX server is in a DRS cluster, you notice, after several hours, the ESX server still has not completed the transition into Maintenance mode. What should you do? (Choose two.)

A. Wait longer; entering Maintenance mode frequently takes up to 24 hours to complete.

B. Check to see if DRS is in fully automatic mode.

C. DRS must be in semiautomatic mode.

D. Some of the VMs may not satisfy VMotion requirements.

E. You need to manually shut down or VMotion VMs when you put an ESX server into Maintenance mode.


5. You are experiencing a problem with a VMkernel port group on a dvSwitch. You think the problem may be that it has been set with an incorrect IP address. You would like to exam-ine and correct the IP address on this port group (assuming that is the problem). Using the vSphere Client, logged into vCenter, how would you do this?

A. Click Home Inventory Networking, select the dvSwitch, and click Edit Settings.

B. Click Home Inventory Hosts And Clusters, select an ESX server, click the Configu-ration tab, click Networking, click Distributed Virtual Switch, select the dvSwitch, click Manage Virtual Adapters, select the port group, and examine or edit as appropriate.

C. Click Home Inventory Networking, select the dvSwitch, right-click the port group, and select Edit Settings.

D. Click Home Networking, select the correct virtual switch, right-click the port group, and select Edit Settings.

6. What is the recommended maximum number of VMs to have in FT mode on an ESX server?

A. 1–2

B. 2–4

C. 4–8

D. 8–16

7. When you are looking at the Maps tab (view) of an ESX server in vCenter’s Hosts And Clusters view, why would an ESX server in the map have a red “x” superimposed over it?

A. The ESX server has crashed.

B. The ESX server does not meet VMotion requirements.

C. The ESX server is overcommitted.

D. The ESX server is rebooting.

8. When you generate a log bundle using the vm-support command, what is the format of the generated file?

A. TAR

B. ZIP

C. TGZ

D. CAB

9. You have a DRS cluster with three ESX servers. In the vSphere Client GUI you are look-ing at the resource distribution chart in the cluster’s Summary tab. All of the ESX servers have multiple VMs running on them, all of which satisfy VMotion requirements. On two of the ESX servers, the VM’s CPU utilization per host bars are all green, whereas on the third ESX server all of the VMs CPU utilization bars are yellow or red. What can you do to fix this not only immediately but into the future as well?

A. You are running too many VMs; power some of them off.

B. Put DRS into fully automatic mode.

C. Apply DRS VMotion recommendations of three stars or more.

D. Change the CPU reservations of the VMs that are showing red bars.


10. Which command could you use in the Service Console to verify the proper IP address infor-mation has been set for correct Service Console networking?

A. ifconfig

B. ipconfig

C. netconfig

D. testnet

E. vicfg-nics

11. How would you verify a VM’s IP address, subnet mask, default gateway, and DNS servers?

A. Select the VM in the vSphere Client GUI, click Edit Settings, select the Network adapter, and view all the settings.

B. Select the VM in the vSphere Client GUI, and click the Summary tab.

C. In the Windows VM, open a DOS command window and enter the ipconfig /all command.

D. Select the VM in the vSphere Client GUI, click Edit Settings, click the Options tab, and select the Network options.

12. Which of the following is not a VMotion compatibility requirement?

A. VMs cannot be connected to a virtual device that is mapped to a physical device on the host.

B. ESX host CPUs must be in the same processor family.

C. VMs must not be connected to standard vSwitches.

D. VMs must not be connected to internal vSwitches.

E. VMs must not be using CPU affinity.

13. If you are unsure a physical network adapter’s (speed, duplex) settings are correct or if you just need to verify other physical network adapter settings (MAC address, observed IP address ranges, wake on LAN support), which vSphere Client GUI form would you use?

A. Click Home Inventory Networking Virtual Switches.

B. Click Home Inventory Networking and select the appropriate dvSwitch uplink port group.

C. Click Home Inventory Hosts and Clusters, select an ESX server, click the Configu-ration tab, click Networking, and click Properties next to the vSwitch you need to query.

D. Click Home Inventory Networking, select a dvSwitch, and click the Ports tab.

14. Which of the following commands would be used to generate a log bundle suitable to diag-nosing a problem on your own or sending to VMware technical support for assistance?

A. vm-support

B. vicfg-exportlogs

C. vm-exportlogs

D. esxcfg-support


15. You have decided to install ESX onto a SAN LUN (that is, boot from SAN). Which of the following would be best practice?

A. Present the boot LUN to all ESX servers.

B. Present the boot LUN to the booting ESX server only.

C. Present the boot LUN to all ESX servers in the DRS/HA cluster.

D. Boot from SAN is not supported in vSphere 4.

16. A virtual machine is unable to communicate on the physical production network. In examining the virtual machine’s settings, you notice it has a virtual NIC, which seems to be connected to the correct port group. Other VMs on the same ESX server are connect-ing to the production network just fine. What might be the cause of the problem?

A. You need to reboot the VM.

B. You need to restart the network agents on the ESX server.

C. The Connect At Power On check box is not selected in the VM’s Network adapter hardware Properties dialog box.

D. The Connected check box is not selected in the VM’s Network adapter hardware Properties dialog box.

E. The virtual switch name is “production” on this ESX server, but “Production” on another ESX server.

17. What would you examine as an indicator of an ESX server’s being unable to keep up with VM disk requests?

A. The device queue depth

B. Ballooning

C. %Ready

D. Disk overcommitment

18. Having ESX servers properly configured for DNS usage is most important with which feature?

A. VMotion

B. DRS

C. HA

D. Storage VMotion

19. One of your ESX servers has lost connectivity with vCenter. You have decided to look at the log files on the ESX server to see if you can get an indication of the source of the problem. Which of the following log files would be most likely to help you troubleshoot this problem?

A. /var/log/messages

B. /var/log/VMkernel

C. /var/log/vmkwarning

D. /var/log/service-console

E. /var/log/errors


20. A VM has been disconnected from the proper vSwitch port group and so has lost its network connectivity. You correct the problem by reconnecting the VM to the correct vSwitch port group, but the VM is still unable to access the network. Other VMs on the same vSwitch port group on the same ESX server are successfully connecting to the network. What might you do to correct this problem? (Choose two.)

A. If the VM is using a DHCP-supplied IP address, use the command ipconfig /release followed by ipconfig /renew.

B. If the VM is using a static IP address, double-check to make sure the address is for the correct subnet.

C. Check the vSwitch to make sure it is using the correct physical uplink NICs.

D. Restart the network agents on the ESX host.

E. Reboot the ESX host.



1. D. The built-in alarm (“Cannot connect to storage”) is enabled and wants to send an SNMP trap by default. However, vCenter is not automatically configured with an SNMP trap sink, which you will need to configure for this alarm to be effective.

2. D. The new hardware health monitor monitors the following: processor (CPU), memory, fan, voltage, temperature, power, network, storage, cable/interconnect, software component, watchdog, and an “other” category. No monitor monitoring is done.

3. B. ESXi has no Service Console and the management network is, therefore, on a VMkernel port group labeled Management Network on the initial (vSwitch0) vSwitch. Only ESX servers have a Service Console port group proper.

4. B, D. For an ESX server to complete the transition into Maintenance mode, all the VMs running on it must be shut down or VMotioned to another ESX host. If you are running a DRS cluster, the easiest way to accomplish this is to have DRS running in fully automatic mode and ensure all the VMs meet VMotion compatibility requirements. Failing that, you will have to manually shut down VMs or ensure they meet VMotion requirements.

5. B. Editing distributed switch port-specific IP address settings is done via the Hosts And Clusters view, not the Networking view.

6. C. The current, initial release of Fault Tolerance recommends you run no more than 4–8 VMs with FT on a single ESX server. If the VMs are busy, you would want to err on the low side.

7. B. Although the red “x” will tell you an ESX server does not meet VMotion compatibility requirements, it will be up to you to investigate the exact cause and rectify it before attempt-ing to use that particular ESX server in a VMotion action.

8. C. The vm-support command generates a compressed (gz) tar archive (t) file, hence the .tgz extension.

9. B. That you have two ESX servers with green bars indicates they are probably not running over capacity. If you put the DRS cluster into fully automatic mode, DRS will apply VMotion recommendations, automatically balancing the load across all three servers (not just two as appears to be the case currently).

10. A. ipconfig is a Linux/Service Console command that returns many of the IP configura-tion parameters for an interface, including IP address, netmask, and broadcast address. ipconfig tells you the current configuration parameters in the system initialization files or what may have been previously manually set.

11. C. The vSphere Client GUI has no place where you can view all of the VM’s network settings. The VM’s Summary tab shows the VM’s IP address, but for the other settings you will have to go inside the VM itself (as you would on a physical server) and use a utility of your choosing in the guest OS.

12. C. There is no restriction as to standard versus distributed virtual switches.


13. C. Uplink/physical NIC adapter’s properties are viewed via the Hosts And Clusters view. The NIC’s speed and duplex can be set here while the other parameters can be examined.

14. A. The vm-support command is used to generate a log bundle (compressed tar) file. None of the other commands are real.

15. B. For security and performance reasons, you should present the boot LUN only to the ESX server booting from that LUN.

16. D. Make sure the VM’s network adapter is connected. Rebooting the VM won’t help in this case, nor will restarting networking on the ESX server. The Connect At Power On check box only helps after a reboot (which should be unnecessary in this case). Although virtual switch names need to be consistently labeled across ESX servers for VMotion compatibility purposes, that is not the problem here.

17. A. Large device queue depths indicate disk requests coming into the ESX server (and by implication the storage devices) faster than they are being satisfied, sort of like a long line at the bank. Longer queue depths/longer lines means longer wait times for the applications needing the data. Ballooning is a memory resource measurement, %Ready is a CPU resource measurement, and disk overcommitment helps you analyze the overuse of thin-provisioned virtual disks.

18. C. Although HA can be made to work without the benefit of DNS, it is more work and having a properly functioning DNS is something you should be doing anyway. None of the other features listed rely on DNS the way HA does.

19. A. The management network on an ESX server is handled via a Service Console network connection. Therefore, the file you would check first would be /var/log/messages, the general Service Console error log.

20. A, B. Anytime you have to reconnect a VM to a network, ask yourself, “How would this behave if it was a physical server on a physical network?” You may need to reassign or assign a new IP address to the VM’s network interface. In this particular scenario, the problem is likely not with the underlying physical NICs or the ESX network agents because other VMs on the same ESX server are working well.

Appendix About the Companion CD

IN ThIS APPENDIX:

What you’ll find on the CD.NÛ

System requirements.NÛ

Using the CD.NÛ

Troubleshooting.NÛ

What You’ll Find on the CDThe following sections are arranged by category and summarize the software and other goodies you’ll find on the CD. If you need help with installing the items provided on the CD, refer to the installation instructions in the “Using the CD” section of this appendix.

Sybex Test EngineThe CD contains the Sybex test engine, which includes the two bonus exams, one each for VCP-410.

Electronic FlashcardsThese handy electronic flashcards are just what they sound like. One side contains a question or fill-in-the-blank question, and the other side shows the answer.

PDF of the BookWe have included an electronic version of the text in PDF format. You can view the electronic version of the book with Adobe Reader.

Adobe ReaderWe’ve also included a copy of Adobe Reader so you can view PDF files that accompany the book’s content. For more information on Adobe Reader or to check for a newer version, visit Adobe’s website at www.adobe.com/products/reader/.

System RequirementsMake sure your computer meets the minimum system requirements shown in the following list. If your computer doesn’t match up to most of these requirements, you may have problems using the software and files on the companion CD. For the latest

http://www.adobe.com/products/reader/

Troubleshooting 541

and greatest information, please refer to the ReadMe fi le located at the root of the CD-ROM.

A PC running Microsoft Windows 98, Windows 2000, Windows NT4 (with SP4 or NN

later), Windows Me, Windows XP, Windows Vista, or Windows 7

An Internet connectionNN

A CD-ROM driveNN

Using the CDTo install the items from the CD to your hard drive, follow these steps:

1. Insert the CD into your computer’s CD-ROM drive. The license agreement appears.

Windows users : The interface won’t launch if you have Autorun disabled . In that case, click Start Run (for Windows Vista or Windows 7, Start All Programs Accessories Run) . In the dialog box that appears, type D:\Start.exe . (Replace D with the proper letter if your CD drive uses a different letter . If you don’t know the letter, see how your CD drive is listed under My Computer .) Click OK .

2. Read the license agreement, and then click the Accept button if you want to use the CD.

The CD interface appears. The interface allows you to access the content with just one or two clicks.

TroubleshootingWiley has attempted to provide programs that work on most computers with the minimum system requirements. Alas, your computer may differ, and some programs may not work properly for some reason.

The two likeliest problems are that you don’t have enough memory (RAM) for the pro-grams you want to use or you have other programs running that are affecting installation or running of a program. If you get an error message such as “Not enough memory” or “Setup cannot continue,” try one or more of the following suggestions and then try using the software again:

Turn off any antivirus software running on your computer. Installation programs sometimes mimic virus activity and may make your computer incorrectly believe that it’s being infected by a virus.

542 Appendix N About the Companion CD

Close all running programs. The more programs you have running, the less memory is available to other programs. Installation programs typically update files and programs; so if you keep other programs running, installation may not work properly.

Have your local computer store add more RAM to your computer. This is, admittedly, a drastic and somewhat expensive step. However, adding more memory can really help the speed of your computer and allow more programs to run at the same time.

Customer CareIf you have trouble with the book’s companion CD-ROM, please call the Wiley Product Technical Support phone number at (800) 762-2974.

Glossary

544 Glossary

Numbers802.1Q VLAN tagging. Standard and Distributed vSwitches can be configured to tag packets with different VLAN IDs for the VMs.

802.3ad Link aggregation. Also known as Ether Channel on Cisco switches. Used with VMware’s IP-based load-balancing policy for both standard and distributed vSwitches.

Aaccess controls Allowing or denying a user or group access to an object. This is used with the vSphere Client and the Web client.

Admission Control Allowing a VM to be powered on if enough resources are available. This is used in conjunction with VM reservations and HA clusters.

Advanced Configuration and Power Interface (ACPI) An open standard for hardware configuration and power management. ACPI S5 is the state in which an ESX/ESXi host is placed while in Standby mode.

Alarm A feature built into vCenter Server that allows an administrator to monitor for cer-tain conditions or events that occur inside the vSphere environment. Alarms are typically set to monitor objects such as, but not limited to, hosts, clusters, VMs, datastores, and networks.

Bballooning The VMkernel’s ability to redistribute memory when physical RAM is scare. See vmmemctl.

CChallenge-Handshake Authentication Protocol (CHAP) vSphere 4 ESX/ESXi supports one-way and mutual CHAP for iSCSI SAN connections.

Cisco Discovery Protocol (CDP) Layer 2 protocol that allows directly connected equipment to discover information such as IOS version and IP address. vSwitches can listen and advertise CDP information.

cold migration The process by which a VM is shut down and moved to a different datastore, a different ESX/ESXi host, or both.

Ddatastore VMware’s term for a local or remote VMFS volume or an NFS share.

Distributed Power Management (DPM) VMware technology that consolidates VMs onto fewer hosts thereby allowing some hosts to be placed in standby, reducing power consumption.

Glossary 545

Distributed Resource Scheduler (DRS) VMware’s load-balancing tool, which uses VMotion to move VMs from one ESX host to another for maintenance or load distribu-tion purposes.

EESX VMware bare-metal hypervisor with a Service Console. Can be manually installed from DVD or scripted.

ESXi VMware bare-metal hypervisor. Can be installed or embedded on new servers from a hardware vendor on an SD card or USB stick. ESXi does not include the Service Console.

FFibre Channel Storage technology that uses Fibre Channel Protocol (FCP) to carry SCSI commands to a centralized storage array.

GGuided Consolidation A plug-in to vCenter Server that allows an administrator to remotely monitor performance metrics of running servers on the network. After gathering performance statistics, it can call upon vCenter Converter for the physical-to-virtual process.

HHigh Availability (HA) VMware’s rapid recovery tool used in the event an ESX host crashes. Its primary role is to power up VMs that crashed with the host. HA clusters can also monitor VM heartbeats and restart individual VMs.

Host Bus Adapter (HBA) A controller card that allows connections primarily to FC, SCSI, and eSATA drives.

host profile A vSphere Enterprise Plus license feature that allows an administrator to gather the configuration settings of one ESX/ESXi server and use those settings as a reference to con-figure additional ESX/ESXi servers in an identical way.

Host Update utility Can be installed with the vCenter Client. It is a standalone Windows GUI application that allows an administrator to upgrade and patch ESX hosts.

Iinitiator A term often associated with iSCSI. There are two types of iSCSI initiators: hardware based and software based. Hardware initiators come in the form of physical NIC or HBA. Software initiators run inside the OS. In the case of ESX/ESXi, the soft-ware initiator runs within the VMkernel.

546 Glossary

Integrated Lights Out (iLO) Built-in management board giving a remote administrator the ability to manage a server. iLO is an HP-specific technology; however, other hardware vendors have similar remote management capabilities. Other examples include Dell’s DRAC and IBM’s RSA.

International Organization for Standardization (ISO) An image file with an .iso extension. It can be burned to a physical CD or DVD or connected to a VM as is.

Internet Small Computer System Interface (iSCSI) A storage system that carries SCSI commands over IP networks.

Llogical unit number (LUN) A logical device typically presented as an FC or iSCSI drive to an ESX host.

LUN masking The process of preventing a host from seeing or accessing a logical drive. This can be done on the storage array or at the host site.

MMaintenance mode The process of placing a server into a state whereby the VMkernel is unable to host running VMs. Maintenance mode is generally used during patch and upgrade installation on a host. DRS can use VMotion to facilitate the evacuation of VMs from a host placed into Maintenance mode.

multipathing The ability for a system to choose an alternate path for accessing storage. VMware ESX and ESXi have native storage multipathing policies: MRU (Most Recently Used), Fixed, and Round-Robin.

NNetwork File System (NFS) This protocol allows the VMkernel to remotely connect to a remote share for the purpose of accessing and storing VMs, ISOs, templates, and other files. The VMkernel can access an NFS version 3 over the TCP server.

network interface card (NIC) teaming Multiple physical NICs can serve as uplinks for vSwitches. These NICs can be configured to be active or passive.

No eXecute or eXecute Disable (NX/XD) A CPU feature that helps to prevent certain exploits such as buffer flow attacks. NX/XD features can be hidden or exposed to VMs. Sometimes these features are hidden from VMs in order to facilitate VMotion.

Ppermission A duty or function that can be assigned to an object (a VM, for example) that allows a user or group to perform a certain task.

Glossary 547

physical-to-virtual (P2V) The process of imaging a physical server and converting that image into a bootable VM.

Promiscuous mode A method in which a network card is configured to listen for all packets rather than dropping all frames not specifically addressed to its MAC address. A VM’s virtual NICs can be placed into this mode in order to monitor network traffic on a vSwitch. vSwitches have a security policy that can be configured to prevent this as well.

Rready time Time that a VM was ready to run on a CPU but was forced to wait on the VMkernel for scheduling. This time is usually measured and presented as milliseconds or a percentage depending on the interface. The vSphere Client shows ready time in milliseconds, and esxtop shows it as a percentage.

remediate The process of patching an ESX/ESXi server, VM, or template to match a baseline (group of patches).

remote command-line interface (rCLI) An appliance (vMA) or installable environment for Windows or Linux that allowes you to perform remote command-line operations on an ESX/ESXi host. See vSphere CLI.

resource pool A container that groups VMs together to control their CPU and memory usage on a single ESX/ESXi server or HA/DRS cluster.

role A collection of privileges that allows a user or group to perform certain functions on an ESX/ESXi or vCenter server.

SService Console Local command-line interface for ESX. It is based on a RedHat Enter-prise Linux (RHEL) 5.2– or CentOS-compatible kernel. It is automatically installed with the VMkernel during an ESX installation.

snapshot The process by which a VM’s disk and memory state are captured, thereby allowing an administrator go back to a VM’s previous state.

Standby mode The state in which an ESX/ESXi host is completely shut down. Also known as the ACPI S5 system state.

Storage Area Network (SAN) Connecting remote storage devices to servers; typically Fibre Channel or iSCSI.

Storage VMotion The process by which a VM’s files are moved from one datastore to another with no downtime. This is different from a standard VMotion.

548 Glossary

Ttemplate A VM that has been designated as a “golden image.” A VM can be converted to a template, and a template can be converted a VM. It is not possible to power on a template.

transparent page sharing The VMkernel uses this technique to eliminate duplicate mem-ory pages in physical RAM.

UUpdate Manager Allows an administrator to automate and simplify the patching of ESX, ESXi, VMs, and templates.

User An account that has permission to access objects on an ESX/ESXi or vCenter server. User accounts can be stored locally on ESX/ESXi, locally on vCenter, or as part of an Active Directory domain.

Vvirtual appliance A virtual machine designed for a specific purpose or function. OS and applications are usually preinstalled.

Virtual LAN (VLAN) Traditionally, LANs were segmented with routers, but VLANing allows for switches to be segmented into multiple broadcast domains.

virtual machine A software-based machine designed to function similar to a physical machine. An OS will be installed and run on top of virtual hardware.

Virtual Machine File System (VMFS) A proprietary, clustered file system for the ESX/ESXi platform.

VMkernel Proprietary OS developed by VMware that acts as the hypervisor for ESX. Its responsibilities include managing hardware and virtual machines.

vmmemctl Virtual machine memory controller driver. Also known as the “balloon driver.” It is loaded into a VM when the VMware Tools package is installed. It allows the VMkernel to reclaim memory from a VM by forcing the VM to use its own swapping techniques, such as the Windows pagefile.sys or the Linux swap partition or file.

VMotion VMotion allows for VMs to be migrated from one ESX host to another with no downtime to the VM. The active memory state and precise execution state of the VM is quickly copied from one VMkernel to the other.

VMware Consolidated Backup (VCB) A series of scripts designed to facilitate the backup of VMs. These scripts can be executed alone or in conjunction with a third-party backup solution.

Glossary 549

VMware Data Recovery (VDR) VMware’s latest backup and recovery solution for VMs. This solution consists of a 64-bit Linux-based virtual appliance and a plug-in that interacts with vCenter.

VMware Management Assistant (vMA) Appliance used for remotely running commands against ESX and ESXi servers. It includes the vCLI command-line environment. It is based on a 64-bit RHEL OS.

vpxuser Service account created on the ESX/ESXi server by vCenter. The password for this account consists of 32 characters and is randomly generated, encrypted, and stored both on the ESX/ESXi host and the vCenter server.

vSphere CLI (vCLI) Formerly known as rCLI. It includes Windows and Linux binaries for allowing an administrator to remotely execute commands against an ESX, ESXi, or vCenter server. It uses the vSphere SDK for Perl.

vSphere Client A Windows software application that can connect to either an ESX, ESXi, or vCenter server. Once connected, it allows an administrator to manage and configure the vSphere environment through a graphical interface.

WWake-On-LAN The process by which a server, physical or virtual, can be powered back on from a suspended state. This involves sending a “magic packet” to the MAC address of a network card inside the suspended server.

World Wide Name (WWN) A unique identifier assigned by a manufacturer typically used to connect an FC HBA to an FC SAN.

Zzoning Typically implemented on FC switches either as hard zoning (port based) or soft zoning (WWN based).

IndexNote to the Reader: Throughout this index boldfaced page numbers indicate primary discus-sions of a topic. Italicized page numbers indicate illustrations.

Aaccess

Service Console, 44–45vCenter Server

inventory objects, 229–231, 230–232

permissions, 224–229, 226–229, 236–237

roles. See roles in vCenter Serveraccess ports for virtual switches, 69actions

connectivity alarms, 458–460, 464, 464

utilization alarms, 468, 473, 473Actions tab

connectivity alarms, 464, 464utilization alarms, 473, 473

activating high availability, 423–424, 423–424

active/active iSCSI SAN storage, 129Active Directory Application Mode

(ADAM), 195Active Directory setting, 220active/passive iSCSI SAN storage, 129ADAM (Active Directory Application

Mode), 195adapters. See network adaptersAdd Adapter Wizard, 82–83, 82–83Add Hardware tab, 392Add Host To vNetwork Distributed

Switch wizard, 103Add Host Wizard, 206–207,

206–207

Add License Key dialog box, 222Add Network wizard, 76–77, 77, 111Add New Role wizard, 230, 230,

234, 234Add New User dialog box, 29, 29Add Patch Source dialog box,

318, 318Add Permission dialog box, 227,

227, 236Add Storage dialog box, 152–155,

152–155Add To Inventory option, 279Add Virtual Adapter wizard, 103address space load randomization

(ASLR), 40addressing

IP. See IP addressesiSCSI SAN storage,

140–141, 140MAC. See Media Access Control

(MAC) addressesadministrative credentials for

VUM, 307Administrator role, 233Admission Control for high availability,

431–432, 527Advanced charts

creating, 481–485, 481–485vs. Overview, 480–481

Advanced Options screenVDR appliances, 394, 394virtual machines, 256, 256

Advanced partitioning option, 7

552 advanced settings – backups for virtual machines

advanced settingsdistributed virtual switches, 92, 92,

96, 97dvPortGroups, 102partitioning, 7vCenter Server, 221VDR appliances, 394, 394virtual machines

CPUs, 286–287hard disk addresses, 256, 256sections, 282–283, 283

Advanced setup option, 11alarms, 456

connectivity. See connectivity alarmsexam essentials, 487performance. See performancereview questions, 488–494summary, 486utilization. See utilization alarmsVMFS volumes, 517

Alarms tabconnectivity alarms, 462, 462utilization alarms, 471, 471

All Groups And Independent Baselines option, 343

Analysis tab for discovered systems, 276

Any option for VM CPUs, 287appliances, virtual. See virtual

appliances (VApps)Application Data folder, 266Apply Profile option, 352–353applying host profiles, 352–353, 353AQLEN metric, 479ASLR (address space load

randomization), 40Assign A New License Key To This Host

option, 25Assign License screens

ESX server, 25, 25vCenter Server, 207, 207

associating ESX hosts with host profiles, 350–351, 351

Attach Baseline Or Group dialog box, 328, 328

Attach Profile option, 350attaching

baselines to inventory objects, 328–329, 328–329

datastores to ESX hosts, 155–156Attempt To Reboot Host And Rollback

Upgrade In Case Of Failure option, 36

authenticationCHAP, 518–519iSCSI SAN storage, 134, 135–136

Automatic DPM mode, 434Automatically Create A Default Port

Group option, 95automation levels in DRS, 433–434, 433AutoProtect feature, 49availability

HA. See High Availability (HA)Service Console, 108vCenter Server, 180

Average Bandwidth setting, 86

Bbackup agents, 31Backup Destinations page, 396Backup Job wizard, 397–399, 398–399Backup tab, 398, 398Backup Window screen, 398–399backups for host configurations, 31backups for virtual machines, 378

exam essentials, 405overview, 31–32

Balloon Driver tool – Choose Setup Language dialog box 553

procedures and strategies, 378–379review questions, 406–412snapshots, 380, 381

deleting, 383–385, 384–385restoring, 385–386, 385–386taking, 381–383, 381–383

summary, 404VDR appliances, 387

adding virtual disks to, 392–394, 392–394

backup jobs, 397–401, 398–401disk formatting, 396installing, 387–391, 387–391plug-in, 395–396restore tests, 402–404

Balloon Driver tool, 259bare-metal architecture vs. hosted,

53–55, 54Baseline Name And Type

screen, 324baselines

compliance data, 342host remediation with, 335–337,

335–337VM remediation with, 338–341,

338–341VUM

attaching to inventory objects, 328–329, 328–329

creating, 323–327, 323–327Baselines And Groups tab, 324, 324Beacon Probing option, 85binding

types, 101VMkernel ports, 136–139,

137–139Block Level cloning mode, 273boot disks, 47/boot mount point, 6

boot options for virtual machines, 283

bootstrap process, 14, 14bulls-eyes for snapshots, 380Burst Size setting, 87BusLogic Parallel SCSI adapters, 257

CCannot Connect To Network alarm,

457–458, 461Cannot Connect To Storage alarm,

457–458, 461, 517capacity issues for High Availability,

431, 527–528, 527Capacity Planner service, 193carbon copy clones, 277CD-ROMs for VM connections, 281CDP (Cisco Discovery Protocol),

79, 96Challenge Handshake Authentication

Protocol (CHAP), 134, 135–136, 518–519

Change Both Host And Datastore option, 376–377

Change Datastore option, 374, 376–377

Change Host option, 376–377CHAP (Challenge Handshake

Authentication Protocol), 134, 135–136, 518–519

Chart Type setting, 482charts, performance, 480–485,

480–485checksums for downloaded files, 5, 5Choose Datastore screen, 374Choose Setup Language dialog box,

189, 189

554 Choose the Destination Resource Pool screen – Configuration tab

Choose the Destination Resource Pool screen, 208, 208

CIFS (Common Internet File System) shares, 387, 392

CIM (Common Information Model) APIs, 52

Cisco Discovery Protocol (CDP), 79, 96

claim rules for LUN masking, 125–126

clientsNTP, 23vSphere. See vSphere ClientVUM, 306–307, 312–313,

312–313clones

vApps, 292, 293vCenter Server, 181, 235, 235virtual machines, 277

cold, 274, 275hot, 273, 274, 277modes, 273vs. templates, 278–279

cluster across boxes scenario, 503–504, 504

cluster in a box scenario, 503–504, 504

Cluster Settings screen, 423Cluster Summary tab, 432clusters, 415

creating, 416–417, 416–418DPM policies, 434, 435DRS

automation levels and migration thresholds, 433–434, 433

settings, 425–429, 426–428ESX/ESXi hosts added to,

418–419, 418EVC, 428–429

exam essentials, 447–448Fault Tolerance, 435–440,

436–437, 439high availability settings, 419–425,

422–425, 431–432requirements, 522–523resource pools. See resource poolsreview questions, 449–454summary, 447Summary tab, 526swap file location, 429–430, 430troubleshooting, 502–505, 504–506vCenter Server, 181VMotion VM migration, 372vSphere, 253

cold clones, 274, 275cold migrations, 365–368, 370,

376–378, 376–378committing snapshot changes, 383Common Information Model (CIM)

APIs, 52Common Internet File System (CIFS)

shares, 387, 392community ports for PVLANs, 98Compatibility Guides, 4, 4compatibility requirements in VM

migration, 365–367compliance, 303

ESX host profiles. See host profilesVUM. See VMware Update

Manager (VUM)Compliance Details tab, 350Confidence metric, 276–277Configuration Complete screen, 396Configuration Details tab, 350Configuration dialog box, 18Configuration tab

dvSwitches, 95ESXi management, 110, 110

Configure Management Network option – Create New Virtual Machine wizard 555

network adapters, 81–82, 81, 251, 512

NFS datastores, 144, 144NTP, 22patch downloads, 317, 317port groups, 509virtual machines, 261VUM, 314

Configure Management Network option, 18

Configure Password option, 17Configure Ports screen

Guided Consolidation module, 194

vCenter Converter module, 195vCenter Server, 192, 192

Confirm Installation screen, 395connection and connectivity issues

network adapters, 510–511, 511port groups, 508–509, 509Service Console, 525, 525storage, 517virtual switches, 78, 78

Connection Settings screen, 78, 78connectivity alarms, 456

actions, 458–460, 464, 464analyzing and evaluating, 460–461,

460–461creating, 461–465, 462–464default, 457–458listing, 457relating, 465–466, 465–466

consolidating physical machines, 277

contention issues in storage, 515–516context switching, 54Continue Modifying This Connection

option, 107control planes for dvSwitches, 88

Convert To Template option, 264converting templates, 264, 264COSMEM metric, 477counters

Advanced charts, 483performance, 480–481

CPU affinity, 366, 523CPU Ready counter, 484–485CPU Usage counter, 484–485CPUID Mask section, 282–283CPUID method, 429cpuid tool, 524, 524CPUs

Advanced charts, 481counters, 480, 483–485, 484ESX/ESXi servers, 3, 32EVC, 429Guided Consolidation

information, 276performance metrics, 477–478reserving, 503resource pools, 441–444resource shares, 444–445utilization alarms, 467–470, 469vCenter Server, 178–179virtual machines, 250, 254,

284–287, 285VMotion, 524, 524VUM, 305

Create A Disk screen, 258, 258Create A New Backup Job After

Completion option, 396Create A New Virtual Disk option,

255, 393Create a standalone VMware

vCenter Server instance option, 192

Create New Virtual Machine wizard, 251–253, 258

556 Create Profile From Existing Host option – default alarms

Create Profile From Existing Host option, 345, 347

Create Profile Wizard, 345–347, 345–346

Create Resource Pool dialog box, 443–444, 443

Create vNetwork Distributed vSwitch wizard, 93–95, 93–95

credentialsESX/ESXi upgrades, 36, 36VDR appliances, 396VUM, 307–309, 309

Credentials page, 396Critical Host Patches baseline, 323Critical VM Patches baseline, 323%CSTP3 metric, 475Current Disk Layout screen, 153, 153Current Host Load Standard Deviation

setting, 526Custom Drivers screen, 9, 9Customer Information screen,

190, 190Customization Specifications Manager,

265–267, 266–267Customize Using An Existing

Customization Specification option, 209, 265

Customize Using The Customization Wizard option, 209, 265

DData Recovery dialog box, 396Data Recovery pane, 398, 398Database Operator (DBO) rights, 187Database Options screen, 190–191,

190–191Database setting, 221Database Retention Policy setting, 221

databasesvCenter Server

preparing, 186–187settings, 190–191, 190–191, 221size requirements, 183–186,

184–186VUM

settings, 308–309, 309sizing, 305–306

datacentersmaps, 215–216, 216Site Recovery Manager, 51vCenter Lab Manager, 51–52vCenter Server, 210–212, 211VMware View, 50–51

Datastore Consumer role, 233Datastore Disk Overallocation

alarm, 517Datastore Disk Usage alarm, 517Datastore screen

VDR appliances, 390, 390virtual machines, 270, 270

Datastore Usage On Disk alarm, 467–468, 469, 517

datastoresalarm actions, 460VDR appliances, 390, 390virtual machines, 252, 254, 261,

390, 390VMFS. See virtual machine file

system (VMFS) datastoresDate and time configuration

subprofile, 349Date and Time screen, 12, 12DAVG metric, 475DBO (Database Operator) rights, 187default alarms

connectivity, 457–458, 457utilization, 467–468

default gateways – Distributed Resource Scheduler (DRS) 557

default gatewaysinstallation issues from, 499network adapters, 511

Default Installation Location screen, 194

default partition layout, 11default security principles, 39Default To Advanced Performance

Charts option, 221Degraded Storage Path Redundancy

trigger, 517deleting

host profiles, 347, 347snapshots, 383–385, 384–385standard virtual switches,

79, 80VMFS datastores, 160–161,

160–161delta disks, 380demilitarized zones (DMZs),

41, 41denial-of-service (DoS) attacks, 40Deploy OVF Template dialog box,

387, 388Deploy Virtual Machine From This

Template option, 268Describe The Snapshot screen,

214, 214Destination screen

backup jobs, 399, 399VMotion VM migration, 372

Destination Folder screenUMDS, 321, 321vCenter Server, 192, 192

Destination Selection screen, 403device drivers, 259devices

network adapter information, 512VM connections, 281

DHCP addresses and servers, 18ESX hosts, 108port groups, 111Service Console, 107virtual switches, 88

diagnostic data, exporting, 501–502Direct Connection To Internet

section, 318direct path devices, 250discovered physical machines

analysis, 276discovery

Guided Consolidation, 276iSCSI SAN storage, 134, 135LUNs, 139, 140

disk-based cloning, 273Disk Format screen, 270, 270Disk.SchedNumReqOutstanding

setting, 516disks and disk drives for

virtual machinescold VM migration, 377, 377designating, 253, 253formats, 270, 270, 280–281growing, 280, 280installation options, 255–256, 256performance charts and counters,

480–481, 483settings, 286Storage VMotion VM migration,

375, 375types, 257–259, 258VDR appliances, 392–394,

392–394, 396Distributed Power Management (DPM),

427–428, 428, 434, 435Distributed Resource Scheduler (DRS),

121, 369, 425, 426automation levels, 433–434, 433

558 Distributed Virtual Switch option – Edit Profile option

clusters, 503Distributed Power Management,

427–428, 428dynamic balancing, 426initial VM placement, 425Migration Threshold setting,

426–427, 427requirements, 522–523resource distribution graph and

Target/Current Host Load Deviation, 526

Distributed Virtual Switch option, 510

distributed virtual switches (dvSwitches), 68, 70, 88–89

binding types, 101creating, 93–99, 93–98dvPortGroup settings, 99–102, 100hosts, 102–103migrating virtual machines to,

104–105, 104uplinks group settings, 99virtual port groups

NIC Teaming and failover policy, 89–90, 90

security policies, 90–92, 91–92VMkernel dvPorts, 103, 103–104

Distributed Virtual Switches option, 514

DMZs (demilitarized zones), 41, 41DNS and DNS servers

configuring, 18ESX hosts, 108–109, 108–109installation issues from, 499network adapters, 511verifying settings, 524–525, 525VMkernel, 106, 106

DNS And Routing Configuration dialog box, 106–108, 107, 109

DNS Configuration page, 106, 106Do Not Create Disk option, 256Do Not Customize option, 265Do Not Use CHAP security level, 134Do Not Use CHAP Unless Required By

Target security level, 134DoS (denial-of-service) attacks, 40downloading

installation media, 5, 5patches, 316–319, 317–318

Downloading System Logs Bundles dialog box, 501

downtime, 368DPM (Distributed Power Management),

427–428, 428, 434, 435%DRPRX metric, 479%DRPTX metric, 479DRS. See Distributed Resource

Scheduler (DRS)DRS tab, 426, 427dvPortGroups

adding and deleting dvPorts, 103, 103–104

settings, 99–102, 100dvSwitches. See distributed virtual

switches (dvSwitches)dynamic balancing, 426dynamic baselines, 324–325dynamic discovery in iSCSI SAN

storage, 134, 135Dynamic Discovery tab, 134, 135Dynamic settings for

dvPortGroups, 101

EE1000 virtualized network adapter, 69Edit Override Settings link, 92Edit Profile option, 349

Edit Role dialog box – Events pane 559

Edit Role dialog box, 235, 235Edit Virtual Hardware option, 271editions

vCenter Server, 183VMware, 47–50

Effective VM Speed In MHz counter, 486

email server alarms, 466, 466embedded ESXi servers, 15, 53Enable Host Monitoring option, 424encapsulated partitioning, 15End User License Agreement.

See licensesEnhanced VMotion Compatibility

(EVC), 365, 428–429, 523Enterprise Converter, 272–273Ephemeral settings for dvPortGroups,

101–102Error events in vCenter Server, 217ESX/ESXi servers

architecture, 52bare-metal vs. hosted, 53–55, 54ESX, 52–53ESXi, 53

exam essentials, 56hosts. See hostsinstallation

from ISO files, 15–20, 16–20on local storage, 6–15, 8–15NTP configuration,

20–24, 21–24planning, 3–5, 4–5on SAN storage, 45–47standalone licenses, 24–28, 25–26troubleshooting, 498–499, 499user accounts, 28–30, 28–30

management interfacesESX, 105–109, 105–109ESXi, 109–112, 110–111

networking. See networks and networking

performance. See performancereview questions, 57–63security. See securitystorage. See storagesummary, 55system health, 500–501upgrades, 30

hardware requirements, 32host backups, 31planning, 30scenarios, 32–39VM backup options, 31–32

user permissions, 229, 229VUM retry policy, 315–316

esxcfg-module command, 515esxcfg-switch command, 76esxcfg-vswitch command, 519esxcli command, 138, 518esxconsole-flat.vmdk file, 15esxconsole.vmdk file, 15, 334esxtop tool

device queue length, 515performance metrics, 474–476

CPU, 477–478memory, 476–477network, 478–479storage, 479

Ethernet controllers, 4EULA. See licensesEvaluation mode, 9EVC (Enhanced VMotion

Compatibility), 365, 428–429, 523

Event Details pane, 219, 220events in vCenter Server, 217–219,

218–220Events pane, 218, 218

560 expandable reservations – FQDNs (fully qualified domain names)

expandable reservations, 445–446Export Events dialog box, 219, 219Export Profile option, 348Export System Logs dialog

box, 501exporting

diagnostic data, 501–502events, 219, 219host profiles, 348users and groups lists, 44, 44virtual appliances, 288, 292VUM patches, 322

extensions for VM files, 262

FFail Task response, 316Failback setting for virtual

switches, 85failover policies

distributed virtual switches, 89–90, 90

dvPortGroups, 102virtual switches, 83–85, 84

Failure Interval setting, 424Failure Response options, 316Fault Tolerance (FT) feature, 435

benefits, 505downtime, 368enabling, 438–439evaluating, 436–437, 436guidelines, 506requirements, 438restrictions, 435–436setting up, 437testing, 439troubleshooting, 506–508

FC storage. See Fibre Channel (FC) SAN storage

FDUPLX metric, 478feature bundles, 26–28Fibre Channel (FC) SAN storage,

121–122configuring, 46ESX/ESXi server support, 4hardware components, 122LUN masking, 125–126, 126multipathing policy, 127, 127NMPs and third-party

MPPs, 128server addressing, 124, 124server connections, 122–124, 123zoning, 124

Fibre Channel NPIV section, 283File Level cloning mode, 273file system attributes, 147–148files for virtual machines, 261–262

importing from, 279, 279types, 262–263

Filter Patches dialog box, 325, 326finding events, 218, 219firewalls

Service Console, 40, 42–43, 42–43subprofiles, 349

fixed baselines, 324–327, 324–327Fixed multipathing policy, 127flat files, 263-flat.vmdk extension, 262Flexible adapters, 69floppy disks and controllers, 250, 281folders

importing VMs from, 279, 279vCenter Server, 210–212, 211–212

Force BIOS Setup option, 283Forged Transmits setting, 75, 90formatting disks, 396FQDNs (fully qualified domain names),

10, 206

free space setting for VMFS datastores – High Availability (HA) 561

free space setting for VMFS datastores, 163

FT. See Fault Tolerance (FT) featureFully Automated DRS mode, 433fully qualified domain names (FQDNs),

10, 206

GGeneral Properties dialog box,

133, 133general settings

connectivity alarms, 462, 462distributed virtual switches, 95, 96dvPortGroups, 100, 101software initiators, 133, 133utilization alarms, 471, 471virtual machines, 281–282, 282virtual switches, 83, 84VMkernel ports, 513, 513vSphere Client, 221, 223

Getting Started wizard, 396grafted resource pools, 418groups and group accounts

port. See port groupssetting up, 43–44, 44vCenter Server, 225–226

permissions, 236–237roles assignments, 236

VMFS datastores, 156–157, 156–157growing

VM virtual disks, 280, 280VMFS datastores, 161–166, 161–165

Guest Customization screen, 209, 265, 265, 271, 271

Guest Operating SystemsEVC, 429vCenter Server, 209, 210virtual machines, 252

Guided Consolidationdiscovered physical machine

analysis, 276discovery, 276installing, 193–194physical machines

consolidation, 277services, 275VM deployment, 275–277

hHA. See High Availability (HA)hard zoning, 124hardware

ESX/ESXi servers, 3–4, 32FC SAN storage, 122health status, 500–501iSCSI initiators, 130–131iSCSI SAN storage, 129, 130NFS datastores, 142vCenter Server, 178–179virtual machines, 250–251,

259, 280VUM, 305–306

Hardware Status tab, 500HBA BIOS configuration, 46–47heartbeats

network paths, 528–529network redundancy, 422, 422timeout setting, 421vCenter Server, 180–181

hierarchy of resource pools, 446, 447

High Availability (HA), 121, 419–420

activating, 423–424, 423–424admission control, 431–432, 527capacity issues, 431, 527–528, 527

562 High priority – hosts

cluster-wide settings, 423heartbeats

network paths, 528–529network redundancy, 422, 422timeout setting, 421vCenter Server, 180–181

host isolation response, 421–422prerequisites, 420redundancy issues, 528–529, 528requirements, 522–523testing, 432third-party, 505vCenter options, 180–182VM monitoring, 424–425, 425

High priorityCPU resources, 444–445VMotion VM migration, 372

high tier in VMFS datastores, 148Host/Cluster screen, 269, 269, 389Host Compliance Failures

section, 354Host Connection And Power State

alarm, 457–458, 457, 462–465, 462–464

Host Connection Failure alarm, 457–458, 461

Host Connection State trigger, 463Host CPU Usage alarm, 467–468Host Failure Capacity setting, 431Host Failures Cluster Tolerates

policy, 527Host Information screen, 206Host Memory Usage alarm,

467–468Host Power State trigger, 463host profiles, 343–344

applying, 352–353, 353associating hosts with,

350–351, 351

compliance checks, 351, 352configuration compliance

information analysis, 353–354, 353–354

creating, 344–346, 344–346deleting, 347, 347exam essentials, 355importing and exporting, 347–348policies, 348–350, 349–350review questions, 356–362summary, 355

Host Profiles screen, 345, 347Host Remediation Options screen,

336, 337Host To Datastore relationship, 527Host To Network relationship, 527Host Update Utility, 20,

35–39, 35–38hosts

vs. bare-metal architecture, 53–55, 54

baselines, 324in clusters, 416–419, 417–418configuration backups, 31connectivity alarms, 459, 462–465,

462–464distributed virtual switches,

102–103DNS and routing, 108–109,

108–109ESX/ESXi upgrades, 34–39,

35–38Fault Tolerance, 438–440iSCSI addressing, 140–141, 140isolation response, 421–422performance, 480–482, 480–481,

485–486, 486profiles. See host profilesremediation, 334–337, 335–337

hot-adding VM hardware – iSCSI SAN storage 563

scanning, 329–334, 329–333troubleshooting, 497–502, 499updates, 341vCenter Server

joining to, 206–208, 206–208maximums, 201–204

hot-adding VM hardware, 280hot clones, 273, 274, 277hyperthreading virtual machines, 287

IIDE controllers and devices, 250ifconfig vswif0 command, 525Import Profile screen, 347Import Wizard screen, 273, 274importing

host profiles, 347virtual appliances, 288virtual machines, 279, 279VUM patches, 322

independent VMDKs, 256Info events in vCenter Server, 217initiators

configuring, 132–133, 132–133hardware vs. software, 130–131issues, 518–519

installable ESXi servers, 15, 53installation

ESX/ESXi. See ESX/ESXi serversUMDS, 319–321, 319–321vCenter Server, 177–178, 187–193,

188–192VDR appliances, 387–391,

387–391VDR plug-in, 395–396, 395–396VMware Tools, 260VUM, 194, 305–311, 307–311

Installation Complete screen, 395, 395

Internal option for VM CPUs, 287Interval setting for Advanced

charts, 482Inventory Location screen, 389inventory objects

access, 225, 229–231, 230–232attaching baselines to, 328–329,

328–329compliance data, 343folders, 211scanning, 329–334, 329–334

Inventory panel, 21Inventory View pane, 222I/O planes, 88IP addresses, 18

ESX hosts, 108ESXi management interface,

111, 111Guided Consolidation module, 194installation issues, 499network adapters, 10, 511Service Console, 107, 107testing, 524–525vApps, 292vCenter Converter module, 195virtual switches, 88VMkernel, 106VUM, 308, 310

IP hashes, routes based on, 74IQNs (iSCSI qualified names), 140iSCSI HBA BIOS configuration, 46–47iSCSI qualified names (IQNs), 140iSCSI SAN storage, 129

addressing, 140–141, 140CHAP authentication, 134,

135–136dynamic/static discovery, 134, 135

564 ISO files – logical unit numbers (LUNs)

ESX/ESXi server support, 4hardware components, 129, 130initiators

configuring, 132–133, 132–133hardware vs. software, 130–131issues, 518–519

LUN discovery, 139, 140VMkernel port binding, 136–139,

137–139ISO files, ESXi installation from,

15–20, 16–20isolated ports for PVLANs, 98

KKAVG metric, 475Keep Existing Signature option, 156Keep Snapshots For A Fixed Period Of

Time option, 314Keep Snapshots Indefinitely

option, 314kernel module integrity, 40keyboard selection, 8, 8

lLCPU(%) metric, 478legends for charts, 482License Agreement screen, 395–396,

395–396Licensed Features link, 24Licensed Features panel, 26, 26licenses

ESX/ESXi, 8–9, 9, 16standalone, 24–28, 25–26upgrades, 35

UMDS, 320, 320vCenter Converter module, 195

vCenter Server, 183, 189–190, 189, 207, 207, 220–221, 222

VDR plug-in, 395–396, 395–396VUM, 308, 308, 313

Licensing setting, 220limits

resource pools, 441–443for security, 40setting, 444–445VM memory, 286

Link Status Only option, 85Linked Mode groups, 195–198Linux virtual machines, 265–266,

265–266Lists tab for vCenter Client settings,

222, 223load balancing

distributed virtual switches, 89options, 73–74Storage VMotion, 369virtual switches, 84

local cloning, 274local storage, ESX/ESXi installation on,

6–15, 8–15.log extension, 262log files, 263logging networks for Fault Tolerance

failures from, 507setting up, 437, 437

Logging Options setting, 221logical unit numbers (LUNs)

boot, 47contention issues, 515–516discovering, 139, 140FC SAN storage, 122,

125–126, 126masking, 45–46, 125–126, 126VMFS datastores, 149–150,

163, 163

logons – memory 565

logons, remote, 15Lost Storage Connectivity

trigger, 517Lost Storage Path Redundancy

trigger, 517Low priority

CPU resources, 444VMotion VM migration, 372

lower tier for VMFS datastores, 149LQLEN metric, 479LSI Logic Parallel SCSI adapters, 257LSI Logic SAS SCSI adapters, 257LUNs. See logical unit

numbers (LUNs)

MMAC addresses. See Media Access

Control (MAC) addressesMail setting for vCenter Server, 220Maintenance mode, 352, 502–503Make A Snapshot Of A Virtual Machine

option, 213Manage Physical Adapters

option, 99Manage Plug-ins manager, 395Manage Plug-ins option, 312Manage Virtual Adapters link, 514management interface

ESX, 105–109, 105–109ESXi, 109–112, 110–111

Management Network Properties dialog box, 111

Management Traffic option, 513manual failover/failback

processes, 503Manual mode

DPM, 434DRS, 433

mapstopology, 526–527, 527vCenter Server

resource, 215–216, 216storage, 216–217, 217–218,

519–521, 520–521Maps tab, 215–216, 216masking, LUN, 45–46,

125–126, 126Maximum Per-VM Resets

setting, 425MBREAD/S metric, 479MbRX/s metric, 475MbTX/s metric, 475MBWRTN/s metric, 479MCTLSZ metric, 477Media Access Control

(MAC) addressesclones, 277distributed virtual switches, 90FC SAN storage, 124network adapters, 512virtual switches, 75

MEMCTL metric, 475memory

Guided Consolidation information, 276

hardening, 40performance metrics, 476–477,

480, 483requirements

ESX/ESXi servers, 4upgrades, 32vCenter Server, 178–179VUM, 305

reserving, 503resource pools, 441–444setting, 445utilization alarms, 467–470,

469–470

566 Memory reservation configuration subprofile – nesting resource pools

virtual machines, 254maximum, 250settings, 286swap files for, 263

VMware Tools for, 259Memory reservation configuration

subprofile, 348MEMSZ metric, 477metrics, performance

CPU, 477–478identifying, 474–476memory, 476–477network, 478–479storage, 479

Microsoft Cluster Service (MSCS), 502–504

Microsoft clusters for vCenter Server, 181

mid tier for VMFS datastores, 149Migrate Existing Virtual Adapters

option, 103Migrate Virtual Machine Networking

wizard, 104, 104migrating virtual machines, 364

cold, 365–368, 370, 376–378, 376–378

compatibility requirements, 365–367to distributed virtual switches,

104–105, 104exam essentials, 405methods overview, 367–368review questions, 406–412Storage VMotion, 366, 369,

373–375, 373–375summary, 404VMotion, 365–366, 369–373,

371–373Migration Threshold setting, 426–427,

427, 433–434, 433

Minimum Uptime setting, 424Modify Linked Mode Configuration

option, 197modules in vCenter Server, 193–195Monitor for specific conditions or state

option, 471monitoring

alarms for. See alarmsESX server system health,

500–501VMware Tools for, 259

Most Recently Used (MRU) policy, 127

MSCS (Microsoft Cluster Service), 502–504

multipathingFC SAN storage, 127, 127iSCSI storage, 136–139, 137–139

NN-Port ID Virtualization (NPIV), 123Name And Location screen, 268, 268names

FQDNs, 10, 206IQNs, 140user accounts, 29VDR appliances, 389virtual machines, 251–252, 268,

268, 282VMFS datastores, 154WWNs, 45, 124

naming authority for iSCSI addressing, 140

NAS (network-attached storage) devices, 141

Native Multipathing Plug-in (NMP), 127

nesting resource pools, 446, 447

Network Access screen – NICs 567

Network Access screen, 77, 77network adapters

connection issues, 510–511, 511distributed virtual switches,

97, 97ESX/ESXi upgrade requirements, 32installation issues from, 499, 499selecting, 10, 10settings, 281, 511–512, 511–512virtual machines, 250, 255, 255virtual switches, 68–70, 82–83,

82–83Network Adapters tab, 82, 82, 97, 97,

512, 512network-attached storage (NAS)

devices, 141Network Configuration screen, 10, 10Network Consumer role, 233Network Failover Detection

settings, 85Network File System (NFS)

datastores, 141–142creating, 144–146, 144–146ESX/ESXi network connectivity,

143, 143ESX exclusivity, 142, 143hardware components, 142

Network Time Protocol (NTP), 12agent, 259configuring, 20–24, 21–24

Networking configuration subprofile, 348

networks and networking, 65–67adapters. See network adaptersdistributed virtual switches. See

distributed virtual switches (dvSwitches)

exam essentials, 112management

ESX, 105–109, 105–109ESXi, 109–112, 110–111settings, 512–514, 513–514

performance metrics, 478–481, 483requirements

clusters, 523vCenter Server, 178VUM, 305

review questions, 113–118Service Console connectivity,

525, 525summary, 112troubleshooting, 508–514, 509–514virtual switches. See virtual

switches (vSwitches)VM backups, 379

New Alarm option, 471New Baseline wizard, 324, 325New Cluster option, 416, 419New License Key dialog box, 25New Port Group wizard, 99New Resource Pool option, 443New vApp wizard, 290, 290NFS (Network File System)

datastores, 141–142creating, 144–146, 144–146ESX/ESXi network connectivity,

143, 143ESX exclusivity, 142, 143hardware components, 142

NIC Teamingdistributed virtual switches,

89–90, 90iSCSI software multipathing,

137, 137–138virtual switches, 73–74, 73,

83–85, 84NICs. See network adapters

568 NMP (Native Multipathing Plug-in) – Patch Download Settings link

NMP (Native Multipathing Plug-in), 127–128

No Access role, 230–232, 231Non-Critical Host Patches

baseline, 323Non-Critical VM Patches

baseline, 323nonpersistent VMDKs, 256Normal priority for CPU resources,

444–445Notification screen, 214, 214,

333, 333Notify switches, 85NPIV (N-Port ID

Virtualization), 123NTP (Network Time Protocol), 12

agent, 259configuring, 20–24, 21–24

NTP Daemon (ntpd) Options dialog box, 23, 23

.nvram extension, 262

OObjects setting for Advanced

charts, 482Observed IP Ranges information for

network adapters, 512Off DPM mode, 434Open Database Connectivity (ODBC)

connections, 187, 308Open Virtualization Format (OVF) files,

288, 387–388Open VM Archives (OVAs), 292operating systems

EVC, 429vCenter Server, 209, 210virtual machines, 252, 254

optional partitions, 7

Options screenvApps, 289, 291, 292VDR appliances, 393virtual machines, 281–282, 282

originating virtual port IDs, route based on, 74

outbound traffic with virtual switches, 86–87, 86

OVAs (Open VM Archives), 292overcommitment storage issues,

516–517, 516–517Override vSwitch failover order

option, 137Overview charts, 480–481, 480OVF (Open Virtualization Format)

files, 288, 387–388OVHD metric, 477%OVRLP metric, 478

Pparallel ports

VM connections, 281VM maximums, 250

paravirtualization, 283partial Fault Tolerance failures, 507Partially Automated DRS mode, 433partitions

encapsulated, 15ESX servers, 6–7VMFS datastores, 163

passwordsESX/ESXi upgrades, 36, 36root, 12, 13, 17user accounts, 29VUM, 307–309, 309

Patch Details dialog box, 343Patch Download Settings

link, 317

patches – pNICs (physical NIC devices) 569

patchesbaselines

creating, 323–327, 323–327host remediation with, 335–337,

335–337VM remediation with, 338–341,

338–341download options, 316–319,

317–318ESX servers, 341exporting and importing, 322

Patches screen, 325–326host remediation, 336VM remediation, 339, 339

Path Selection Plug-ins (PSPs), 128paths

FC SAN storage, 127, 127iSCSI storage, 136–139, 137–139

pausing VM disk activity, 259PCI addresses, 499, 499PCPU(%) metric, 478Peak Bandwidth setting, 86Percentage Of Cluster Resources

Reserved policy, 527performance, 474

charts, 480–485, 480–485hosts, 485–486, 486metrics

CPU, 477–478identifying, 474–476memory, 476–477network, 478–479storage, 479

Performance Monitor (Perfmon), 485–486, 486

permissionsESX Server, 229, 229vCenter Server

creating, 224–229, 226–229

propagation, 236users and groups, 236–237

vSphere Client plug-ins, 200Permissions tab, 226–227, 236persistent VMDKs, 256physical compatibility mode, 504Physical Computer column in Guided

Consolidation, 276physical machines

consolidating, 277discovered, analysis, 276vCenter Server installation on, 187

physical NIC devices. See pNICs (physical NIC devices)

physical switches vs. virtual, 70–71, 71

ping command, 529PKTRX/s metric, 479PKTTX/s metric, 478planning

ESX/ESXi installation, 3–5, 4–5vSphere upgrades, 30

platforms, VMware, 47–50Plug-in Manager, 198, 199,

312–313, 312plug-ins

NMP, 127–128PSP, 128VDR, 395–396vSphere Client, 198–200, 199–200VUM, 312–313, 312–313

Pluggable Storage Architecture (PSA), 128

PMEM metric, 477pNICs (physical NIC devices), 67

link state, 85load balancing, 73–74, 89number of, 81–83, 81–83settings, 512, 512

570 policies – processors

virtual switch connectivity, 69–70, 75

vs. virtual switches, 70–71, 71vmnics, 97

policiesAdmission Control, 527DPM, 428, 434, 435dvPortGroups, 102ESX server retry, 315–316failover


dvPortGroups, 102virtual switches, 83–85, 84

FC SAN storage multipathing, 127, 127

host profiles, 348–350, 349–350NIC teaming, 73–74, 73virtual port groups, 90–92, 91–92virtual switches

failover, 83–85, 84security settings, 74–75, 75,

86–87, 86VUM snapshots, 314–315

pools, resource. See resource poolsPort Group Override Settings dialog

box, 92, 92port groups, 70

creating, 81, 81NIC Teaming and failover policy,

89–90, 90security policies, 90–92, 91–92troubleshooting, 508–510, 509–510virtual switches, 68, 79–80, 80

PortIDs, 123ports

iSCSI SAN storage, 129PVLANs, 98Service Console, 513

heartbeat network redundancy, 422

port groups, 70virtual switches, 68

vCenter Server, 221virtual machines

connections, 281maximums, 250

virtual switches, 68–70, 76VMkernel

binding, 136–139, 137–139creating, 87, 87dvPorts, 103, 103–104editing settings, 105–107, 106verifying settings, 513–514,

513–514VUM, 310

Post Upgrade Options screen, 36, 37power management options

Distributed Power Management, 427–428, 428

virtual machines, 283–284, 283Power Management Options screen,

284, 284Power Off Virtual Machines And Retry

response, 316Power On This VM After Creation

option, 271primary virtual machines, 437priorities

CPU resources, 444–445DRS, 427high availability, 423VM CPU time, 285VMotion VM migration, 372

Private VLANs (PVLANs), 92, 98, 98Private VLANs tab, 98, 98processors. See CPUs

Profile Compliance tab – Repeat Triggered Alarm Every setting 571

Profile Compliance tab, 350–354, 352, 354, 439

Profile Details screen, 346, 346profiles, host. See host profilespromiscuous mode

distributed virtual switches, 90virtual switches, 75

promiscuous PVLAN ports, 98Propagate To Child Objects

option, 228proxy settings for UMDS, 320, 321PSA (Pluggable Storage

Architecture), 128PSHARE metric, 477PSPs (Path Selection Plug-ins), 128PVLANs (private VLANs), 92,

98–99, 98PVSCSI controllers, 257

QQUED metric, 479Quiesce Guest File System (Needs

VMware Tools Installed) option, 214, 382

RRAID (Redundant Array of Inexpensive

Disks) controllers, 4RAM. See memoryraw device mappings (RDMs),

147–148, 255Raw Device Mappings

option, 255%RDY metric, 475–476Read Only role, 232READS/s metric, 479

Ready To Complete screenbackup jobs, 400, 400cold VM migration, 378, 378ESX/ESXi upgrades, 37host remediation, 337, 337restores, 404, 404standard virtual switches, 78, 78Storage VMotion VM

migration, 375vCenter Server, 208VDR appliances, 390, 391virtual machines, 271, 271VM remediation, 341, 341VMFS datastores, 155–156, 155VMotion VM migration, 373

Ready To Complete The Profile screen, 346, 346, 348

Ready To Install The Program screenUMDS, 321, 321vCenter Server, 193VUM, 310, 310, 313, 313

redundancy issues in High Availability, 422, 422, 528–529, 528

Redundant Array of Inexpensive Disks (RAID) controllers, 4

regular user accounts, 28–30, 28–30remediation

hosts, 334–337, 335–337virtual machines, 334–335, 338–341,

338–341remote logons, SSH, 15removing

hosts from clusters, 419port groups, 79–80uplinks, 80

renaming virtual machines, 282Repeat Triggered Alarm Every

setting, 472

572 Repeat Triggered Alarm When Condition Exceeds . . . – Rollback Options screen

Repeat Triggered Alarm When Condition Exceeds This Range setting, 472

Reporting tabconnectivity alarms, 463, 463utilization alarms, 472, 473

reportsbackup jobs, 401, 401connectivity alarms, 463, 463storage, 519–521, 520–521utilization alarms, 472, 473vCenter Server storage, 216–217, 217

Reports tab, 401, 401requirements

clusters, 522–523DRS, 522–523ESX/ESXi servers, 4Fault Tolerance, 438High Availability, 522–523resource pools, 441upgrades, 32vCenter Server, 178–180, 183–186,

184–186VM migration, 365–367VUM, 305–307

Rescan dialog box, 126, 126reservations, 441–443

expandable, 445–446for security, 40setting, 444–445VM memory, 286

Resource Allocation tab, 442–443, 443

resource distribution graphs, 526resource maps, 215–216, 216Resource Pool Administrator

role, 233Resource Pool screen, 269, 269resource pools, 440–441

CPU resource shares, 444–445creating, 443–444, 443–444

evaluating, 441–442, 442exam essentials, 447–448expandable reservations, 445–446hierarchy, 446, 447memory resources, 445requirements, 441review questions, 449–454Storage VMotion VM migration, 374summary, 447virtual machines, 269, 269, 442–443,

443, 446VMotion VM migration, 372, 372

Resource setting for Advanced charts, 482

Resources tab for virtual machines, 284Restart Management Network

option, 18Restart Priority setting, 423Restart To Apply Changes option, 23Restore tab, 403Restore Virtual Machine

wizard, 402restores

host configurations, 31snapshots, 385–386, 385–386tests, 402–404, 402–404

restrictions in Fault Tolerance, 435–436

Retention Policy screen, 400, 400Retry response, 316reverting snapshots, 383rights for vCenter Server

databases, 187roles in vCenter Server, 225

assigning, 236cloning and editing, 235, 235creating, 233–234, 234predefined, 232–233privileges, 230–231, 230–232,

236–237Rollback Options screen, 340, 340

rollbacks – Select a Task to Schedule dialog 573

rollbackshost remediation, 335snapshots, 385VM remediation, 340, 340

root accountsESX/ESXi upgrades, 36, 36limiting use of, 43–44passwords, 12, 13, 17

Round Robin policy, 127routing for hosts, 108–109, 108–109Routing tab, 109, 109%RUN metric, 475, 478Runtime settings for vCenter

Server, 220

SSame Format As Source option, 375SAN storage

boot LUN size, 47ESX/ESXi installation on, 45–47FC. See Fibre Channel (FC) SAN

storageiSCSI. See iSCSI SAN storageLUN masking, 45–46preparing, 46

SAS (Serial-Attached SCSI) controllers, 4SAS (Serial attached storage)

compatibility, 257SATA (Serial Advanced Technology

Attachment) controllers, 4SATP (Storage Array Type Plug-in), 128Save As dialog box for host profiles, 348Scan For Updates option, 330scans

compliance information analysis, 342–343, 353–354, 353–354

hosts and virtual machines, 329–334, 329–333

for LUNs, 126, 126

Schedule screen, 340, 340Schedule Task screen, 214, 214,

332, 332Scheduled Task feature, 212–215,

213–215, 330, 331Scheduled Task Type screen, 330, 331Scheduling Affinity settings, 287SCSI (Small Computer Systems

Interface) controllers and adaptersESX/ESXi servers, 4virtual machines, 250, 255, 255,

257, 257Search feature for events, 218, 219secondary virtual machines, 437Secure Shell (SSH) sessions, 12, 15security, 39

authenticationCHAP, 518–519iSCSI SAN storage, 134, 135–136

default security principles, 39distributed virtual switch policies,

90–92, 91–92Service Console

access, 44–45firewall operation, 42–43, 43strategies, 40–41

user and group accounts, 43–44, 44vCenter Server

inventory objects, 229–231, 230–232

permissions, 224–229, 226–229, 236–237

roles. See roles in vCenter Servervirtual machines, 40virtual networking layer, 41–42, 41virtual switch policies, 74–75, 75, 83,

86–87, 86virtualization layer, 39–40

Security tab, 83, 86, 86Select a Task to Schedule dialog,

213, 213

574 Select Database screen – Snapshot Memory

Select Database screenUMDS, 320VUM, 308

Select Entity screen, 331, 331Select Mail Sender Settings screen,

222, 222Select Users Or Group dialog box,

227, 227Select Virtual Machine screen,

213, 213Send A Notification Email action, 464Send Targets discovery, 134Serial Advanced Technology Attachment

(SATA) controllers, 4Serial-Attached SCSI (SAS)

controllers, 4Serial attached storage (SAS)

compatibility, 257serial ports for virtual machines

connections, 281maximums, 250

server components in VUM, 306–307

servers for FC SAN storageaddressing, 124, 124connections, 122–124, 123

Service configuration subprofile, 349

Service Consoleaccess, 44–45availability, 108backup agents on, 31connectivity, 525, 525firewall operation, 42–43, 42–43IP settings, 107, 107partitions, 6–7, 15ports, 513

heartbeat network redundancy, 422

port groups, 70virtual switches, 68

securityaccess, 44–45firewall operation, 42–43, 43strategies, 40–41

settings, 513–514, 513for troubleshooting, 498versions, 4–5VM backups, 379and VMkernel

dvPorts, 103, 103–104settings, 105–107, 105–106

service levels for VMFS datastores, 148

Setup Type screen, 11, 11Shared Repository setting, 322shares

CIFS, 387, 392CPU, 444–445resource pools, 442VM memory, 286

Show All Datastores reports, 520, 520Show Getting Started Tabs option, 221Show Virtual Machines option, 104Show Virtual Machines In The

Inventory option, 222SHRD metric, 477single host cluster scenario, 503Site Recovery Manager (SRM), 51size

boot LUN, 47vCenter Server databases, 183–186,

184–186VUM databases, 305–306, 306

Small Computer Systems Interface (SCSI) controllers and adapters

ESX/ESXi servers, 4virtual machines, 250, 255, 255,

257, 257Snapshot Manager, 214, 380–383,

381, 385Snapshot Memory, 214

Snapshot The Virtual Machine’s Memory option – subprofiles 575

Snapshot The Virtual Machine’s Memory option, 382

snapshots, 380, 381deleting, 383–385, 384–385restoring, 385–386, 385–386scheduled tasks, 212–215, 213–215taking, 381–383, 381–383VUM policy, 314–315

SNMP setting for vCenter Server, 221soft zoning, 124software initiators

configuring, 132–133, 132–133vs. hardware, 130–131issues, 518–519

source MAC hashes, routes based on, 74Source Selection screen, 403, 403spanning VMFS datastores, 161–166,

161–165spare capacity, 503Specify A Failover Host policy, 527Specify Reference Host screen,

345, 345SPEED metric, 478SRM (Site Recovery Manager), 51SSH (Secure Shell) sessions, 12, 15SSL settings for vCenter Server, 221staging ESX/ESXi host updates, 341standalone licenses, 24–28, 25–26Standard setup type, 11standard virtual switches

creating, 76–79, 76–79deleting, 79, 80

standby modeDPM, 434virtual machines, 284

Start Order tab for vApps, 289, 291, 291

static discovery for iSCSI SAN storage, 134

static IP, 18Static settings for dvPortGroups, 101

statistics in vCenter Server, 184–186, 184–186, 220

Status column in Guided Consolidation, 276

storage, 121connectivity issues, 517contention issues, 515–516exam essentials, 167FC SAN. See Fibre Channel (FC)

SAN storageiSCSI SAN. See iSCSI

SAN storageNFS datastores. See Network File

System (NFS) datastoresovercommitment issues, 516–517,

516–517performance metrics, 479reports and maps, 216–217,

217–218, 519–521, 520–521review questions, 168–173summary, 166–167supported controllers, 4troubleshooting, 514–521,

516–521vCenter Server

requirements, 178–179VMFS datastores. See virtual

machine file system (VMFS) datastores

Storage Adapters link, 132Storage Array Type Plug-in

(SATP), 128Storage configuration

subprofile, 348Storage Views tab, 216, 519–520Storage VMotion, 258, 366–370,

373–375, 373–375subnet masks

installation issues from, 499network adapters, 511

subprofiles, 348–349

576 Summary screen – Time Configuration dialog box

Summary screenESX/ESXi installation, 13, 13inventory object scanning, 333, 333scheduled tasks, 215, 215

Summary tabclusters, 526High Availability, 528, 528network adapters, 511, 511resource pools, 443

Suspend Virtual Machines And Retry response, 316

swap fileslocation, 429–430, 430virtual machines, 263, 283

SWAP metric, 475SWCUR metric, 477switches. See virtual switches

(vSwitches)synchronization, 259–260, 260%SYS metric, 478Sysprep utility, 209, 266, 267System Configuration screen, 18System Logs screen, 501system reconfiguration for virtual

machines, 274–275

TTake Snapshot option, 381Take Virtual Machine Snapshot dialog

box, 382, 382TAR format, 292Target Host Load Standard Deviation

setting, 526Task & Events tab, 460, 461TCP/IP offload engines (TOEs), 131Teaming

dvPortGroups settings, 102NIC


iSCSI software multipathing, 137, 137–138

virtual switches, 73–74, 73, 83–85, 84

templatesvs. clones, 278–279VDR appliances, 388–389, 388virtual machines

creating, 264, 264–265deploying from, 268–272,

268–272Test These Settings button, 10testing

Fault Tolerance, 439high availability, 432restores, 402–404, 402–404

thick disks formatclusters, 253selecting, 280–281storage consumption, 258–259Storage VMotion VM migration, 375VM deployment, 270vSphere, 263

thin disks formatclusters, 253selecting, 280–281storage consumption, 257–259Storage VMotion VM migration, 375VM deployment, 270

third-party high-availability scenarios, 505

third-party MPPs vs. NMPs, 128thresholds

migration, 426–427, 427, 433–434, 433

utilization alarms, 470, 472tiers

Storage VMotion, 369VMFS datastores, 148–149

Time Configuration dialog box, 22, 22, 24, 24

time synchronization – Use This Port For Management Traffic option 577

time synchronization, 259–260, 260Time Zone Settings screen, 12Timeout Settings in vCenter Server, 221TOEs (TCP/IP offload engines), 131topology maps, 526–527, 527Traffic Shaping tab, 83, 86, 86Transient option for vApps, 292triggers

connectivity alarms, 458, 461, 463, 463

utilization alarms, 468–470, 469–470, 472, 472

VMFS volumes, 517Triggers tab

connectivity alarms, 463, 463utilization alarms, 469, 469,

472, 472troubleshooting, 497

clusters, 502–505, 504–506, 522–523DNS settings, 524–525, 525exam essentials, 530exporting diagnostic data, 501–502Fault Tolerance, 506–508guidelines, 498High Availability

capacity issues, 527–528, 527redundancy issues, 528–529, 528

hosts, 497–502, 499installations, 498–499, 499Maintenance mode considerations,

502–503networking, 508–514, 509–514review questions, 531–537Service Console, 525, 525storage, 514–521, 516–521summary, 529–530VMotion, 524, 524, 526–527, 527

trunk ports, 68Turn On Fault Tolerance option, 436two hosts cluster scenario, 503

UUMDS (Update Manager Download

Service), 317, 319unique names in iSCSI

addressing, 140unmounting VMFS datastores, 158–159,

158–159Update Manager Download Service

(UMDS), 317, 319Update Manager Sizing Estimator,

306, 306Update Manager tab, 328–329,

328–329, 342–343Update Types screen, 332, 332updates, VUM. See VMware Update

Manager (VUM)upgrading

ESX/ESXi. See ESX/ESXi serversVMware Tools, 261

uplinksgroup settings, 99removing, 80

Use A Shared Repository option, 318Use All Available Partitions option, 163Use An Existing Supported Database

option, 308Use An Existing Virtual Disk

option, 255Use CHAP security level, 134Use CHAP Unless Prohibited By Target

security level, 134Use Explicit Failover Order option, 74Use Free Space option, 163Use Free Space To Add New Extent

option, 163Use Free Space To Expand Existing

Extent option, 163Use This Port For Management Traffic

option, 111

578 Use This Port Group For VMotion option – vCenter Server

Use This Port Group For VMotion option, 87

Use This Virtual Adapter For Management Traffic option, 529

%Used metric, 478user interface for FC SAN storage, 122usernames in VUM, 307–309, 309users and user accounts

creating, 28–30, 28–30ESX Server permissions, 229, 229setting up, 43–44, 44vCenter Server, 225

assignments, 236permissions, 224–229, 226–229,

236–237Users & Groups tab, 28, 28Users And Groups tab, 44utilization alarms

actions, 468analyzing and evaluating, 468–470,

469–470creating, 470–473, 471–473default, 467–468relating to resources, 473–474

UUIDs for virtual machine datastores, 261

VVA Upgrade To Latest baseline, 323VA Upgrade To Latest Critical

baseline, 323vApps. See virtual appliances (VApps)/var/logExt3 mount point, 7VCB (VMware Consolidated Backup)

tool, 31–32, 379vCenter

alarms. See alarmsinventory object baselines, 328–329,

328–329

vCenter Collector service, 275vCenter Converter, 272–273, 275vCenter Converter Agent, 273vCenter Converter Boot CD, 273vCenter Converter CLI, 273vCenter Converter Client, 273vCenter Converter Server, 273vCenter Guided Consolidation module.

See Guided ConsolidationvCenter Provider service, 275vCenter Server, 88

access control, 224–237inventory objects, 229–231,

230–232permissions, 224–229, 226–229,

236–237roles. See roles in vCenter Server

availability, 180–182clones, 181, 235, 235configuration, 200–201

maximums, 179–180, 201–204settings, 220–221, 222

databasespreparing, 186–187settings, 190–191, 190–191, 221size requirements, 183–186,

184–186datacenters and folders, 210–212,

211–212editions, 183events, 217–219, 218–220exam essentials, 238guest OS customization, 209, 210hardware requirements, 178–179heartbeats, 180–181installing, 177–178, 187–193,

188–192joining ESX/ESXi hosts to, 206–208,

206–208Linked Mode groups, 195–198

vCenter Server Information screen – Virtual Machine Power User role 579

mapsresource, 215–216, 216storage, 216–217, 217–218,

519–521, 520–521Microsoft clusters, 181module installation, 193–195reports, 216–217, 217–218review questions, 239–245scheduled tasks, 212–215, 213–215summary, 237–238VM maximums, 205vSphere Client

plug-ins, 198–200, 199–200settings, 221–222, 222–224

vCenter Server Information screen, 308, 308

vCenter Server Linked Mode Options screen, 192, 192

vCenter Server Service screen, 191, 191vCenter Update Manager. See VMware

Update Manager (VUM)VDR. See VMware Data Recovery

(VDR) appliancesversions

ESX/ESXi servers, 4–5virtual machine hardware, 254

VGT (Virtual Guest Tagging), 78VIBs (vSphere installation bundles), 334vicfg-cfgbackup command, 31virtual appliances (VApps), 287

baselines, 323building, 288–290, 290cloning, 292, 293evaluating, 287–288exporting, 288, 292importing, 288Open VM Format, 288properties, 291–292, 291–292remediation, 338

VDR. See VMware Data Recovery (VDR) appliances

virtual machines for, 289Virtual Center upgrading, 34virtual disks (VMDKs), 6, 256

adding to VDR appliances, 392–394, 392–394

block sizes, 148files, 263growing, 280, 280Service Console, 11Storage VMotion VM

migration, 374thin provisioning, 253types, 257–259, 258, 280–281

Virtual Guest Tagging (VGT), 78virtual local area networks (VLANs), 10

distributed virtual switches, 92dvPortGroups, 102PVLANs, 92, 98–99, 98virtual switches, 68, 86–87, 86

Virtual Machine CPU Usage alarm, 467, 470

virtual machine file system (VMFS) datastores, 121, 147

attaching to new ESX hosts, 155–156creating and configuring, 150–155,

151–155deleting, 160–161, 160–161Fault Tolerance failures from, 507file system attributes, 147–148grouping, 156–157, 156–157growing, 161–166, 161–165location, 148–149unmounting, 158–159, 158–159volumes, 149–150, 516–517, 516

Virtual Machine Memory Usage alarm, 467, 470

virtual machine monitor (VMM), 122Virtual Machine Power User role, 233

580 Virtual Machine User role – virtual ports for iSCSI SAN storage

Virtual Machine User role, 233virtual machines (VMs), 40, 121, 249

advanced options, 282–283, 283alarm actions, 459backups. See backups for virtual

machinesbaselines, 324BIOS state file, 263cloning, 277

cold, 274, 275hot, 273, 274, 277modes, 273vs. templates, 278–279

in clusters, 417, 418CPU settings, 284–287, 285creating, 251–256, 251–256customization specifications,

267, 267deploying

from Enterprise Converter, 272–273

using Guided Consolidation, 275–277

from templates, 268–272, 268–272device connections, 281disks. See disks and disk drives for

virtual machinesexam essentials, 294Fault Tolerance, 438–439files, 261–263general options, 281–282, 282hardware

adding, 280maximums, 250

importing, 279, 279log files, 263maps, 216, 217memory settings, 286migrating. See migrating virtual

machinesperformance. See performance

port groups, 68power management options,

283–284, 283remediation, 334–335, 338–341,

338–341renaming, 282resource pools, 269, 269, 442–443,

443, 446review questions, 295–301scanning, 329–334, 329–333SCSI adapters, 257, 257summary, 293system reconfiguration, 274–275templates

creating, 264, 264–265deploying from, 268–272,

268–272vApps, 287–292, 290–293vCenter Server, 209

installation on, 187maximums, 205

virtual disksgrowing, 280, 280types, 257–259, 258

VMware Tools, 259–261, 260, 284, 285

Windows and Linux, 265–266, 265–266

Virtual Machines screen, 399, 399

virtual network interface cards (vNICs), 70, 281

settings, 511, 511virtual switches, 69

virtual networking layer, 41–42, 41virtual port groups

NIC Teaming and failover policy, 89–90, 90

security policies, 90–92, 91–92virtual ports for iSCSI SAN

storage, 129

virtual switches (vSwitches) – VMotion 581

virtual switches (vSwitches), 67–68alarm actions, 460configuration maximums, 72–73distributed. See distributed virtual

switches (dvSwitches)load balancing, 84network adapters, 68–70, 512vs. physical, 70–71, 71physical adapter assignments, 81–83,

81–83policies

failover, 83–85, 84security settings, 74–75, 75, 86–87,

86ports and port groups, 509–510,

509–510creating, 81, 81maximums, 68–70removing, 79–80, 80

standardcreating, 76–79, 76–79deleting, 79, 80

uplinks, 80VMotion, 87–88, 87

virtual-to-physical server cluster scenario, 503–504, 506

virtualization layers, 39–40, 122Vlance NICs, 69, 436VLANs (virtual local area networks), 10

distributed virtual switches, 92dvPortGroups, 102PVLANs, 92, 98–99, 98virtual switches, 68, 86–87, 86

VM configuration (VMX) file, 262VM disk (VMDK) files, 253, 256, 263VM Hardware Upgrade To Match Host

baseline, 323VM Memory Control Driver

(vmmemctl), 259VM Memory performance object, 485VM Monitoring, 424–425, 425

VM Processor performance object, 485vm-support script, 502vMA (VMware Management

Appliance), 31vMA (vSphere Management Assistant),

4, 125.vmdk extension, 262VMDKs. See virtual disks (VMDKs)VMFS. See virtual machine file system

(VMFS) datastoresVMkernel, 39–40

FC SAN storage, 122partitions, 6port groups, 70ports and port settings, 68

binding, 136–139, 137–139creating, 87, 87dvPorts, 103, 103–104editing, 105–107, 106verifying, 513–514, 513–514virtual switches, 68

swap files, 430VMkernel Connection Settings screen,

111, 111VMkernel swap file (VSWP), 263,

429–430vmkload_mod command, 515VMKMEM metric, 477vmkping command, 529VMM (virtual machine monitor), 122vmmemctl process, 259VMotion

configuring, 87–88, 87DRS, 426EVC, 365, 428–429, 523Fault Tolerance failures from, 507requirements, 522–523troubleshooting, 524, 524,

526–527, 527VM maps for, 216, 217VM migration, 365–373, 371–373

582 VMs – VMware Workstation 6/7

VMs. See virtual machines (VMs)VMware

clusters. See clustershigh availability, 180–182platform products and

editions, 47–50vCenter Server. See vCenter Server

VMware Consolidated Backup (VCB) tool, 31–32, 379

VMware Consolidated Backup User role, 233

VMware Converter, 48VMware Data Recovery (VDR)

appliances, 379, 387adding virtual disks to, 392–394,

392–394backup jobs, 397–401, 398–401disk formatting, 396installing, 387–391, 387–391plug-in, 395–396, 395–396restore tests, 402–404, 402–404

VMware Enterprise Converter, 34VMware Fusion, 48–49VMware HA screen, 424, 424VMware Management Appliance

(vMA), 31VMware Paravirtual SCSI adapters, 257VMware Player, 49–50VMware Profile Format (VPF) files, 347VMware Server, 49VMware Tools, 259–260, 260

installing, 260upgrading, 261virtual machine options, 284, 285

VMware Tools Options screen, 284, 285VMware Tools Upgrade To Match Host

baseline, 323vmware-umds command, 320, 322VMware Update Manager (VUM), 34,

108, 304baselines

attaching to inventory objects, 328–329, 328–329

creating, 323–327, 323–327compliance information analysis,

342–343configuring, 314databases

settings, 308–309, 309sizing, 305–306

description, 193ESX server retry policy, 315–316exam essentials, 355host updates, 341installation, 194

client plug-in, 312–313, 312–313process, 307–311, 307–311requirements, 305–307

patchesdownload options, 316–319,

317–318exporting and importing, 322

remediationhosts, 334–337, 335–337virtual machines, 334–335,

338–341, 338–341review questions, 356–362scanning inventory objects, 329–334,

329–333sizing calculator, 306snapshot policy, 314–315summary, 355UMDS for, 319–321, 319–321

vmware-updateDownloadCli.exe utility, 319

VMware vCenter Lab Manager, 51–52VMware vCenter Update Manager

Extension, 312VMware vCenter Update Manager Port

Settings screen, 310, 310VMware View, 50–51VMware Workstation 6/7, 48

VMwareDataRecoveryPlugin .msi file – zoning in FC SAN storage 583

VMwareDataRecoveryPlugin.msi file, 395–396, 395–396

VMwareVCMSDS service, 196VMX (VM configuration) file, 262.vmx extension, 262VMXNET adapters, 69VMXNET 2 adapters, 69VMXNET 3 adapters, 69VMXNET device drivers, 70vNetwork distributed switches. See

distributed virtual switches (dvSwitches)

vNetwork standard switches. See virtual switches (vSwitches)

vNICs (virtual network interface cards), 70, 281

settings, 511, 511virtual switches, 69

volume-based cloning, 273volumes in VMFS, 149–150VPF (VMware Profile Format) files, 347vSphere architecture, 47

bare-metal vs. hosted, 53–55, 54datacenter solutions, 50–52ESX/ESX architecture, 52–53network management settings,

512–514, 513–514platform products and

editions, 47–50vSphere Client

exporting diagnostic data, 501installing, 19–20, 19plug-ins, 198

enabling, 200, 200identifying, 198, 199permissions, 200requirements, 199, 199

settings, 221–222, 222–224upgrades, 30

vSphere Host Update Utility, 20, 34–39, 35–38

vSphere installation bundles (VIBs), 334

vSphere Management Assistant (vMA), 4, 125

vswif0 port, 529vSwitch Properties dialog box,

110–111, 110vSwitches. See virtual switches

(vSwitches)VSWP (VMkernel swap file),

263, 429–430.vswp extension, 262VUM. See VMware Update

Manager (VUM)

WWake On LAN For VM Traffic

On Your VM Network option, 284

Wake On LAN Supported information, 512

Warning events, 217Windows virtual machines, 265–266,

265–266wmkping command, 518World Wide Names (WWNs),

45, 124World Wide Port Numbers (WWPNs),

123, 123WRITES/s metric, 479

Zzoning in FC SAN storage, 124

READ THIS. You should carefully read these terms and conditions before opening the software packet(s) included with this book “Book”. This is a license agreement “Agree-ment” between you and Wiley Publishing, Inc. “WPI”. By opening the accompanying software packet(s), you acknowledge that you have read and accept the following terms and conditions. If you do not agree and do not want to be bound by such terms and conditions, promptly return the Book and the unopened software packet(s) to the place you obtained them for a full refund.1. License Grant. WPI grants to you (either an individual or entity) a nonexclusive license to use one copy of the enclosed software program(s) (collectively, the “Software,” solely for your own personal or business purposes on a single computer (whether a standard computer or a work-station component of a multi-user network). The Software is in use on a computer when it is loaded into temporary memory (RAM) or installed into permanent memory (hard disk, CD-ROM, or other storage device). WPI reserves all rights not expressly granted herein.2. Ownership. WPI is the owner of all right, title, and inter-est, including copyright, in and to the compilation of the Software recorded on the physical packet included with this Book “Software Media”. Copyright to the individual programs recorded on the Software Media is owned by the author or other authorized copyright owner of each pro-gram. Ownership of the Software and all proprietary rights relating thereto remain with WPI and its licensers.3. Restrictions On Use and Transfer.(a) You may only (i) make one copy of the Software for backup or archival purposes, or (ii) transfer the Software to a single hard disk, provided that you keep the original for backup or archival purposes. You may not (i) rent or lease the Software, (ii) copy or reproduce the Software through a LAN or other network system or through any computer subscriber system or bulletin-board system, or (iii) modify, adapt, or create derivative works based on the Software.(b) You may not reverse engineer, decompile, or disas-semble the Software. You may transfer the Software and user documentation on a permanent basis, provided that the transferee agrees to accept the terms and conditions of this Agreement and you retain no copies. If the Software is an update or has been updated, any transfer must include the most recent update and all prior versions.4. Restrictions on Use of Individual Programs. You must follow the individual requirements and restrictions detailed for each individual program in the About the CD-ROM appendix of this Book or on the Software Media. These limitations are also contained in the individual license agreements recorded on the Software Media. These limi-tations may include a requirement that after using the program for a specified period of time, the user must pay a registration fee or discontinue use. By opening the Software packet(s), you will be agreeing to abide by the licenses and restrictions for these individual programs that are detailed in the About the CD-ROM appendix and/or on the Soft-ware Media. None of the material on this Software Media or listed in this Book may ever be redistributed, in original or modified form, for commercial purposes.5. Limited Warranty.(a) WPI warrants that the Software and Software Media are free from defects in materials and workmanship under normal use for a period of sixty (60) days from the date of purchase of this Book. If WPI receives notification within

the warranty period of defects in materials or workman-ship, WPI will replace the defective Software Media.(b) WPI AND THE AUTHOR(S) OF THE BOOK DIS-CLAIM ALL OTHER WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THE SOFTWARE, THE PROGRAMS, THE SOURCE CODE CONTAINED THEREIN, AND/OR THE TECHNIQUES DESCRIBED IN THIS BOOK. WPI DOES NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE SOFTWARE WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE SOFTWARE WILL BE ERROR FREE.(c) This limited warranty gives you specific legal rights, and you may have other rights that vary from jurisdiction to jurisdiction.6. Remedies. (a) WPI’s entire liability and your exclusive remedy for defects in materials and workmanship shall be limited to replacement of the Software Media, which may be returned to WPI with a copy of your receipt at the following address: Software Media Fulfillment Department, Attn.: VCP: VMware Certified Professional on vSphere 4 Study Guide, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapo-lis, IN 46256, or call 1-800-762-2974. Please allow four to six weeks for delivery. This Limited Warranty is void if failure of the Software Media has resulted from accident, abuse, or misapplication. Any replacement Software Media will be warranted for the remainder of the original war-ranty period or thirty (30) days, whichever is longer.(b) In no event shall WPI or the author be liable for any damages whatsoever (including without limitation dam-ages for loss of business profits, business interruption, loss of business information, or any other pecuniary loss) arising from the use of or inability to use the Book or the Software, even if WPI has been advised of the possibility of such damages.(c) Because some jurisdictions do not allow the exclusion or limitation of liability for consequential or incidental damages, the above limitation or exclusion may not apply to you.7. U.S. Government Restricted Rights. Use, duplication, or disclosure of the Software for or on behalf of the United States of America, its agencies and/or instrumentalities “U.S. Government” is subject to restrictions as stated in paragraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause of DFARS 252.227-7013, or subparagraphs (c) (1) and (2) of the Commercial Computer Software - Restricted Rights clause at FAR 52.227-19, and in similar clauses in the NASA FAR supplement, as applicable.8. General. This Agreement constitutes the entire under-standing of the parties and revokes and supersedes all prior agreements, oral or written, between them and may not be modified or amended except in a writing signed by both parties hereto that specifically refers to this Agreement. This Agreement shall take precedence over any other docu-ments that may be in conflict herewith. If any one or more provisions contained in this Agreement are held by any court or tribunal to be invalid, illegal, or otherwise unen-forceable, each and every other provision shall remain in full force and effect.

Wiley Publishing, Inc. End-User License Agreement

he Best VCP4 Book/CD Package on the Market!T

Get ready for your VCP4 certification with the most comprehensive and challenging sample tests anywhere!

The Sybex Test Engine features:

All the review questions, as covered in each Nchapter of the book

Challenging questions representative of Nthose you’ll find on the real exam

Two full-length bonus exams available only Non the CD

An assessment test to narrow your focus to Ncertain objective groups

Use the Electronic Flashcards to jog your memory and prep last-minute for the exam!

Reinforce your understanding of Nkey concepts with these hardcore flashcard-style questions .

Now you can study for the VCP4 exam N(VCP-410) anytime, anywhere .

Search through the complete book in PDF!

Access the entire N VCP: VMware Certified Professional on vSphere 4 Study Guide complete with figures and tables, in electronic format .

Search the N VCP: VMware Certified Professional on vSphere 4 Study Guide chapters to find information on any topic in seconds .

Find answers to your VMware vSphere 4 questions quickly and easily with this perfect companion to Mastering VMware vSphere 4.

Answers at Your FingertipsAnswers at Your Fingertips

978-0-470-52072-7

978-0-470-53050-4 978-0-470-52539-5 978-0-470-49660-2

Available at www.sybex.com or wherever books are sold.

Also Available in the Instant Reference Series

47471_SybexBOB.indd 1 7/24/09 12:57:23 PM

http://www.sybex.com

VCP: VMware Certified Professional on vSphere 4 Study GuideExam VCP-410 Objectives

OBjECTIVE ChAPTER

Section 1 – Plan, Install And Upgrade Vmware Esx/Esxi

Objective 1 .1 – Install VMware ESX/ESXi on local storage 1

Objective 1 .2 – Upgrade VMware ESX/ESXi 1

Objective 1 .3 – Secure VMware ESX/ESXi 1

Objective 1 .4 – Install VMware ESX/ESXi on SAN Storage 1

Objective 1 .5 – Identify vSphere Architecture and Solutions 1

Section 2 – Configure ESX/ESXi Networking

Objective 2 .1 – Configure Virtual Switches 2

Objective 2 .2 – Configure vNetwork Distributed Switches 2

Objective 2 .3 – Configure VMware ESX/ESXi Management Network 2

Section 3 – Configure ESX/ESXi Storage

Objective 3 .1 – Configure FC SAN Storage 3

Objective 3 .2 – Configure iSCSI SAN Storage 3

Objective 3 .3 – Configure NFS Datastores 3

Objective 3 .4 – Configure and Manage VMFS Datastores 3

Section 4 – Install and Configure vCenter Server

Objective 4 .1 – Install vCenter Server 4

Objective 4 .2 – Manage vSphere Client plug-ins 4

Objective 4 .3 – Configure vCenter Server 4

Objective 4 .4 – Configure Access Control 4

Section 5 – Deploy and Manage Virtual Machines and vApps

Objective 5 .1 – Create and Deploy Virtual Machines 5

Objective 5 .2 – Manage Virtual Machines 5

Objective 5 .3 – Deploy vApps 5

Exam objectives are subject to change at any time without prior notice and at VMware’s sole discretion . Please visit VMware’s website (www.vmware.com/education) for the most current listing of exam objectives .

OBjECTIVE ChAPTER

Section 6 – Manage Compliance

Objective 6 .1 – Install, Confi gure and Manage VMware vCenter Update Manager 6

Objective 6 .2 – Establish and Apply ESX Host Profi les 6

Section 7 – Establish Service levels

Objective 7 .1 – Create and Confi gure VMware Clusters 8

Objective 7 .2 – Enable a Fault Tolerant Virtual Machine 8

Objective 7 .3 – Create and Confi gure Resource Pools 8

Objective 7 .4 – Migrate Virtual Machines 7

Objective 7 .5 – Backup and Restore Virtual Machines 7

Section 8 – Perform Basic Troubleshooting and Alarm Management

Objective 8 .1 – Perform Basic Troubleshooting for ESX/ESXi Hosts 10

Objective 8 .2 – Perform Basic Troubleshooting for VMware FT and Third-Party Clusters 10

Objective 8 .3 – Perform Basic Troubleshooting for Networking 10

Objective 8 .4 – Perform Basic Troubleshooting for Storage 10

Objective 8 .5 – Perform Basic Troubleshooting for HA/DRS and VMotion 10

Objective 8 .6 – Create and Respond to vCenter Connectivity Alarms 9

Objective 8 .7 – Create and Respond to vCenter Utilization Alarms 9

Objective 8 .8 – Monitor vSphere ESX/ESXi and Virtual Machine Performance 9

