I would like to gather feedback before posting this feature spec on the cwiki.
Feature: Add CIFS secondary storage Spec: 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.176.4/my_folder Username and password will be dealt using the current design for NFS secondary storage. Implementation: 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. E.g. mount -t cifs //10.70.176.4/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. Use existing NfsTO object to represent a CIFS data store. The workflows for CIFS and NFS are identical, because they are both mounted on the local file system. Creating a subclass of NfsTO for CIFS should be avoided. This subclass introduces maintenance problems for conditionals that test for NfsTO. In addition, the database schema would probably be affected by a new data store type. In both cases, additional testing is required without any gains. Update setup operations responsible for putting mounting the CIFS share on the local operating system. E.g. the implementation of SecStorageSetupCommand must treat a CIFS scheme URI slightly different. Update validation in API calls and database operations involving NFS URIs. It should be possible to pass a scheme with a CIFS URI. Note that CIFS cannot be used for primary storage. You would need the latest SMB (3.0) for this. Development environment: The work will be done using Quick Cloud secondary storage services. Quick Cloud allows the secondary storage to run as a local service. This makes it quicker to redeploy and to gather feedback such as logs. Quick Cloud would be run local to the management server. This will most likely be a Linux environment. I propose to use logging for debugging. For the most part, I'm not changing the code. 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.
