Chapter 5 Upgrading a vSphere Deployment

2V0-21.19 EXAM OBJECTIVES COVERED IN THIS CHAPTER:

• Section 1 - VMware vSphere Architectures and Technologies

  • Objective 1.1 - Identify the pre-requisites and components for vSphere implementation

• Section 4 - Installing, Configuring, and Setting Up a VMware vSphere Solution

  • Objective 4.6 - Deploy and configure VMware vCenter Server Appliance (VCSA)

• Section 5 - Performance-tuning and Optimizing a VMware vSphere Solution

  • Objective 5.2 - Monitor resources of VCSA in a vSphere environment

• Section 7 - Administrative and Operational Tasks in a VMware vSphere Solution

  • Objective 7.15 - Utilize VMware vSphere Update Manager (VUM)

Keeping your vSphere environment up-to-date is important in order to have the latest features and improvements that typically provide improved performance and stability. It is also important to ensure compatibility with new industry changes such as hardware and operating systems. VMware has a prescriptive “top down” upgrade path for its products that has not changed much over the years.

Following a carefully planned upgrade strategy will ensure consistency and reliability during the transition. It will also allow you to recover smoothly from issues encountered during the upgrade process. Key components of the upgrade path will be backing up your current environment, checking the compatibility guides, and deciding if your deployment topology will need to change.

An additional consideration will be whether to move a Windows-based vCenter to the vCenter Server Appliance (VCSA). VMware vSphere 6.5 does not have a Windows requirement for any of its components, and VMware suggests you migrate to the appliance. However, the Windows-based vCenter is still supported for 6.5.

VMware provides tools such as vSphere Update Manager (VUM) to automate some of the processes and help you implement a reliable upgrade path. Following the steps outlined by VMware will ensure that you have a consistent and safe upgrade.

Upgrading from vSphere 5.5

This section will list the specific issues with upgrading from vCenter 5.5 to vCenter 6.5.

There are several considerations to address depending on your topology.

• If you have a simple vSphere 5.5 installation with all v5.5 components, then the upgrade is straightforward.

• However, if you have deployed your 5.5 environment in a fully distributed deployment, you will need to manage those separate components because they are decentralized during the upgrade.

• Also, if you are using a now-deprecated topology, such as linked, embedded Single Sign-On (SSO), you will need to move to a supported topology before the upgrade. See KB Article 2147672 for supported and unsupported topologies.

With vSphere 5.5, there were multiple components that could be installed either on the vCenter server or on separate servers. With vSphere 6.x, only the Platform Services Controller (what the Single Sign-On server evolved into for version 6) can be installed separately from vCenter. For the other distributed services, the upgrade process will migrate the responsibilities, configuration, and possibly the data from the distributed services to the new vCenter 6.5 server as described in the following list:

• vCenter Inventory Service Data from the service will be copied to the vCenter Content Library.

• vSphere Web Client Any data will be copied to the vSphere web client on vCenter 6.5.

• vSphere Auto Deploy Data will be copied to the new vCenter 6.5 service. The old service will not be shut down. You will need to change your DHCP options to point to the new vCenter server.

• vSphere Syslog Collector The configuration is retained but not the data. You will need to repoint your hosts to the new vCenter server.

• vSphere ESXi Dump Collector No data is kept. You will need to repoint hosts to the new vCenter server.

• vSphere Update Manager Configuration and data will be copied to the new vCenter 6.5 server. Make sure you run the migration assistant on the host running VUM before you start the migration.

Regardless of how many different servers were used to distribute the 5.5 services, the end result will be one 6.5 vCenter server for each v5.5 vCenter server. You will also have one 6.5 Platform Services Controller for each v5.5 Single Sign-On service, which will be either stand-alone or embedded with vCenter depending on how your v5.5 environment was deployed. See Figure 5.1 for the upgrade diagram of a basic vCenter installation with an embedded Single Sign-On service.

If you used an external Single Sign-On server for vCenter 5.5, the upgraded environment will have an external Platform Services Controller (PSC) as shown in Figure 5.2. Note that in this diagram the Auto Deploy server was also deployed on the SSO server; however, with 6.5 the Auto Deploy service is only available on a vCenter server. Only the Platform Services Controller can be installed on a separate instance.

If you have a fully distributed vCenter 5.5 instance, where every possible service was deployed on its own server, the end state will still be one PSC and one vCenter server, with all of the services installed on the vCenter server as shown in Figure 5.3.

If you are currently using an unsupported topology, or one that would be unsupported in vSphere 6.5 such as linked embedded SSO services, VMware suggests you migrate to a supported topology as shown in Figure 5.4 before starting the 6.5 upgrade. See VMware Knowledge Base article 2130433 for more information.

Before the vCenter 6.5 migration can start, you need to make sure all components are at least version 5.5. This includes any ESXi hosts, vCenter servers, and SSO servers in the environment. Since vCenter 6.5 cannot be used with ESXi hosts before version 5.5, any that are version 5.0 or 5.1 will need to be upgraded or decommissioned. This may add an interim step to the 6.5 migration, similar to what is shown in Figure 5.4.

Before migrating a vCenter 5.5 database, there are cleanup scripts you can run to prepare the database. There is a separate script for MS SQL databases and Oracle databases: cleanup_orphaned_data_MSSQL.sql and cleanup_orphaned_data_Oracle.sql. These cleanup scripts will remove any unnecessary data from your vCenter server database. The appropriate script should be run after backing up your database. Backing up the database before any changes are made will ensure that your environment can be completely recovered.

If your topology includes a distributed linked mode environment, the distributed linked mode will not work during the transition period when both vCenter 5.5 and vCenter 6.5 servers are in use. However, the upgraded vSphere 6.5 client will show the 6.5 and 5.5 vCenter servers during the transition. The vSphere 5.5 web client will not show the 6.5 servers.

After your migration has completed and you have verified that the upgraded environment is working properly, make sure you decommission any services that were consolidated to the vCenter server.

Upgrading a vCenter Server on Windows

There are essentially two options for upgrading a Windows-based vCenter server from either 5.5 or 6.0: GUI or command line (CLI). This is because changing the topology during an upgrade is not supported (refer to the preceding section) and there are no options for a distributed installation. You can migrate a Windows-based vCenter server to a vCenter Server Appliance (VCSA); that will be covered in the section “Migrating to the vCenter Server Appliance.”

Before upgrading your environment, there are several tasks that should be addressed. In the vSphere 6.5 Upgrade documentation, VMware has broken these out as follows:

1. Verify basic compatibility.

2. Download the vCenter Server Installer.

3. Prepare a vCenter Server database for upgrade

4. Prepare for upgrading the Content Library.

5. Verify network prerequisites.

6. Verify load balancer

7. Prepare ESXi hosts.

8. Verify that preparations are complete.

Verify Basic Compatibility and Download the Installer

As mentioned in the previous section, upgrading from a deprecated topology is not supported. Make sure your topology and all of the components are supported with 6.5 before you start the upgrade process. You should also verify that all of your components are compatible with vSphere 6.5 on the VMware Compatibility Guide at www.vmware.com/resources/compatibility. In case you have multiple VMware components in your environment, VMware has a prescribed upgrade path available in Knowledge Base article 2147289. If you have any of these components in your environment, this is the order in which VMware suggests they be upgraded. (Note that most of the topics listed here are outside the scope of this book/the exam.)

1. vRealize Automation

2. vRealize Orchestrator, vRealize Business

3. vRealize Operations, vRealize Log Insight

4. vRealize Log Insight Agent, vRealize Operations Manager EndPoint Operations Agent

5. vStorage APIs for Data Protection-based backup solution

6. NSX for vSphere

7. External PSC/SSO

8. vCenter Server

9. vSphere Update Manager

10. vSphere Replication, SRM

11. VMware Update Manager Download Service

12. ESXi

13. VMware Tools

14. Virtual hardware

15. vSAN, VMFS

Once your environment and topology are known to be compatible with vSphere 6.5, you can continue preparing for the vCenter upgrade. The second step in the VMware list is to download the binaries for vCenter 6.5. You will need to have a current support license for vSphere in order to download the files.

Prepare the Database for Upgrade

Before any changes to the environment are made, you should back up the database by either using a database backup tool or making a backup of the entire virtual machine. See VMware Knowledge Base article 2091961 for steps on backing up the PostgreSQL database. You can also make a backup of the vCenter SSL certificates by copying the C:UsersAll UsersVMwareVMware VirtualCenterSSL directory to a safe location.

Once an upgrade is completed, you cannot revert to an earlier version; you must instead restore the earlier state. The simplest backup method would be to make a clone of the VM(s) related to the upgrade. The vCenter 6.5 installer will require you to check a box stating that you have backed up the environment prior to starting the upgrade, as shown in Figure 5.5.

With vCenter version 6.5, the embedded database used is PostgreSQL. If you are currently using the embedded Microsoft SQL Express database installed with earlier versions, it will be replaced with PostgreSQL during the upgrade. If you do not want to use PostgreSQL, you can migrate your SQL Express database to a full SQL database (see Knowledge Base article 1028601) or change your embedded SQL Express so it will not be converted to PostgreSQL (see Knowledge Base article 2109321).

If you are using an external database (either Microsoft SQL or Oracle), make sure the version is compatible with vSphere 6.5. If the database is not compatible, it will need to be upgraded before vCenter is upgraded. With either external database, you should verify that the correct permissions are assigned. See the section “Database Permission Requirements for vCenter Server” in the vCenter Server Upgrade guide. For Oracle, also verify the Oracle instance using the SERVICE_NAME and check that the CLASSPATH variable includes the JDBC driver. If you are using an external SQL database, make sure JDK 1.6 or later is installed, the CLASSPATH variable includes sqljdbc4.jar, and you are using Microsoft SQL Server Native Client 10 or 11.

Prepare for Upgrading the Content Library

If you are using the vSphere Content Library, there are a few things to check before the upgrade. You must be using Remote File Systems or Datastores for the libraries. If you have any libraries using the local disks of a vCenter, they need to be migrated to Remote File Systems or Datastores. You also need to make sure all libraries are accessible during the upgrade and no subscribed libraries are using a file-based URI.

Verify Network Prerequisites, Load Balancer, and ESXI Hosts

The VMware upgrade document lists several steps for testing network settings before the upgrade. You should check that the fully qualified domain names (FQDNs) of your vSphere components resolve to the IP address configured for each component and the IP addresses of your vCenters and SSO servers (if used) will return the correct FQDN when queried. If you use DHCP, make sure the DNS records are updated if the IP addresses change. Also, make sure each component has the correct DNS servers entered. If you are using Active Directory (AD), make sure it is configured properly and that all components use the same time source as the Active Directory servers.

The VMware upgrade guide provides a list of services that must be running before an upgrade is started:

• The vCenter Single Sign-On instance to which you are registering vCenter Server

• VMware Certificate Authority

• VMware Directory Service

• VMware Identity Manager Service

• VMware KDC Service

• tcruntime-C-ProgramData-VMware-cis-runtime-VMwareSTSService

The list of tasks provided in the vCenter Server Upgrade guide includes checking the load balancer and ESXi hosts, but the steps you are expected to take have already been covered by verifying that “all components” and the topology are compatible with vSphere 6.5. Those compatibility checks should include verifying that the load balancer and its topology are compatible and that all ESXi hosts are at least version 5.5.

Starting the vCenter on Windows Upgrade

Once the compatibility checks and prerequisite steps are done and the environment is backed up, you can proceed with upgrading the environment. Assuming you have already updated any other products mentioned in Figure 5.5, your first step will be to upgrade your Single Sign-On servers. If you are using a simple installation with embedded SSO, then there will be only one wizard to run through that will update the embedded SSO to an embedded PSC and upgrade vCenter at the same time.

To start the upgrade, launch autorun.exe from the ISO image (either extracted or mounted on your Windows desktop). The wizard will identify upgrading an external PSC compared to upgrading an embedded 6.0 PSC (Figure 5.6) or an embedded 5.5 SSO service (Figure 5.7).

You will need to make sure you are executing the upgrade in the correct order, upgrading the SSO or PSC first (if separate) and then vCenter followed by hosts and virtual machines. During the vCenter migration, you will be prompted to migrate data from the old installation (Figure 5.8). You will not see this option if you are upgrading an external SSO or PSC.

This allows you to choose how much old data to bring forward from the previous version, and you are given size estimates for the data. While we would suggest bringing over all of the data, this is a very useful option if you are doing a test migration.

If the migration fails at a later step, you will need to clean up the export directory, which is defined on the screen after you set the upgrade options as shown in Figure 5.9.

If you do not clean up the export directory between upgrade attempts, you will get the error shown in Figure 5.10.

After the migration is complete, you can delete the export directory, which by default is C:ProgramDataVMwarevCenterServerexport. Make sure the new topology is working correctly before you move on to upgrading ESXi hosts (which we'll do in the the section “Upgrading ESXi Hosts and Virtual Machines” later in this chapter); reverting to the previous version will be much more difficult if you have to restore hosts as well as the vCenter topology.

Migrating to the vCenter Server Appliance

The vCenter Server Appliance is the preferred deployment for a Platform Services Controller and vCenter Server. It doesn't require a Windows Server license and is very simple to deploy and maintain compared to having to maintain the Windows OS in addition to vCenter. If you decide to migrate from a Windows-based vCenter to the vCenter Server Appliance during your migration to vSphere 6.5, there are a few considerations to address.

You cannot change topologies during the migration, and you should not migrate a deprecated topology. You should make sure your environment and topology are compatible with vCenter 6.5 before starting the migration. Check the VMware Compatibility Guide at www.vmware.com/resources/compatibility to make sure your environment is fully compatible with VCSA 6.5

Migrating to the VCSA from Windows has an easier revert path than a Windows or VCSA upgrade because the source is untouched and simply shut down at the end of the migration. Reverting to the previous version is a matter of powering off the new appliance and powering on the Windows VM.

There are two methods of upgrading to VCSA 6.5: you can use a GUI or command-line tool. Either one requires a PC that can access the existing vCenter server and the management IP of the host ESXi server that the appliance will be deployed on. The host ESXi will also need access to the network on which the current vCenter server is running.

You will also need to launch the migration-assistant utility on the existing vCenter server before the migration or migration prechecks start. You can find the migration-assistant in the migrationassistant directory on the VCSA 6.5 install .ISO you download from VMware.

Upgrading Using the Command Line

Using the command-line version requires some prework to create the required JSON template file. You can find sample files in the installation media at vcsa-cli-installer/templates/migrate to migrate from 5.5 or 6.0 with embedded or external databases and stand-alone or embedded SSO/PSCs. For authentication, there is an Active Directory section in the JSON templates, or you can use the migration.ssl.thumbprint key in the JSON, which uses the key provided by the migration-assistant utility on the vCenter server.

After the file is created, you can verify it by using the --verifytemplate-only parameter. If a problem is found in the JSON file, you will need to resolve the issue before the verification will complete. If the JSON file is OK, it will start a limited version of the prechecks and prompt you to run the full version of the prechecks.

You can initiate the precheck sequence using the --pre-check-only parameter and the JSON file. Additional tests include space required and the ovftool.

Once the checks have completed successfully, you can initiate the migration using the vcsa-deploy command in the migrate mode with the JSON file. You will also need the --acknowledge-ceip and --accepteula parameters.

You will need to execute the CLI from a server other than the existing vCenter server since the vCenter server will be shut down during the migration process.

Upgrading Using the Graphical Interface

The GUI version of the migration can be found on the VCSA ISO downloaded from VMware in the vcsa-ui-installer directory. As with the command-line version, there are 32-bit Windows, 64-bit Linux, and Mac versions of the GUI installer. Upon launching the installer utility, click Migrate to start the migration process.

The GUI version detects the vCenter version and type (SSO/PSC-only or SSO/PSC embedded), as shown in Figure 5.11 and Figure 5.12.

The CLI and GUI migration paths can migrate an external SSO server to a version 6.5 VCSA Platform Services Controller or a version 6.0 PSC to a version 6.5 VCSA Platform Services Controller. The tools can also migrate a 5.5 vCenter with an embedded SSO or a 6.0 vCenter with embedded PSC with vCenter to a version 6.5 VCSA with embedded PSC. See Figure 5.13 for migration options.

During the migration option, you assign a temporary IP to the VCSA appliance in either the JSON file or the GUI. This IP is used to initially stand up the appliance so that it can receive the file transfer containing the configuration and exported data from the source appliance. When the migration is complete, the VCSA appliance should have the same configuration, including name and IP address as the source server. However, if the temporary IP address is not on the same network as the source server, the temporary IP address will be retained by the VCSA appliance at the end of the migration. This is to ensure that the VCSA server has network access at the end of the migration but will require additional work to change any other components referencing it. As with the CLI version, you need to execute the GUI from a server other than the existing vCenter server since the vCenter server will be shut down during the migration process

Upgrading ESXi Hosts and Virtual Machines

The VMware vSphere Update Manager is included with vSphere to help you apply patches, updates, and upgrades to hosts, virtual machines, and virtual appliances (VMs/VAs). Starting with version 6.5, you do not need a separate Windows server if you are using the vCenter Server Appliance because VUM runs as an embedded service on the VCSA. If you are not using VCSA, you will need to install VUM on either the same server as your vCenter Server or a separate Windows server.

Using the Update Manager Download Service

If the vSphere Update Manager is installed on a system that doesn't have Internet access, or you have multiple VUM servers and want to consolidate the downloads, you can install the vSphere Update Manager Download Service (UMDS) in order to download the patches and updates. You can install UMDS on a Windows or Linux-based operating system as long as it has Internet access. You cannot install UMDS on a Windows server with vSphere Update Manager installed.

If you install on a Windows server, you can manually create a database instance to use, or the installer will deploy SQL Express. On a Linuxbased server, you will need to configure a PostgreSQL database prior to installing UMDS.

After UMDS is installed, you can configure it using the command-line utility vmware-umds. Some of the command-line parameters used with this utility include the set parameter -S and the --enable-host and -- enable-va parameters to download host and appliance patches respectively

The -E parameter is also important because it exports the downloaded patches for you to copy to your VUM server.

The downloaded patches can be copied to the web server acting as a shared repository for multiple VUM servers or copied onto a portable device to transfer to an air-gapped VUM server.

Using vSphere Update Manager

VMware continually makes patches and updates for ESXi hosts, virtual machines, and appliances available online. You can use VUM (or the UMDS) to download the patches and then apply the patches to your vSphere environment.

The vSphere Update Manager groups patches and updates available from VMware into baseline objects. These baselines can then be grouped into baseline groups. You attach baselines or baseline groups to vCenters, datacenters, clusters, hosts, virtual machines, appliances, or folders to scan the associated entities for compliance and remediation.

There are two types of baselines (host and VM/VA), and a baseline group can only include one type of baseline. There are predefined baselines for hosts that include Non-Critical and Critical patches as shown in Figure 5.14 and predefined baselines for VMs/VAs that include VA Upgrade to Latest, VM Hardware Upgrade to Match Host, and VMware Tools Upgrade to Match Host as shown in Figure 5.15.

You can create your own baseline objects that only include the patches you are looking to apply to your hosts or VMs/VAs and create baseline groups to combine multiple baselines to be applied at once.

Baselines and baseline groups are then attached to vCenter objects using the Update Manager tab of that object. Some objects such as clusters and hosts can only attach host baselines and baseline groups, while virtual machines and VM folders can only attach VM/VA baselines and groups. Other objects, including vCenter and datacenters, can have host and VM/VA baselines and groups attached (Figure 5.16) as those objects can contain hosts and virtual machines/appliances.

After a baseline or group is attached to a vSphere object, you can scan the objects for compliance with the baseline or group as shown in Figure 5.17.

The options presented for scanning allow you to only check for a subset of the baseline or group. For hosts, you can choose to check for either patches and extensions or upgrades. Extensions are defined as “any additional software” in the Update Manager Guide, and by default VMware only has extensions for the Cisco NEXUS 1000v as shown in Figure 5.18.

For VMs/VAs, you can check for virtual appliance upgrades, VMware Tools upgrades, and VM Hardware upgrades. By default, VMware only has virtual appliance upgrades for VMware appliances as shown in Figure 5.19.

After the scan is complete, you will see in the Update Manager tab for the object which items are in compliance with the baseline or baseline group used in the scan. You are not required to scan before remediating, but it is suggested to scan so you are aware of what items will be updated and what updates they will receive. After scanning, you can click on the number of patches that are noncompliant to see the list as shown in Figure 5.20 and Figure 5.21.

Remediating hosts requires copying the patches or upgrade to the host, placing the host in maintenance mode, and then installing the patches. You can reduce the time it takes for this sequence by copying the required patches to the affected hosts using the Stage option.

During the Stage wizard, you will be given the option of staging some or all of the updates, as shown in Figure 5.22. You cannot stage VM/VA patches.

Whether or not you scan the objects or stage the hosts, you need to use the Remediate wizard to apply the patches. When remediating VM/VA baselines or groups, you have an option to schedule the update as shown in Figure 5.23 and set a pre-update snapshot that can be automatically removed as shown in Figure 5.24. Being able to automatically take a snapshot before the update allows a quick return to a known good state if there is a problem with the update; having an automatic removal of the snapshot reduces administrative overhead by not requiring an administrator to manually remove them.

When applying updates to hosts, you are presented with options including the ability to ignore warnings, as shown in Figure 5.25. While this is useful for avoiding flags for known issues, ignoring warnings would not be considered a best practice.

Other options include whether to change the power state on virtual machines on the host, which will affect how the host enters maintenance mode, and the number of retries for maintenance mode, which is useful if it takes a while to shut down VMs or evacuate the host (Figure 5.26).

If you are remediating a cluster, you will see options to disable Distributed Power Management (DPM), HA admission control, and fault tolerance (FT); see Figure 5.27. Disabling DPM (if it is enabled) will ensure that all hosts are powered on, which will make moving virtual machines around easier (as hosts are put into maintenance mode), and ensure that the hosts are available for remediation. Shutting off HA admission control will make moving virtual machines around easier as hosts will be able to hold more virtual machines without capacity being reserved. Disabling FT for VMs with FT will make moving virtual machines around easier as FT may prevent the VMs from being on hosts with different update levels, will reduce the number of VMs being moved (since the secondary will be removed), and will reduce overhead on the hosts.

Other cluster options include the ability to update multiple hosts at a time (the default is one host at a time), and you can also manually set the max number of hosts to remediate at one time or allow VUM to decide the max. You can also choose to migrate powered-off and suspended VMs before a host is updated, which is useful if you suspect the update might make the host unavailable. These options are shown in Figure 5.27.

If you will be using VUM to upgrade your ESXi hosts as well as to apply updates, you will need to import the ESXi image to use and then use that image in the baseline. Figure 5.28 shows the import utility for ESXi images

When you create the baseline for the host upgrade, choose Host Upgrade from the first screen and then select the image you updated. If you want the upgraded host to have all the latest patches, you can create a baseline group with the upgrade and patch baselines.

You can monitor the VUM process using the Tasks & Events tab of the object being patched (Figure 5.29) or the Monitor tab of VUM ( Figure 5.30 ).

After all of your hosts are upgraded, you can upgrade any Distributed Virtual Switch to the latest version supported by all the hosts connected. Please see the section “Upgrading and Deleting Distributed Switches” in Chapter 3, “Networking in vSphere,” for more information.

Summary

This chapter has covered upgrading a vSphere environment to version 6.5. Keeping your environment current is crucial to maintaining the best security, performance, features, and support. When migrating to 6.5, it is important to update the components in the correct order to maintain compatibility with all of the components in the environment. The upgrade order is SSO or PSC (depending on the current environment version), vCenter, hosts, and then virtual machines.

If you are currently using a Windows-based vCenter server, you have the option during the 6.5 upgrade to migrate to a vCenter Server Appliance (VCSA). This has a variety of benefits, including reducing the number of Windows licenses that are needed. The VCSA also includes vSphere Update Manager (VUM), which prior to 6.5 also required a Windows license.

After the upgrade, you can keep your hosts, VMs, and appliances upto-date by using VUM, which allows scheduling of updates as well as choosing options such as concurrent host updates and automatic snapshot creation and removal.

Exam Essentials

Know how the upgrade changes the topology. At the end of an upgrade, you will have either an external Platform Services Controller and vCenter server or a vCenter server with embedded PSC. While the topology can extend from there (multiple PSC and/or vCenters with or without load balancers), you can't have a distributed installation like 5.5 offered and any unsupported topology must be changed before the upgrade starts.

Understand how many Windows servers would be required. Since your topology can't be distributed and VUM is deployed automatically on VCSA, using Auto Deploy, Inventory Service, PSC, vCenter, and VUM could use either zero, one, two or three Windows servers. Also know that VUM can't be installed on a Windows server to support VCSA, but you could deploy UMDS on a separate Windows server.

Know the upgrade order. Know that you must update an external SSO/PSC before vCenter, update vCenter before hosts, and update hosts before VM Hardware. You need to maintain compatibility with all objects in the environment.

Know the UMDS options. Know the main parameters for the vmware-umds.exe executable including -S, -D, -E, --enable-host, and -- enable-va, and know that the UMDS can be installed on Windows- or Linux-based platforms in order to download the patches for VUM.

Understand the host and VM/VA remediate options for VUM . Know how to configure VUM to automatically take and remove virtual machine snapshots and update concurrent hosts.

Review Questions

1. What database migration can be performed during an upgrade?

   1. Full MS SQL to PostgreSQL
   2. MS SQL Express to PostgreSQL
   3. Oracle 10 to Oracle 11
   4. MS SQL Express to full MS SQL

2. If VCSA is deployed, what function can be installed on a Windows server?

   1. Platform Services Controller
   2. Update Manager Download Service
   3. vCenter Update Manager
   4. Auto Deploy

3. If vCenter is installed on a Windows server, what other components can be installed on a separate Windows server to support it? (Choose two.)

   1. vSphere web client
   2. Auto Deploy
   3. vCenter Update Manager
   4. Update Manager Download Service

4. What vSphere objects can VUM be used to upgrade? (Choose two.)

   1. VMware virtual appliances
   2. Virtual distributed switches
   3. ESXi hosts
   4. vCenter Server

5. What virtual machine components can VUM be used to upgrade? (Choose two.)

   1. Guest OS
   2. Virtual hardware
   3. Guest applications
   4. VMware Tools

6. When you're upgrading from VCSA 6.0 to VCSA 6.5, what functions can be performed on a Windows server? (Choose two.)

   1. vCenterServerexport
   2. vmware-umds
   3. vcsa-deploy
   4. migration-assistant

7. When migrating from Windows-deployed vCenter 6.0 to VCSA 6.5, what function must be performed on a Windows server?

   1. vCenterServerexport
   2. vmware-umds
   3. vcsa-deploy
   4. migration-assistant

8. After migrating from Windows-deployed vCenter 6.0 to VCSA 6.5, what can be used to clean up the move?

   1. C:ProgramDataVMwarevCenterServerexport
   2. vmware-umds
   3. vcsa-deploy
   4. migration-assistant

9. What is not a primary function of the vcsa-deploy utility?

   1. Migrate
   2. Upgrade
   3. Install
   4. Export

10. What database will be migrated to PostgreSQL during a vCenter for Windows upgrade?

    1. SQL Express
    2. MS SQL Full
    3. Oracle 11e
    4. JSON

11. What databases can be used by vCenter 6.5 on Windows? (Choose three.)

    1. SQL Express
    2. MS SQL Full
    3. Oracle 11e
    4. JSON
    5. IBM DB2

12. What is the proper upgrade order for vSphere 6.5?

    1. PSC, hosts, VMs, vCenter
    2. Hosts, PSC, vCenter, VMs
    3. vCenter, PSC, hosts, VMs
    4. PSC, vCenter, hosts, VMs

13. After several hosts were upgraded to vSphere 6.5, they are no longer available to manage in the vSphere client. What steps could be taken to resolve this? (Choose two.)

    1. Revert the hosts to their previous version
    2. Upgrade the VDS to version 6.5.
    3. Upgrade vCenter to version 6.5.
    4. Upgrade the Web Client to version 6.5.

14. What steps should be taken after a migration of a fully distributed vSphere 5.5 environment to VCSA 6.5? (Choose two.)

    1. Change DHCP to point to the new VCSA 6.5 server
    2. Shut down the Auto Deploy v5.5 service.
    3. Copy the historic vCenter events to the new 6.5 vCenter.
    4. Upgrade the VMware Update Manager to 6.5.

15. What data is included in a migration of a fully distributed vSphere 5.5 environment to vCSA 6.5? (Choose two.)

    1. Inventory Service data
    2. vSphere Syslog Collector
    3. vSphere Update Manager
    4. vSphere ESXi Dump Collector

16. After a migration of a fully distributed vSphere 5.5 environment to VCSA 6.5, what changes should be made manually?

    1. Update vCenter to point to the new PSC.
    2. Repoint ESXi Dump Log settings to the new VCSA
    3. Update hosts to point to the new Auto Deploy server.
    4. Update the Auto Deploy service for the new DHCP settings.

17. Which topologies are supported for end-state of the migration of a fully distributed vSphere 5.5 environment to VCSA 6.5? (Choose two.)

    1. One Windows-based vCenter server, embedded PSC
    2. Two Windows-based vCenter servers, embedded PSC
    3. Two VCSA, embedded PSC
    4. Two VCSA, external PSC

18. By default, how many hosts will VUM update at a time?

    1. One
    2. Two
    3. Depends on the Admission Control settings
    4. Two VCSA, one external PSC, one embedded PSC

19. Which inventory objects can VUM baselines be attached to? (Choose two.)

    1. vSphere Distributed Switch
    2. Datastores
    3. Virtual machine view folders
    4. vCenter

20. Which inventory objects can VUM host and VM/VA baselines be attached to? (Choose two.)

    1. Clusters
    2. Datacenters
    3. Virtual machine view folders
    4. vCenter

21. What feature can be enabled during remediate to allow for easy rollback of changes?

    1. Export
    2. Snapshot
    3. VDP
    4. JSON