VMware Integrated OpenStack 3.1.0.2 | 24 OCT 2017 | Build 6902555

Check for additions and updates to these release notes.

What's in the Release Notes

The release notes cover the following topics:

About VMware Integrated OpenStack

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.

Internationalization

VMware Integrated OpenStack version 3.1 is available in English and seven additional languages: Simplified Chinese, Traditional Chinese, Japanese, Korean, French, German, and Spanish. ASCII characters must be used for all input and naming conventions of OpenStack resources (such as project names, user names, image names, and so on) and for the underlying infrastructure components (such as ESXi hostnames, virtual switch port group names, data center names, datastore names, and so on). 

What's New

This patch set introduces two minor enhancements previously not available in the 3.x series.

Add flag to force resize on same node. 

In some special cases, it might be needed to force a resize to take place on the same host and not move the workload. An optional flag, always_resize_on_same_host,  was added to address this. 

Host group edge management 

To reduce complexity and ease the burden of managing edges, two global groups are created for active and standby edges instead of one group per edge. Also, group creation is atomic and the backing VM is deleted automatically when the edge is deleted. 

Compatibility

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.

Upgrading to VMware Integrated OpenStack 3.1.0.2

To upgrade to version 3.1.0.2 from version 3.1, you install and apply the 3.1.0.2 patch (3.1.0.2 Build 6902555) to your existing deployment.

The following procedures assume you have installed version 3.1. Install the patch by using CLI commands.

NOTE: You cannot upgrade to 3.1.0.2 from version 3.0.x. If your current deployment is version 3.0.x, you must first upgrade to version to 3.1. See the VMware Integrated OpenStack 3.1 Release Notes.

Perform the following steps to install the patch:

  1. Obtain the patch (3.1.0.2 Build 6902555).

    1. Log in to the VMware Integrated OpenStack management server.

    2. Download the debian file for the patch.

    3. Add the patch with the following command:​
      viopatch add -l [path to the debian file]

      NOTE: An existing Adobe bug might prevent uploading the file using Firefox. For more information, see  Problem uploading patch file in Firefox Web Browser under Known Issues.
    4. Confirm that the patch was successfully added:
      viopatch list
      This command returns a list of available patches, including version numbers, types, and current status.

  2. Install the patch.

    1. Verify that the VMware Integrated OpenStack service is either running or not yet deployed. If the VMware Integrated OpenStack service is in any other state, the upgrade will fail.

    2. Log in to the VMware Integrated OpenStack management server and run the following command:
      viopatch install -p vio-patch-3102 -v 3.1.0.6902555
      The patch installation takes up to 15 minutes to complete.
      NOTE: During the patch installation, the API endpoint is automatically turned off. As a result, any API calls during installation will return a 503 error.

  3. To complete the update, log out of the vSphere Web Client and log in again. Ignore any error messages you encounter when logging back in.

  4. (Optional) If necessary you can revert to an earlier patch version by uninstalling the patch.

    1. Log into the VMware Integrated OpenStack management server and run the following command:
      viopatch uninstall -p vio-patch-3102 -v 3.1.0.6902555
      The revert process takes up 15 minutes to complete.

    2. After uninstalling the patch, you must restart the vSphere Web Client service on the vCenter Server to downgrade the VMware Integrated OpenStack plug-in. For information about restarting vCenter Server appliance services, see KB 2054085.

Open Source Components for VMware Integrated OpenStack 3.1.0.2

The copyright statements and licenses applicable to the open source software components distributed in VMware Integrated OpenStack 3.1.0.2 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.

Resolved Issues

  • When instance is resized, it is moved to another compute host (vCenter cluster).

    The Nova scheduler may decide to move the instance to another host during resize

    This issue is resolved in this release.

  • Volume creation fails after a time period of 30 minutes with no volume operations

    The vCenter session created by OpenStack Cinder expires if there are no volume operations for 30 minutes. The session is not re-created and as a result volume create operations will fail.

    This issue is resolved in this release.

  • Volume retype does not change the policy of the virtual disk in volume shadow VM

    During volume retype, if the destination volume type has a different storage policy, the new storage policy is applied only to the volume shadow VM's configuration. The storage policy of the vmdk remains unchanged.

    This issue is resolved in this release.

  • Duplicate edges following upgrade from 3.1 to 3.1.0.2

    Redundancy backup edges are created in Neutron database.

    This issue is resolved in this release.

  • LDAP configuration fails

    During LDAP configuration, the LDAP port value is passed to the backend from UI. The default port value is 636. Even if the user defines a different port value, the UI always passes 636.

    This issue is resolved in this release.

  • Failure reported when running the command "viocli inventory-admin sync-availability-zones"

    viocli inventory-admin sync-availability-zones should only return a result if 'Compute' is in in the node_group['roles'].

    This issue is resolved in this release.

  • When migrating across compute clusters backed by independent VDS networks, live migration fails

    With two different distributed virtual switches for each cluster, a VMware Integrated OpenStack instance cannot communicate with the network following a live migration.

    This issue is resolved in this release.

  • Network connections through floating IPs are lost when router_type is changed from shared to exclusive

    Following a migration, floating IP addresses are not in the exclusive router external interfaces.

    This issue is resolved in this release. 

  • Deleting the default domain removes users and breaks Keystone v2 API access

    VMware Integrated OpenStack populates the default domain with AD/LDAP and SQL-based users. Because services and APIs rely on the default domain for information, it should never be deleted.

    This issue is addressed in this release.

  • OpenStack reports less free storage space than actually available

    Nova chooses the wrong datastore when reporting free space

    This issue is resolved in this release.

Known Issues

  • New Tenants traffic might get blocked after enabling NSX policies in Neutron

    After enabling security-group-policy in the Neutron plug-in, the NSX firewall sections order might be wrong. The correct order must be:

    1. NSX policies
    2. Tenants security groups
    3. Default sections

    Workaround: Create the first NSX policy before configuring VMware Integrated OpenStack. If you have already made configurations, go to the NSX Firewall page in the vSphere Web Client and move the policies sections up.

  • Provider network creation through horizon fails if no UUID of a transport zone is entered

    When you create VLAN type networks, it is mandatory that you provide the UUID value for the transport zone in the provider_network text box in horizon. If no value is entered, network creation fails.

    Workaround: See the UUID of the transport zone in your VMware NSX interface and enter that value in the provider_network text box.

  • Metadata is not accessible for a DHCP disabled subnet on a distributed logical router

    Instances on DHCP disabled subnets cannot access metadata through the interface of the router if a distributed logical router is used. This behavior is not observed for shared and exclusive routers. This might be an expected behavior since same logical networks, for example metadata networks, cannot be attached to multiple distributed logical routers.

    Workaround: None.

  • When you boot from a glance image created using the Ubuntu Xenial OVA, the OS fails to boot

    The OS fails to boot with the following errors:

    error: file `/boot/grub/i386-pc/efi_gop.mod' not found
error: file `/boot/grub/i386-pc/efi_uga.mod' not found

    This is an issue with the Xenial cloud OVA that is tracked by a bug in the Ubuntu cloud-images project, for more inforamtion see https://bugs.launchpad.net/cloud-images/+bug/1615875.

    Workaround: Until the Ubuntu bug is resolved and new OVA is published, use Xenial ISO images.

  • LBaaS v2 fails when you add members to a pool that is created with the --loadbalancer option

    OpenStack LBaaS v2 provides two options to configure a loadbalancer pool: --loadbalancer and --listener. At least one of the two option must be specified to create the pool.
    If you create the pool for the OpenStack LBaaS v2 with the --loadbalancer option, addition of members fails and the loadbalancer goes to an ERROR state.

    Workaround: Create the pool with the --listener option.

  • Renamed OpenStack instances appears under the old name in vCenter Server

    If you rename your OpenStack instance by using the nova rename command, changes appear only in the OpenStack database. Your vCenter Server instance shows the old name.

    Workaround: None

  • Availability zone configuration might not be successfully applied

    After you modify the configuration of an availability zone, the new configuration might not be applied until the backup edges are deleted and recreated.

    For example, the following configuration in the nsx.ini file features an availability zone that has backup edges:
    zone3:resgroup-163:datastore-12:true:datastore-21
    If you change the resource pool of that zone and restart Neutron, the backup edges won't be updated. If you deploy new routers or networks, they will use the out-of-date backup edges that leads to inconsistent availability zone configuration.

    Call the admin utilities after you change the configuration of an availability zone and before you start Neutron:

    1. Modify the availability zone configuration in the nsx.ini file.
    2. Delete all backup edges in succession.
      nsxadmin -r backup-edges -o clean --property edge-id=edge-XX
    3. Restart Neutron.
    4. Verify the new configuration.
      availability-zone-list
  • Certificate is not in CA store error might appear when you deploy new OpenStack instance

    When you deploy a new VMware Integrated OpenStack instance with an IP address that was used by another instance that has been connected to vRealize Automation, you might get certificate errors:
    Cannot execute the request: ; java.security.cert.CertificateException: Certificate is not in CA store.Certificate is not in CA store. (Workflow:Invoke a REST operation / REST call (item0)#35)

    Workaround: Delete the certificate of the old VMware Integrated OpenStack instance and import the new one by running the respective workflows in vRealize Orchestrator.

    1. Log in to vRealize Orchestrator.
    2. Go to Library > Configuration > SSL Trust Manager.
    3. Run the workflow to delete the trusted certificates of the old VMware Integrated OpenStack instance.
    4. Run the workflow to import the certificate of the new instance from URL.
  • Unable to modify syslog setting post deployment in VIO Manager interface.

    After deploying VIO, you cannot modify the syslog server configuration using the setting in the VIO Manager interface (VMware Integrated OpenStack > Management Server > Edit Settings > vApp Options).

    Workaround: Modify the configuration here: VMware Integrated OpenStack > OpenStack Cluster > Manage > Syslog Server.

  • Dashboard might show a Volume as attached even if it failed to attach.
    This is a known OpenStack issue, first reported in the Icehouse release.

  • Long image upload times cause NotAuthenticated failure.
    This is a known OpenStack issue (https://bugs.launchpad.net/glance/+bug/1371121), first reported in the Icehouse release.

  • Special characters in datastore names not supported by Glance (Image Service).
    If a datastore name has non-alphanumeric characters like colons, ampersands, or commas, the datastore cannot be added to the Glance service. Specifically, the following characters are not permitted in Glance datastore names because their use is reserved for other purposes and therefore can interfere with the configuration: : , / $ (colon, comma, forward slash, dollar).This issue has been fast-tracked for resolution.

  • If either controller VM reboots, high availability might be compromised.

    When a controller fails, the other controller continues to provide services. However, when the initial controller reboots, it might no longer provides services, and thus is not available if the other controller also fails. This issue has been fast-tracked for resolution.

    Workaround: If a controller fails and HA is invoked, review your deployment to ensure that both controllers are providing services after the failed controller reboots.

  • Metadata service is not accessible on subnets created with the no-gateway option.

    Deployments using NSX 6.2.2 or earlier do not support no-gateway networks; Edges are used for edge-routed networks and DHCP is used for VDR networks. Deployments using NSX 6.2.3 or later do not support no-gateway or no-dhcp networks; DHCP is used for any DHCP network and Edges are used for non-DHCP networks. In 2.x, autoconfiguration is turned off for Edge VMs. When applicable, DHCP sets the gateway and metadata is served through this gateway Edge. As a result, when a subnet is created with the the no-gateway option, there is no router Edge to capture the metadata traffic.

    Workaround: For networks with the no-gateway option, configure a route for 169.254.169.254/32 to forward traffic to DHCP Edge IP.

  • Problem uploading patch file in Firefox Browser.

    If you are using Firefox to update the patch for VMware Integrated OpenStack, the upload will fail if Firefox is using version 19 of the Adobe Flash plug-in.

    Workaround: Obtain the patch using the CLI. You can also work around this issue by using an alternative browser or restoring the Flash plugin in your Firefox browser to an earlier version (15, 16, 17 or 18.)

  • OpenStack management service does not automatically restart.
    Under certain conditions, the OpenStack management service does not automatically restart. For example, after a failover event, all OpenStack services successfully restart but the management service remains unreachable.

    Workaround: Manually restart the VMware Integrated OpenStack vApp in the vSphere Web Client. Right-click the icon in the Inventory page and select Shut Down. After all the services shut down, power on the vApp. Check the OpenStack manager logs to confirm that the restart was successful.

    NOTE: Restarting interrupts services. This issue is fast-tracked for resolution in a future VMware Integrated OpenStack release.

  • Network creation sometimes fails when running Heat templates.
    Observed in VMware Integrated OpenStack deployments using NSX 6.2.2. When running multiple Heat templates, an iteration of a network creation sometimes fails at the backend.

    Resolved in NSX 6.2.3 and greater.

  • Recovery operation returns "Nodes already exist" error.

    Under certain conditions, running the viocli recovery - <DB name> command fails if the ansible operation is interrupted. As a result, the database nodes remain and causes the error.

    Workaround: Manually remove the nodes and run the viocli recovery command again.

  • LBaaS v2 migration: health monitors not associated to a pool do not migrate.
    In LBaaS v2, health-monitors are required to specify and be attached to a pool. In LBaaS v1, health monitors can be created without pool association, and associated with a pool in a separate procedure.

    As a result, when migrating to LBaaS v2, unassociated health monitors are excluded.

    Workaround: Before migrating to LBaaS v1, associate all health monitors with a pool to ensure their successful migration. The migration process is optional after installing or upgrading to VMware Integrated OpenStack 3.0. See the VMware Integrated OpenStack Administration Guide.

  • NSX LBaaS v2.0 tenant limitation.

    NSX load balancers support only one tenant per subnet. Under normal operation, this is not an issue because tenants create their own load balancers. If a user attempts to create and attach a load balancer to a subnet, the load balancer will be created in an ERROR state.

    Workaround: Allow tenants to create their own load balancers. Do not create and attach a load balancer to an existing subnet.

  • Operations times out with error "Connection reset by peer".
    Observed in VMware Integrated OpenStack 2.0.1 deployments using NSX 6.2.1. Sometimes the HA proxy will time out due to insufficient timeout configuration in the load balancer and controller node settings.

    Workaround: Edit the custom.yml to modify the timeout values. Add or modify the following parameters as shown.

    neutron_client_socket_timeout: 1500
    haproxy_neutron_client_timeout: 1500s
    haproxy_neutron_server_timeout: 1500s

  • Heat stack deletion fails with "Failed to publish configuration on NSX Edge" error.
    Observed in deployments using NSX v6.2.2. Under stressful conditions, the Heat stack or OpenStack API might fail at the backend.

    Workaround: Retry the failed operation.

    NOTE: This issue is fast-tracked for resolution in a future NSX release.

  • Online documentation: Some graphics might not display.

    If you use the Firefox or Internet Explorer browser to view the online documentation for VMware Integrated OpenStack, some graphics might not display. This does not affect the PDF documentation.

    Workaround: Use the Google Chrome browser. All graphics display without issue.

  • Images must be VMX version 10 or greater.
    This issue affects streamOptimized images and OVAs. For example, if an image is not VMX-10 or greater, it might import without difficulty but OpenStack instances created from the image will not function. This is typically experienced when OpenStack compute nodes are deployed on older ESXi versions, such as 5.5. You also cannot correct such an image by modifying the image metadata (vmware_hw_version) or flavor metadata (vmware:hw_version).

  • Recovery after vSphere HA event shows synchronization and process start-up failures.

    If vSphere experiences and HA event, it can affect your VMware Integrated OpenStack deployment. After the recovery, in VMware Integrated OpenStack, run the viocli deployment status -v command. If the resulting report shows any synchronization or process start-up failures, use the workaround below.

    Workaround: Use the viocli services stop command to stop all OpenStack services. Use the viocli services start command to restart all OpenStack services. After restarting, run the viocli deployment status -v command again. There should be no errors.

  • Interoperability with other VMware products with TLS v1.0 disabled.
    VMware Integrated OpenStack experiences interoperability issues with other VMware products when those products have disabled TLS v1.0 and SSL v3. Many clients are phasing out TLS v1.0 and SSL v3 because they are no longer considered secure by current revisions of the PCI Data Security Standard. Previous versions of VMware Integrated OpenStack disabled TLS v1.0 and SSL v3 on inbound public API connections. VMware Integrated OpenStack v2.5.1 and v3.0 fully interoperate with components that have disabled TLS v1.0 and SSL v3, including vSphere 6.0 update 2, NSX 6.2.4, and LDAP servers.

    Workaround: Disable TLS on the vCenter server where VMware Integrated OpenStack is running.

    1. Modify the /etc/vmware-rhttpproxy/config.xml file.
      <vmacore>
         <ssl>
            <doVersionCheck> false </doVersionCheck>
            <useCompression>true</useCompression>
            <libraryPath></libraryPath>
            <sslOptions> 117587968</sslOptions>
         </ssl>
      ...
    2. Modify the /etc/vmware-vpx/vpxd.cfg file.
      <vmacore>
         <cacheProperties>true</cacheProperties>
         <ssl>
            <useCompression>true</useCompression>
            <sslOptions> 117587968</sslOptions>
         </ssl>
      ...
    3. Restart the vpxd and rhttpproxy services on the vCenter server.
  • OpenStack recovery sometimes fails when starting RabbitMQ.

    In rare occurrences, VMware Integrated OpenStack recovery fails at the point where RabbitMQ initiates.

    Workaround: Repeat the recovery process. Recovery should succeed the second time.

  • Heat stack deletion fails to delete associated Cinder volumes.
    Under heavy loads, Cinder volumes sometimes fail to be deleted after their Heat stacks are deleted, resulting in database deadlock warnings and slower Cinder performance.

    This issue is fast-tracked for resolution in a future release.

  • SQL-configured users cannot be modified in dashboard.
    If your VMware Integrated OpenStack deployment is configured to use LDAP for user authentication, you cannot modify user definitions in the OpenStack dashboard (Horizon) even those that are sourced from a SQL database.

  • OpenStack dashboard: router-size drop-down menu is missing.

    In the OpenStack dashboard (Horizon), you can specify the size when you create an exclusive router. However when you modify a router from shared to exclusive, the router-size drop-down menu does not appear, preventing you from specifying the router size.

    Workaround: Restore the default value, modify type to exclusive again. The drop-down menu should appear.

  • Unable to set Cinder volume default adapter type using custom.yml

    Setting the default adapter type of Cinder volumes using custom.yml does not work.

    Workaround: To set the volume adapter type, use vmware:adapter_type in the volume type, including the default volume type.

check-circle-line exclamation-circle-line close-line
Scroll to top icon