Migration from VMware to HVM quirks

[jamgwert81]

I think I followed the Migration guindance in the latest documentation pretty well:
Overview | HPE Morpheus VM Essentials Software Documentation v8.0.10

I noticed in the video posted by Calvin and Sean demoing this piece they didn't go into much detail on the prep work that is required, and I believe Sean only showed how to migrate some Ubuntu VMs.

I just tested this a few times with a Windows Server 2025 vm built from our basic VMware template.  Only thing done on the template is we remove the recovery partition on the C drive so it can be sized according based on request, otherwise it's in the way to do an expand. Our template is fully patched on the Windows side, has the most current VMtools installed for our environment and the latest VM Hardware Compatibility.  It's also already running the Paravirtual SCSI adapters and VMXNet3 NICs.

I rebooted this VM to inject the VirtIO Storage and VirtIO SCSI drivers with the DISM commands.  I did not have to do the paravirtual drivers as they are already present in 2025.  I then booted back to the OS and installed both the VirtIO drivers MSI and the VirtIO Tools MSI.  I then setup my Migration plan and ran it.

VM pulled over OK, and got a COMPLETED status when it finished.  However I noticed on the VMware side, the "Export OVF template" task hits 100 percent but never truly goes to Completed, and eventually says "Operation timed out". 

This doesn't really create a problem, just wondering if anyone else experiences this?

I also notice on the HVM side, the migrated VM has the same Mac Address as the old VMware VM but it's not able to retain the Statically configured IP????  It instead switches it to DHCP Automatic which then ends up with an APIPA address.

VMtools is still installed and throws up an error upon startup.  I saw notes about this in the guide.  I'm not able to uninstall this via Control Panel once it comes over.  It appears like it's going to uninstall by lauching the MSI wizard but then just disappears.  This is a frequently discussed issue with others who have migrated their VMware VMs to other platforms like HyperV or ProxMox.  I was able to actually get it uninstalled by following this method

posted in the comments on this forum:
Force removal of VMware Tools, Program Files, and Windows Services · GitHub

I also notice that the RPC Host port is set to 22 like it would be for a Linux VM and not 5985 like it should be for WinRM when I go to Edit the VM, however the Summary info shows it's 5985?  I don't understand that at all.  If I set the correct IP manually on the VM, I'm still having trouble doing Install Agent.  I even manually added the WinRM TCP 5985 to the WIndows Firewall as well as added the correct Username and Password under the Edit VM and it still can't deploy the agent, so I'm totally confused on that.

Other than those quirks the VM came over fine.

I ended up trying the Migration again, same VM and Plan settings, the only thing I did different was I removed VMware Tools before kicking off the Plan.  That actually created less work as I didn't have to modify the VMtools MSI with Orca to be able to remove it. 

I'm wondering why removing VMware Tools before you kick off the Migration plan is not the recommended course, rather than just leaving the VMtools carcass installed on the VM and just disabling the Startup of the application? 

I think there are even 4-5 Windows Services for VMtools that would remain on the OS as well, but just disabling the Startup of the app wouldn't really remove those services.  I'd believe this to be a security concern at somepoint as you would eventually have an unpatched version of VMtools remaining on the OS that you wouldn't uninstall or be able to fix.  There have been so many VMtools vulnerabilities as of late would hate to leave this on these migrated VMs and have this become an issue later.

Thanks!

[dya]

I also failed to install the agent.
At that time, I ran the following on Windows Server 2025, and after restarting the OS just to be safe, I was able to install the agent.

・winrm quickconfig
・Enable-PSRemoting -Force

I'm not very familiar with Windows, so this might include unnecessary steps. I'm sharing it for reference.

[Arnout_Verbeken]

I personally remove VMware Tools before migration.

We  indeed reuse the source MAC address on the migrated host, but we have no means to also migrate the IP since the virtual NIC hardware changes and as thus it is seen as a new NIC for the OS.
We are able to read the MAC from the source upfront,and create the new Virtual Machine and NIC with that same MAC address, but we can't (or we don't want to) make changes to anything in your OS.  That's why the NIC in the migrated VM is on DHCP and why you have to configure the new NIC manually.

For the agent install, it's difficult to troubleshoot without the logs, but running "winrm quickconfig" before the migration could certainly help.

[jamgwert81]

@Arnout_Verbeken wrote:
I personally remove VMware Tools before migration.

Should this be added to the guide then?  The Post-Conversion guidinace of just disabling Startup of VMtools isn't really a great guidance, especially from a security vulnerability perspective.  

@Arnout_Verbeken wrote:

We  indeed reuse the source MAC address on the migrated host, but we have no means to also migrate the IP since the virtual NIC hardware changes and as thus it is seen as a new NIC for the OS.
We are able to read the MAC from the source upfront,and create the new Virtual Machine and NIC with that same MAC address, but we can't (or we don't want to) make changes to anything in your OS.  That's why the NIC in the migrated VM is on DHCP and why you have to configure the new NIC manually.

---

If this is the case, there should be something in the guide indicating this.  I'm thinking something should be added to Post-Conversion section about setting the IP again, as well as some Warning on the Migration Plans page about how statically set IPs need to be manually set again post migration.  The video posted by Calvin Zito and Sean Jabro demoing this product doesn't really outline setting the IP manually after you've migrated it, nor that having the IP get set during a migration only works when doing a DHCP configuration on your VMs.

For the agent install, it's difficult to troubleshoot without the logs, but running "winrm quickconfig" before the migration could certainly help.

Which logs should I be grabbing?  I can certainly try "winrm quickconfig". Thanks!

[CalvinZito · Accepted solution]

@jamgwert81 Thanks for the feedback. I shared it with Sean and another person on Sean's team that is working on our documentation. A few things:

• The bulk migration tool is a v1 tool. I don't know what is on the roadmap but I do know they have improvements to it on the list. I'll get your feedback to our dev team so they can add it to the list. 
• Whether we add the clean-up you see to the docs depends on how fast the dev team updates the bulk migration tool but as I said, I'll give the feedback to the dev team. 

On the topic of what we showed in our video, I'm not deep enough technical to address that but I would suggest you check out the demo my friend @BartHeungens did on his YouTube channel. I know he talks about the prep steps you need to take before the migration in his video. Here's a link to his demo. 

[jamgwert81]

@CalvinZito  Thanks Calvin!  Totally understand this is v1 tool.  Came here to post feedback as instructed in your video to relay my experience. 

Yes I've also watched @BartHeungens video on this as well.  His demo aligns exaclty as the guide currently lays it out.  He has a comment near the end after he gets the same onscreen error about VMware Tools failing to start and indicates it might be better to remove it beforehand.  I can tell you from personal experience that it cannot be removed from Add/Remove programs on Windows, after migration, without modifying the orginial .MSI with the Microsoft Orca MSI servicing tool, which I posted a screenshot of above, becuase of how that orginal MSI was built to silently error out when you attempt to uninstall it.

Overall this is looking pretty promising for a v1 tool.

I highly recommend all the videos from @BartHeungens for anyone new to this product and starting to test it out, they are great way to start to learn how to use this product.  Really hope he makes more.