When migrating a vCenter server to a new server or to a new hardware platform such as the vCenter appliance (VCSA), you should consider how your existing subclient content is configured and how the migration is performed.
To plan a migration, use the following method:
-
Determine the types of subclient content you have.
-
Choose a migration method that matches your resources and content.
-
Monitor backups after the migration is complete to verify that the migrated content is being backed up.
Subclient Configuration
On the Content properties tab for each subclient, you can include virtual machines by selecting them directly or by defining a rule that automatically discovers VMs.
-
Some entities are identified by a managed object reference that is defined in vCenter. These IDs will change if you move from one vCenter database to another. The following entities are identified using managed object references:
-
Datacenter
-
Cluster
-
Folder
-
Resource pool
-
vApp
-
-
Hosts and datastores are also stored using a managed object reference, but those entities can be found by their names if a managed object reference is not valid.
-
Virtual machines can be selected by browsing or by creating a rule:
-
When a VM is selected by browsing, the UUID of the VM is stored instead of the managed object reference.
-
Rules that are defined for Template and Power State are attributes on a VM, and are not dependent on vCenter associations.
-
Rules that are defined for VM Name/Pattern, Guest DNS Hostname, or Guest OS discover virtual machines using search strings, so they are completely portable to a new server.
-
Tags, Notes and Custom Attributes are also search strings, but those values are stored in the vCenter database rather than being tied to the VM. Tags are stored in the vCenter inventory server.
-
Migration Method
When deploying a new server or a VCSA, you have the following options:
-
Migrate to an existing vCenter server.
If you migrate to an existing server, then all managed object references should be retained, along with custom attributes, notes, and tags.
-
Perform a totally new deployment.
If you perform a side-by-side migration by deploying a new vCenter server and re-associating hosts to it, then you need to recreate any of the content types that are mapped to managed object references. You need to recreate those objects in vCenter because (unlike VMs and datastores) they are not auto created or registered when a host is connected to a new vCenter server.
For either migration method, you should monitor backups after the migration to verify that they are protecting the content that they are expected to protect.
Monitoring Backups After Migration
You can use the following reports to review backups operations after you migrate a vCenter:
Changed Block Tracking (CBT) and Incremental Backups
If you use the same subclient to back up a virtual machine before and after the migration, then CBT should be valid regardless of the change in vCenter. The CBT information is stored on the datastore, so it is not affected by migration to a new vCenter. CBT should still be valid even if the host is changed as part of the migration, provided that the VM is migrated to the new host using a storage vMotion operation (which also migrates CBT information).
UUIDs and xxxx_1 Clients
When the instance UUID of a virtual machine changes, a duplicate Commvault client is created with a numeric suffix (such as '_1').
The VMX file for a virtual machine stores the instance UUID and the BIOS UUID for the VM, and these UUIDs should not be changed by a migration. After migration a VM should map to the same Commvault client and the migration should not create any '_1' clients.