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.
Best answer by jlaunier
@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.