The answer is an emphatic yes. One can absolutely use storage policies with vSphere Integrated Containers (VIC). However, there is currently no way to specify a policy at the docker CLI when creating a container (at this time). Therefore one would have to deploy the VCH, then deploy the container, and then finally modify the storage policy as appropriate. My understanding is that consideration is being given to a way to do this at deployment time, but at the present, it involves a number of steps. Let’s discuss them in turn.

First off, the containers would need to be deployed on a datastore that can consume policies. Let’s take vSAN as an example. When deploying the VCH (Virtual Container Host) you must specify the container-store. At the moment, this defaults to the same as the image-store, but this should change going forward. Now that the image-store is a vsanDatastore, then containers are also deployed to the vsanDatastore, with a default policy. Here is the complete deployment of the VCH, where the image-store (and conversely the container-store) is specified as a vsanDatastore:

root@photon-NaTv5i8IA [ /workspace/vic ]# ./vic-machine-linux create \ --bridge-network Bridge-DPG --image-store vsanDatastore \ -t 'administrator@vsphere.local:VMware123!@10.27.51.103' \ --compute-resource Mgmt INFO[2016-11-01T12:16:29Z] ### Installing VCH #### INFO[2016-11-01T12:16:29Z] Generating certificate/key pair \ - private key in ./virtual-container-host-key.pem INFO[2016-11-01T12:16:29Z] Validating supplied configuration INFO[2016-11-01T12:16:29Z] vDS configuration OK on "Bridge-DPG" INFO[2016-11-01T12:16:29Z] Firewall status: DISABLED on \ "/CNA-DC/host/Mgmt/10.27.51.10" INFO[2016-11-01T12:16:29Z] Firewall status: DISABLED on \ "/CNA-DC/host/Mgmt/10.27.51.8" INFO[2016-11-01T12:16:29Z] Firewall status: DISABLED on \ "/CNA-DC/host/Mgmt/10.27.51.9" INFO[2016-11-01T12:16:29Z] Firewall configuration OK on hosts: INFO[2016-11-01T12:16:29Z] "/CNA-DC/host/Mgmt/10.27.51.10" INFO[2016-11-01T12:16:29Z] "/CNA-DC/host/Mgmt/10.27.51.8" INFO[2016-11-01T12:16:29Z] "/CNA-DC/host/Mgmt/10.27.51.9" INFO[2016-11-01T12:16:30Z] License check OK on hosts: INFO[2016-11-01T12:16:30Z] "/CNA-DC/host/Mgmt/10.27.51.10" INFO[2016-11-01T12:16:30Z] "/CNA-DC/host/Mgmt/10.27.51.8" INFO[2016-11-01T12:16:30Z] "/CNA-DC/host/Mgmt/10.27.51.9" INFO[2016-11-01T12:16:30Z] DRS check OK on: INFO[2016-11-01T12:16:30Z] "/CNA-DC/host/Mgmt/Resources" INFO[2016-11-01T12:16:31Z] Creating virtual app "virtual-container-host" INFO[2016-11-01T12:16:31Z] Creating appliance on target INFO[2016-11-01T12:16:31Z] Network role "external" is sharing NIC with "management" INFO[2016-11-01T12:16:31Z] Network role "client" is sharing NIC with "management" INFO[2016-11-01T12:16:35Z] Uploading images for container INFO[2016-11-01T12:16:35Z] "bootstrap.iso" INFO[2016-11-01T12:16:35Z] "appliance.iso" INFO[2016-11-01T12:16:38Z] Registering VCH as a vSphere extension INFO[2016-11-01T12:16:46Z] Waiting for IP information INFO[2016-11-01T12:17:01Z] Waiting for major appliance components to launch INFO[2016-11-01T12:17:09Z] Initialization of appliance successful INFO[2016-11-01T12:17:09Z] INFO[2016-11-01T12:17:09Z] vic-admin portal: INFO[2016-11-01T12:17:09Z] https://10.27.51.18:2378 INFO[2016-11-01T12:17:09Z] INFO[2016-11-01T12:17:09Z] DOCKER_HOST=10.27.51.18:2376 INFO[2016-11-01T12:17:09Z] INFO[2016-11-01T12:17:09Z] Connect to docker: INFO[2016-11-01T12:17:09Z] docker -H 10.27.51.18:2376 --tls info INFO[2016-11-01T12:17:09Z] Installer completed successfully root@photon-NaTv5i8IA [ /workspace/vic ]#

Let’s take a look at the VCH storage policy. We can clearly see that it is using the default storage policy for Virtual SAN.

Next, lets deploy a container. In this example, we will deploy an Ubuntu image and drop into a bash shell:

root@photon-NaTv5i8IA [ /workspace/vic ]# docker -H 10.27.51.18:2376 --tls run \ -it ubuntu bash Unable to find image 'ubuntu:latest' locally Pulling from library/ubuntu a3ed95caeb02: Pull complete 6bbedd9b76a4: Pull complete fc19d60a83f1: Pull complete de413bb911fd: Pull complete 2879a7ad3144: Pull complete 668604fde02e: Pull complete Digest: sha256:312986132029d622ae65423ca25d3a3cf4510de25c47b05b6819d61e2e2b5420 Status: Downloaded newer image for library/ubuntu:latest root@6c8d6a4add24:/# root@6c8d6a4add24:/# ls bin boot dev etc home lib lib64 lost+found media mnt opt proc root \ run sbin srv sys tmp usr var root@6c8d6a4add24:/#

Let’s take a look at what this looks like from a storage policy perspective. Remember, one of the great benefits of VIC is that we get full visibility into our container, as it looks just like a VM:

We can clearly see that this “container as a VM” has been deployed to the vSAN datastore and has also picked up the default vSAN datastore policy. Now we can easily go in and edit the settings of this “container as a VM” and change the policy of its VMDK to something else. For example, I can set this to a non-default policy called FTT=1, even though it achieves the same availability as the default policy. Now if I look at the compliance state, I see two policies:

The reason why we see two policies is because the default policy is still associated with the VM Home object, but the VMDK object now has the new FTT=1 policy. This can be seen in greater detail if we navigate to the Monitor > Policies view, and look at the physical placement of the VMDK object, as shown here:

So there you have it. As a vSphere admin, not only do you have full visibility into the “containers as VMs” deployed via VIC, but you can also make VIC containers highly available from a storage persistent perspective. You can do this by deploying these containers on a storage system that is policy driven, such as vSAN. And you can then modify the policies according to your requirements.