Inaccessible boot device hot converting VMware to Hyper-V

[yaroslav (staff)]

Matt,

No worries. That's how we learn new stuff
I believe there are drivers that can be clashing with the Hyper-V components.

[Matt_NZ]

Makes sense…but I would have thought the same thing would happen to an offline conversion as well. I guess there’s something extra happening behind the scenes to make hot conversions work that is enough to cause issues with them

[yaroslav (staff)]

Thanks for sharing your thoughts and progress on this case. I am very glad to read that it worked.
P.S. If you are converting many VMs, reach out to us https://www.starwindsoftware.com/support-form use this thread and 1239795 as your references.

[bspeers.dlc]

Hi everyone,

I'm currently working through this process in my lab and was hoping to get some additional clarification around the hot migration and synchronization workflows described here:

https://www.starwindsoftware.com/blog/s ... ware-esxi/

First off, thank you for making this tool freely available. So far I've been genuinely impressed with what I've been able to accomplish with it.

I do have a few questions though, as I seem to be missing some pieces of the workflow and I haven't found much detailed documentation around the newer synchronization/live migration functionality.

A few things I'm trying to better understand:

Does the converter always power down the source VM automatically after synchronization/conversion completes, or is that optional somewhere in the workflow? If optional, where are those settings located?
It appears the software can detect a previously migrated VM and then enable synchronization options. Is it identifying the VM by existing disks/VHDX files on the destination Hyper-V host? Or is there another mechanism being used to associate source and destination VMs?
Can someone explain the synchronization process in more detail?
Is it doing true incremental synchronization?
Is VMware CBT involved?
Is it snapshot + delta synchronization only during the migration session?
How exactly does the “Synchronization parameters” step work internally?

I've been trying to piece this together from blog posts, release notes, and forum threads. GPT has attempted to explain some of it to me, but honestly it has been hallucinating/confabulating quite a bit around this product specifically, so I would appreciate clarification from people who actually know the internals or intended workflow.

I realize this is a free product and documentation resources are limited, but I think there is a lot of interest in understanding these newer migration/synchronization capabilities better.

For context, I have a fairly extensive lab environment:

10 Gb networking
multiple ESXi hosts
Hyper-V targets
high-end server hardware
mixed VMware and Hyper-V workloads

I'm actively testing VMware → Hyper-V migration scenarios right now.

Depending on what I learn, I may consolidate my findings into a dedicated blog post or forum write-up to help others understand the workflow better.

Thanks very much in advance.

[yaroslav (staff)]

Does the converter always power down the source VM automatically after synchronization/conversion completes, or is that optional somewhere in the workflow? If optional, where are those settings located?

No, the source VM is not powered off. You need to manually shut down that VM once the conversion is over.

It appears the software can detect a previously migrated VM and then enable synchronization options. Is it identifying the VM by existing disks/VHDX files on the destination Hyper-V host? Or is there another mechanism being used to associate source and destination VMs?

It refers to the disks connected to the VM in the VM settings.

Is it doing true incremental synchronization?

Synchronization is effectively a snapshot merge stage. Think of the conversions as an "always full" backup.

How exactly does the “Synchronization parameters” step work internally?

Synchronization stage is where the destination VM catches up with the source. When conversion starts the snapshot is created and tracks the data changes during conversion. This snapshot merges during replication phase so the source and destination both end up with the same data.