{"id":2221,"date":"2025-03-31T22:30:00","date_gmt":"2025-04-01T02:30:00","guid":{"rendered":"https:\/\/enterpriseadmins.org\/blog\/?p=2221"},"modified":"2025-03-31T15:32:43","modified_gmt":"2025-03-31T19:32:43","slug":"reviving-an-old-esxi-host-usb-to-local-disk-migration","status":"publish","type":"post","link":"https:\/\/enterpriseadmins.org\/blog\/virtualization\/reviving-an-old-esxi-host-usb-to-local-disk-migration\/","title":{"rendered":"Reviving an Old ESXi Host: USB to Local Disk Migration"},"content":{"rendered":"\n

I have an older Intel NUC in my lab, and although its aging, it still serves a purpose, and I plan to hang on to it for a little while longer. This post will outline some issues I encountered while recently migrating from a USB boot device to a more permanent option. As described extensively in this knowledge base article: https:\/\/knowledge.broadcom.com\/external\/article\/317631\/sd-cardusb-boot-device-revised-guidance.html<\/a>, using USB devices is no longer a recommended boot media due to the endurance of the media. In addition, this host recently started throwing an error message:<\/p>\n\n\n\n

Lost connectivity to the device mpx.vmhba32:C0:T0:L0 backing the boot filesystem \/vmfs\/devices\/disks\/mpx.vmhba32:C0:T0:L0. As a result, host configuration changes will not be saved to persistent storage.<\/code> <\/p>\n\n\n\n

This message appeared on the host object in vCenter Server. I decided this would be a good time to move the boot device to a more durable media. The host had a local disk, which contained a single VMFS volume where I stored a VM containing some backups. I moved this VM to a shared datastore for safe keeping and proceeded to delete the VMFS volume. I wanted to re-install ESXi and specify this device, and not having a VMFS volume makes me more confident when selecting the disk during the ESXi install.<\/p>\n\n\n\n

Creating the boot media<\/h1>\n\n\n\n

For this ESXi host, I knew that I would need the latest ESXi base image (8.0u3d), the Synology NFS Plug-in for VAAI, and the USB NIC Fling Driver. Instead of just installing ESXi and then adding packages, or using New-ImageBundle<\/code>, I decided to turn to vCenter Server Lifecycle Manager for help. I first created a new, empty cluster object. I then selected the updates tab and selected ‘manage with a single image’, and then ‘setup image manually’. I selected the required ESXi version and additional components, save, and finally ‘finish image setup’. Once complete, I was able to select the ‘…’ and ‘Export’ options, pictured below. <\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

This allowed me to export the image as an ISO image, pictured below:<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

With the ISO image in hand, I used Rufus to write the ISO image to a USB drive to use as the installation media.<\/p>\n\n\n\n

Installing ESXi<\/h1>\n\n\n\n

Since I only needed to install ESXi on a single host, I decided to do so manually \/ interactively. Knowing that this was an old host, and the installed CPU was no longer supported on the HCL, I pressed SHIFT<\/code>+o<\/code> (the letter o, not the number zero) during bootup to add a couple of boot options:<\/p>\n\n\n\n

systemMediaSize=min allowLegacyCPU=true<\/code><\/p>\n\n\n\n

The systemMediaSize<\/code> option limits the amount of space used on the boot media to 32GB (min) instead of 128GB (default). This is described more here: https:\/\/knowledge.broadcom.com\/external\/article\/345195\/boot-option-to-configure-the-size-of-esx.html<\/a>. The allowLegacyCPU<\/code> option allows ESXi installs to continue on unsupported CPUs. This is documented various places, including here: https:\/\/williamlam.com\/2022\/10\/quick-tip-automating-esxi-8-0-install-using-allowlegacycputrue.html<\/a>. <\/p>\n\n\n\n

The install went well, I was able to select my empty local disk to use as an installation target and the system booted up fine afterwards. I noticed I now had a datastore1<\/code> on this host which was 32GB smaller than the original VMFS volume.<\/p>\n\n\n\n

Configuring USB NIC Fling Driver<\/h1>\n\n\n\n

My USB NIC was recognized immediately as well, since I had included the driver in the custom image. I added the host to a distributed virtual switch, and mapped uplinks to the appropriate physical NICs, but on reboot the vusb0 device was no longer in use by Uplink 2.<\/p>\n\n\n\n

Some of my notes mentioned that I had previously added some lines to the \/etc\/rrc.local.d\/local.sh<\/code> script to handle this, although I didn’t list which<\/em> commands. Thankfully I was able to get the system to boot from the failing USB device and review this file. I’ve included the code added below: <\/p>\n\n\n\n

vusb0_status=$(esxcli network nic get -n vusb0 | grep 'Link Status' | awk '{print $NF}')\ncount=0\nwhile [[ $count -lt 20 && \"${vusb0_status}\" != \"Up\" ]]\ndo\n    sleep 10\n    count=$(( $count + 1 ))\n    vusb0_status=$(esxcli network nic get -n vusb0 | grep 'Link Status' | awk '{print $NF}')\ndone\n\nesxcfg-vswitch -P vusb0 -V 308 30-Greenfield-DVS\n\/bin\/vim-cmd internalsvc\/refresh_network<\/code><\/pre>\n\n\n\n
The esxcfg-vswitch<\/code> help states that the -P<\/code> and -V<\/code> options are used as follows:<\/p>\n\n\n\n
 -V|--dvp=dvport             Specify a DVPort Id for the operation.\n -P|--add-dvp-uplink=uplink  Add an uplink to a DVPort on a DVSwitch.\n                              Must specify DVPort Id.<\/code><\/pre>\n\n\n\n
 The Physical uplink I wanted to add was vusb0<\/code> and the DV Port Id for the operation was 308<\/code>, which could be found on the distributed switch > ports tab > when filtering he ‘connectee’ column for the specific host in question, pictured below:<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Now on system reboot, the vusb0<\/code> uplink correctly connects to the expected distributed switch.<\/p>\n\n\n\n
Lifecycle Manager – Host is not compatible with the image<\/h1>\n\n\n\n
Once I had the host networking situated, I wanted to verify that vCenter Lifecycle Manager agreed that my host was up to date with the latest image.  I was surprised to see that the system said The CPU on the host is not supported by the image. Please refer to KB 82794 for more details.<\/code> <\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
I knew these CPUs were unsupported, but had expected a less significant The CPU on this host may not be supported in future ESXi releases<\/code>, which is what I had observed prior to the host rebuild.  After some searching, I found this thread: https:\/\/community.broadcom.com\/vmware-cloud-foundation\/discussion\/syntax-for-an-upgrade-cmd-to-ignore-cpu-requirements<\/a>, which proposed edits to the \/bootbank\/boot.cfg<\/code>, specifically adding the allowLegacyCPU=true<\/code> flag to be added to the end of the kernelopt=<\/code> line.  This resolved my issue and allows me to continue functioning with this older system.<\/p>\n\n\n\n
Conclusion<\/h1>\n\n\n\n
This migration process highlights the challenges of maintaining older ESXi hosts while ensuring compatibility. Moving from USB-based boot devices to more durable storage is a critical step, especially as support is phased out for USB\/SD boot devices. Leveraging vCenter Lifecycle Manager simplifies image management, though workarounds (such as allowLegacyCPU=true<\/code>) may be needed for legacy hardware.<\/p>\n","protected":false},"excerpt":{"rendered":"
I have an older Intel NUC in my lab, and although its aging, it still serves a purpose, and I plan to hang on to it for a little while longer. This post will outline some issues I encountered while … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":6,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[9,4],"tags":[],"class_list":["post-2221","post","type-post","status-publish","format-standard","hentry","category-lab-infrastructure","category-virtualization"],"_links":{"self":[{"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/posts\/2221","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/comments?post=2221"}],"version-history":[{"count":3,"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/posts\/2221\/revisions"}],"predecessor-version":[{"id":2228,"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/posts\/2221\/revisions\/2228"}],"wp:attachment":[{"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/media?parent=2221"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/categories?post=2221"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/tags?post=2221"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}