You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Background:

The Hyper-V hypervisor uses a Windows operating system for it's Dom0 / Parent Partition. This means NFS support is relatively poor. Instead, Windows offers excellent support for CIFS.

To take advantage of CIFS support, a proposal was made to add CIFS to the set of storage types available with CloudStack.

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. Updated, see Design Details below

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. 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.

Design Details

CIFS URL

  • No labels