On this step we will validate the cluster configuration and will start a SQL Server instance. If sql server service failed to start, use the roll-back section below in the document to move back to on-premises.

Step 1. Power on the migrated VM

Step 2. Connect to the cluster

Step 3. Start the windows cluster

Step 4. Check shared disks

Step 5. Check SQL Server clustered Role

Step 6. Check the application connection to the database

Step 1. Power on the VM migrated to SDDC (“SQL-DB1Node01”). The second and all consecutive VMs (“SQL-DB1Node02, 03” located on-premises) *must be* powered off.

Step 2. Login to the Windows OS, start the Failover Cluster Manager Console. Connect to the cluster. For clusters having more than two nodes it’s expected for the cluster status to be down (due to the cluster votes violation).

Step 3. Start the cluster. Use this procedure to force start cluster if required (depending on the number of nodes and the cluster voting configuration). If it’s undesirable to use the “Force Cluster Start”, you can migrate the remaining nodes of the cluster, but it will make the roll-back (if required) more complicated.

Step 4. Navigate to the Storage-- Disks section. Check the status of shared disks now located on a vSAN datastore on VMware Cloud on AWS

The following warnings for Physical Disk Resource are expected as the underlying physical disk has been changed:

Step 5. Navigate to the Role section. Check if the SQL Server role is online. Investigate any failures if the role is in the offline state. Prevent users to connect to the SQL Server Instance at this point.

Step 6. Check application consistency. If any issues found: do not proceed with the migration of other nodes of the cluster and use the Roll back procedure to move back to on-premises.

check-circle-line exclamation-circle-line close-line
Scroll to top icon