StarWind Software

I'm using the V2V_Converter.exe (v9.0.1.509) to test migrate some VMs from ESXi to HyperV. Our HyperV cluster is using all CIFS shares for our Vms and not iSCSI CSVs, etc. The target HyperV hosts do not have very large local drives on them either.

I don't seem to be able to point to a CIFS share with this utility to have it converted into our HyperV with CIFS backed shares. It's forcing me to use actual local drives on the HyperV host. I've even tried to trick it with mklink /d and with a SYSTEM level net use to make the drive letter show up to all users of the system, to get around login context issues. When I watch in ProcessMonitor, it looks like the application is calling out to WMI to do a local real disk enumeration and something similar when using a remote HyperV host. So, I'm guessing that enumeration is where the locally mapped drive letter is excluded and it's some how also able to ignore any directory links off server (even when running V2V from the same HyperV I'm converting to).

I would like to know how we can go about telling the GUI to convert a VM from ESXi to HyperV and to tell it to use a remote data store. I don't fully understand why a remote share is intentionally excluded in the gui? I can't even seemingly type in the UNC for it in the GUI. I'm guessing the place in the Path section where the ... is isn't an interactive text box and is fully populated from the drive\path chooser.

I know I can just attach an iSCSI mount to a single host, but I'd really rather not have to deal with that.

You need to make sure that the user that runs V2V in Hyper-V has privileges to write to that share.
It is actually a good workaround. Thanks for sharing it!

The user does have full rights as I'm running it as me. What I'm saying is the V2V UI does not give you the option to type in the UNC path in the path, nor will it show you the mounted drive Z:\ if I mounted as the system or even as myself. It also intentionally ignores mklink /d made directory links in the UI, even though I can see and follow them just fine in Windows Explorer.

So, it's not really a work around but me asking a question.

I discussed it with my colleague and you indeed cannot type the path, yet, you can select from the browser the FS mounted to your system as a disk or directory and convert the VM there.
It should be available in V2V's explorer.

For real local disks or iSCSI attached disks, yes, that's true. However, it does not show drive letters if they are UNC/CIFS shares mapped. It also seems to ignore and not display directoy symlinks. Please ask your colleague to verify this by mapping a drive letter to a cifs share then trying to use the ... button to choose it as a path. Additionally, you can use:
to create a local directory at c:\v2v-conversion on the machine you're running the V2V on, which actually points to the server, share and folder of \\cifs-server.domain.tld\cifstest\v2v-conversion and while you can see and browse that in Windows Explorer, you cannot see it in V2V converter. Even if you drop the link down a level, to something like c:\realfolder\v2v-conversion, you will only see c:\realfolder\ and inside it will be empty.

Which brings me back to the root of it, the V2V seems to be intentionally designed to only present to you real local disks or iSCSI attached (which show up as real local mostly). So I have to assume that whatever mechanism is in play here is filtering or querying something in registry or wmi where only actual disks drop into place.

Were you able to run conversion with CLI?

I have tried, but the help file on that isn't very helpful and the online page for it is also difficult to understand. I've read several threads where users have reported similar issues with trying to understand the command line structure. Most of our Vms have multiple disks and they're online, so I would be needing to try and convert a live VM from ESXi to HyperV but I'm not entirely sure how to put all of that together based on what I'm reading. I will try it again and see if I can make the command line work, but the first time around I couldn't even get it to properly convert to local disk, let alone over to a share.

Sorry for such a delay. I have logged an internal request for testing. Did you try converting with CLI?

No, I did not. The instructions for CLI are so ridiculously vague and hard to read, I'm not going to mess with that as most all of our VMs have multiple disks. If it doesn't work in GUI, then we'll just use another option.

May I wonder what exactly is confusing you? It's mora about typing tht paths right. Try converting an individual disk.

yaroslav (staff) wrote: ↑

Thu Dec 26, 2024 7:57 pm

May I wonder what exactly is confusing you? It's mora about typing tht paths right. Try converting an individual disk.

https://www.starwindsoftware.com/v2v-he ... rface.html

This doc, while somewhat helpful, is just strung together like copy/paste from code. There's not even a sample here for command line from VMware to Hyper-V. There is one the other way around, so I can reverse those options where needed -- but, in none of these samples does it show you how to handle VMs in the CLI that have multiple disks attached to them. They all revolve around single disk VMs.

What does your console command look like, as a sample, from a VMware host, to a HyperV host, named VM that has 3 or more disks attached to it? Are the in and out filename options numerically indexed? So it's like

in_file_name=
in_file_name2=
in_file_name3=
?

Thank you for your feedback.
The document outlines the syntax of the CLI-based conversion but does not provide the ready-to-go solution which the user is welcome to deduct/fit according to the task.
As for the multi-disk conversion, I do not think the script is intended to be used like that. This being said, I am not sure if indexing like
in_file_name=
in_file_name2=
in_file_name3=
will be helpful.
you can run parallel conversions (i.e., multiple cmd windows) where each in_file_name points to own file.

Deduction only works when the provided data is sane enough to make such assumptions. What is provided does not fit that criteria.

As to running multiple parallels, one per disk. That's incredibly archaic, to be honest. Why is it that the GUI handles a VM with multiple source disks, but the cli cannnot? Running in parallel like that is also a good way to make a triplicate copy of a VM unless you're just suggesting we manually recreate the VM and attach all these converted disks manually. If that's the case, then using this tool is a bit pointless to begin with as I'd just use other manual conversions that make me have to recreate the VM. The point of using a tool like this is it's supposed to be intuitive, robust and not require hours of reading and scripting to make it not have errors, VM boot issues, compilation issues where I have to hunt down a prior version of the EXE because the latest is messed up, etc.

I have submitted the request to add samples to the documentation. Thanks for your cooperation.