When migrating your VMware environment to a new SAN or storage provider, edge cases often require special attention. One such case involves virtual machines with Raw Device Mapped (RDM) LUNs. This is usually done for VMs that require more storage than a typical vmware datastore can manage or, more typically, when Microsoft Cluster Services are needed to provide fault tolerance for an application, usually SQL Server.
This post walks through the steps required to migrate a two node SQL server cluster to new RDM storage on a different SAN.
The first step is to make full backups of the SQL data and the server in case a restore is needed. This example migration uses PRODSQL-01 as the primary SQL node and PRODSQL-02 as the secondary SQL node
Gracefully shutdown SQL
Open Cluster manager and Pause ⭢ Drain Roles on PRODSQL-02.
Click Roles ⭢ Choose SQL Server and right click and choose Stop Role.
At this point, all cluster disks should still be online and connected to PRODSQL-01. This is required for VMware standalone converter to capture the disks.
Start VMware Converter
Run VMware Converter as admin and click Convert Machine. In this case, converter is being run from the local machine being migrated, PRODSQL-01.
Enter the vCenter server and credentials.
Enter the name for the destination VM and choose the folder in VMware to place it.
Choose the datastore to place the VM.
Under options, click Edit in the ‘Data to copy’ section, click Advanced, and under Destination Disks, choose ‘Thin’ for all the disks.
Under ‘Networks’, click Edit and choose ‘VMXNET 3’ under the controller type.
Under ‘Advanced options’, click Edit. Be sure ‘Perform final synchronization’ and ‘Synchronize changes’ are checked, along with ‘Run synchronization after cloning’.
The Default options for Post-conversion are sufficient.
Click Next and then click Finish to start the clone process. Repeat this process for PRODSQL-02. This should run much more quickly due to the cluster disks not being attached. When both are complete, shutdown the existing SQL cluster servers.
Configure the newly created VMs
Under Storage Devices on any ESXi host that has the attached RDM LUN, take note of the Identifier.
Edit the settings for the cloned PRODSQL-01 and remove (but do not delete) the former RDM disks that have now been converted to VMDK files.
Open an SSH session to an ESXi host and navigate to the folder containing the PRODSQL-01 VM.
Create a folder and move the converted VMDK files to that folder to avoid conflict with the RDM VMDKs that will be created in the next step.
Next, use vmkfstools to create the RDM VMDK files from the converted VMDK files:
Once the VMDK files are cloned, edit the settings on PRODSQL-01 and PRDOSQL-02 and add the SCSI controllers. For SQL clusters, VMware recommends adding more than one controller and adding disks to different controllers to better distribute the I/O.
Change the SCSI controller type to ‘VMware Paravirtual’, then change the SCSI Bus Sharing to ‘Physical’ and click OK. With this setting, SQL cluster nodes can be located on any host. ‘Virtual’ restricts SQL cluster nodes to the same host.
Once both VMs have new SCSI controllers added, click Edit -> Add New Device -> Add Existing Disk. Then browse to the folder where the newly created RDM VMDK files are located and select a VMDK file.
Once added, set the ‘Virtual Device Node’ to the various VMware Paravirtual controllers that were added in a prior step.
Optional (Remove old missing network adapter)
Power-on the two nodes and on each, open a command prompt with admin privileges and type:
In Device Manager, click View ⭢ Show hidden devices.
Select the missing adapter and click Uninstall.
Click OK to delete the device.
Bring the cluster online
Open the Network Adapter properties and re-ip the Ethernet0 to match the old IP of the server.
Once both servers are given a correct IP, open Cluster Manager and verify both nodes are up.
Verify all cluster disks are up.
Start the SQL Server cluster role.
Once everything is up, test failover by changing ownership of the disk.
Test SQL failover by moving the SQL Role.
Finally, bring up applications that connect to the SQL cluster and begin application testing.
That’s it! If your organization has any additional questions around Migrating a VMware MS SQL Cluster with RDM Disks or around any other aspects of migrating your VMware environment, including any edge case situations, please don’t hesitate to reach out to us. We’d love to help you out.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
|cookielawinfo-checbox-analytics||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".|
|cookielawinfo-checbox-functional||11 months||The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".|
|cookielawinfo-checbox-others||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.|
|cookielawinfo-checkbox-necessary||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".|
|cookielawinfo-checkbox-performance||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".|
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.