Vsphere Upgrade
Vsphere Upgrade
Vsphere Upgrade
Table Of Contents
10
11
2. Pre-Upgrade Considerations
12
2. 1 Release Notes
2. 3 Interoperability Matrices
13
2. 5 vSphere Documentation
14
15
16
17
18
19
20
In our workshops one of the common things I hear is that most folks
aren’t using the CLI based tools that have been included in the
21
22
Upgrade
When doing a CLI based upgrade, we use a configuration file template
(JSON) that is part of the vCenter Server Appliance (VCSA) ISO. When
you mount the ISO you will see a directory labelled vcsa-cli-installer
and within that folder is a directory called templates. Once you are
here you have the option to see the CLI templates for install, migrate
and upgrade. As a reminder a migration is when we are moving from a
vCenter Server on Windows, and an upgrade is when we are moving
from VCSA to VCSA.
23
When opening this file at first glance you might say WOAH! That looks
complicated, but there is quite a bit of extra text explaining each field.
Lets fill in the blanks with the required information and take another
look.
This looks a lot better, we can clearly see the details it is asking for.
The vCenter Server to deploy the new appliance to, the appliance
information, the temporary IP to use, and then last but not least the
source information for the appliance we are upgrading. If we have a
deployment where there are multiple PSC’s we could see how easy it
24
would be to make a copy of this file, and edit lines 17 and 41 putting in
the second PSC and then re-saving. How much time saving could this
be!? With vSphere 6.5 allowing 10 PSC’s per SSO domain and vSphere
6.7 allowing 15 this could be quite a bit of time saved!
Next up, its time to upgrade our vCenter Server. To get our JSON file
ready we will head back and grab the vCSA_on_VC.json template.
Also remember that if you happen to have multiple VCSA’s to upgrade
you can easily update lines 16 ,17 and 40 to upgrade other appliances
in your environment.
Now that we have prepared our templates for our upgrade, the next
section we will jump into how to actually perform our upgrade using
the CLI.
25
CLI templates in hand, its now for the fun. Using these templates we
will automate our upgrade. vSphere 6.0 originally introduced this
concept of a CLI based tool, however its been enhanced with vSphere
6.7. With vSphere 6.7 we now have a “batch template” technology
built into the installer. Prior to vSphere 6.7 we had to run the installer
against a single JSON file and wait for it to finish, we would then have
to manually kick off the second JSON file when the previous one
completes. With the batch upgrade we can put multiple JSON files into
a single directory and point the installer to the directory and it is smart
enough to map out the dependencies and upgrade the PSC’s first and
then the vCenter Servers.
To run our CLI based installer we will mount our vSphere 6.7 media as
that is the version we are going to. We will again navigate to the vcsa-
cli-installer directory. From here depending on the operating system
of the machine we are on we will either navigate to the lin64, win32 or
mac folder to use the supported installer for that operating system.
Here we will see quite a few files, but the one we want to focus on is
vcsa-deploy.exe in the win32 folder since I will be running this from a
windows machine. If we run .\vcsa-deploy.exe upgrade it will give us
the details on how to properly use the CLI tool.
26
27
Now that we have the service running and re-run our pre-check we can
see everything is successful and we can now proceed to remove the –
precheck-only flag from our command.
Conclusion
Automating your vSphere Upgrade does not have to be scary or hard,
as we went through the steps its actually quite easy. Now that we have
our PSC and vCenter Server updated we can now proceed to our next
step which is automating the upgrade of our ESXi hosts.
Article: https://blogs.vmware.com/vsphere/2018/09/upgrading-
28
platform-services-controller-and-vcenter-server-via-the-cli-
installer.html
Date: 2018-10-29
Title
29
NOTE: The upgrade of the vCenter Server is broken up into two stages, Stage 1 &
Stage 2. Stage 1 is the deployment of a new VCSA and Stage 2 is where all of the
configuration data and inventory are imported into the newly upgraded vCenter
Server.
30
Stage 1
Step 1: This is the introduction and an explanation of the two Stages
of the Upgrade. Click Next to continue.
Step 2: Review the EULA, check the box to accept the terms of the
license agreement, and then click Next to continue.
Step 3a: Enter the source vCenter Server that you will be Upgrading by
its FQDN or IP address. Click Connect To Source to reveal the
additional fields.
31
Step 3b: Complete each required field for SSO as well as the
information about the ESXi host that manages the source vCenter
Server. Then click Next to continue.
Step 3c: You will prompted to verify the SSL Certificates. Review and
click Yes to continue.
32
Step 4a: Specify the target host or vCenter Server to which the new
VCSA will be deployed to. Click Next to continue.
Step 4b: When prompted, review the SSL Certificate and thumbprints
then click Yes to continue.
33
Step 5: Specify the Virtual Machine name (this is only the Inventory
name) and set the password for the VCSA that will be deployed during
the upgrade. Click Next to continue.
NOTE: During an upgrade of the source VCSA, a new VCSA virtual machine is
deployed and configurations are imported to the new vCenter Server Appliance.
The source VCSA will be powered off and should be either removed from
inventory, or have its network adapter disabled after the upgrade completes.
Step 6: Select the deployment size for the vCenter Server. If more
storage is needed than the default sizing, choose the “Storage Size”
34
NOTE: If you plan to use vCenter High Availability (VCHA) after you upgrade your
vCenter Server, the smallest deployment size supported for VCHA is Small.
Step 7: Select the datastore location for the vCenter Server Appliance.
The option to also Enable Thin Disk Mode is available, if you require it.
35
36
Once the VCSA is deployed and all RPM installs are completed in
Stage 1, you can click Continue to move on to Stage 2.
37
Stage 2
Stage 2 of the upgrade is when the data from the source vCenter
Server as well as vSphere Update Manager (VUM) is imported into the
newly deployed VCSA.
Step 1: Review the details of the Stage 2 process and then Click Next
to continue.
This will kick off a series of pre-checks on the source vCenter Server.
38
Step 3: Select the data that you will require to be imported. The
Inventory & Configuration data is moved by default, any historical data
(events, tasks, performance, etc) is optional to import. This is offered
to shorten the upgrade and migration of data into the new VCSA.
Make the required choice, and then click Next to continue.
39
Step 5: Review all setting choices here and once complete, click Finish
to continue.
40
The prompt here is a reminder that the source vCenter Server will be
powered down once all network configuration is enabled on the
destination VCSA.
Click OK to continue.
Stage 2 begins. Data is exported from the source vCenter Server and
prepared for import.
41
Last, the copied data from the source vCenter Server is imported to
the destination VCSA.
42
When all data has been imported to the destination VCSA, the process
is complete. Messages are presented at this step as informational,
such as a notice about TLS changes in vSphere 6.7.
43
Closing the installer will launch the vCenter Server splash page
allowing you to login via the vSphere Client on HTML5.
Since the vSphere Web Client (Flex) is now deprecated, I will use the
HTML5 vSphere Client because it is now our default client and it
contains 95% of all workflows as compared to vSphere 6.5 Update 1
that contained 90% of workflows. The HTML5 vSphere Client will be
fully featured by the Fall of 2018.
44
Now we will verify the vCenter Server is now running on version 6.7.
We do this by clicking on the inventory name of the vCenter Server
and viewing the Version Information from the Summary tab.
Enable DRS
Since we disabled DRS during our preparing to upgrade post, it should
be enabled once again. We begin this task by highlighting the cluster
and then clicking on the Configure tab to view vSphere DRS settings.
If you had set DRS to Manual versus disabling, now is the time to
45
In the Edit Cluster Settings window, click the slider switch to enable
vSphere DRS then click OK to save. DRS is now enabled on the cluster.
NOTE: You can also quickly perform these actions via PowerCLI with
the ‘Set-Cluster’ cmdlet.
Enable DRS:
46
Final Steps
After the vCenter Server Upgrade is completed, it is important to call
out that power off operations only happen automatically for the
vCenter Server, the VUM server must be powered off manually.
As a best practice, I suggest removing the Network Card from the old
vCenter Server as well as renaming the VM to differentiate it within
inventory and mitigate any accidental power on operations. Notice the
new VCSA (VCSA67) virtual machine inventory name that was given.
Note that renaming the VM does not change the FQDN of the VCSA,
this is just the inventory name of the VM.
Rollback
Did your maintenance window close or maybe you encountered
another issue during an Upgrade? Not to worry, rollback is quite
simple. In this vSphere environment that we just upgraded we have no
external PSCs, only the vCenter Server Appliance to worry about. If we
did have an external PSC, we would first power off the newly deployed
PSC, restore the PSC instance from backup, and if it was joined to an
47
In our case without an external PSC we would, power off the newly
deployed vCenter Server Appliance 6.7, bring the old vCenter Server
Appliance 6.0 instance online (If already powered off, simply power it
on. If not powered off, a restart is required), if it was joined to an
Active Directory domain, it may need to be joined again (if your
vCenter Server was Windows, be sure to have a local account on the
server and do not rely on any cached credentials). Lastly we wait for all
vCenter Server services to start and log in to the vSphere Web Client
to verify the vSphere inventory.
Conclusion
Remember; Focus, Plan, Execute!
Article: https://blogs.vmware.com/vsphere/2018/07/vsphere-
upgrade-series-part-2-upgrading-vcenter-server.html
Date: 2018-10-29
Title
48
49
50
51
I should also mention that utilizing VUM is not the only way to perform
ESXi host upgrades. Upgrades for ESXi hosts can be done Interactively
with a CD/DVD or USB drive, with vSphere Auto Deploy, scripted, or
via esxcli commands. All methods may have different requirements
which should be reviewed. Each method listed are valid and supported
for upgrading ESXi hosts.
Note: In regards to ESXCLI Upgrades & Secure Boot; “If your host was upgraded
using the ESXCLI command then your bootloader wasn’t upgraded and doesn’t
persist the signatures. When you enable Secure Boot after the upgrade, an error
occurs. You can’t use Secure Boot on these installations and will have to re-install
from scratch to gain that support.” – Mike Foley’s Secure Boot for ESXi Blog
Preparing VUM
In this environment I will be using VUM to manage the upgrades of
four ESXi hosts on vSphere 6.0 to vSphere 6.7. Before we begin
upgrading the vSphere ESXi hosts we will need to have the VMware
vSphere Hypervisor (ESXi) 6.7 installation ISO (named similar to this;
“VMware-VMvisor-Installer-<vSphere_version>-
<build_number>.x86_64.iso“) which is available on My.VMware.com.
A vSphere Update Manager (VUM) Upgrade Baseline is also required
since we will be using VUM to perform the upgrades of our ESXi hosts.
I will cover how to create the baseline that we will use during this post.
Last, we need at least one vSphere ESXi host to upgrade with our VUM
baseline.
52
53
When complete, click Import to complete the action and save the ESXi
Image to VUM.
54
From the Update Manager ESXi Images screen, we can see the image
is loaded into Update Manager for use with a Baseline.
55
Click on Baselines to begin. From this screen click on NEW, then New
Baseline.
Fill out the name & description for the baseline, click the radio button
for “Upgrade” as the content type for the baseline, and click Next.
Select the ESXi 6.7 Image to use with this baseline, click Next to
continue.
56
57
Next, click on the Datacenter object (#1) then click on Updates (#2)
and last click on Attach (#3).
58
In the pop up window, select the vSphere 6.7 Upgrade baseline so that
we can attach it to our vSphere 6.0 hosts. Click OK to continue.
59
Once the Compliance Checks are completed we can quickly see that
our vSphere hosts need attention. This is a good and expected result.
What this means is that the vSphere 6.7 code is not running on these
vSphere hosts.
Note: If the status was to read ‘Compliant‘ vs. ‘Non-Compliant‘ it would indicate
that the hosts that were checked, already have vSphere 6.7 software installed.
60
61
62
Once all edits, changes, and reviews have been completed, click Done.
63
Review and Accept the End User License Agreement (EULA), then click
OK to continue.
Select the hosts that you would like to Remediate with the vSphere 6.7
Upgrade baseline. You can choose to do all hosts within a cluster or a
select few. Click OK to continue.
64
Below we can see our vSphere host going into Maintenance Mode and
preparing to Upgrade. Once this host is done and back online after its
reboot, Update Manager will move to the next ready host in the
cluster to update in the same manner.
65
Conclusion
We have successfully executed Upgrading vSphere Hosts with
66
Article: https://blogs.vmware.com/vsphere/2018/07/vsphere-
upgrade-series-part-3-upgrading-vsphere-hosts.html
Date: 2018-10-29
67
68
None
69
70
71
72
73
types of VM Tools.
74
Recall from the previous post that there are three types of VM Tools –
the familiar Tools ISOs for all supported operating systems, plus two
additional offerings in the form of binary packages for Linux. There are
several ways to initiate VM Tools updates from vSphere or from within
a guest. The following applies only to Windows and Linux guests using
VM Tools ISOs except where noted. The VM Tools Linux packages –
OVT and OSP – are not managed via vSphere, so they can only be
installed and updated from within each guest OS using native package
management tools.
75
Important note for guests other than Windows and Linux: Solaris,
FreeBSD, and Mac OS VM Tools can only be updated using the manual
interactive method. There is currently no automatic Tools update for
these guests.
76
VMware Update Manager (VUM) has two very different roles to play
when it comes to updating VM Tools. The first one has to do with
fetching updated VM Tools ISOs in the form of the ‘tools-light’ VIB
that is offered when needed in the normal ESXi patch stream. This
patch is then pushed out to all managed hosts according to baselines
established by administrators. Once this occurs, individual VMs will
begin to detect that a new version of VM Tools is available and will be
eligible for update.
77
78
For advanced use cases where vSphere APIs are being used for deeper
integration with other processes, consider the UpgradeTools_Task for
programmatic upgrades of VM Tools.
Summary
With these flexible means of updating VM Tools, there is a suitable
approach for any VMware datacenter, whether the requirement is
centralized control, automation, delegation to app owners, or
integration with existing patch management processes.
Article: https://blogs.vmware.com/vsphere/2016/03/six-methods-
for-keeping-vm-tools-up-to-date.html
Date: 2018-10-29
Title
79
80
81
Recall from the previous post that there are three types of VM Tools –
the familiar Tools ISOs for all supported operating systems, plus two
additional offerings in the form of binary packages for Linux. There are
several ways to initiate VM Tools updates from vSphere or from within
a guest. The following applies only to Windows and Linux guests using
VM Tools ISOs except where noted. The VM Tools Linux packages –
OVT and OSP – are not managed via vSphere, so they can only be
installed and updated from within each guest OS using native package
management tools.
82
Important note for guests other than Windows and Linux: Solaris,
FreeBSD, and Mac OS VM Tools can only be updated using the manual
interactive method. There is currently no automatic Tools update for
these guests.
VMware Update Manager (VUM) has two very different roles to play
when it comes to updating VM Tools. The first one has to do with
fetching updated VM Tools ISOs in the form of the ‘tools-light’ VIB
that is offered when needed in the normal ESXi patch stream. This
patch is then pushed out to all managed hosts according to baselines
established by administrators. Once this occurs, individual VMs will
begin to detect that a new version of VM Tools is available and will be
eligible for update.
83
84
For advanced use cases where vSphere APIs are being used for deeper
integration with other processes, consider the UpgradeTools_Task for
programmatic upgrades of VM Tools.
Summary
With these flexible means of updating VM Tools, there is a suitable
approach for any VMware datacenter, whether the requirement is
85
Article: https://blogs.vmware.com/vsphere/2016/03/six-methods-for-
keeping-vm-tools-up-to-date.html
Date: 2018-10-29
86
However, since we are talking about automation lets show this another
way using PowerCLI.
87
88
Now that we know which VMs need tools update we can actually go
forth and upgrade tools. That is quite simple we can do this using the
Update-Tools PowerCLI cmdlet. Using our existing one-liner from
above we will just append Update-Tools to update the VMs with tools
currently out of compliance.
89
You may have noticed that all the VMs had their updates kicked off at
the same time and this may not be ideal, this is one way that the
Update-Tools cmdlet works, however we can get around this by
storing the VMs within a variable and then using a loop process them
one at a time. This is definitely preferable as it will limit the impact to
the environment.
90
The easy way to enable this option is to log into the vSphere Client,
edit the VM settings and enable the setting.
91
After all this a post on automation, so lets see if we can find a way to
use PowerCLI to modify the VM’s setting so this gets easier when we
have a large environment.
Here we can see which VMs have the automatic upgrade set and
which ones are configured for manual. Utilizing a filter we can look for
objects that are set for manual and then configure them to be set for
upgradeAtPowerCycle
92
93
If we do a final check we can see that all VMs are now set to
upgradeAtPowerCycle.
Upgrading VM Compatibility
When it comes to upgrading your VM Compatibility this is something
that should be done with caution. Upgrading VM Compatibility aka
VM Hardware is like pulling out the motherboard and replacing it with
a new one, so this should only be done when features and
functionality in a higher level are needed. Our current recommended
level is Hardware Version 11 as it handles remediation from current
security threats.
Its quite easy to see the current version of VM Compatibility via the
vSphere Client, however when checking the current levels across our
entire vCenter Server we may want to automate this Below you will
find a quick and easy one-liner to identify the VMs and their current
VM Compatibility version.
94
As we can see above a few VMs are currently running v14 which is
compatible with vSphere 6.7 only. This was needed for us to take
advantage of VBS and TPM security features.
If you wish to do this via the vSphere Client my colleague Nigel Hickey
covers this in his blog series here. However, we are talking automation
here so lets jump into the quick script to accomplish this.
1
2 $HardwareUpdateVMs = Get-Folder Testing | Get-VM
3 VM08Foreach ($VM in ($HardwareUpdateVMs)) {$VMConfig =
4 Get-View -VIObject $VM.Name$vmConfigSpec = New-Object
5 VMware.Vim.VirtualMachineConfigSpec$vmConfigSpec.Schedul
6 edHardwareUpgradeInfo = New-Object -TypeName
7 VMware.Vim.ScheduledHardwareUpgradeInfo$vmConfigSpec.S
8 cheduledHardwareUpgradeInfo.UpgradePolicy =
9 “always”$vmConfigSpec.ScheduledHardwareUpgradeInfo.Versi
1 onKey = “vmx-14”$VMConfig.ReconfigVM($vmConfigSpec)}
0
95
Conclusion
Automating your VMware Tools and VM Compatibility upgrades do
not need to be hard, we have quite a few ways to help you with this
and help this blog has helped educate you on some additional
methods. For more information on Automating your vSphere Upgrade
be sure to check out the full series here.
Article: https://blogs.vmware.com/vsphere/2018/09/automating-
upgrade-of-vmware-tools-and-vmware-compatibility.html
Date: 2018-10-29
https://blogs.vmware.com/vsphere/2018/09/automating-upgrade-of-
vmware-tools-and-vmware-compatibility.html
96
97
install newer versions of VMware Tools when they reboot. The guest
OS checks the version of VMware Tools when you power on a Virtual
Machine (VM). The status bar of the VM displays a message when a
new version is available.
98
Step 3: Once you click Upgrade VMware Tools, you will be presented
with 2 types of upgrades. Choose an upgrade type, click Upgrade to
continue. (In my scenario, I have selected an Automatic Upgrade)
Step 4: Review the Recent Tasks pane to monitor the VMware Tools
upgrade progress
99
100
Step 1: Right click on the VM to be upgraded (or use the Actions menu
once the VM is highlighted), choose Compatibility and then click
Schedule VM Compatibility Upgrade.
101
102
103
Conclusion
As you have witnessed updating VMware Tools or Virtual Machine
Compatibility are not complex tasks, but absolutely include steps that
will require consideration prior to execution. It is always best to
consult VMware Documentation pages for further details on VMware
Tools as well as Virtual Machine Compatibility prior to upgrading. Also
be sure to review the vSphere Upgrade Guide.
104
NOTE: The upgrade of the vCenter Server is broken up into two stages, Stage 1 &
Stage 2. Stage 1 is the deployment of a new VCSA and Stage 2 is where all of the
configuration data and inventory are imported into the newly upgraded vCenter
Server.
105
Stage 1
Step 1: This is the introduction and an explanation of the two Stages
of the Upgrade. Click Next to continue.
Step 2: Review the EULA, check the box to accept the terms of the
license agreement, and then click Next to continue.
106
Step 3a: Enter the source vCenter Server that you will be Upgrading by
its FQDN or IP address. Click Connect To Source to reveal the
additional fields.
Step 3b: Complete each required field for SSO as well as the
information about the ESXi host that manages the source vCenter
Server. Then click Next to continue.
107
Step 3c: You will prompted to verify the SSL Certificates. Review and
click Yes to continue.
Step 4a: Specify the target host or vCenter Server to which the new
VCSA will be deployed to. Click Next to continue.
108
Step 4b: When prompted, review the SSL Certificate and thumbprints
then click Yes to continue.
Step 5: Specify the Virtual Machine name (this is only the Inventory
name) and set the password for the VCSA that will be deployed during
the upgrade. Click Next to continue.
NOTE: During an upgrade of the source VCSA, a new VCSA virtual machine is
deployed and configurations are imported to the new vCenter Server Appliance.
The source VCSA will be powered off and should be either removed from
inventory, or have its network adapter disabled after the upgrade completes.
109
Step 6: Select the deployment size for the vCenter Server. If more
storage is needed than the default sizing, choose the “Storage Size”
dropdown for more choices. Storage size changes will be reflected in
the table below the selection dropdown in the Storage (GB) column.
NOTE: If you plan to use vCenter High Availability (VCHA) after you upgrade your
vCenter Server, the smallest deployment size supported for VCHA is Small.
110
Step 7: Select the datastore location for the vCenter Server Appliance.
The option to also Enable Thin Disk Mode is available, if you require it.
111
Once the VCSA is deployed and all RPM installs are completed in
Stage 1, you can click Continue to move on to Stage 2.
112
Stage 2
Stage 2 of the upgrade is when the data from the source vCenter
Server as well as vSphere Update Manager (VUM) is imported into the
newly deployed VCSA.
Step 1: Review the details of the Stage 2 process and then Click Next
to continue.
This will kick off a series of pre-checks on the source vCenter Server.
113
Step 3: Select the data that you will require to be imported. The
Inventory & Configuration data is moved by default, any historical data
(events, tasks, performance, etc) is optional to import. This is offered
to shorten the upgrade and migration of data into the new VCSA.
Make the required choice, and then click Next to continue.
114
Step 5: Review all setting choices here and once complete, click Finish
to continue.
115
The prompt here is a reminder that the source vCenter Server will be
powered down once all network configuration is enabled on the
destination VCSA.
Click OK to continue.
Stage 2 begins. Data is exported from the source vCenter Server and
prepared for import.
116
Last, the copied data from the source vCenter Server is imported to
the destination VCSA.
117
When all data has been imported to the destination VCSA, the process
is complete. Messages are presented at this step as informational,
such as a notice about TLS changes in vSphere 6.7.
118
Closing the installer will launch the vCenter Server splash page
allowing you to login via the vSphere Client on HTML5.
Since the vSphere Web Client (Flex) is now deprecated, I will use the
HTML5 vSphere Client because it is now our default client and it
contains 95% of all workflows as compared to vSphere 6.5 Update 1
that contained 90% of workflows. The HTML5 vSphere Client will be
fully featured by the Fall of 2018.
119
Now we will verify the vCenter Server is now running on version 6.7.
We do this by clicking on the inventory name of the vCenter Server
and viewing the Version Information from the Summary tab.
Enable DRS
Since we disabled DRS during our preparing to upgrade post, it should
be enabled once again. We begin this task by highlighting the cluster
and then clicking on the Configure tab to view vSphere DRS settings.
If you had set DRS to Manual versus disabling, now is the time to
120
In the Edit Cluster Settings window, click the slider switch to enable
vSphere DRS then click OK to save. DRS is now enabled on the cluster.
NOTE: You can also quickly perform these actions via PowerCLI with
the ‘Set-Cluster’ cmdlet.
Enable DRS:
121
Final Steps
After the vCenter Server Upgrade is completed, it is important to call
out that power off operations only happen automatically for the
vCenter Server, the VUM server must be powered off manually.
As a best practice, I suggest removing the Network Card from the old
vCenter Server as well as renaming the VM to differentiate it within
inventory and mitigate any accidental power on operations. Notice the
new VCSA (VCSA67) virtual machine inventory name that was given.
Note that renaming the VM does not change the FQDN of the VCSA,
this is just the inventory name of the VM.
Rollback
Did your maintenance window close or maybe you encountered
another issue during an Upgrade? Not to worry, rollback is quite
simple. In this vSphere environment that we just upgraded we have no
external PSCs, only the vCenter Server Appliance to worry about. If we
did have an external PSC, we would first power off the newly deployed
PSC, restore the PSC instance from backup, and if it was joined to an
122
In our case without an external PSC we would, power off the newly
deployed vCenter Server Appliance 6.7, bring the old vCenter Server
Appliance 6.0 instance online (If already powered off, simply power it
on. If not powered off, a restart is required), if it was joined to an
Active Directory domain, it may need to be joined again (if your
vCenter Server was Windows, be sure to have a local account on the
server and do not rely on any cached credentials). Lastly we wait for all
vCenter Server services to start and log in to the vSphere Web Client
to verify the vSphere inventory.
Conclusion
Remember; Focus, Plan, Execute!
Article: https://blogs.vmware.com/vsphere/2018/09/vsphere-
upgrade-series-part-4-upgrading-vmware-tools-and-vm-
compatibility.html
Date: 2018-10-29
Write Something
123
6. VMFS Upgrade
Topics related to upgrading VMFS version to 6
124
125
You will also see that we have mentioned migrating from VMFS-5 to
VMFS-6. Due to the underlying storage changes to support 4K Native
storage as well as other features the metadata has changed and the
upgrade cannot be done In-Place. The migration requires you to
delete the current datastore and re-create. In a later section we will
cover how to automate this process.
In case you are not sure what VMFS version your datastore is currently
running, we can find out with a simple PowerCLI one-liner.
Here we can see that DS01 is still at VMFS-5 and DS02 has already
been upgraded to VMFS-6. In the next section we will target
upgrading our datastore to VMFS-6.
126
So now that we know some things to look out for what does the
cmdlet actually do?
1.
2. Checks for VADP, SMPFT, MSCS/RAC virtual machines on Source
Datastore.
3.
4. Makes sure datastore is accessible to all hosts.
5.
Now that we understand how it works, lets jump into the usage.
1
2 Connect-VIServer ds-vcsa-03.cpbu.lab$Source = Get-Datastore
3 "DS02"$Temp = Get-Datastore "DS-TEMP"$Server = (Get-
4 VIServer -Server "ds-vcsa-03.cpbu.lab")Update-VmfsDatastore -
5 Datastore $Source -TemporaryDatastore $Temp -
6 TargetVmfsVersion "6" -Server $Server
7
127
It requires very minimal input, we will put in the source datastore, the
temporary datastore, vCenter Server and the Target VMFS version.
The above animated gif will show the process. It is quite simple and if
you encounter errors they will be logged and you can rollback using
the rollback parameter of if the error can resumed you can use the
resume parameter.
Conclusion
It is always great to see some native tools to assist us in accomplishing
complicated tasks. For those who have an abundance of datastore’s in
their environment, this cmdlet can save quite a bit of time. If you have
used it, leave some feedback on your thoughts. Next up on our series
will be Automating Your Virtual Distributed Switch upgrade.
Article: https://blogs.vmware.com/vsphere/2018/10/automating-
migration-of-vmfs-5-to-vmfs-6-datastores.html
Date: 2018-10-29
Write Something
128
Storage
• vSphere 5.5 End of General Support Reminder •
If you are running vSphere 5.5, please be advised that End of General
Support (EOGS) for vSphere 5.5 occurred on September 19, 2018.
Read the 5.5 EOGS blog for more details.
Today brings us Part 5 of the vSphere Upgrade series which will cover
Upgrading VMFS Storage. Upgrading storage is key to take advantage
of the new features of VMFS as well as running a supported version of
the storage filesystem. With the introduction of vSphere 6.7,
filesystem version VMFS-3 is now deprecated and now supports just
two versions, VMFS-5 and VMFS-6. If you have been following this
blog series or not, you can recap what we have covered by starting
with the first blog “vSphere Upgrade Series Part 1: Preparing to
Upgrade“.
129
If you use an ESXi .iso image to upgrade your legacy host through
vSphere Update Manager, and the upgrade is not successful, the
VMFS3 datastore is upgraded to VMFS5 if the installation process
passes the mount phase.
In the mixed environment of the 6.5 and 6.7 ESXi hosts, the
VMFS3 datastore upgrades when the 6.7 host attempts to mount
it. The 6.5 host can continue to access the datastore even when
the upgrade is unsuccessful.
130
There is not too much behind this process because essentially what we
are doing is creating a new VMFS6 datastore and then migrating any
VMs off of the VMFS5 storage. Next would be moving those
workloads to the newly created VMFS6 datastore. I will step through
the process of creating the new datastore & removing the old one.
Step 1: Verify the current datastore type by moving the the Datastore
view, then selecting a datastore to review. We can see that this is a
VMFS5 type datastore. At this point you should evacuate any VMs
from the datastore to another location before the new VMFS6
datastore is created.
Step 2: Next we will begin the creation of the VMFS6 datastore. From
the Actions menu navigate to Storage and then New Datastore…
131
Step 4: Fill out the name of the new datastore and select the disk/LUN
to use also. Click Next to continue.
132
Step 5: Choose VMFS6 for the version and click Next to continue.
Step 6: Review the partition configuration for the disk layout and
make any necessary changes if required. Once edits are complete,
click Next.
133
Step 7: The last step here in the wizard is to review the settings that
you have selected and click Finish to create the datastore.
134
NOTE: If you have any VMs to move to the new VMFS6 datastore, now
is the time to migrate them over before deleting the older VMFS5
datastore.
Step 9: The final steps will be to delete the old VMFS5 datastore.
Begin by selecting the datastore, from the Actions menu choose
Delete Datastore.
Step 10: Confirm the deletion of the VMFS5 datastore and when
ready, click Yes to continue with the removal operation.
135
Conclusion
After these steps you now have a new VMFS6 datastore and have
removed the older version VMFS5 storage. To learn more or review
other features of VMFS, please review the VMware KB 2147824 and
also VMware Documentation for VMFS.
In the next and final vSphere Upgrade Series post, we will focus on
upgrading Upgrading vSphere Networking in a vSphere 6.7
136
Article: https://blogs.vmware.com/vsphere/2018/09/vsphere-
upgrade-series-part-5-upgrading-vmfs-storage.html
Date: 2018-10-29
Write Something
137
138
139
With vSphere 6.7 and the introduction of VDS version 6.6 there are
some known issues and considerations I want to mention prior to
getting started upgrading our switch. A question I get asked quite
frequently is why is vSphere 6.7’s VDS version 6.6? The answer is quite
simple, VMware on AWS (VMC) shares quite a bit of the same code as
vSphere On-Perm and since there were no major changes to the VDS
features or functionality the version stayed the same. Prior to
upgrading our VDS version to 6.6 we definitely want to make sure we
review KB52621. This KB covers considerations around known issues
upgrading to version 6.6. Some of these considerations are making
sure to put DRS into partially automated mode since if a vMotion
140
occurs during the upgrade the VDS upgrade will fail. To take these
considerations into account, we will make sure to include this in our
Upgrading your Virtual Distributed Switch automation.
Prior to upgrading we also need to verify that all hosts have been
upgraded to vSphere 6.7 so we do not have any errors. If there is a
incompatible host attached the upgrade will not be allowed to
proceed.
To validate our ESXi host version for all hosts attached to our VDS we
can do so as follows.
We can see here that one of our hosts is not upgraded to 6.7 so if we
were to proceed with upgrading our VDS it would fail. Before we
proceed on to our next section we will make sure to upgrade our ESXi
host to vSphere 6.7. If we were to attempt to upgrade our VDS prior to
upgrading we would have encountered an error such as below.
Now that we are ready to move forward with upgrading our VDS, we
will take some of the above considerations into place. Since we know if
a vMotion is occurring during upgrade it will fail. We will make sure
that if DRS is enabled we will put it into Partially Automated mode.
Also, since we know we cannot rollback from a version upgrade we will
make sure to take a backup prior to our upgrade. Unlike our previous
blogs where we used simple one-liners, we will utilize a bit more logic
in this upgrade that will be required as a script.
141
You can see the code below and grab the script from GitHub.
1
2
3
4
Connect-VIServer "ds-vcsa-03.cpbu.lab" | Out-Null$VDSwitch =
5
"VDS"$VDVersion = "6.6.0"$Cluster = Get-Cluster "Cluster"If
6
($Cluster.DrsEnabled -like "True") {Write-Host "DRS is Enabled,
7
it will be temporarily disabled during upgrade." -
8
ForegroundColor "Green"$ClusterDRSLevel =
9
$Cluster.DrsAutomationLevelWrite-Host "DRS Cluster is
1
currently set to $ClusterDRSLevel. Will change back when
0
complete." -ForegroundColor "Green"Get-Cluster $Cluster | Set-
1
Cluster -DrsAutomationLevel "PartiallyAutomated" -
1
Confirm:$falseGet-VDSwitch -Name $VDSwitch | Export-
1
VDSwitch -Description "My Backup" -Destination
2
"/PathToBackup/VDSBackup-$VDswitch-$((Get-
1
Date).ToString(‘yyyy-MM-dd-hh-mm’)).zip"Get-VDSwitch -Name
3
$VDSwitch | Set-VDSwitch -Version $VDVersionWrite-Host
1
"Upgrade is complete. Setting Cluster to $ClusterDRSLevel." -
4
ForegroundColor "Green"Get-Cluster $Cluster | Set-Cluster -
1
DrsAutomationLevel $ClusterDRSLevel -Confirm:$false}ElseIf
5
($Cluster.DrsEnabled -like "False") {Write-Host "DRS is Disabled,
1
No additional action needed." -ForegroundColor "Green"Get-
6
VDSwitch -Name $VDSwitch | Export-VDSwitch -Description
1
"My Backup" -Destination "/PathToBackup/VDSBackup-
7
$VDswitch-$((Get-Date).ToString(‘yyyy-MM-dd-hh-
1
mm’)).zip"Get-VDSwitch -Name $VDSwitch | Set-VDSwitch -
8
Version $VDVersion}
1
9
2
0
142
As we can see the upgrade is now complete. Even though the upgrade
is itself a simple one-liner (Get-VDSwitch -Name $VDSwitch | Set-
VDSwitch -Version $VDVersion), we can automate the pre-requisites,
backups and considerations to make this a more seamless upgrade. If
you are interested in understanding how you can upgrade your VDS
through the UI please see my colleague Nigel Hickeys blog here.
You can find more information on Backing Up and Restoring your VDS
here and more information on Upgrading your Virtual Distributed
Switch here.
Conclusion
As we have now completed Automating our vSphere Upgrade we can
see it wasn’t so bad after all. Im hoping this series has helped you
better understand what it takes to Automate your vSphere Upgrade
and for those of you with large environments it gives you an idea on
how you can start to streamline the upgrades across your entire
vSphere environment.
Article: https://blogs.vmware.com/vsphere/2018/10/automating-
upgrade-of-virtual-distributed-switch.html
Date: 2018-10-29
143
Title
144
1.
2. vSphere 6.0
3.
4. vSphere 6.5
5.
6. vSphere 6.6
7.
Most updates to networking have been within ESXi itself, but some
features require upgrading VDS as outlined above. When upgrading to
VDS version 6.0 or 6.5 it’s quite simple and can be done with no
disruption. However, when upgrading to VDS version 6.6 there are
some considerations to take, KB52621 has considerations to review to
prevent most issues.
Step 1: First we will review what version the current VDS is running by
viewing the Summary tab on the Networking screen. Once reviewed
we will move to upgrading.
145
Step 2: Here we click on the Upgrades Available link and can see an
upgrade is needed.
146
Step 5: Once the switch upgrade completes, you can see the new
version shown on the Summary tab of the Networking screen. The
VDS upgrade is now finished.
147
Conclusion
Thats a wrap! From beginning to end of a vSphere Upgrade,
component to component, screen by screen. I hope that this series has
helped take some of the unknowns or complexity away from your
vSphere Upgrade Journey. My job is to educate as well as help make
things easier to understand and digest. If these blogs have helped in
anyway, please leave a comment.
For review, please follow the below links to each part of the vSphere
Upgrade Series:
Article: https://blogs.vmware.com/vsphere/2018/09/vsphere-
upgrade-series-part-6-upgrading-vsphere-networking.html
Date: 2018-10-29
Write Something
148
8. Post-Upgrade Considerations
149
150
151
152
153
154
None
None
None
155
156
None
157