Way back in 2012, I dabbled with ESXi. In fact, I faced then, moreorless the same problem I was facing a few days ago.
That particular ESXi server didn’t last particularly long – no technical issues, it just didn’t turn out to be the thing I wanted.
Fast forward 6 years, and I found myself in a new situation where having an ESXi host would be useful. We use Azure a lot nowadays, but there are still some scenarios where we’d like some on-premise kit such as developing against Sharepoint. (Although in fairness, I’m not sure anyone really ever *wants* to do that.) I digress.
More importantly, it’s cool. So a few weeks ago, rather than trying to build an ESXi host, I cut to the chase and splashed out on a SuperMicro SuperServer. If the 2012 machine was a beast… this thing is a behemoth. 8-core processor, 128gb RAM, 600gb SDD, 10gb NICs – the works. This is hooked up to a ReadyNAS with 16tb storage and running VMWare ESXi 6.7. Still free but nowadays more awesome – there is no longer a fat client – it’s all web client, which makes managing it from OSX a lot easier. I might do a post on the setup itself at some point.
But to the issue – well, it was exactly as it was back then – I wanted to transfer some pre-built VMWare Fusion virtual machines to it. We’ve become so accustomed to “draggy-droppy it just sorta works” recently that I hoped it would be the same here. And, same as in 2012, it ain’t.
I initially looked at the Converter tool – but remembering the pain from last time – wanted to find a new way. I looked at ovftool – and after passing out trying to read the million switches and options and complex terminology – not to mention some pretty scathing thoughts on it in the VMWare forums, I fortunately stumbled over a way of doing it.
On a Mac, the .vmwarevm file is little more than a wrapper around the various bits that a VM needs to run. And, one step further, the things it really only needs are:
- A .vmx file – this is a description/definition of the machine
- Some .vmdk files – these are the (virtual) hard disks attached to the machine
- There are some other files (e.g., .vmsd and .vram) which will be created if you modify machine settings such as RAM allocation etc.
If you look inside your .vmwarevm file, you’ll see these files there (and a bunch of other crap.) The danger here though is that some of those configuration files will be Fusion specific, and if you try to load them in ESXi, you’ll get configuration issues.
So here follows my method for porting a VMWare Fusion virtual machine to VMWare ESXi. This is mostly cobbled together from this post which came from this post – repeated here for posterity / safeguard. Both written some time ago, but seem to work fine for ESXi 6.7 and VMWare Fusion 10.
Part 1: Prepare the new VM
In this step, we actually create/register a new VM in ESXi, that is ready to become the new VM.
- In the ESXi web client, create a new VM
- Ensure you choose the correct datastore you want to use (if you have more than one.)
- Choose the options that match the Guest OS you’ll be creating
- It will create a hard disk for you – delete this.
- Next next finish everything else.
I do this step first because it creates the spot on the datastore that we’ll need next.
Part 2: Convert the existing VM
This will use a tool built in to VMWare Fusion called vmware-vdiskmanager and is run from Terminal.
One of the most infuriating things about Terminal is the way it handles spaces in paths, having to backslash escape them. This can make dealing with complex paths a real headache, so I try to simplify this as much as possible.
Some of the early steps therefore aren’t strictly necessary for this reason or if you’re happy assembling long paths or if you manage your VMs and virtual disks better!
- In Finder, create a temp directory (e.g., VMWareTemp), somewhere near the root of your user account. So in path terms, this may look like /Users/username/VMWareTemp (i.e., no spaces!)
- Inside that folder, create a further two folders – ‘Source’ and ‘Target’
- Again in Finder, locate the VM you want to migrate. By default this will be /Users/username/Documents/Virtual Machines/ExampleVM.vmwarevm
- Right click on the virtual machine file and ‘Show Package Contents’
- In there, locate your VMDK files. This will vary based on how many virtual disks your machine has and also how they’ve been provisioned, but in a simple scenario, you should see one file called ‘Virtual Disk.vmdk’ and then a bunch of Virtual Disk-s00*.vmdk files, where * is a number that increments. Typically there will 16 of them.
- Select all of those .vmdk files, and copy them to the ‘Source’ folder you created previously.
- Now for the fun. Open up Terminal.
- To simplify path issues again, issue
cd /Applications/VMWare\ Fusion.app/Contents/Library
- Now to convert. The command is:
./vmware-vdiskmanager -r /Users/username/VMWareTemp/Source/Virtual\ Disk.vmdk -t 4 /Users/username/VMWareTemp/Target/newVMDisk.vmdk
- There are a few things going on here. The ‘./’ at the start tells terminal to look for the application in the current folder. The ‘-r’ is the switch to convert, followed by the source. ‘-t’ indicates the disk type where 4 is the ESX-type. Followed by the target/name of the disk to create. For more info, in terminal type
- This will do its thing and length of time will vary based on how much data is on the disk.
- Once created, you will have two files – newVMDisk.vmdk and newVMDisk-flat.vmdk.
- You can now copy these files to ESXi. How? (You might ask.) Well, there are (at least) two ways. The easiest is to use the Datastore Browser through the web client, find the folder that was created for your new VM in Part 1, then click upload. This works OK. However, whenever there’s more than one file to upload, I prefer to do it via scp. To do this, enable SSH on the host (via the web client), then connect to the server using your preferred scp tool – I use Cyberduck on the Mac which seems to work OK. It’s basically an FTP client; so navigate through the structure until you find the folder for your new VM, and then drop the file(s) in there. This at least provides some resilience for failure and a bit more feedback on transfer speeds.
- ESXi will nag you to disable SSH when you’re finished. Probably best to do that.
Once this is all done, you are now ready to spin up your shiny new VM.
Part 3: Fire it up
- In ESXi web client, find your new VM. Select it and choose ‘Edit Settings’ from the ‘Actions’ menu.
- In there, add a hard drive – choose add existing – and point to your newly uploaded .vmdk file. (The -flat files will be hidden.) Repeat for as many virtual disks as you have.
- With that done, you should be able to now power up the machine.
- It should prompt you about where it came from – I usually choose I Copied It. (Here’s why.)
With all being well, it will just spin up – and the rest is for you to figure out.
Anyway, that’s about it.
Hope this has been useful. Happy virtualising.