Solved

Moving SQL VM from ESXi to AHV

  • 5 April 2019
  • 6 replies
  • 2152 views
L
We have a couple production SQL servers on our ESXi Cluster that need be transitioned to our new Nutanix Cluster. Nutanix Best Practices indicates that the SQL servers should be created new on the Nutanix Cluster instead of doing a VM move from ESXi to AHV.

I am aware that Nutanix had Xtract Db for awhile that was supposed to make moving a SQL instance possible but they have since discontinued the product. I must assume they had issues with it.

My question is what are the technical implications of using Nutanix Move to "move" the SQL VM from ESXi to AHV? I have used the tool to move a number of non-SQL VMs without any issues. Knowing that the underlying Hyper-visor components are changing and the VirtIO drivers must be installed before the move and then NGT installed after the move, what might the issue be that discourages or prevents a SQL VM cross-hyper-visor move?

The SQL version is 2016 Standard with no mirroring or Always on Availability. Just standalone SQL. We have about 10 databases within a single Instance and many jobs. Instance size is several hundred GBs of data and logs.
icon

Best answer by jlaunier 8 April 2019, 18:29

@limin , It depends on your SQL Server. Move can't migrate multi-writer VMDKs or any VMs with pRDMs. So migration of SQL clusters using Move is almost guaranteed to be problematic. If your SQL instance is standalone and not relying on any disks exposed directly to the OS, pRDM/iscsi LUNs, Move should be able to migrate it. Your point is valid though. The other key reason we do not recommend this is that Move is a like for like migration. It doesn't take into account disk layout changes or other BPs that we recommend for databases. So yes, it can be used for restricted SQL Server migration use cases but is not a good idea for most scenarios.
View original
This topic has been closed for comments

6 replies

aluciani
Userlevel 7
Badge +35
Hi @limin

I think @jlaunier can help share some insight here
Follow me on Twitter: https://twitter.com/AngeloLuciani
L
Yes, I read that thread before my original post. All that is really indicated in regards to using Move to migrate SQL is that it doesn't allow for SQL design changes. Such as proper use of virtual disks, Files, etc. But really that has nothing to do with a straight V2V move.

This has all lead me to believe there is no real technical issues in using Move to perform a SQL move from ESXi to AHV. And that Nutanix feels so strongly about the proper design of a SQL server that they will not comment on the feasibility of using MOVE to perform a straight V2V migration. IMHO that is sad. I should also say that I have reached out to Nutanix support for input on this question and was given a an answer of " follow best practices". I wasn't asked whether or not our SQL server was already designed following best practices. An Engineer giving an answer like that with no reasoning behind it is no help at all.

Love my Nutanix Cluster, but frustrated with lack of solid product usage answers.
J
Rank
Userlevel 3
Badge +11
@limin , It depends on your SQL Server. Move can't migrate multi-writer VMDKs or any VMs with pRDMs. So migration of SQL clusters using Move is almost guaranteed to be problematic. If your SQL instance is standalone and not relying on any disks exposed directly to the OS, pRDM/iscsi LUNs, Move should be able to migrate it. Your point is valid though. The other key reason we do not recommend this is that Move is a like for like migration. It doesn't take into account disk layout changes or other BPs that we recommend for databases. So yes, it can be used for restricted SQL Server migration use cases but is not a good idea for most scenarios.
L
@jlaunier This is the kind of info that is helpful. Our SQL Servers do not have any disks exposed, etc. There may be an issue with performance though on the Nutanix platform but I don't know. Maybe you can shine some light on it.

I have read that their is a single OPLog per virtual disk which is one reason to implement multiple disks. I don't fully understand OPLogs yet, but perhaps this poses a an issue for us. We have about 10 DBs within our instance. Some busier than others of course. The current implementation uses individual disks for logs, data, and temp. Nutanix BP suggests IIRC up to 8 virtual disks depending on situation. Our Nutanix cluster is a Hybrid 1465 G6 with 1.92GBs SSD on each node. If I understand the OPLog function correctly, having a single data disk for all the Dbs could be a contention problem.

With Move we could transfer to the Nutanix cluster and if needed add virtual disks where needed and move some of the DBs to them.

We are under a real time crunch to get the SQL servers moved off of the existing platform to the new Nutanix cluster. So I am weighing the time for a "build from scratch" vs. a Move with possible modifications afterwards.
B
Badge
Was this answered???
i too was told to believe that we can move our VMs (application, SQL and Exchange) from ESXi to AHV using MOVE. Now I am not sure. So I am faced with keeping VMware and not AHV with added costs each year. This was one of the selling points and or Nutanix sales manager knew this but never disclosed the possible issue.
it really comes down to this, can Nutanix migrate our existing SQL servers in their entirety from ESXi to AHV???
J
Rank
Userlevel 3
Badge +11
@Bmcgrath as I mentioned above, Move can be used to migrate DB VMs as well as Exchange VMs to AHV as long as you aren't using pRDMs or multi-writer VMDKs as a part of a Microsoft failover cluster. We recommend that for these types of applications that you apply disk layout best practices after migration. In the case of SQL server, even a relatively straight forward backup/restore still results in the original disk layout of the source DB server, so whether you use Move or not, you will still want to add the needed number of disks per our best practices and then re-balance your data via db shrink operations after the migration. For Exchange it is a bit more nuanced. While it may be possible to use Move, it may be more practical to build a new Exchange server and then migrate at the mailbox level over to the new server.