CI needs "docker-machine snapshot <snapname>" and "docker-machine restore <snapname>" capability

[PaulCharlton]

A typical CI use case involves provisioning a new machine instance, then running tests, then rinse/wash/repeat.

Some CI tests need to run in privileged containers. The fact that that it ran in privileged containers renders the entire machine untrusted from that moment forward.

If a CI application is offered as SaaS, there is no express control over what end users may submit to the CI job-stream. (Example: their CI job is permitted to launch an Android emulator -- privileged with installable kernel drivers), which renders the VM instance untrusted for subsequent CI jobs.

For security and isolation reasons, the machine must be re-provisioned between runs back to a known good state, independently of using the machine's kernel. Creating an entirely fresh "docker-machine create XXX" is the current solution.

For budget and cost reasons, it is preferred to re-use the same VM instance for subsequent runs. (For example, a Digital Ocean droplet has a minimum charge of 1 hour, even if the CI job was only 5 minutes) Reusing the same VM instance can create a cost-saving opportunity of 12x in such a scenario.

This use case can be met by providing a "docker-machine snapshot " which would allow a snapshot to be taken immediately after initial provisioning. Subsequent CI jobs can confidently re-use the same VM instance by performing "docker-machine restore "

Snapshot capability would also be useful in other scenarios, such as debugging, backup/restore, and baseline provisioning of complex application stacks.

[PaulCharlton]

related to #2121 with different use case and requirements

[PaulCharlton]

the CI use case, specifically, can be handled by a "docker-machine reimage '. Other than semantic context, there is little difference between snap/restore and image/reimage.