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.