The migration tool remains incomplete.

[shiba9967]

When I tried the migration tool, there was an issue with the source VM that prevented it from completing, leaving it in an incomplete state. Even after stopping and restarting the manager VM, the issue persists, and we are unable to safely finish this task. Is there a way to manually force-terminate this task?

We suspect that the reason it did not complete successfully was not that we chose not to skip the agent installation, but that the source VM could not install the qemu-guest-agent over the Internet.

I apologize for any expressions that may seem inappropriate due to machine translation.

[PeterTzvetanov]

Hello Shiba9967,

best would be to have session together and look on it. Please send a mail on hpe-sw-trial-vmessentials@hpe.com and we could have a look eventually next week.

With regards

Peter Tzvetanov

Support Engineer

Peter.Tzvetanov@hpe.com

Technical Support Phone Numbers

HPE Operations

You can manage your cases on HPE Support Center

[dccolpitts]

Here's what I did for my migration testing.

I wrote a PowerShell script that removes all the OS drivers from the virtio-win-0.1.271.iso except the OS you want to keep (in this case Windows 2022, so 2k22):

$ParentPath = "C:\VME\virtio-win-0.1.271"
$FolderToKeep = "2k22"
Get-ChildItem -Path $ParentPath -Directory | Select Name | Foreach {
$Name = $_.name
$ParentFolder = $ParentPath + "\" + $Name
Get-ChildItem -Path $ParentFolder -Directory -Exclude $FolderToKeep | Remove-Item -Recurse -Force
}

Then I copied "C:\VME\virtio-win-0.1.271" (which now only has the 2k22 folders / drivers in it) to my test migration server (in "C:\VME\virtio-win-0.1.271"), and then I rebooted the VM into WinPE (you can probably just use the Windows 2022 .iso image to boot off and when setup appears, press Shift + F10 to open a command prompt). Once at the WinPE command prompt, I injected the Virtio drivers with:

dism /image:c:\ /add-driver /driver:C:\VME\virtio-win-0.1.271 /recurse

You may get an Error 50 with the smbus driver as it is not properly signed depending on which OS you are injecting into.  I ignored that, as the biggest thing was to get the storage drivers injected so the VM would boot.

When that finished, I rebooted the VM back into Windows (wpeutil reboot) and installed virtio-win-gt-x64.msi. The virtio-win-guest-tools.exe crashed when I tried to run it, so I ignored it.

I shut the VM down at this point and created a migration plan. When creating the migration plan, I did add the local Administrator credentials (not domain credentials, making sure to type hostname\Administrator so it would be the local credentials). I did NOT select either of the migration options (skip prechecks, skip guest tools). The VM only had about a 20GB boot volume, and my test VME cluster is connected on a segregated VLAN across a firewall at 1Gbps to my production VMware cluster. The enitre migration process took about 12 minutes. The time estimates given were rather high compared to what reality was. It finished in 12m11s (which happened when I was gone making a fresh coffee). When I came back from making my coffee, I saw it was completed, so I went back to provisioning and found it was powered on.

Upon connecting to the console, it was booted and it had a valid DHCP address from the vlan's DHCP server.  I then logged in, installed virtio-win-guest-tools.exe from C:\VME\virtio-win-0.1.271. VMware Tools threw up a crash too on logon. I removed them with this script:

https://gist.github.com/broestls/f872872a00acee2fca02017160840624

At this point, the VM migration was completed and Windows Server 2022 was runnnig with the Virtio tools and without VMware Tools.

For Linux, I test migrated a Ubuntu 18.04 VM.  I first installed qemu-guest-agent (apt-get install -y qemu-guest-agent).  I then verified that the guest had the Virtio drivers already in it (https://www.tencentcloud.com/document/product/213/9929), and then I rebooted the VM so it was at a clean boot.  I then created a migration plan, providing my user credentials to it (my credentials are also a sudo user) and leaving everything else default.  Once the migration finished, the VM automatically booted.  I logged into the console and found networking was not functioning.  Upon checking the yaml (/etc/netplan), I discovered that under ESXi the nic was labeled ens160, while under VME it's labeled as ens1.  I updated the adapter name (and IP since it was no longer on my production vlan) and ran netplan apply and I immediately had network connectivity again.

Good luck!

dcc