StarWind Software

Hello StarWind Team,
I've discovered an inconsistent behavior with the V2V Converter CLI (version 772) when converting VMs with multiple disks from VMware ESXi to Hyper-V.
Problem Description:
When converting a VM with multiple disks using out_file_type=ft_vhdx_growable, the conversion creates inconsistent disk allocation types:

Boot disk (first disk): Created as thin/dynamic VHD
Additional disks (data disks): Created as thick/fixed VHDX

Test Results:
I've confirmed that single file conversions work correctly:

out_file_type=ft_vhdx_growable → Creates thin disk ✓
out_file_type=ft_vhdx_pre_allocated → Creates thick disk ✓

However, VM conversions (using in_vm_name=) show this mixed behavior.

Additional Observations:

• The boot disk is also created with different characteristics:

Boot disk: VHD format on IDE controller
Data disks: VHDX format on SCSI controllers

• These are VMs running Windows server OS
• V2V converter is creating a VM with multiple disks on the Hyper-V node perfectly. It boots up just fine. The disks are in the correct order and have the correct drive letters too.

CLI Command Used:

V2V_ConverterConsole.exe convert
in_host_type=esx
in_host_address=[ESXi_HOST]
in_host_username=root
in_host_password=[PASSWORD]
in_vm_name=[VM_NAME]
out_host_type=win
out_host_address=[HYPER-V_HOST]
out_vm_name=[VM_NAME]
out_vm_path=[PATH]
out_file_type=ft_vhdx_growable

Questions:

1. Is this the expected behavior for multi-disk VM conversions?
2. Is there a parameter to ensure all disks follow the same allocation type?

I really cannot convert each disk individually as suggested in other forum posts because we have some DB VMs with lots of disks, some even have more than 10. It will become very difficult to identify and map those vhdx files in the correct order.

I noticed from previous forum discussions that the CLI may have limitations with multi-disk scenarios, but the parameter documentation suggests out_file_type should apply to all converted disks. This inconsistency creates storage efficiency issues in our environment where we specifically need thin provisioning for all disks.

Any guidance would be appreciated.

Thanks,
Raj


PS: The documentation page may need to be corrected. The file types seem to be wrong/deprecated.
https://www.starwindsoftware.com/v2v-he ... rface.html

Welcome to the StarWind forum, and thanks for sharing your observations. Could you please let me know what the source VM configuration is?

Boot disk: VHD format on IDE controller
Data disks: VHDX format on SCSI controllers

The resulting VM is GEN1, I believe, and the boot option for the source is set to BIOS.
These are expected.

Is there a parameter to ensure all disks follow the same allocation type?

I think no. Only if you convert individual disks.

Thanks for responding.

The source VMs are running on VMware 7
Hypervisor: VMware ESXi, 7.0.3, 24585291
VM OS: Windows Server 2019 and above.

We have lots of VMs with multiple drives but here is an example of a config

https://imgur.com/a/UEJuLo5

Hey,

Thanks for sharing. Can't see if they are thin/thick, though.
Can you please share this bit?

oh right. Sure: They are all thin.

We make all VM's disks thin here. That is why the VMs after conversion by SW need to be all thin also.

Greetings,

Thanks for sharing.
Yes, I saw that during other conversions. I will report it to devs.
Many thanks!

ok thanks for reporting to the devs. Of course, this will take time, and we are under pressure to migrate lots of VMs ASAP.

What would you suggest, as an alternative strategy for the CLI scripts or tool?

For large conversions, sadly, CLI will be the only option.
As a workaround, you could try converting individual disks and resuming the VM afterward.
Alternatively, if you have Veeam B&R installed, try using that solution.

Additional observation:

I just tried doing a multi disk VM conversion using the GUI version of V2V.
It made all the disks thin and the VM boots fine too in HV.

So if the GUI can do it, the CLI probably can do it too. Just its code needs to be fixed.

Thanks for walking an extra mile with this case. I appreciate your cooperation.
The devs vere informed about this one. Hoping to see the fix in the future builds.
Many thanks.

Do we have any update or feedback from the dev team about this?

Just looking to set my own expectations of timeline on a fix.

Sadly I have no ETA for this. Sorry.

Greetings!

Is there any possibility of getting this issue fixed soon?

-Raj

Hi Raj,

Your request is on the to-do list, but I can't provide a realistic ETA. Sorry. Stay tuned.

Greetings!
Some time has passed, I was wondering if there has been any progress/update on fixing this issue?

We really need this feature to be fixed.
Thank you!

-Raj