Add Fusion driver and vmx template

[zeeyang]

Fusion driver for boot2docker-cli WIP...

[tianon]

Very interesting! 😄

So, since you've self-titled this a WIP, can you elaborate on what bits aren't complete? I'm curious why the driver needs a concept of "hostname", too.

Also, I'm not nearly as familiar with Fusion as I used to be (since I don't use a Mac as my daily driver any more); any chance much of this would be portable to VMware Player or VMware Workstation at some point in the future? 👼

[zeeyang]

It's 80% there... At this point I could init, boot up with Fusion, start, stop, pause, delete, and ssh.

The current Virtualbox implementation maps SSH and Docker ports to localhost. But Fusion doesn't have a port forwarding API. It would require sudo modify nat.conf. It's cleaner just connect directly to the vm IP - plus it solves the port conflict issue if you run multiple instances of boot2docker vm. It also opens doors to pushing boot2docker to ESX or AWS.

@oliverkurth is putting together a pull request for boot2docker iso to include vmware guest tools. It would probably defer running make_iso.sh to runtime, so we can parametize which guest to include. I'll save that discussion for Oliver's PR.

This driver should work for Workstation on Windows/Linux with a few path tweaks, but I have yet to test it. I'll create a separate PR for it.

[SvenDowideit]

awesome! I might play after 1.3.0's cooked, then i can finally stop running 3 virtualisation tools (I use qemu in consle mode for very fast OS tests)

[bfirsh]

@zeeyang Just a heads up: boot2docker-cli will likely be deprecated after the release of host management.

There are examples of host management drivers on my host-management branch. It'd be great to get a VMWare Fusion driver for that.

[SvenDowideit]

@tianon can we merge this please?

[tianon]

Can you adjust these similarly to what was done to VirtualBox in #290 (normalizing the error interfaces a bit, essentially using driver.Err... instead)?

[tianon]

Other than the error handling nit from #290, LGTM.

[tianon]

docker-archive-public/docker.machine#6 is where this is happening for Docker Machine 👍

[tianon]

See also #328 for where @jamtur01 carried this and added the error handling fixes I requested above. 👍

[zeeyang]

We have a patch for docker machine that are a few fixes ahead. Are there plans to sunset b2d-cli? If not, it's probably best we refactor the fusion bindings to a standalone lib to minimize the duplication between these two drivers.

[jamtur01]

@zeeyang Can you link to the PR?

[zeeyang]

@jamtur01 docker-archive-public/docker.machine#6

[jamtur01]

I don't mind where they get merged. I suspect b2d will live longer than expected as is the way of these things. I just want the functionality and wanted to push this ahead.

[SvenDowideit]

@zeeyang if we can refactor the b2d driver interface to use the docker machine one, then we're hedging and can test the code out in b2d releases :)

[SvenDowideit]

ok, I've played with this a little, and its mostly working, so I'm going ot merge

LGTM

[tianon]

...

[tianon]

Care to elaborate more on what "mostly working" means? I'm specifically interested in what isn't working, and would rather not merge things that aren't user-ready.

[SvenDowideit]

@tianon see the other 2 PR's - @jamtur01 resolved the error handling, and then in my new PR, I've made it work with the existing b2d.iso (ie, without needing the vmware tools)

I have noticed an intermittent issue with deleting - once the vmware gui gets involved, but otherwise, its been seriously solid.

[tianon]

Ok, that's more fair, but doesn't explain why it was necessary or appropriate to merge this one, which has none of those improvements.

[SvenDowideit]

pretty simple - your LGTM from #265 (comment) plus my having tested it, and both @jamtur01 and I having follow on PR's meant that I could this and then get on with my work actually using it.

with machine hanging and crashing on my system, I'm looking for a non-pre-beta way to use existing TLS and non-TLS b2d iso's with fusion.