I've had to convert serveral SQL clusters into VMs. Unfortunately, it is not possible to do a P2V on a cluster node. At least not that I ever found. It ended up being a fresh build. This can be a major problem; however, it can be a blessing since it could enable a fresh server.
Are you looking at taking a physical cluster and making a new VM cluster? In our environment, we were using clustering to protect against server failure. With HA, that issue goes away. So we actually converted all of our clusters into non-clustered VMs. Your host dies, it's restarted automatically on the other host. This doesn't protect against guest software issues, but that's not what we were clustering for. Do you really need to cluster in a VM? Something to consider.
Another quick question. The Vmware SQL Clustering KB article says:
vSphere MSCS Setup Limitations
Before you set up MSCS, review the list of functionality that is not supported for this release, and any
requirements and recommendations that apply to your configuration.
The following environments and functionality are not supported for MSCS setups with this release of vSphere:
n Clustering on iSCSI, FCoE, and NFS disks.
n Mixed environments, such as configurations where one cluster node is running a different version of ESX/
ESXi than another cluster node.
n Use of MSCS in conjunction with VMware Fault Tolerance.
n Migration with VMotion of clustered virtual machines.
n N-Port ID Virtualization (NPIV)
n With native multipathing (NMP), clustering is not supported when the path policy is set to round robin.
n You must use hardware version 7 with ESX/ESXi 4.0.
Can you not do clustering if your shared storage is iSCSI ? or can you not do RAW mapping with it to create the cluster ?
Ya the whole reason for the psyhical server cluster was for failover as the it coudln't be down for any long period of time as it runs mots of are line of business applications. So i'm thinking that is the best way to go and just create a new SQL server with HA and migrate the databases over
Any other thoughts ?
1 person found this helpful
The other option is to create another node that is virtual and simply migrate the cluster completely to the new VM and then remove the physical nodes. SQL will run "clustered" with just one node. I think it will complain though. Plus it leaves you the option to add another node in the future if desired.
If you wanted to eliminate the SAN disk and use VMDK on VMFS or NFS then simply add those disks separately to the VM, shut the cluster down, add them into the cluster and migrate databases/logs to the new disks and when all moved over, remove the mapping for the SAN disk.
Recently we have done P2V of SQL Cluster node. We just need to take care of disk signatures and proper disk assignemnt from storage and VMware.
I would avoid running it as a clustered node, unless you really require clustering for OS level redundancy. For clustering to work (even with a single node), you have to enable SCSI bus sharing and that prevents vMotion for the VM. That means that you will have to take an outage of your VM each time you need to do maintenance on the host.
For the metro cluster environment os level clustring will avoid HA restart times. Services will failover to another node so only service failover window required.
For this specific environment ,we are using EMC vplex metro cluster(virtual storage). distributed volume is maintaining data consistency between sites.