In order to streamline Chef cookbook development and give everyone in IT a dev node where they could make and test infrastructure changes locally, we decided to build a Vagrant box to distribute internally. Having built many Vagrant boxes in recent months, I set out in earnest and configured the Virtual Machine just how I wanted it. When I went to
vagrant package, however, I discovered the vmware_fusion provider does not support this action and that this box would have to be packaged manually.
I read through the official Vagrant docs, and I packaged up the VM, only to discover–when it was just a bit too late–that I had packaged up the wrong virtual disk and didn’t save any of my changes. Since I hadn’t seen this clearly documented anywhere else, I wanted to share the key finding I had overlooked the first time through.
When working on a Mac, at least, you will find VMWare virtual disk files in a boxes dir in
~/vagrantd/ as well as inside a similarly named directory in
~/.vagrant.d/. However, those are not the vmdk, vmxf, and metadata.json files that you need to archive to make your running VM into a Vagrant box. As it happens, the section of the Vagrant vmware_fusion provider docs that mention a
vm.vmwarevm directory weren’t erroneous after all–it just wasn’t totally clear that they were pointing to a subdirectory of the
.vagrant/ directory that lives in the directory with your Vagrantfile–the directory from which you ran
Having worked with the Virtualbox provider pretty extensively, I did not expect this pattern and wanted to share this experience since I hadn’t seen it clearly documented elsewhere online. Whereas Virtualbox puts VM disk files inside
~/VirtualBox VMs, when using the vmware_fusion provider with Vagrant, the virtual disks are stored in
~/running_vagrant_dir/.vagrant/machines/default/vmware_fusion/vm.vmwarevm. Now you know and can build VMWare Fusion-based Vagrant VMs following the instructions provided in the official Vagrant vmware_fusion provider docs.