vSphere Integrated Containers Engine Version v1.2.1-rc2

Changes from 1.2.0
v1.2.0...v1.2.1-rc2

vSphere Integrated Containers Engine Version v1.2.1-rc1

Changes from 1.2.0
v1.2.0...v1.2.1-rc1

vSphere Integrated Containers Engine Version v1.2.0 GA

v1.2.0 is tagged on releases/1.2.0 branch

Changes from v1.1.1 v1.1.1...v1.2.0

New Features

• Reconfigure deployed virtual container hosts (VCHs). Read more
• Improved functionality for the vSphere administrator in the vSphere Client. Read more
• A fully functional Docker Engine in vSphere Integrated Containers, that allows developers and cloud admins to deploy docker container hosts. Read more
• Support for the Docker commit, diff, stats, and cp commands. Read more

Resolved Issues

The following issues found in vSphere Integrated Containers Engine 1.1.1 have been fixed in 1.2.0:

• HTML5 vSphere Client plug-in does not work with vCenter Server 6.5u1. #6052
  If you deployed the HTML5 vSphere Client plug-in for vSphere Integrated Containers with vCenter Server 6.5.0, and then subsequently upgraded vCenter Server to version 6.5u1, the plug-in no longer works. Attempts to install the HTML5 plug-in on vCenter Server 6.5u1 fail.

• Cannot login to insecure registries that use self-signed certificates. #4681
  If you deploy a VCH with the --insecure-registry option, and if that registry uses self-signed certificates, attempts to use docker login to log in to the registry fail with Error response from daemon: Unexpected http code: 400, URL: http://X.X.X.X:443/v2/. However, performing docker pull from that registry without attempting docker login succeeds.

• Docker client 1.13 returns an incorrect error message on non-existent objects. #4573
  If you run a Docker command against a non-existent object, for example docker inspect fake, where fake is an object that does not exist, vSphere Integrated Containers Engine reports Error response from daemon: vSphere Integrated Containers does not yet support Docker Swarm. The error message should be Error: No such image, container or task: fake.

• Shared data volumes are not supported. #2303
  vSphere Integrated Containers Engine does not support shared data volumes, meaning that multiple containers cannot share a common vSphere volume. As a consequence, using vSphere Integrated Containers Management Portal to provision applications that include containers that share volumes fails when using vSphere Integrated Containers Engine, with the error Server error from portlayer: Failed to lock the file. Do not design or import such templates in vSphere Integrated Containers Management Portal and do not attempt to deploy applications based on such templates when using vSphere Integrated Containers Engine.
  Fix is using NFSv3 based shared volumes - see example vic-machine command with NFS volume store

• VCH Admin portal does not respect proxy settings. #4557
  This affects is the internet connectivity status on the VCH Admin portal, which does not use the proxy used by the rest of the VCH.

• Specifying the same datastore for volume store and images store leads to unintended volume loss on ESXi hosts. #4478
  When deploying VCHs directly to ESXi hosts, if you specify vic-machine create --name dev --image-store datastore1 --volume-store datastore1/dev:default, volumes will go into the same folder as images and the VCH. If you then run vic-machine delete, the volumes are deleted, even if you do no specify --force. This does not occur when deploying to vCenter Server.

• Containers have access to vSphere management assets. #3970
  Containers that are attached to the bridge network can use NAT through the VCH and so have full access to assets on the management and client networks, or they can be reached via the gateway on those networks. As a consequence, any container can access to vSphere assets.

• Deleting container VMs by using the vSphere Client can remove the underlying image. #2928
  If you delete a container VM by using the vSphere Client, attempts to create other containers that use the same base image containers can fail if the base image has been removed.

• Mounting directories as a data volume using the -v option is not supported. #2303

Known Issues

• Gateway information is missing from docker inspect. #6010
  If you configured a container network on a VCH, if this network uses DHCP, and if you did not specify --container-network-gateway, the gateway is configured correctly but does not show up in the output of docker inspect commands that are run on containers on that network.

• Schema 2 image manifests not supported. #5187
  vSphere Integrated Containers Engine does not support pulling images that only have schema 2 image manifests. If an image registry offers only the schema 2 manifest for an image, pull operations fail. This is most commonly seen when pulling an image by digest.

• docker exec always returns 0 and ignores the exit code of processes. #5692
  docker exec always returns 0, even if you specify -it. This is potentially due to a delay in vSphere host synchronization.

• Container VMs deleted between upgrading and rolling back an upgrade on a VCH show up in docker ps. #5754
  If you upgrade a VCH, perform vic-machine delete on container VMs, then use vic-machine upgrade --rollback to revert the VCH to the previous version, the cache information in the VCH is reverted. However, the deleted container VM cannot be reverted, so if you run docker ps, the deleted container VMs are listed.

  Workaround: Restart the VCH endpoint VM in the vSphere Client.

• ifconfig only shows eth0 when a container connects to multiple bridge networks. #5990
  If you create multiple bridge networks and connect a container to them, running ifconfig on that container only returns the details of eth0. The networks function correctly, but the output information of ifconfig is incomplete.

• docker diff does not fully work with all containers. #6059
  Running docker diff on certain containers, for example postgres, results in Error response from daemon: Server error from portlayer: Server error from portlayer: Server error from archive reader for device.

• Cannot delete images using image ID after restarting VCH. #6076
  If you pull images into a VCH, then restart that VCH, running docker rmi image_ID results in Error response from daemon: No such image.

  Workaround: Delete images by using the human-readable name.

• docker info does not report secure registries. #6256
  Running docker info on a VCH reports any registries that you have whitelisted, but does not report secure registries that you specified with vic-machine create --registry-ca.

• Enabling content trust in Management Portal does not work if a VCH is in whitelist mode. #6258
  If you install a VCH with whiltelist mode enabled, attempting to a enable content trust on a vSphere Integrated Containers Registry in Management Portal does not update the whitelist, and you cannot pull from that registry.

• docker stop fails with error about collision of concurrent operations.#6236
  Error response from daemon: Conflict error from portlayer... collision of concurrent operations. This error is due vSphere Integrated Containers Engine not obtaining the up-to-date power state of the container VM from vCenter Sever in a slow environment. The container VM is already powered off but vCenter Server assumes that it is running, which causes the conflict error. vSphere Integrated Containers Engine obtains the latest power state of the container VM after some time.

  Workaround: Retry the docker stop operation after a few minutes.

• Running docker create results in InvalidDeviceSpec. #4666
  When attempting to create a VMDK for the read-write layer of a container during docker create, the parent VMDK sometimes cannot be accessed or located, resulting in an InvalidDeviceSpec fault. This is specific to vSAN datastores.

  Workaround: Attempt to create the container again.

• Publishing all exposed ports to random ports with the -P option is not supported. #3000
  vSphere Integrated Containers Engine does not support docker create/run -P.

• Occasional disconnection during vMotion. #4484
  If you a...

vSphere Integrated Containers Engine Version v1.2.0-rc5

Release candidate 5 tag.

vSphere Integrated Containers Engine Version v1.2.0-rc4

Cherry pick : Reset session status on tether init (#6202)

We were not reinitializing session status on out-of-band power
operations, meaning we hit a filter in the launch logic that skipped
launching the container process.

Additional tests to follow

vSphere Integrated Containers Engine Version v1.2.0-rc3

Never releaseed

Do not use - vSphere Integrated Containers Engine Version v1.2.0-rc2

Do not use

VIC next release development

v1.3.0-dev

updating to 1.2 license (#6089)

vSphere Integrated Containers Engine Version v1.2.0-rc1

Changes from 1.1.1
v1.1.1...v1.2.0-rc1

vSphere Integrated Containers Engine Version v1.1.1

v1.1.1 is tagged on releases/1.1.1 branch

Changes from v1.1.0 v1.1.0...v1.1.1

This is an interim pre-release and does not include support from VMware global support services (GSS). Support is OSS community level only. See https://github.com/vmware/vic/blob/master/CONTRIBUTING.md#community for details on how to contact the VIC Engine community.

Resolved Issues

The following issues found in vSphere Integrated Containers Engine 1.1.0 have been fixed in 1.1.1:

• Container VMs immediately power off with Server error from portlayer: ServerFaultCode: Permission to perform this operation was denied. #4817
  This error results if the --ops-user option was used when deploying VCHs. Operations user accounts require more permissions than were initially documented. The list of required permissions in Use Different User Accounts for VCH Deployment and Operation has been updated to include all of the required permissions.
• Race condition in vSAN can cause VCH kvstore to enter an inconsistent state. #4601
  
  VCHs store the key-value state for the VCH in a file on the datastore named kvstore. When values are updated a new version is uploaded as kvstore.tmp, which then overwrites the existing file. Race conditions can occur in VSAN if you upload a file and then quickly move that file.
  If this condition occurs, the kvstore of the VCH can enter an inconsistent state. If this error occurs you see the following error:

  Error response from daemon:
  
  failed to save image cache: [PUT /kv/{key}][500]
  
  putValueInternalServerError  &{Code:500 Message:Error uploading apiKV.dat:
  
  File [vsanDatastore] 5568e458-4f51-10c5-3994-020...

  This error mostly occurs when running docker rmi, but could also occur when performing docker pull, docker run, or docker create on a new image.
• Installing vSphere Client plug-in fails on VCSA. #4906
  When you attempt to install the vSphere Client plug-in for vSphere Integrated Containers on a vCenter Server Appliance, the installation fails with the error failed to find target plugin.
• vSphere Web Client plug-in does not appear after successful installation. #4948
  When you install the Flex plug-in for the vSphere Web Client, the installation process reports success but the plug-in does not appear in the vSphere Web Client.
• vSphere Integrated Containers Engine files not upgraded. #5013
  If you upgrade the vSphere Integrated Containers appliance from 1.1.0 to 1.1.1, vSphere Integrated Containers Registry and Management Portal upgrade successfully, but the downloads for vSphere Integrated Containers Engine remain at 1.1.0.

Known Issues

• vRealize Automation cannot create VCH blueprints that use bridge network. #3542
  vRealize Automation cannot create blueprints for VCHs that have either on-demand or existing bridge networks. If you deploy such blueprints, containers cannot be reached over the network. Only the default bridge network works in the VCH.

  Workaround: Use container networks instead of bridge networks in VCH blueprints.

• HTML5 vSphere Client plug-in does not work with vCenter Server 6.5u1. #6052
  If you deployed the HTML5 vSphere Client plug-in for vSphere Integrated Containers with vCenter Server 6.5.0, and then subsequently upgraded vCenter Server to version 6.5u1, the plug-in no longer works. Attempts to install the HTML5 plug-in on vCenter Server 6.5u1 fail.

  Workaround: This issue is resolved in vSphere Integrated Containers 1.2. Upgrade to vSphere Integrated Containers 1.2, upgrade the HTML5 vSphere Client plug-in, and restart the vSphere Client service. For information about upgrading to vSphere Integrated Containers 1.2, see Upgrading vSphere Integrated Containers.

• vSphere Client plug-ins do not install on vCenter Server for Windows. #5204
  When you run the /vic/ui/vCenterForWindows/install.bat script to install either the HTML5 or Flex plug-ins for the vSphere Client, the installer reports success and the plug-in successfully registers as a vCenter Server extension, but the plug-ins do not appear in the vSphere Client or vSphere Web Client. An error in install.bat prevents the plug-in files from uploading to vCenter Server.

  Workaround: Open install.bat in a text editor and insert a missing v character before %version%.zip in the following line:

  • Before: SET PLUGIN_URL=%vic_ui_host_url%%key%-%version%.zip
  • After: SET PLUGIN_URL=%vic_ui_host_url%%key%-v%version%.zip

  Then run install.bat.

• Running docker create results in InvalidDeviceSpec. #4666
  When attempting to create a VMDK for the read-write layer of a container during docker create, the parent VMDK sometimes cannot be accessed or located, resulting in an InvalidDeviceSpec fault. This is specific to vSAN datastores.

  Workaround: Attempt to create the container again.

• Cannot login to insecure registries that use self-signed certificates. #4681
  If you deploy a VCH with the --insecure-registry option, and if that registry uses self-signed certificates, attempts to use docker login to log in to the registry fail with Error response from daemon: Unexpected http code: 400, URL: http://X.X.X.X:443/v2/. However, performing docker pull from that registry without attempting docker login succeeds.

  Workaround: Download the self-signed certificate from the registry and redeploy the VCH, specifying the path to this certificate in the --registry-ca option.

• Docker client 1.13 returns an incorrect error message on non-existent objects. #4573
  If you run a Docker command against a non-existent object, for example docker inspect fake, where fake is an object that does not exist, vSphere Integrated Containers Engine reports Error response from daemon: vSphere Integrated Containers does not yet support Docker Swarm. The error message should be Error: No such image, container or task: fake.

• Publishing all exposed ports to random ports with the -P option is not supported. #3000
  vSphere Integrated Containers Engine does not support docker create/run -P.

• Shared data volumes are not supported. #2303
  vSphere Integrated Containers Engine does not support shared data volumes, meaning that multiple containers cannot share a common vSphere volume. As a consequence, using vSphere Integrated Containers Management Portal to provision applications that include containers that share volumes fails when using vSphere Integrated Containers Engine, with the error Server error from portlayer: Failed to lock the file. Do not design or import such templates in vSphere Integrated Containers Management Portal and do not attempt to deploy applications based on such templates when using vSphere Integrated Containers Engine.

• Occasional disconnection during vMotion. #4484
  If you are attached to a container VM that is migrated by vMotion, the SSH connection to the container VM might drop when vMotion completes.

  Workaround: Perform docker attach after the vMotion completes to reattach to the container.

• Using volume labels with docker-compose causes a plugin error. #4540
  Setting a label in a volume in the Docker compose YML file results in error looking up volume plugin : plugin not found.

  Workaround: Set the volume driver explicitly as local or vsphere in the compose file. E.g.,

  volumes:
    volume_with_label:
      driver: local
  

• VCH Admin portal does not respect proxy settings. #4557
  This affects is the internet connectivity status on the VCH Admin portal, which does not use the proxy used by the rest of the VCH.

• vSphere Integrated Containers Management Portal cannot pull images from an insecure vSphere Integrated Containers instance when creating a container using vSphere Integrated Containers Engine. #4706
  Creating a container in vSphere Integrated Containers Management Portal with vSphere Integrated Containers Engine as the only Docker host results in the error certificate signed by unknown authority.

  Workarounds: Specify the vSphere Integrated Containers Registry port when you set the vic-machine create--insecure-registry option, or provide a CA certificate in the --registry-ca option.

• Specifying the same datastore for volume store and images store leads to unintended volume loss on ESXi hosts. #4478
  When deploying VCHs directly to ESXi hosts, if you specify vic-machine create --name dev --image-store datastore1 --volume-store datastore1/dev:default, volumes will go into the same folder as images and the VCH. If you then run vic-machine delete, the volumes are deleted, even if you do no specify --force. This does not occur when deploying to vCenter Server....