Instant Recovery...what is the disk modify step doing?

[AaronKCollege]

I have been working with Veeam B&R as a means to move a Suse Linux based virtual appliance from Vmware to Hyper-V. I do a backup of the VM in Vmware, then use Instant Recovery to get it on to the Hyper V server, then do a Migrate to Production. The first time I tried, during Instant Recovery, it hit a step where it was "using Helper Application to modify disks". That part came back as "Failed to modify disks". Everything else succeeded and the resulting VM in Hyper-V seemed just fine. Booted up, everything seemed to be there. I don't like there having been a warning though so I looked in to it and it turns out I needed to provide IP information for the Helper Application. I'm still in figuring things out phase so I deleted everything and went through the process again, this time providing valid IP information for the helper application. Everything succeeded this time, and everything came back green. However, the result VM in Hyper-V was completely horked up. The network information had been blown away and reset, and the disk mount points were bizarre. Instead of mount /dev/sda1 it had /dev/mapper.3600224804fcf5f9f<long string of same>-part2. Everything seemed to BE there, but nothing worked.

My question is...what is that step actually *doing*? I mean, making sure it fails seems to accomplish my goal of moving the VM from vmware to HyperV but I'd like to know why letting it work "successfully" causes the copied VM to be completely unusable.

[david.domask]

Hi AaronKColleage,

The disk conversion process is done to "patch" the VM to accommodate for differences between platforms and to try to ensure a bootable VM. During the migration process, things like disk UUID, networks, etc will change, so the disk conversion process attempts to accommodate for this.

Have you opened a Support Case for the behavior yet? Regrettably we won't be able to tell what went wrong with the conversion over the forums as it will require a review of the debug logs for a proper answer.

Also a small hint: Were the backups of the source machine taken with Guest Indexing enabled? For *Nix machines, the Guest Indexing process does a bit more than just collect information about files on the system, and it often helps (is required) for V2V conversions like this. Give it a shot with indexing enabled if it was not enabled and see if it goes better.