Known Issues

General Issues

Fresh installation of CSE 2.5.1 or below via pip install is broken

CSE 2.5.1 or below versions have an open-ended dependencies, which permit pip to pull and install latest versions of the dependencies. Two such dependencies are pyvcloud and vcd-cli, and their latest available versions are incompatible with CSE 2.5.1 or below. We are reviewing our design on dependencies, and hope to bring improvements in near future.

Workaround: - Uninstall incompatible pyvcloud and vcd-cli libraries, and manually install compatible versions.

# Un-install pyvcloud and vcd-cli
pip3 uninstall pyvcloud vcd-cli --user --yes

#Install specific version of the libraries which are compatible with CSE 2.5.1 and CSE 2.0.0
pip3 install pyvcloud==21.0.0 vcd-cli==22.0.0 --upgrade --user

vcd cse ovdc list operation will timeout when a large number of organization VDCs exist

CSE makes an API call per organization VDC in order to access required metadata, and that can timeout with large number of VDCs.

Example - Trying to use vcd cse ovdc list with 250+ VDCs:

vcd cse ovdc list
Usage: vcd cse ovdc list [OPTIONS]
Try "vcd cse ovdc list -h" for help.

Error: Unknown error. Please contact your System Administrator

Workaround: extend the cell timeout to be able to wait for the required amount of time. See the section ‘Setting the API Extension Timeout’ under CSE Server Management.

CSE server fails to start up after disabling the Service Provider Access to the Legacy API Endpoint

Workaround: Don’t disable Service Provider Access to the Legacy API Endpoint

vCD 10.0 deprecates the /api/sessions REST end point, and introduces a new /cloudapi/ based REST endpoint for authenticating vCD users. CSE relies on the ‘/api’ end point for operations, so it is necessary that the legacy API endpoint is not disabled in vCloud Director.

More details

Failures during template creation or installation

CSE service fails to start

CSE 1.2.6 and up are incompatible with vCD 9.0

Cluster creation fails when vCD external network has a DNS suffix and the DNS server resolves to a valid IP

This is due to a bug in etcd (More detail HERE, with the kubeadm config file contents necessary for the workaround specified in this comment).

The main issue is that etcd prioritizes the DNS server (if it exists) over the /etc/hosts file to resolve hostnames, when the conventional behavior would be to prioritize checking any hosts files before going to the DNS server. This becomes problematic when kubeadm attempts to initialize the master node using localhost. etcd checks the DNS server for any entry like localhost.suffix, and if this actually resolves to an IP, attempts to do some operations involving that incorrect IP, instead of localhost.

The workaround (More detail HERE is to create a kubeadm config file (no way to specify listen-peer-urls argument in command line), and modify the kubeadm init command in the CSE master script for the template of the cluster you are attempting to deploy. CSE master script is located at ~/.cse-scripts/<template name>_rev<template_revision>/scripts/

Change command from, kubeadm init --kubernetes-version=v1.13.5 > /root/kubeadm-init.out to kubeadm init --config >/path/to/kubeadm.yaml > /root/kubeadm-init.out

Kubernetes version has to be specified within the configuration file itself, since --kubernetes-version and --config are incompatible.

NFS Limitations

Currently, NFS servers in a Kubernetes cluster are not only accessible by nodes of that cluster but also by any VM (outside of the cluster) residing in the same orgVdc. Ideal solution is to have vApp network created for each Kubernetes cluster, which is in our road-map to implement. Until then, please choose one of below workarounds to avert this problem if the need arises.

Enterprise PKS Limitations