We currently have an old environment that needs to get upgraded, not just vmware but also hardware, and looking at best practice for this.
Vcenter running 5.5.0, 2183111 (enterprise plus license) inside Windows 2008 R2 (guest VM)
5 hosts in a cluster are running ESXi 5.5.0, 2302651 (Dell R710)
1 host outside the cluster but under same vcenter running ESXi 5.1.0, 1065491 (Dell R805)
The R805 has a couple of guests running on local drives. The rest all attached to an iSCSI SAN. We are replacing the hardware with 4x Dell R740 and at this point looking to upgrade to 6.5. Several guests are production so can't really have any down time. I do understand that the guests in the R805 would have to go down since they are not part of the cluster in order to move them into the cluster and SAN (or at least when I tried, that's what it said).
Was suggested at one point was to create a completely new Cluster and Vcenter on the new servers, and then migrate the guest VMs from one cluster to the other one. But not sure if this can be done while the guests are running. Networking is just vSwitches.
Otherwise, I know that the 5.1 host cannot go straight to 6.5. Since that has a couple of VMs only, we thought of moving them to another host and inside the cluster. Then we would decommission the old host, and start an upgrade from 5.5 to 6.5. We would upgrade Vcenter and then bring one of the new R740 into the cluster, move VMs to it, then continue bringing in the new hosts and decommissioning the old ones (don't have physical space to add all new hosts at once) and we may need to reuse IP addresses.
Any pointers as to which is better? TIA.
Welcome to the Community,
I'd prefer the last mentioned option:
Thanks - can someone clarify the following? It seems like moving live VMs between two vcenters is only supported on 6.0 or above. So I don't think I would be able to create a new vcenter and move the vms from the 5.5 cluster, right?
Looks like upgrading vcenter and then deploying the new individual hosts is my only option?
If you install/migrate your 5.5 vCenter to a 6.5 VCSA you can manage the old hosts as well as the new R740 (assumed you install/ordered them with 6.5)
BUUUUUUTTT.... the R805 is a AMD based Hosts and the R710 and your shiny new R740 are Intel based, so no vMotion from the AMD to Intel which means you need a downtime for migrations.
A vMotion from the R710 to new R740 is only possible with the help of EVC on the Cluster or both Cluster(old and new). For a migration maybe ok............. but i highly suggest after you remove all old hosts to lift the EVC up to Sklylake/CascadeLake and than shutdown and restart one VM (not GuestOS!) after another. Otherwise your VMs will see the CPU featureset from 10 years ago.
I'm aware of the R805. That one will be removed from the cluster prior to any of this - just 2 guests to move.
Now, I see that the R710s are not compatible with 6.5. And the R740 came with 6.7 installed, so will need to install 6.5 on it first.
My understanding is that vcenter will be upgraded first to 6.5 (into a new appliance) but will be running inside the cluster in one of the old R710, right? So basically I need to do:
a) Install 6.5 on new R740
b) Upgrade vcenter to 6.5 (will use embedded PSC)
c) Add new R740 to new cluster, storage, etc
d) Move test VMs to new cluster
e) Reboot test VMs
f) Move vcenter to new cluster
g) Vacate VMs from one R710 and remove form old cluster
h) Add new R740 to new cluster
i) Move remaining VMs and reboot when possible
Blame it all on Covid - vm admin position frozen, windows admin furloughed. Did one host upgrade many many years ago. At least I know what rm -rf and format c: can do. TIA.
Sounds ok, except for the VM reboots. In order to make the VMs aware of the new CPU features, you need to power cycle the VMs, i.e. shut down+power on. A simple reboot is not sufficient.
Regarding the EVC mode for the new cluster. It should work to select the highest possible EVC mode for the new cluster. Life migration (vMotion) from the current cluster to the new one should still work, since the powered on VMs currently have less CPU features than available.