Welcome back to vSphere 8 in the real world, and now we're going to discuss the VCSA upgrade process.
So the VCSA is the vCenter's virtual appliance that VMware has been deploying for a while now.
When we first started with VMware back in the 3.5 days or before that, 3.0, 3.5, and then going forward,
vCenter was installed on a Windows machine.
So we'd have a Windows machine, and we would install vCenter on that Windows machine.
It could be a virtual Windows machine, or it could be a physical Windows box that was in our environment,
but it was installed on Windows.
Then VMware came out with that virtual appliance, and when it first, first came out, it was kind of touted as
a quick way to deploy vCenter for like a lab environment or something like that.
And then quickly VMware started saying, this is the way to deploy vCenter in production,
and then it became, this is the only way to deploy vCenter.
So for a long time, you had the choice between, or for quite a while anyway,
you had the choice between the virtual appliance or deploying it on Windows.
Now it's just a virtual appliance, and migrating away from a Windows version of the vCenter to the virtual appliance
version is not super difficult, but it is a process.
There are steps involved, and we'll discuss that as we go forward.
So when we do a vSphere upgrade, meaning we're going to upgrade from one version of, you know, vSphere to another.
So we are on 7, and we want to go to 8, for example.
We do more than just upgrade vCenter, but the first thing we're going to upgrade is we're going to upgrade vCenter.
After we've upgraded vCenter, then we're going to upgrade our ESXi host.
After we've upgraded our ESXi host, then we can upgrade the VMs, meaning the virtual hardware on the VMs
that they're running, and then we can upgrade VMware tools.
You don't want to upgrade out of that order, okay?
You don't want to start up trying to upgrade your ESXi host before vCenter because the new host,
the newer version of the host, aren't going to work with an old version of vCenter.
You need to have the most current version of vCenter, which works with older hosts.
Then you can upgrade your older host to the current version that matches your vCenter.
Then we can upgrade the VMs virtual hardware because now the new ESXi host can understand that new virtual hardware.
Then we can upgrade the VMware tools because that will give us all that additional functionality then.
So that's the order you need to make sure you do that.
If you're going to do an upgrade in your environment, okay, we're on 7 and 8's out.
We want to upgrade to 8.
First, you do vCenter.
Then you do your hosts.
Then you do your VMs virtual hardware.
Then you do your VMware tools.
It's very important you do them in that order, vCenter first, hosts second.
Now, what can we upgrade from and to?
We can go from 6.5 or 6.7 to 7, and we can go from 7 to 8.
We can't go from 6.7 straight to 8.
If we are on 6.5 or 6.7 and we want to go to 8, we have to do a multi-hop upgrade.
We need to go to 7.
Then we can go to 8.
You're going to have to do your upgrade twice in that scenario.
Now, if you're on an older 6.7 vCenter, actually you're going to have several different pieces.
You're going to have the vCenter server service.
You're going to have the PSC, which is how you do your authentication and things like that,
your platform service controller.
And then you're going to have, of course, the operating system,
which is going to be Linux on the virtual appliance.
When we're done, we're going to have vCenter.
vCenter is going to include all the components.
If we go back to 5, 5 could be broken out into as many as I believe it was like six different virtual machines.
And so all these different services could be broken out into all these different virtual machines spread out,
and then we had to tie them all together.
It was very complicated.
And you could put them all down onto one, but you would often see people trying to get fancy
and put them in different ones, and you'd get corruption, and it was a huge, huge mess.
VMware consolidated that down, so now it's only two pieces.
And then with 7, now it's only one piece.
And 8, it's one.
It's one vCenter.
And vCenter runs all the different services,
and we no longer have an external single sign-on component that we need to try and manage separately
and things like that.
It's all integrated into it.
We have a single sign-on module, but it's an internal.
We don't have the external one that you could deploy separately.
So upgrades, what will you need?
So obviously if you're going to upgrade from 6, 7, you'll have your platform service controller, right,
where you need to upgrade that.
We're going to upgrade the vCenter server appliance itself,
and verification the system meets the minimum requirements for updating.
So, again, if we're going from 6, 7, we're not going to go to 8, right?
Going from 6, 7, we're going to go to 7, and then 7, we're going to go to 8.
All right.
So when you install, you can install two different ways.
You can upgrade two different ways.
You can do it from the GUI, or you can do it from the CLI.
You might do it from the CLI if you wanted to, like, automate this.
You don't want to sit there and click next, next, next.
If you're doing one, if you have one vCenter in your environment,
you're probably just going to go through the GUI and just, you know, answer the questions and go through it.
It's not really worth it to create a long customization answer file or script.
And if you're not going to do that, there's not a lot of reason to do it from the CLI.
You could.
But most of the time, you do it from the CLI because you want to automate things, right?
You could go through the CLI and, you know, but usually if you're only doing one,
you're going to do the GUI, and you're just going to answer the questions along the way.
If I have a huge infrastructure, and my huge infrastructure has a lot of vCenter servers,
and I want to automate the process of updating all these different vCenter servers
in this big infrastructure I have, then we might look at using the CLI
and creating some answer files and scripting the upgrade process.
But for one, maybe two, you probably aren't going to do that.
So upgrade the vCenter server appliance, right?
Does the equipment meet the upgrade requirements?
So do we have the right hardware and things like that in place to do this upgrade?
Prepare your network for the upgrade.
Firewall ports.
We'll go over just a moment all the different services that vCenter uses,
and we want to make sure if we have a network that's segmented
and we only allow a zero-trust communication through,
so we only allow just the ports needed,
then we'll need to make sure we have all the right ports open,
and we'll go over those in a moment.
Upgrade or migrate the appliance in the GUI or the CLI.
How are we going to do that?
So probably you're going to go to the GUI most of the time.
Most people do from the GUI.
You'll go to the wizard.
It'll be a couple-of-step process, and then you'll be finished
and you'll do your post-upgrade work and you'll be all done.
So here we're looking at some hardware requirements, right?
So if we need a small, tiny environment, like we have no more than 10 hosts
and no more than 100 VMs, so this is probably maybe a lab or something like that,
or maybe it's a small business running it.
Minimum hardware, two virtual CPUs, 12 gigs of RAM.
That kind of is really like the minimum you want on that environment.
Small, 100 hosts and 1,000 VMs.
For some of you that might not seem that small,
but for a big enterprise that would be obviously considered small.
Four virtual CPUs, 19 gigs of RAM.
Medium, 404,000, so eight virtual CPUs, 128 gigs of RAM.
You kind of see as we go through here, we end with 2,000 hosts, 35,000 VMs.
We need 24 virtual CPUs and 56 gigs of RAM.
So that starts to get – I mean, the 24 CPUs is more daunting
than the 56 gigs of RAM part is for a lot of people.
That's an extra-large environment.
Now, what if you need more than 2,000 hosts?
What if you have more than 35,000 VMs?
Then what you're going to need to do is deploy another vCenter server
and you'll use them in linked mode probably.
For storage, for tiny, the default is 415 gigabytes.
Now, do we want to do an environment where we have a small –
it's a small appliance, but we want a large amount of space
or an extra-large amount of space?
We want to do a lot of logging.
We're doing a small appliance, we want to do a lot of logging.
Then you might want to start incrementing the amount of disk space you're using.
As you can see, we could go as high as an extra-large,
which requires the default 1,805 gigabytes of disk space.
But if we want to log additional, we might go into 1905
all the way up to 3,665 gigs of space.
That means we're going to be storing a lot of logs.
If you're doing a lot of logging and you think you might need a lot of disk space,
you probably want a syslog server to help gather that and sort through
and make sense of it and create alerts for you and things like that.
You're storing a huge amount of log information for not a lot of reason.
Software.
Again, you can run it from the GUI or the CLI.
You can run it from Windows, Linux, or a Mac.
And here it shows you if you're running on Linux,
the different versions of Linux that are supported
and the minimum hardware.
Windows, if you want to run it from Windows,
here's a version of Windows, Windows 8, 8.1, 10,
the different versions of Windows Server, 2012, 16, 19,
and then the minimum hardware for that Windows box to run the installer,
and then it has all the Mac information, too.
So pretty minimal, right?
It supports most versions of Windows that you'll see out there in the field
nowadays, and the hardware requirements aren't that much.
The installer's not super heavy duty.
A lot of the work, once it gets started deploying,
the actual work's done on the host.
That's actually creating the virtual appliance
and running the virtual appliance, not the virtual machine
that's pushing out the installer.
So here we're seeing the network ports, right?
So, for example, you probably want to have SSH access, which is port 22.
DNS access, which is going to be UDP-53 for queries,
and if you're doing some kind of DNS replication, that's TCP,
but the ESXi host will be doing queries, so UDP port 53.
AD for HTTP, 88 for active directory servers for authentication.
And we can kind of go down this line, LDAP, HTTPS,
are we using syslog servers?
Usually it's considered a good idea.
RPC, remote procedure call ports, all the way through to the vSphere client
uses HTTPS on port 9443.
So all these ports are going to need to be configured to allow for your
firewall if you are, you know, segmenting your network
in a zero-trust type environment.
If you're not, if you just have simple routing and everything's wide open,
then these ports won't be as important for you to know.
So DNS is required, okay?
So when you go to deploy vCenter, the vCenter server needs to be,
have its name, whatever name you assign to the vCenter server
and whatever IP address you give the vCenter server need to be registered
with an A record in DNS.
So DNS needs to have that registered in there because the installer is going
to go through and query that and make sure it's there
and make sure it resolves properly.
And if it doesn't resolve properly, then the installation is going to fail.
So make sure that you do have, you know, records configured in DNS
that match the name you assigned the vCenter server
and the IP address you're going to give it.
So plan that in advance and make sure that's in DNS.
So, again, we need to have, you know, our A record that, you know,
resolves to an IPv4 address, right?
You can verify that using your NS lookup tool from the command line.
Clock synchronization.
You're going to see this come up multiple times in this lesson.
So clock synchronization is super important because authentication is going
to be super important, right?
So SSL certificates need to have, you know, the timing be within a few minutes.
SAML tokens need their timing to be within five minutes.
So both of them are going to be very time sensitive.
So clock synchronization is going to be very important.
So I would suggest that you use like an NTP server, use a time server,
and have everybody pointing to the same NTP server, right?
You might use a public one, like there's pool.ntp.org,
and that pool is actually a pool of NTP servers,
so there's not like one server that might fail on you.
That's usually a pretty safe option for you, okay?
If for some reason the dependencies fail,
then you might have to restart your update again.
And so here you'll see what happens if the FPXD service fails to start
because of clock synchronization not working,
you'll start your upgrade over again.
So here we're going to see how we can make sure our clocks are synchronized,
right?
So we're going to find the vCenter server.
So this is where we're going to do an upgrade.
We want to make sure that our old vCenter server clock is going to match
with, you know, what we're deploying to.
We can log into there as root.
We can select time, time zones, make sure we're in the correct time zone,
and we can also make sure if we're going to figure any kind of time
synchronization, we have NTP enabled, something like that,
and we can edit that and use whatever time server we want to use.
So for clock synchronization, we can select how we want to do it.
We can say none and hope that we get everything, you know,
in the right time and nothing slides.
You can synchronize with the host.
You can have the VMs synchronize with the host they're running on.
And then if your hosts are using NTP, the VMs should also then be in sync
because they'll sync with the clock on the host itself.
That's not a bad option.
It's not my preferred option.
I prefer to use NTP.
I want my host to point to NTP.
I want my domain controllers pointing to, you know, some kind of NTP.
I want my vCenter server pointing to an NTP server too.
And I do like to use an external NTP server personally.
So what's transferred?
When we're doing an upgrade, what gets transferred?
So we have this external database that contains all the vCenter server
information, right?
So we're going to dump all this information out of this progress database,
and it is a relational database, and it's used by vCenter 7,
and vCenter 8 is going to use the same one.
And we do this because we don't want to deploy a new vCenter server
and then have to reconfigure my clusters, my networking.
If I'm using, you know, distributed virtual, you know,
switching import groups and things like that,
I don't want to configure all this over again.
I want to keep all my logs.
I want to keep all my log file information.
I don't want to have to start over again and say,
I can only look back as far as, you know,
two weeks ago when I did the upgrade.
I want all my log information.
I want all my configuration information.
I want my matrix.
I want to make sure that I can go back and look at what was the CPU
utilization and memory utilization and disk utilization in my environment
going back, you know, six months ago, eight months ago, a year,
because I want to be able to see trends.
And if I have to start over again and then I can only see back two weeks,
I can only see a two-week trend, which doesn't really tell me much.
If I can look back over six months,
I might over six months see a gradual increase.
But if I look at only two weeks, it might look kind of flat.
But over a longer period of time,
I start to see that trend line easing its way up.
And I can say, okay, based on this, I know I need to look at, you know,
adding another host to my cluster by the end of the year
or something like that maybe.
So why did we do this?
To keep our configuration consistent, to keep our, you know,
obviously make it easier to do the upgrade, less overhead,
and so we can have historical information in our environment.
That's all super important to do, right?
So begin the update.
So we're going to download the ISO from VMware's website.
Once we've downloaded the ISO, we want to just do an MD5 hash check
and make sure that nothing has been corrupted during that download.
Make sure it's all, you know, first of all,
I got the golden image that VMware stamped and nothing's been changed on that.
Nothing got, you know, corrupted during the download.
I've got the bits that VMware wanted me to get, right?
Then I put that ISO someplace that I can mount.
I'm going to mount it on the machine that I'm running the upgrade from, right?
So if I'm going to run it from this Windows server VM,
I'm going to put it someplace where I can mount it onto that Windows VM
so I can go into Explorer on that Windows VM
and I can browse to the setup executable file.
So when I get ready to do the upgrade, I'm going to configure my hosts, right?
So on my vCenter server that I want to upgrade,
I'm going to check my configuration settings, all my general stuff like that.
I want to make sure that everything is, you know, configured the way I want it.
SSL settings, verify that vCenter server, right,
requires verified host SSL certificates.
So you want to make sure that you're using verified host certificates on this
deployment, otherwise you're going to have problems when you get into A.
Because A is going to require that.
Using the GUI, if we're running off of Windows, for example,
we're going to find the EXE, right?
There will be an installer EXE, and we want to execute that.
Now, what happens is that setup program is going to run,
and it does it in two phases.
There will be a phase one and a phase two.
And it's going to ask me a bunch of questions about deploying the OVA,
like what host I want to deploy to.
Am I going to deploy to a vCenter environment?
Am I going to deploy to an ESXi host?
It's going to want credentials and things like that,
and it's going to deploy the OVA.
So once the OVA is out there and running,
then the next step kicks in.
Okay, this completed successfully.
Step two will be actually the appliance setup.
And then I'll start getting into the more nitty-gritty of the actual vCenter
deployment, all right?
So one step is going to deploy the OVA and give some basic configuration on
there.
The next step is going to actually configure vCenter itself.
So when you start your wizard, the first thing it's going to do is, you know,
just give you all the options you're going to go through.
Here's the things you're going to do.
And it's going to ask you to accept the end-user license agreement.
So if you actually want to deploy this,
you're going to need to accept the end-user license agreement,
and you're going to say next, right?
This is going to ask you to connect to the source appliance.
So the source appliance is the machine you're upgrading, right?
We're going to upgrade this appliance.
So it's going to ask you for the server name.
If you're not using the standard default ports, you know,
what port are you using?
Your single sign-on credentials.
So it might be administrator at vSphere.local.
It might be something else if you configure something else.
If you're configuring deploying to a host directly,
then you'll like want root and whatever the root password information is.
And if you have a non-standard port for that, the port number, right?
The port credentials for the target machine,
the vCenter we're going to deploy to.
The target vCenter information, name and root password, right?
So root name, root probably, and password.
Deployment size, what size are we going to do?
Are we going to do a tiny, a medium, or a large?
Select your data store.
You want to pick something that is going to be basically accessible to the
different machines that are going to need to be running your vCenter
environment, right?
So you want to make sure you don't pick, like, a local data store
or something like that.
You want to make sure you pick shared storage.
And then thin provisioning.
Usually most people are going to want to provision their vCenter server
with thin provisioning because, by default, when you first deploy,
it only takes up, you know, 100 gigs, less than 100 gigs.
If you deploy it in full, it could take up, you know,
1,000 gigs and things like that, which is a bunch of zeros.
So usually you deploy that in a thin provisioning.
And then your network settings.
IP address.
Are we using IPv4, IPv6?
What IP address are we using?
What subnet mask are we using?
Default gateway DNS information.
And, again, make sure whenever DNS servers you configure here that the vCenter
name and IP address that you entered here are in that DNS server.
So we can query and we can resolve that vCenter's name
and IP address from those DNS servers.
So, again, using the GUI.
So we've deployed the vCenter server.
The virtual appliance is deployed, the VM.
So now we need to configure vCenter, right?
So now we're going to go through
and we're going to connect to the source vCenter server,
where it needs to be coming from, right?
We're going to select what data we want to upgrade.
And you probably want to upgrade as much as possible.
You want to pull as much as you can.
Do you want to join the customer experience program?
You can say if you want to join that or not.
And then you can say, you know, you're complete and all right.
You want to review these settings and you're going to say okay.
And once it starts the upgrade, it's going to start pulling over the information.
It's going to shut down the old vCenter during the process, right?
And then the new one should be up and running and live.
And then there will be some upgrade checks that it's going to run to make sure
that the upgrade process is going to complete successfully.
So it will attempt to predict if this is going to work
or not work before it gets too far along.
It will do some pre-upgrade checks.
You could do the CLI.
And why would you do that?
You have a little bit more control.
You can script it.
Really the why for most people is going to be I need to do a lot of vCenters,
and so I want to create answer files and just do tweets for the, you know,
individual settings and push that out.
If I'm only doing one or two, you know, a small number of vCenter servers,
most people only have one.
Maybe you have two or three.
Those are just easier a lot of times just to do it and not worry about
automating it and things like that and not do it from the CLI.
You can, when you, you know, part of a couple of the arguments you might do is
you want to accept the EULA because you don't want to get stuck on that.
And you can say you want to do a check only.
That one really might be one of the more common ones is that, okay,
we're going to plan on deploying this over the weekend,
but we want to make sure our answer files and things like that are all good.
So I just do a pre-check only
and make sure this migration is going to even be successful.
Right?
You can do that.
So post vCenter update.
So you'll verify the success that it worked.
Now, if you're going from, like, for example, 6.7,
we're going to want to go in.
We're going to log in to the FQDN, right?
We're going to connect to it.
Or we can use the IP address and go directly from there,
but hopefully your FQDN works and we're going to connect that way.
We're going to shut down.
If we have an external PSC for authentication,
we're going to shut that down.
Then we're going to remove it from the single sign-on domain,
and we're going to use the internal PCM and not the external one anymore.
So vSphere 8 only supports, or in the very near future,
will only support an internal.
So in 8, it's recommended we just cut off right away.
We don't want to get to a point to where we still have it,
and yet we can't log in to our new one.
So use only the internal PCA.
And you can see one of your options on your login screen will be to
download the enhanced authentication plug-in,
which will allow you to more easily use things like Windows credentials
or the internal PCA.
All right?
So post vCenter server updates, we're going to go through.
We can say, all right, we've done our vCenter update.
We're all good, so now what do we want to do?
We can say we want to configure single sign-on, right?
So we can say we want to go in and use AD authentication, right?
We're going to use AD with LDAP,
or we want to use integrated Windows authentication.
We've got to make sure we end up at a point to a Windows domain
controller that's going to join that Windows domain.
You can also use OpenLDAP 2.4 or later for a single data source for
authentication.
Maybe you have an environment where you don't have AD,
you don't have Windows, you don't run AD.
There are some of those out there,
and so you can just use an OpenLDAP database.
So migration, this is something for Windows.
We've been talking about doing an upgrade,
and most of these upgrades we've been discussing so far are going to be
from virtual clients to virtual clients.
So what if we have a Windows appliance that's running vCenter,
and we want to upgrade to the virtual appliance?
This is not quite as straightforward.
It is still pretty easy.
There's tools involved to make it easy,
but it's not as few steps as it was for going from virtual appliance to
virtual appliance, okay?
So if we have a vCenter for Windows,
we're going to need to convert that to a vCenter virtual appliance, right?
And then we can go through and upgrade for 7 there, right?
So we need the migration assistant.
What's required here is that migration assistant.
There's going to be a tool that's going to help us get the PSC,
the vCenter, all over to the virtual appliance.
If we are running update manager,
and we have update manager information,
then we'll also need to run it against our update manager,
because update manager used to be a separate component, right?
It wasn't integrated like it is now.
So we'll also migrate the update manager.
So now we're going to be on the new vCenter virtual appliance.
And this new vCenter virtual appliance is going to be one appliance that
runs both my vCenter information, my authentication information,
and my update manager all in that one virtual appliance.
And the migration assistant is going to help you get all those off those
Windows systems into that one virtual appliance now for the vCenter server.
So you can see here what we're talking about is we have a vCenter server,
right, running on Windows,
and we want to migrate that to a virtual appliance.
So we're going to run the migration assistant.
We're going to need to run it against the PSC,
which is our authentication or single-sign authentication database,
and we're going to need to run it against the vCenter server itself.
And both those will get migrated into the virtual appliance, the new VSCA.
And if we were running update manager, that as well.
Okay.
So verified permissions for vCenter server user accounts.
So if you're going to do a migration,
here are some of the permissions that your user account is going to have to
have in order to do that.
It's going to need to be in the admin group.
It's going to be able to log on as a service to run these different services
to migrate these things, can replace the process level token,
and act as part of the operating system.
Okay.
Another key piece of this migration is going to make sure that your PSC
and your vCenter server certificates are not expired.
All right.
Because you'll need to have current certificates for this process to work.
Of course, as we've mentioned,
this is going to be a big part of this whole lesson, time synchronization.
If you're using NTP, make sure that your NTP servers,
you know, are pointing to the same NTP server.
Our clocks are in sync.
We want to have SSL certificate valid.
And if our clocks are in sync, then our certification won't work.
Service accounts,
we need a local service account that has a read permission for both the vCenter
servers.
And a system work name.
Basically, we need to make sure that our systems are named and in DNS.
With static addresses, we do not want DHCP addresses.
We want to make sure that our hardware is compliant.
If our hardware is compliant,
we have the right amount of hardware deployed and available.
FQDNs registered in DNS.
Clock synchronization.
Again, we keep mentioning the clock synchronization.
For certificates, for migrating, you know, information back and forth,
making sure we authenticate properly,
clock synchronization is super important.
Make sure your clocks are synchronized.
Migration system requirements.
On the target.
So we've been discussing the source.
On the target, again, we see admin privileges.
Now, this one will need more than just read,
because this is the target we're going to be writing to.
So we need admin privileges on the other machine so we can get all the
information dumped into there.
We need to make sure we have enough storage for this virtual machine.
If we're bringing over a lot of, like, logs and things like that,
then we need to have enough room on the virtual disk and our physical
storage for all those logs to land onto.
Do we have enough CPU power to make all this happen?
Can the storage be accessed?
Obviously having enough storage also means can you access your storage,
right?
And then make sure our environment is all set.
Our hosts are ready, our data stores are ready,
our virtual appliance is all ready for all this stuff to come over to it.
Network.
Again, we keep talking about DNS.
DNS, super important.
Static address registered in DNS with the same name as the vCenter
appliance's name.
That's going to be really important.
If you're using DHCP for the virtual appliance,
you need to make sure that the host and the virtual appliance are on the
same network.
But, again, you're going to need to have, like,
DNS or you want your DHCP server to register the name for you in DNS.
It's strongly recommended just use static IPs.
You really don't want to be using DHCP.
You want to be using static IPs and have static IPs configured on all
these things for you.
So some things to be careful for during your migration, okay?
The source vCenter server you're migrating from is going to shut down,
right?
As part of the process,
we don't want both vCenters online trying to service at the same time.
We don't want to confuse our hosts and things like that.
So the source is going to shut down and the new one is going to take over.
So any solutions that are on that source will become unavailable.
During that migration, you'll need to add your solutions to the new one.
Network ID conflicts with the target.
You don't want IP address conflicts and things like that.
That can cause a huge problem, right?
So make sure that we don't have both running at the same time.
Network adapters, only one adapter is going to be migrated.
If your vCenter has multiple adapters on there,
only one adapter setting gets migrated,
one name gets registered from the DHCP and the IP and things like that.
Only one adapter setting will get migrated.
Preparing for this update,
if you are going from the physical environment,
Windows VM or physical to the virtual appliance,
then you're going to need to run that VMware Migration Assistant.
So you do a lot of the same steps,
but one of the first things you're going to do is you're going to run the
VMware Migration Assistant, okay?
So the Migration Assistant is going to help you go through and it runs your
prechecks and gives you some reporting information.
But one of the big things is it's going to migrate that PSC and the virtual
appliance information to the new virtual appliance, okay?
So you'll still deploy your virtual appliance,
but you're going to have your Migration Assistant help you get all the
information over from the Windows version of vCenter into the virtual
appliance version of vCenter.
So if we're going to run the Migration Assistant,
so you can see here, again,
we're going to download the installer package for the new vCenter server,
and we're going to then, you know,
we're going to mount that onto a machine that we can run it from.
We're going to go to the folder from our – they say the source machine,
they mean the source for the ISOs,
our machine that's going to be running the upgrade wizard,
the deployment wizard, right?
And then we're going to go through,
browse through there to find the executable,
and then we're going to just run it and say we want to do an upgrade,
right?
So when they say the source machine here,
they're not talking about the source vCenter server.
They're talking about where we're running the installer from.
So if we're running from a Windows machine, the installer,
we mounted the ISO on the Windows box.
We're going to browse through the ISO to our CD-ROM drive on the Windows VM.
We're going to find the executable for the migration tool.
Good idea to run a pre-check just to make sure we're not going to have any
issues with the upgrade process, right?
And then we'll go through and we'll run through there, all right?
So we're going to then, again,
after you go through the whole migration part of it, the system,
it will go through, it will deploy the OVA, right?
We'll select our migration.
Instead of saying we want to do an update, we want to do a migration.
And then we follow along the same prompts we would normally.
And we have a migration tool that's going to help us migrate the PSC,
the vCenter appliance, and if we have update manager, update manager.
So some known issues.
Upgrading vCenter server can cause issues with Lifecycle Manager.
So if you are running an older version of Lifecycle Manager and then you do
this upgrading and Lifecycle Manager is not working for you, all you need to do
is reset the Lifecycle Manager database and let it kind of re-download its
files and repopulate that.
So we're going to go to the vCenter shell.
So we're going to go to the actual virtual appliance shell CLI.
And we're going to go in and we're going to stop the VMware update manager.
So you can see service dash control dash dash stop.
And what do we want to stop?
The update manager.
Then we're going to browse through and we're going to reset the database.
And it tells you there's a command right there for resetting the database.
Then we're going to remove any patches in the patch store.
So the R means remove.
And R is recursive.
And just want to push through everything that's in that.
The star means everything in that folder.
Then once we delete everything in the folder,
we're going to restart the VMware update manager.
We'll re-log in, authenticate,
and it should just download all the new updates and start over again from
scratch.
But it'll start over with a new database and the new files with version 8,
with the new version of vCenter you're running.
And that should take care of any problems that you have with migrating that
database over.
So we discussed the vCSA upgrade process.
You went over an overview, over your requirements,
post-configuration steps, and the migration.
If you have any questions,
please feel free to reach out to me.