Oncommand Shift conversion

[#1]

I am having trouble with the volumes and mount points with the OnCommand Shift tool. We are using VMM and to the best of my knowledge we have to use SMI-S to attach our SMB3 shares to the Hyper-v environment. What I have seen from SMI-S is it attaches to the volume and then creates a qtree with a quota and then makes the qtree, not the volume, available to VMM.

We currently have VMware on the same cDOT filer that we will be migrating Hyper-v to.   Since we are already on Netapp disk, we are attempting the Shift conversion by storage vmotion form the VMware SVM to the hyper-v SVM and then running the conversion. We are not using a 3rd SVM as a go between.

Where I have my lack of understanding is in the volume selection for the conversion process. In VMware the path /hyperv_2010/hv_2012/<vm-hostname>, the nfs mapping is HVSVM:/hyperv_2012. On the Hyper-v SMV the SMB map is the qtree \\hyperv_2012\hv_2012 . When we do a conversion we have to specify the volume /hyperv_2012, not the mapped qtree hv_2012 or the conversion will fail. The conversion process places the VM hard drive in the root of /hyperv_2012. Hyperv_2012 is not a registered in VMM so Hyper-v will not start the VM.

How do I get Shift to keep the VM in the same structure as the VMware?

[#2]

Hello,

When you say "When we do a conversion we have to specify the volume /hyperv_2012, not the mapped qtree hv_2012 or the conversion will fail.", do you mean this path is given as the Destination path in Shift settings (where the converted VMs must reside) ? If So then you can always specify the qtree path for the destination path as "/hyperv_2012/hv_2012" (that is /volume/qtree). There is no restriction for the path, the only requirement is that the NFS share(where the ESX VMs reside) and the SMB Share(where the converted Hyper-V VMs reside) must be on the same SVM. 

If this doesn't solve your problem, then please provide details about the conversion failure error.

Thanks,

Shashanka

[#3]

Thank you for responding, Hyper-v is still very new to us.  I will attempt to clarify the mount points and mappings.  All storage is in the same cDOT cluster.

I will be switching volume names to hv_2008.  The base issue is still the same but with the hv_2012 conversion we received different errors that would complicate and distract from this issue.

VMware there are no qtrees in the VMware environment, all mount points are to volumes.
SVM_VM:/vm_2008       /vm_2008 -- All VMware vm’s are in there own directories.

Hyper-v    mapping is a qtree created by VMM, we are using SMI-S provider to connect to VMM to create shares and mappings
\\SVM_HV\hv_2008  -- hv_2008 is a qtree on the filere /hyperv_2008/hv_2008

VMware to Hyper-v target, in the VMWare environment, both environments see the same path, hv_2008
SVM_VM:/hyperv_2008/vm_2008      /hv_2008  - (this may be the issue, I will attempt the mapping directly to the qtree not the /vol/qtree)

In VMware we storage vmotion the vm to the shared mapping /hv_2008

Conversion:
If we set the “Hyper-V destination path” to \\SVM_HV\hv_2008\ or to /hv_2008 we get this error message

This is a direct copy of the logs:

Error Description    : ONTAP_DEST_PATH_INVALID
Error Reason         : The destination path //SVM_HV/hv_2008/ is not on the same volume of the source VM (/hyperv_2008).
Error Fix            : Correct the destination path on the ONTAP configuration and re-run again.

VMmigration succeeded when we changed the “Hyper-V destination path” to /hyperv_2008.  However the VM guest did not start because it was on a file system that is not registered with VMM

This is a copy of the VMM error:

Error (13932)
The file \\SVM_HV\hyperv_2008\hyperv-w2k8ent-test\hyperv-w2k8ent-test.vhdx is in a share which is not registered to the cluster cDOT.co.local.

Recommended Action
Register the share to the cluster, and then try the operation again.

[#4]

Hi,

There is a confusion in the mount points you have mentioned.

For VMware its mentioned SVM_VM and for Hyper-V its mentioned SVM_HV.

Please make sure you have only 1 SVM, and have only 1 volume inside that SVM. And inside this volume both the NFS and SMB shares must reside. The path doesn't matter as long as you have both the shares on the same volume of a same SVM.

While giving the path for destination path(to store the converted VMs), in your case it must be the SMB share. Please provide the full path, not just the volume or just the qtree. It must be as /vol/sMB_Share.

The error you have mentioned clearly states that the source VMs are residing on an NFS share which is on a diffrenet volume, and you have given the destination path as the different volume. So please make sure both NFS and SMB shares reside on the same volume.

Thanks,

Shashanka

[#5 · Accepted solution]

Interesting, it seems I am having difficulty verbalizing the configuration in a manner that is understood. Let me try again. I have 2 Storage Virtual Machine’s one that is connected to the VMware environment SVM_VM, which is only NFS. I have another connected to the Hyper-V environment; SVM_HV, which has a CIFS only LIF and an NFS only LIF and who’s volume is NTFS security style. All VMware VM’s that are to be migrated are first moved, via storage vmotion, to the Hyper-V NTFS volume. The Shift conversion is performed in the final Hyper-V destination. Since I have restated this, we recreated more test VM’s and ran the test Shift migration again and it was successful without changing any of the Netapp structure. I am at a loss as to why the last two previous tests failed, the failed VM test data structure was delete before I could do an analyses. So it appears that that issue went away, I appreciate your time and attention to this issue.