...

Allow the user to specify CIFS storage by way of a URI. This URI will follow RFC 2986 syntax (see: http://tools.ietf.org/html/rfc3986#section-3). Specifically, the scheme will be "cifs", the authority will name the server hosting the cifs share, and the path will identify the shared folder. E.g. cifs://192.168.1761.4128/my_folder

Username and password will be dealt using the current design for NFS secondary storage. Updated, see Design Details below

...

Use existing secondary storage agent with CIFS secondary storage and deploy using the existing secondary storage workflow. The existing workflow can be
used, because CIFS support is already available on our System VMs. E.g. mount -t cifs //10192.70168.1761.4128/cshv3 CSHV3 /mnt/cifs -o username=administrator,password='my_password' will work in the case of a CIFS share running on a Windows Server 2012 that is not domain joined.

...

The Hyper-V hypervisor will be supported in the first phase. I'm using the existing motion service, so the deciding factor is whether the hypervisor can mount CIFS storage. I haven't looked into this for other hypervisor types other than Hyper-V.

Design Details

Expressing CIFS share in a URI: why? how?

Encoding the CIFS share informatin in URI form allows NFS-centric code to be reused. Existing code takes advantage of URI format and data structures in validation code and database code.

Unfortunately, there is no standard for a URI for CIFS. E.g. smb URI never accepted, see https://datatracker.ietf.org/doc/draft-crhertel-smb-url^{Image Added}

Our alternative to use the existing URI standard, introduce a "cifs" scheme, and encode mount parameters in query parameters.

The scheme will be "cifs". This allows us to mirror existing NFS validation code, which is triggered when a URI's scheme is "nfs"

The CIFS hostname can be comfortably accommodated in the host subcomponent of the URI authority (see http://tools.ietf.org/html/rfc3986#section-3.2.2^{Image Added})

The CIFS share name can be comfortably accommodated by the path path of URI for the share name see (http://tools.ietf.org/html/rfc3986#section-3.3^{Image Added})

E.g. \\192.168.1.128\CSHV3 becomes cifs://192.168.1.128/CSHV3

The CIFS URI needs to capture additional details not required in NFS. E.g. when using the Linux mount command, the user, password and domain of a CIFS share are specified separately to the remote device path using the '-o' parameter. Http query parameters offer a simple solution to passing this information. Recall that an the URI's query is after the '?' that follows the path, see http://tools.ietf.org/html/rfc3986#section-3.4^{Image Added} In our case, query parameters will be key=value pairs, linked by '&', values are URL encoded. See http://en.wikipedia.org/wiki/Query_string#URL_encoding^{Image Added}

E.g. including user=root,password=1pass@word1 would make the URI look like cifs://192.168.1.128/CSHV3?user=root+password=1pass%40word1

Note that username and password are not added to the userinfo section of the URI authority. The URI spec says this is deprecated (see http://tools.ietf.org/html/rfc3986#section-3.2.1^{Image Added} says it's deprecated.)

Note that passing password / username plain text is a short term solution until a secure means of passing the authentication details is introduced.

It is left to the GUI developer to decide how to convert user input to the URI. They will probably hide the encoding from the user.

Sample:

cifs://192.168.1.128/CSHV3?user=root+password=1pass%40word1

corresponds to

mount -t cifs //192.168.1.128/CSHV3 /root/github/cshv3/client/tmp -o 'user=root,password=1pass@word1'