Named remote volumes

This Proposal assumes that some variation on docker volumes cli cmd
is merged.

This is also a follow on proposal for fuse based Remote Shared Volumes

UI changes

Add extra parameters to docker volumes create:

-s/--storage-driver=(*vfs*|vbox|rsync|nfs|sshfs|samba|fuse|andrewfs|*) - filesystem type to mount (vfs is what we use atm)
-o/--options="mount options"
-p/--password - prompt for password
--create - set up the share (some storage drivers may be able to create the share - like the vbox user share)

For example:

docker volumes create --name data --path //server/data --storage-driver smb --options "rw,relatime,vers=1.0,sec=ntlmssp,cache=strict,username=sven,domain=SVENS-MAC-MINI,uid=1000,forceuid,gid=100,forcegid,addr=10.10.10.14,file_mode=0755,dir_mode=0755,nounix,noperm,rsize=61440,wsize=65536,actimeo=1" --password
> Enter smb password for `sven`:

To define the current boot2docker Users share:

docker volumes create --name home --path $HOME --storage-driver vbox --create
# fuse based
docker volumes create --name home --path $HOME --storage-driver fuse --create

and then using the aliased volume

docker run -d -v home:/home/sven ubuntu bash

What the user is doing, is setting up an alias to a possibly remote resource.
When an alias is used, its cfg needs to be sent to the daemon, so it can
instanciate the volume, and persist that connection as well as possible.

Some kind of restart policy needs to be worked out when the resource is
not available.

Remote Docker daemon volumes

When the docker client detects that its talking to a non-local deamon, it can create the necessary volume on the fly for both docker build and docker run, choosing whatever reasonable defaults work for that platform. (docker hosts will give us more meta info to make the right choices)

Config store

The alias->type and settings needs to be stored both on the client side, and on any daemon that has containers that use it.

The config needs to be semi-secure, as it will container passwords in some
instances.

Possible implementation

Implement storage drivers which mount into /var/lib/docker/<driver>.

The major change is to allow the Docker daemon to use more than one storage driver at any one time.

From the little code reading i've done, the basic Storage driver could be enough, and I think we have to make the volume mounting into the container be recursive.

awesome side effect :)

This means that we won't be creating a new API for volumes to be coded against, we're using the existing one - so a Gluster, Ceph driver can be implmented now, and will be accessible as a volume backend as soon as we implement the extra /volume API endpoints.