Moving Physical Cluster into Virtual Cluster RRS feed

  • Question

  • Hello All...........I have a Physical SQL Cluster 1 cluster1.domain.com (Node A and Node B) using SAN A.  Physical SQL Cluster contains three-3 instances.

    I have built a Hyper-V Failover Cluster and upon it I have also built a Guest/Virtual SQL Cluster 2 cluster2.domain.com (Node A and Node B) using SAN B.

    Now, I want to move the instance/databases from Physical SQL Cluster 1 cluster1.domain.com to Guest/Virtual SQL Cluster 2 cluster2.domain.com.  Is this supported?

    Or do I have to add the Virtual Nodes (NodeC and NodeD) to cluster1.domain.com and then failover the instances/database to new virtual nodes and then remove the Physical Nodes (NodeA and NodeB).

    Also, confused as to how would I manage the Storage as old Physical SQL Cluster cluster1.domain.com uses SAN A and I have new Virtual SQL Cluster cluster2.domain.com on SAN B.  Would I be requiring to change the instances/databases location as well?

    Any help on this would be appreciated.   

    Wednesday, December 3, 2014 8:36 PM

All replies

  • Hello All............I have a SQL Cluster based on Physical Hardware that has Three-3 instances as well.  I have setup a Hyper-V Failover Cluster (2012 R2) and have built Virtual/Guest SQL Cluster (2012 R2) upon it.  Now, I intend to move the instances/databases from Physical SQL Cluster to Virtual SQL Cluster.

    1.  Is this supported?  If so, I would appreciate any guidance on it?

    2.  Is P2V of SQL Cluster supported in Hyper-V Failover Cluster based on Windows Server 2012 R2?

    Wednesday, December 3, 2014 7:30 PM
  • Hello,

    There is a good bit of different things going on here so I'll try and make it short.

    Normally, it wouldn't be a problem to add in new nodes (virtual) to the current physical, install SQL Server, and eventually evict the physical nodes in order to migrate. However, you're using a different SAN for the storage. You could *still* do this, but you'd need to have SAN replication on the backend between the two and set it up very much like a 2008/R2 geo-cluster.

    The *easier* way, depending on clients, would be to either log-ship or mirror the databases to the new instances. When you have time to cutover, fail the mirrors to the new cluster and then remove mirroring. The clients would need to either be aliased or re-pointed. It could be done less cleanly by using a cname change for the old to the new but I'd stay away from that.


    The views, opinions, and posts do not reflect those of my company and are solely my own. No warranty, service, or results are expressed or implied.

    Thursday, December 4, 2014 3:45 AM
  • Thanks for the reply.

    If I have understood it correctly, I cannot move/migrate instance/databases from cluster1.domain.com to cluster2.domain.com as they would be separate clusters (unless I create geo cluster).  I would either be required to create virtual nodes in the cluster1.domain.com and then after failover, evict the physical nodes.  The above would not have been an issue had I not created cluster2.domain.com already and that too with a different SAN.  With cluster2.domain.com with different SAN already in place, I would need setup a Geo Cluster between cluster1.domain.com and cluster2.domain.com and process the migration.  Please, correct me if I have understood it wrong.

    The instances/databases that I am running on cluster1.domain.com include SCCM, SCOM, SharePoint, etc.  So, any limitations of those with Geo Clusters?

    Also, can you share any link to article/blog of step by step instructions to setup a Geo Cluster?  Thanks in advance.


    Thursday, December 4, 2014 5:49 AM
  • Hello,

    Yes, you've got it. The only thing missing is that I did say you can mirroring the databases between clusters and then migrate them at a good point.

    Here is the link: http://download.microsoft.com/download/5/B/D/5BD13FFA-5E34-4AE1-9AA0-C6E6951B8FC8/SQL%20Server%202008%20R2%20High%20Availability%20Architecture%20White%20Paper.docx

    It covers many different types of HA with SQL Server. Definitely worth the read.


    The views, opinions, and posts do not reflect those of my company and are solely my own. No warranty, service, or results are expressed or implied.

    Thursday, December 4, 2014 12:40 PM
  • Thanks for the reply.

    So, other than Geo Cluster, Database Mirroring can be a solution as well.  And for that, I would also require to create instances with the same name and then configure mirroring accordingly.  Please, correct me if I have understood it right.

    Thursday, December 4, 2014 2:14 PM
  • Mirroring can definitely be used. You don't need instances with the same name, you can mirror from any server (assuming pre-reqs met) to any other server. In this case you *could* mirror between the two clusters without changing anything. I'm not sure how your disk is setup, so you may have different paths for the files, in which case you'll want to be aware of this.

    Please note that I am only suggesting to use mirroring to *migrate* the databases and to not leave it up indefinitely.


    The views, opinions, and posts do not reflect those of my company and are solely my own. No warranty, service, or results are expressed or implied.

    Thursday, December 4, 2014 2:27 PM
  • Thanks for the reply.

    But since my motive is to move instances/databases from one place (physical) to another (virtual), mirroring can only provide me connectivity between the two.  Or it would also allow me to move the cluster role instances as well?  Not entirely sure of that.

    Also, I am running databases from SCCM, SCOM and SharePoint, would not it cause problems if I do not have those instances at the virtual cluster?

    Also, what about the layman approach........Creating instances on the virtual cluster............taking backup at physical cluster..............restoring it to virtual cluster..............can this work too?  If it can work, I am clueless as to how I would point the applications to the new virtual cluster as both would have different names?

    Thursday, December 4, 2014 3:11 PM