UPDATE: 2016-03-15

I just closed the PR, the latest comment was to use the built-in docker client and the problem is that the changes were caught in middle of transitioning to engine-api’s client or adding image save support to dockerclient which is what’s being used at the moment. From what I can tell, both have plans or at least open to switching to engine-api so I don’t feel compeled to open PR for image save support on dockerclient so I’ve decided to close the PR for now. Might re-open it in the future if either switches to engine-api, with the built-in ImageSave from engine-api, implementing this would be straigt forward.

UPDATE: 2016-03-12

Cool, it looks like they’re interested with the change. I made some changes on the implementation so it uses local docker client as per the review advice instead of doing it via ssh to vm. Feel free to check the PR for the discussion, I hope this gets merged. ;)

–

A couple of days ago I needed to run two different consul containers, and since it doesn’t work if both resides on the same VM due to the way its consensus algorithm works, I needed to create another VM just for the second one. The problem then is that all my images are on the first VM and pulling them again might take a while since some are quite huge. I ended up manually saving the image from the first VM then loading on the second one and it wasn’t a fun experience since I have handful of images.

So I thought, wouldn’t it be nice if there was an image copy command? So I just opened this PR#3182 which exactly does that. Its basically just a wrapper to the otherwise manual command, you can run it like:

docker-machine scpi [source-machine]:[image][:tag] [destination-machine]

The tag param is optional, if not passed, it defaults to latest and also copying uses the built-in scp command. Not sure if this is ever going to be merged, but it was fun learning how the docker-machine commands work and I’m running this locally now using my custom build.