VMware Integrated OpenStack 5.0 | 03 JUL 2018 | Build 8909572
Check for additions and updates to these release notes.
What's in the Release NotesThe release notes cover the following topics:
- About VMware Integrated OpenStack
- What's New
- VMware Integrated OpenStack with Kubernetes
- Upgrading to version 5.0
- Open Source Components for VMware Integrated OpenStack 5.0
- Known Issues
VMware Integrated OpenStack greatly simplifies deploying an OpenStack cloud infrastructure by streamlining the integration process. VMware Integrated OpenStack delivers out-of-the-box OpenStack functionality and an easy configuration workflow through a deployment manager vApp that runs directly in vCenter Server.
VMware Integrated OpenStack 5.0 is available in the following languages:
- Simplified Chinese
- Traditional Chinese
For more information about product language support, see the VMware Product Globalization Guide.
This release is based on the latest OpenStack Queens release and provides the following new features and enhancements:
- Support for the latest versions of VMware products. VMware Integrated OpenStack 5.0 supports and is fully compatible with VMware vSphere 6.7, VMware NSX for vSphere 6.4.1, VMware NSX-T 2.2, vSAN 6.7, vRLI 4.6.0 and vROps 6.7
- Increased scale validation. VMware Integrated OpenStack has been fully validated with 500 physical nodes and 15000 VMs per region, with tests indicating support for even larger scale.
- Keystone Federation. Identity can now be federated across multiple OpenStack regions, enabling unified identities across large scale deployments..
- DNS-as-a-Service. Inclusion of the Designate projects allows self-service DNS and simplifying records management for tenants.
- vGPU enablement. Workloads can now now benefit from hardware acceleration by using GPU enabled instances, increasing performance for HPC, machine learning, graphics processing and streaming.
- Accelerated data plane. Workloads running on VMware Integrated OpenStack can now take full advantage of the new enhanced mode of the Network Virtual Distributed Switch (N-VDS), introduced in vSphere 6.7 and NSX-T 2.2.
- Encryption enabled on HA deployment by default. In order to further secure in-flight data and protect possible sensitive information, VMware Integrated OpenStack can now configure encrypted control plane endpoints.
- Telemetry improvements. The time series database Gnocchi has been added alongside Panko and Aodh to improve OpenStack telemetry performance
- Attached volume snapshots. Cinder now supports taking snapshots of attached volumes.
A container orchestration platform built on Kubernetes is now included with VMware Integrated OpenStack, enabling the privisioning of full infrastructure stacks for application developers. The platform provides the following new features:
- Updated Kubernetes release. VMware Integrated OpenStack 5.0 includes and fully supports Kubernetes version 1.9.8.
- Heterogenous clusters. Kubernetes clusters can now be created with a heterogenous node composition, allowing pods to be deployed to, and taking advantage of, specialized hardware or resources.
- N-VDS enhanced mode support for Kubernetes. The accelerated data plane networking introduced in VMware Integrated OpenStack 5.0, has also been made available to workloads deployed as containers using the Multus plugin.
The VMware Product Interoperability Matrix provides details about the compatibility of the current version of VMware Integrated OpenStack with VMware vSphere components, including ESXi, VMware vCenter Server, the vSphere Web Client, and optional VMware products. Check the VMware Product Interoperability Matrix also for information about supported management and backup agents before you install VMware Integrated OpenStack or other VMware products.
The VMware Integrated OpenStack user interface is compatible with the FLEX or HTML5 web client of the following vCenter Server 6.5 builds:
For vCenter Server 6.7, the UI is compatible with build 8217866, dated 2018-04-17.
Complete multi-step upgrade procedures for both VMware Integrated OpenStack and VMware Integrated OpenStack with Kubernetes upgrades are provided in the product documentation.
Upgrading VMware Integrated OpenStack
You can upgrade directly to VMware Integrated OpenStack 5.0 from a VMware Integrated OpenStack 4.x deployment. Upgrades are documented in the VMware Integrated OpenStack Administration Guide. See Upgrade to VMware Integrated OpenStack 5.0
Upgrading VMware Integrated OpenStack with Kubernetes
To upgrade from VMware Integrated OpenStack with Kubernetes 4.1 to VMware Integrated OpenStack with Kubernetes 5.0, see Upgrade to VMware Integrated OpenStack with Kubernetes 5.0 in the VMware Integrated OpenStack with Kubernetes Getting Started Guide.
Some OMS lifecycle management APIs available in VMware Integrated OpenStack 4.1 and 5.0 will be changed or deprecated in a future major release of VMware Integrated OpenStack.
The SDDC provider in VMware Integrated OpenStack with Kubernetes, intended for deployments without an existing VMware Integrated OpenStack instance, will be deprecated in a future major release. For new VMware Integrated OpenStack with Kubernetes deployments, use the OpenStack provider.
The copyright statements and licenses applicable to the open source software components distributed in VMware Integrated OpenStack 5.0 are available on the Open Source tab of the product download page. You can also download the source files for any GPL, LGPL, or other similar licenses that require the source code or modifications to source code to be made available for the most recent available release of VMware Integrated OpenStack.
The known issues are grouped as follows.VMware Integrated OpenStack
- E-W traffic does not travel between the VMs booted under the virtual-wire type provider network.
If a user directly creates provider network using virtual-wire and does not create spoofguard policy, then E-W traffic will not travel between the VMs booted under this provider network.
Workaround: Create a spoofguard policy and add virtual-wire to this spoofguard policy. Then create a provider network of type virtual-wire.
- Hostname that starts with a number results in "java.io.IOException" error
The OMS server does not support any hostname that starts with number. The error "java.io.IOException: DNSName components must begin with a letter" appears if the hostname starts with a number.
Workaround: None. For more information, see the JDK upstream issue: https://bugs.openjdk.java.net/browse/JDK-8054380
- Failed to launch instances due to "ResourceProviderAggregateRetrievalFailed: Failed to get aggregates for resource provider with UUID xxxxxxxxxxxxxxxxxx"
You cannot launch instances on a compute node where an existing tenant VDC was deleted. For example, the operation fails if you:
- Have tenant VDCs on a compute node before starting the nova-compute service.
- Start the nova-compute service, then delete one or more of the tenant VDCs.
- Attempt to launch an instance on the same compute node.
Workaround: Restart nova-compute service on the compute node.
- Unable to deploy OVA file using vCenter 6.7 H5 web client
When attempting to deploy the VMware Integrated OpenStack OVA using the vCenter 6.7 HTML5 web client, the VMware Integrated OpenStack vApp fails to power on and the UI displays the error: "The virtual machine
has a required vService dependency 'vCenter Extension Installation' which is not bound to a provider."
Workaround. Use the
ovftoolcommand to deploy the OVA files using the FLEX-vsphere-web-client.
NOTE: This is known issue for vCenter 6.7 HTML5 web client and is documented in the vSphere 6.7 Release Notes: https://docs.vmware.com/en/VMware-vSphere/6.7/rn/vsphere-esxi-vcenter-server-67-release-notes.html. Also, a KB for this issue is: https://kb.vmware.com/s/article/55027
- Deleting compute nodes out of order then attempting to add a compute node results in an error
Earlier VMware Integrated OpenStack versions only supported deletion of compute nodes in order of largest to smallest number. For example, with three compute nodes: VIO-compute-0, VIO-compute-1，VIO-compute-2, you would delete VIO-compute-2, VIO-compute-1 first. If you did not delete the nodes in this order, then adding a node later would generate an error.
Workaround: The VMware Integrated OpenStack 5.0 UI supports node deletion in any order. However, the old node deletion and addition error checking code still exists. To work around the problem, delete nodes in order from largest to smallest node number.
- Inaccessible OpenStack deployment due to failure in the data store where nodes are located
In an HA deployment with nodes located in a single data store, if the data store fails, the entire deployment is not accessible.
Workaround: To work around the problem, try to fix the failed data store and recover its data. After the node VMs are back in the vCenter Server, restart the OpenStack deployment. If data is not recoverable use the
viocli recovercommand to restore the failed nodes.
- Keystone endpoint health status appears with a red X
internal_api_protocolin the custom.yml file to enable encryption, the Keystone endpoint does not reconnect with the new Keystone URL. On the OpenStack Configuration page in the vSphere Web Client, the state of the endpoint health is in error with a red X.
Workaround: Select the Keystone endpoint and click the pencil icon to update the configuration. Scroll down to the Update Endpoint screen and perform the following steps:
- Change the URL to https.
- Enter the admin password.
- Click the Update button.
- Nova-compute service fails to start following upgrade to VIO 5.0
A user deletes a nova compute node in VIO 4.x, then adds a new nova compute node with the same vCenter Server and same cluster. After upgrading to 5.0, the nova-compute service fails to start with "ERROR nova ResourceProviderCreationFailed" in /var/log/nova/nova-compute.log.
Workaround: Perform the following steps to remove the nova compute node from the database.
- Find the MOID of the deleted compute node.
- Log into MySQL on the database node.
- Switch to the nova_api database with the SQL command
- In the "resource_providers" table, remove the resource_provider record with the MOID of the deleted compute node.
- In the "host_mappings" table, remove the host record for the deleted compute node.
- Delete router interface ends with timeout
When concurrent heat stacks are deployed with shared-type NSX routers which is the default deployment, router interface deletion can timeout. Timeouts may be:
Workaround: While timeouts can be tuned or increased, do not use shared-type routers in environments with frequent changes to network resources, for example where resources are frequently added or deleted. Use either an exclusive-type router if NAT/FIP is required, or use a distributed-type router.
- Attempting to re-add a deleted compute node with tenant VDCS fails
After successfully deleting a compute node with tenant VDCS, attempting to re-add it fails with a "Failed to create resource provider" error in /var/log/nova/nova-compute.log.
Workaround: After deleting the compute node, perform the following steps to remove it from the database before re-adding it.
- Find the MOID of the deleted compute node.
- Log into to MYSQL on the database node.
- Switch to the nova_api database with the SQL command
use nova_apiand remove the resource_provider record with MOID of the deleted compute node and all its children from the "resource_providers" table.
- Authentication fails with a username or domain containing '\'.
The Keystone authentication plugin uses the backslash character as a separator to encode the domain name and username in a single string
. If there is an additional backslash in either the domain name or username, the Keystone authentication plugin will not decode the domain name and username correctly.
Workaround: Use domain names or usernames that do not include the backslash character.
- Failed to delete cluster in ERROR state
If the infrastructure is out of resources, cluster creation, healing, or scaling will fail and the cluster will fall into an ERROR state.
Workaround: To correct this problem, perform the following steps:
- Run bash on the toolbox container
- Use the OpenStack client to delete hosts in the ERROR state.
- Re-run the command:
vkube cluster delete