Add VHD/Parallels HDD Support + README Overhaul

[americanhanko]

This PR

• Is too large
• Complete rewrite of the README to make it more procedural and organized
• Switch from .vdi to .vhd type so that we can convert from VHD to both VirtualBox and Parallels disks
• Add Chef-client as a provisioner. This was out of pure need for our own builds and base box creation, so I thought it might be useful to have here. Happy to remove if outside the scope of the repo
• Reformats template.json with packer fix - also subjective/preference. The prlctl commands are slightly nauseating, but that's how packer fix chooses to format for some reason.
• Adds a new prepare_pvm.sh script to convert VHD into a parallels.pvm` to use with Packer. More (a lot more) in the README.

Known Issues / Questions Before Merging

• prepare_vhd.sh does not actually work with any versions less than macOS Sierra...table should probably be modified if it is okay to keep.
• Adds a second version of install-parallels-tools.sh. Although the two versions are basically the same thing, I have found more consistent success with install-parallels-tools.sh. Not sure why. Open to suggestions.

This has been a WIP for a while, so there might mistakes in here so keen eyes are appreciated.

[timsutton-sl]

Awesome! I'll just start adding comments as I slowly make my way through it.

[jonanh]

• I would rename the prepare_{vdi,vhd}.sh to something format agnostic like prepare_disk.sh and allow it to export the images as either vmdk, vdi or vhd. Probably for virtualbox/prepare_ovf.sh the best choice is already using vmdk to prevent virtualbox reexporting the image as vmdk as part of the ovf export.

• Lately I have been trying to speed up the process avoiding the intermediate state of exporting a complete virtual machine for the packer provisioner. Removing this step is specially interesting for my use case since I am creating first a basic OSX box and then creating specific boxes with different development tools.

  • The first trick that I did was creating an empty iso file and manually adding the disk to the virtualbox-iso builder. And it works quite well, though is not very elegant, probably the best solution would be creating or extending the existing builders to allow just specify a virtual disk image.
  • Then I found out that the vmware-vmx builder supports the VMWare EXSI, which is perfect since now I can automate the whole process, I can generate the virtual disk image for several macosx versions and provision them later, from a single machine.

  I was thinking that maybe we could do the provision with a single provisioner and export the virtual machine as the last step, since it will be more flexible, we can from the same virtual disk generate a virtualbox packer box, a vmware box and a parallel box without provisioning several times.

• I really like the idea of keeping a table with each option. 👍

[timsutton]

Hey @americanhanko, sorry this continues to linger. Just wanted to let you know I didn't forget :)

[americanhanko]

No worries @timsutton! I've actually been thinking about closing since I think we both agree that we ought to work toward keeping ISO as the only source type...rather than having a slew of scripts to construct base VMs for the various hypervisors. I think the README updates are the most valuable part of this PR, so I'd be happy to close and re-open a new one that contains only information about the current workflow. Totally up to you.

---

@jonanh Sorry it's taken this long to respond to your comments (Tim's ping helped 👍).

I really like your ideas, particularly about having a single prepare_disk.sh utility that takes some parameters. I had originally had that design in mind but decided that a separate script was better in the interest of making an immediate impact. Depending on where @timsutton wants to take this, that script may or may not become a reality. I'm of the opinion that we should simplify the workflow as much as possible, even if that means taking a bit longer to get it there.

This thought of yours also struck a chord with me:

maybe we could do the provision with a single provisioner

After reading that, I started thinking about what it would look like to use a configuration management tool as the provisioner (e.g. Chef) with a user-configurable set of provisioning steps (Packer variables) that could replace the current script-driven workflow. I started working on an experimental branch (currently broken) that uses Chef as the provisioner. The final implementation of this would leverage a recipe (e.g. boxcutter.rb) that would be taken from the macOS cookbook.

My team will likely end up utilizing this approach anyway in a private fork since it fits so well with our infrastructure. The question is whether or not that approach is right for this repository. My feeling is the answer is probably not since it would mean any box build with this repo would have chef-client installed, as well as increasing this repo's dependencies. The benefit would be that, since the provisioning steps would be written in Ruby and well-tested, there would be an increase in provisioning flexibility, as well as creating an opportunity for CI.