VMware Integrated OpenStack 2.0.1 Patch Release Notes

VMware Integrated OpenStack 2.0.1 | 10 DECEMBER 2015 | BUILD 3302254

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.

Supported Languages

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

Updated New Features in this Release

VMware Integrated OpenStack enables the rapid deployment of OpenStack on a VMware vSphere virtual platform. This release provides the following new features and enhancements.

  • Multiple domain controller support. You can connect your deployment to Active Directory with multiple domain controllers by modifying the ldap_url parameter in the custom.yml file. List the URL of each domain controller separated by commas. For example:

    ldap_url: ldaps://domain1.acme.com:636,ldaps://domain2.acme.com:636

    This feature requires adding and modifying the custom.yml file. See Enhanced customizability.

  • New interface for updating the DNS server. Users can now directly modify the DNS server used by the OpenStack deployment. In the vSphere Web Client, click the VMware Integrated OpenStack icon in the Inventories page, then choose Manage > Networks. Select the target network, then choose All Actions > Change DNS.

  • Cinder volume migration. VMware Integrated OpenStack 2.0.1 enables user to migrate Cinder volumes even when attached to a running Nova instance. Users can now remove disks from Cinder VMs on specific datastore. After completing this procedure, users can migrate the VMs to another datastore. After it is detached from OpenStack, the removed disk is automatically fixed.

    1. Log in as admin to the VMware Integrated OpenStack manager.

    2. Switch to root user.

      sudo su -

    3. Prepare a datastore for maintenance.

      viocli ds-migrate-prep [-d DEPLOYMENT] DC_NAME DS_NAME

      • -d DEPLOYMENT - Specifies the name of the VMware Integrated OpenStack deployment.

      • DC_NAME - Specifies the datacenter name.

      • DS_NAME - Specifies the datastore name.

    Users can now put the datastore in maintenance mode or migrate the Cinder volumes to another datastore.

  • Expanded syslog server settings configuration. Syslog server configuration has been expanded to include port and protocol settings.

  • VXLAN/VLAN L2 Bridging Support. In a Leaf/Spine fabric architecture, the OpenStack Compute cluster cannot access VMs on a VLAN. This limitation can be overcome by creating a VXLAN network and L2 VXLAN/VLAN bridging. Note: Procedures for this feature are detailed below in Configuring VXLAN/VLAN L2 Bridging Support.

  • NSX-V Edge nodes now HA capable. High availability can now be configured for networking services provisioned from the NSX-v Neutron plugin. HA on Edge nodes is disabled by default. This feature requires adding and modifying the custom.yml file. See Enhanced customizability.

    To enable Edge HA prior to installing VMware Integrated OpenStack:

    1. Deploy the VMware Integrated OpenStack OVA in vSphere, but do not install VMware Integrated OpenStack.

    2. Edit the /opt/vmware/vio/custom/custom.yml file by uncommenting and setting the nsxv_edge_ha option to true.

      nsxv_edge_ha: True

    3. Save the file.

    4. Install VMware Integrated OpenStack in vSphere.

    To enable Edge HA in VMware Integrated OpenStack post-installation:

    1. Edit the /opt/vmware/vio/custom/custom.yml file by uncommenting and setting the nsxv_edge_ha parameter to true.

      nsxv_edge_ha: True

      The nsxv_edge_ha parameter is located in the NSX-V options section of the custom.yml file.

    2. Save the file.

    3. In the VMware Integrated OpenStack controller, get a list of all running Edge nodes and their edge-id values.

      nsxadmin -r edges -o list

    4. Enable high availability on an Edge node by specifying its edge-id value.

      nsxadmin -r edges -o nsx-update --property highavailability=True --property edge-id=<edge-id>

    5. Repeat the preceding step on each Edge node.

    6. Push the new configuration to your VMware Integrated OpenStack deployment.

      viocli deployment -v configure

      IMPORTANT: This command updates your entire deployment and might briefly interrupt operations.

  • Updated Improved optional log collection services. Added in version 1.0.3 and migrated to version 2.0.1.

    • Option to collect only non-rolled logs.

      viocli deployment getlogs -nrl

      or

      viocli deployment getlogs --non-rollover-log-only

    • Option to collect logs of specific services.

      viocli deployment getlogs -svc [OpenStack component such as nova, database, or other]

      or

      viocli deployment getlogs --service-only [OpenStack component such as nova, database, or other]

  • Deployment-specific tagging for logs. Users with multiple VMware Integrated OpenStack deployments can customize log tagging for each deployment. This tag is then applied to all logs from that deployment, enabling users to distinguish logs from different deployments. This feature requires adding and modifying the custom.yml file on each deployment. See Enhanced customizability.

    To configure custom tags for logs, repeat the following procedure on each VMware Integrated OpenStack deployment:

    1. Edit the /opt/vmware/vio/custom/custom.yml file to include the syslog_server_tag parameter.

    2. Enter a unique label to tag all logs from this deployment. For example:

      syslog_server_tag: VIO_123

      The label can include any combination of alphanumeric characters, underscore (_), or period (.). No spaces allowed.

    3. Save the file.

    4. Push the new configuration to your VMware Integrated OpenStack deployment.

      viocli deployment configure -v --tags configure_rsyslog

  • Security group rule extended to specify local IP prefix for ingress rules. The Neutron security-group-rule-create CLI command has been extended to specify the --local-ip-prefix parameter for incoming traffic.

  • Enhanced customizability. Several new features can be configured by implementing and modifying the custom.yml file. To implement the file, login to the VMware Integrated OpenStack manager and copy the template into your deployment.

    sudo mkdir -p /opt/vmware/vio/custom
    sudo cp /var/lib/vio/ansible/custom/custom.yml.sample /opt/vmware/vio/custom/custom.yml

    Implementing the file does not affect your deployment because all the parameters are commented out by default.

    WARNING: Changing the parameters in the custom.yml file can adversely affect your deployment. Do not modify any parameters unless you are following specific procedures or instructed by a VMware engineer.

  • Policy-based management to define default Nova storage. VMware Integrated OpenStack enables you to apply SPBM policy settings to instances created by OpenStack, and to ensure that instances booted from a volume use the correct volume type. This feature requires implementing and modifying the custom.yml file. See Enhanced customizability.

    To define default Nova storage for VMware Integrated OpenStack instances:

    1. If you have not already done so, implement the custom.yml file.

      sudo mkdir -p /opt/vmware/vio/custom
      sudo cp /var/lib/vio/ansible/custom/custom.yml.sample /opt/vmware/vio/custom/custom.yml

    2. Edit the /opt/vmware/vio/custom/custom.yml file to uncomment the PBM options.

      ##############################
      # PBM options
      ##############################

      # (string) The PBM default policy to use when no policy is associated with a flavor (Mandatory) if nova_pbm_enabled is set to True.
      nova_pbm_default_policy: nova

      # (boolean) The PBM status. Set this to True to enable storage policies for nova flavors.
      nova_pbm_enabled: False

    3. Set the nova_pbm_enabled parameter to True.

      nova_pbm_enabled: True

    4. Save the custom.yml file.

    5. To apply this policy to a flavor, modify the flavor configuration by adding the following specification to its metadata.

      vmware:storage_policy=nova

      Whenever an instance is created using this flavor, the storage policy is applied.

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.

Open Source Components for VMware Integrated OpenStack 2.0

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

Upgrading to version 2.0.1 from version 2.0

To upgrade to version 2.0.1 from version 2.0, you install the 2.0.1 patch (2.0.1 Build 3309787) on version 2.0.

The following procedures assume you have installed version 2.0. This patch updates the product UI and therefore must be installed using the CLI instructions documented below.

  1. Obtain the patch (Build 2.0.1.3309787).

    • Log into the VMware Integrated OpenStack management server.

    • Download the debian file for the patch.

    • 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 below.

    • Confirm that the patch was successfully added:

      viopatch list

      This returns a list of available patches, their version numbers, their type, and current status.

  2. Install the patch.

    • Ensure that 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.

    • Log into the VMware Integrated OpenStack management server and run the following command:

      viopatch install --patch vio-patch-x --version 2.0.1.3309787

      The patch installation takes up to 10 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 back in.

    You can ignore any error messages you encounter when logging back in.

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

    • Log into the VMware Integrated OpenStack management server and run the following command:

      viopatch uninstall -p vio-patch-201 -v 2.0.1.3309787

      The reversion process takes 5 to 10 minutes to complete.

    • After uninstalling the patch, you must restart the vSphere Web Client service on the vCenter Server to downgrade the VMware Integrated OpenStack plugin.

      Read VMware KB 2054085 to learn about restarting vCenter Server appliance services.

Upgrading to version 2.0.1 from version 1.0.x

To upgrade to version 2.0.1 from any version 1.0.x, you perform the upgrade procedure directly in the VMware Integrated OpenStack manager. Because vSphere will have to accommodate the existing deployment and the upgrade files, the upgrade process requires you to temporarily double the datastore resources.

NOTE: The general upgrade procedure is described in greater detail in the VMware Integrated OpenStack Administrator Guide.

Prerequisites

  • Double the datastore resources dedicated to your current VMware Integrated OpenStack deployment.
  • Verify that you have twice the required number of IP addresses available.
  • As a precaution, back up your current deployment. See the VMware Integrated OpenStack Administrator Guide for details.
  • Preserve your current VMware Integrated OpenStack deployment configuration by exporting it as a template.

To upgrade to VMware Integrated OpenStack 2.0.1:

  1. In VMware OpenStack Manager, add IP ranges to both the Management and API networks. The number of IP addresses you add must match the number of addresses configured for the existing network. See Add IP Addresses to the Network Configuration in the VMware Integrated OpenStack Administrator Guide.

  2. Obtain and install the Debian patch for the upgrade. See Install the VMware Integrated OpenStack 2.0 Upgrade Patch in the VMware Integrated OpenStack Administrator Guide.

  3. In the vSphere Web Client, select Home > Inventories, and click the VMware Integrated OpenStack icon.

  4. Click the Manage tab and click the Upgrades tab.

  5. Click the Upgrades tab.

    This tab lists the current VMware Integrated OpenStack deployment.

  6. Right-click the deployment name and choose Upgrade from the pop-up menu.

  7. Enter the name for the new deployment, and click Next.

    For customers with multiple deployments, this name value is used to tag logs for easy identification.

  8. Configure the public and private VIP settings for the load balancer service.

    • Public Virtual IP This value should be on the same subnet as the OpenStack API Access network, and should be outside the IP range specified for the OpenStack API Access network.

    • Private Virtual IP This IP connects the load balancer interface with the Management network.

  9. Click Next.

  10. Review the upgrade configuration, and click Finish.

  11. On the Upgrades tab, right-click the name of the 1.0.x deployment, and select Migrate Data.

    When the migration process finishes, the status for the 2.0 deployment on the Upgrades tab changes to Migrated.

  12. On the Upgrades tab, right-click the name of the 1.0.x deployment, and select Switch to New Deployment.

    When the deployment switching process finishes, the status for the 2.0 deployment on the Upgrades tab changes to Running. The 1.0 deployment shows a status of Stopped.

  13. Optionally, login to the VMware Integrated OpenStack manager to migrate your 1.0.3 deployment customizations to the new 2.0.1 deployment.

    vioconfig configure

    NOTE: This step applies only if you have modified the custom.yml file in version 1.0.3.

Configuring VXLAN/VLAN L2 Bridging Support

In a Leaf/Spine fabric architecture, the OpenStack Compute cluster cannot access VMs on a VLAN. This limitation can be overcome by creating a VXLAN network and L2 VXLAN/VLAN bridging. Note: The VDS port group for the VXLAN network must be created before performing the configuration.

  1. Using SSH, log in as administrator to the OpenStack controller node.

  2. Create the logical L2 gateway on Neutron.

    neutron-l2gw l2-gateway-create <gateway-name> --device name=<device-name1>,interface_names="<interface-name1>[|<seg-id1>]"

    • <gateway-name> - Specifies the name of the new gateway.

    • <device-name1> - Specifies the device name. This is a dummy name. The NSX-V plugin creates a dedicated DLR.

    • <interface-name1> - Specifies the distributed port group MOB ID as the interface name.

    • <seg-id1> - Specifies the distributed port group segmentation ID.

    From the backup edge pool, NSX-V creates a dedicated DLR called L2 bridging-{gateway-id}, and passes the Edge ID to the following operation.

  3. Create the logical L2 gateway connection on Neutron.

    neutron-l2gw l2-gateway-connection-create <gateway-name/uuid> <network-name/uuid> [--default-segmentation-id=<seg-id>]

    • <gateway-name/uuid> - Specifies the name of the existing gateway.

    • <network-name/uuid> - Specifies the network name. This is a dummy name. The NSX-V plugin creates a dedicated DLR.

    • default-segmentation-id=<seg-id1> - Specifies the default distributed port group segmentation ID.

    This operation connects the OpenStack network with the Provider VLAN network.

Updated Known Issues

VMware Integrated OpenStack 2.0.1 has the following known issues. If you encounter an issue that is not in this known issues list, search the VMware Knowledge Base, or let us know by contacting VMware Technical Support.

  • Updated Restore function fails after upgrade fails.
    Observed when upgrading from version 1.0.3 to version 2.0.1. If the upgrade process fails, you might be unable to restore the earlier version. OpenStack returns the following message: "Lost connection to MySQL server at \'reading initial communication packet\', system error: 0 "Internal error/check (Not system error)."

    Workaround: Manually restore the earlier version before attempting to upgrade again:

    1. In the Manage > Upgrades panel, delete the newer version.

    2. Uninstall the patch.

    3. Manually restart the existing deployment.

    4. Use SSH to access the OpenStack manager CLI and run vioconfig configure

    After successfully restoring the old deployment, you can try the upgrade process again.

  • Network connectivity issues
    If you experience failures when connecting or reconnecting virtual machines to a logical switch, the cause might be from NSX-V. This is a known issue that sometimes results after ESXi hosts in NSX-V are upgraded or reprepared.

    Workaround: Read VMware KB 2107951 for a solution.

  • 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 > LogInsight.

  • 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.

  • Detaching volume fails with FileNotFoundException error.
    During volume detachment, the relocation of the shadow VM fails if storage DRS (SDRS) has moved the virtual disk. The following workaround works only if the volume does not contain snapshots.

    Workaround: The following procedure works only if the volume does not contain snapshots.

    1. In detach_volume, reconfigure the shadow VM to remove its VMDK.

      NOTE: Do not set the option to destroy files.

      This will remove the disk device even if the backing files do not exist and the VM is now ready for relocate

    2. Destroy the volume's VMDK.

      NOTE: Ignore the filenotfound exception. This implies that SDRS has moved the VMDK instead of copying; because there are no references to the VMDK, you must delete it explicitly.

    3. Relocate the shadow VM to the datastore of the instance.

    4. Reconfigure the shadow VM to attach the latest copy of volume's VMDK.

    5. Reconfigure the instance to remove volume's VMDK.

  • Updated Host route injection doesn't work in VMware Integrated OpenStack 1.0.1
    This issue has been fast-tracked for resolution.

  • Volume extend fails if a shadow VM has a disk chain.
    The extend volume feature is not supported when the volume contains one or more snapshots.

  • OpenStack dashboard does not immediately reflect volume extension.
    If you extend the size of a volume, the dashboard might still display the pre-extended size. Eventually, the correct size appears.

  • Nova component is choked and becomes unreachable and times out.
    When Nova is choked for a long time, the master message queue becomes unreachable under the benchmark "NovaServers.boot_and_delete_servers".

    Workaround: Restart the nova-conductor on both controller nodes, and restart nova-compute on the Compute node.

  • OpenStack Management Service does not restart after vSphere HA event.
    If vSphere experiences an HA event (for example, the ESXi host hosting the OpenStack Management Server), when vSphere HA restarts, the OpenStack Management Service remains is not restarted. Observed in vCenter Server 5.5.

    Workaround: If a vSphere HA event occurs that affect the OpenStack deployment, ensure that the OpenStack Management Service has restarted. Restart manually if necessary.

  • Database node failure might block access to the dashboard for up to thirty minutes.
    If the master database node fails and restarts, users may not be able to log in to VMware Integrated OpenStack dashboard (Horizon) for up to thirty minutes. Observed in vCenter Server 5.5.

  • Installer gives priority to local storage by default.
    When provisioning datastores for the three database VMs, the VMware Integrated OpenStack installer automatically gives priority to local storage to improve I/O performance. For resiliency, users might prefer shared storage, but the installer does not make it clear how to modify this setting.

    Workaround: Before you complete the installation process, the VMware Integrated OpenStack installer allows you to review and modify the configuration. You can use this opportunity to change the datastore configuration for the three database VMs.

  • 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.

  • Nova boot creating a new volume from OVF fails.
    OVF is an unsupported format.

    Workaround: Convert the OVF to an OVA using the appropriate VMware tool or use another supported format.

  • VMware Integrated OpenStack dashboard (Horizon) throws a 504 Gateway Timeout.
    After approximately 1500 networks have been configured, clicking Networks in the dashboard navigation panel might result in a 504 error.

  • 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.

  • vSphere Datacenter Names with Commas Prevent Deployment.
    If the VMware vSphere Datacenter name has a comma in it (for example: "Palo Alto, CA"), you will be unable to deploy VMware Integrated OpenStack. The deployment wizard displays an invalid parameter error.

    Workaround: If possible modify datacenter names to be used for VMware Integrated OpenStack deployments to omit the "," character.

  • Need to run vioconfig start command if any OpenStack node is restarted
    If some of the node VMs in a cluster are restarted, you might need to restart the other nodes also. You can restart each node individually in the vSphere Web Client or by using the sudo vioconfig start command. If you cannot restart any of the nodes, ensure that the VMware Integrated OpenStack manager is running. Restart the manager first, then run sudo vioconfig start command to ensure all the OpenStack nodes start also.

  • "Nova boot image" fails intermittently.
    If the OpenStack Manager IP address is changed (for example, by modifying the FQDN setting), thus causing the OpenStack VMs to fall out of synchronization with the OpenStack Management Service. This bug is fast-tracked for correction.

    Workaround: Manually modify the OpenStack Manager IP address.

    1. From the vSphere Web interface, choose VMware Integrated OpenStack vApp Get Started > Edit Settings... > Networking Properties.

    2. Change the Management Server Network IP Address to the new one.

    3. Power off and restart the VMware Integrated OpenStack vApp.

    4. Using SSH, log in to Management Server console.

    5. Navigate to the /etc/network/interfaces file and edit the IP address setting to the new one.

    6. Restart the OpenStack VMs.

  • Unable to reach node using SSH.
    A node might be unreachable externally through SSH, even though it may reachable through SSH from the VIO management server. This has since been identified as due to network fluctuations outside the scope of vSphere and VMware Integrated OpenStack.

    Workaround: You can discover the specific cause by enabling debugging for the jarvis service.

    1. Log in to the management server. and edit file /etc/jarvis/jarvis.conf and change line "verbose=False" to "verbose=True"

    2. Edit the file /etc/jarvis/jarvis.conf by changing "verbose=False" to "verbose=True".

    3. Save and close the file.

    4. Restart jarvis: sudo service jarvis restart.

    5. Run the deployment again.

      NOTE: Verbose logging output will quickly fill the ansible log. Reset to False after you have debugged the issue.

  • Metadata service is not accessible on subnets created with the no-gateway option.
    In 2.0, 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 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.

  • Failure to recover multiple OpenStack VMs.
    After recovering multiple VMs, a rabbitMQ node doesn't recover and causes the config-mq failure.

    Workaround: Recover the entire VM tier:

    viocli recover -v -r RabbitMQ -n VIO-Controller-0 VIO-ComputeDriver-0 VIO-Memcache-1 VIO-LoadBalancer-1 VIO-DB-0

  • Post upgrade: duplicate image caches
    When you upgrade from VMware Integrated OpenStack 1.0 to 2.0, the existing image caches are duplicated. The 1.0 images caches are required to support all instances created in 1.0; instances created in 2.0 use the new image cache.

    Workaround: Do not delete the 1.0 image caches if you still have instances created in 1.0, or the instances will fail. When you have no more 1.0 instances, you can delete the 1.0 image caches.

  • Horizon dashboard shows error after switching projects as admin user
    If you are logged into Horizon as the administrative user and try to switch between projects using the drop-down menu in Horizon, the dashboard might begin returning errors. This is caused by an issue in OpenStack.

    Workaround: Log out of the Horizon dashboard and log back in to restore the dashboard.

  • Problems with heat template creating ScalingPolicy.
    Ceilometer Heat templates cannot create ScalingPolicy as a tenant member, only as a tenant admin. This appears to be a permissions issue. This issue is fast-tracked for resolution.

    Workaround: If you do not use LDAP in your deployment, you can work around this issue by manually modifying the Keystone configuration to give the user and tenant owner privileges.

    keystone user-role-add --user USER_NAME --tenant TENANT_NAME --role heat_stack_owner

    Note: You must restart the VMware Integrated OpenStack template for the modified setting to take effect.

  • WaitConditionHandle not working with current heat.conf.
    Using OS::Heat::WaitConditionHandle in a Heat Orchestration Template (HOT) template might generate the following error:

    Resource Create Failed: Error: Resources.Mysql.Resources.Wait Handle: Cannot Get Stack Domain User Token, No Stack Domain Id Configured, Please Fix Your Heat.Conf

    This issue has been fast-tracked for resolution.

  • Upgrade to 2.0 Fails with "No qualified ESXi Host for Controller-1" error
    The patch and upgrade procedures overwrites any customizations made to the omjs.properties, and this error is a result.

    Workaround: Reapply your customizations to the 2.0 omjs.properties file and restart the VMware Integrated OpenStack manager.

  • Reverting from 2.0 to 1.0.x results in error alert.
    If you revert to 1.0.x, VMware Integrated OpenStack might show an authentication error alert.

    Workaround: Close the alert and VMware Integrated OpenStack manager, and restart the vSphere Web client service. When you restart the VMware Integrated OpenStack manager, the VMware Integrated OpenStack service will restart without the error.

  • Snapshot upload fails due to timeout error.
    Snapshot upload fails due to HTTP read timeout in vCenter.

    Workaround: You can prevent this error by modifying the readTimeoutMs setting in the vpxd.cfg file.

    1. As a precaution, make a backup copy of the vpxd.cfg file.

    2. Modify the readTimeoutMs setting to 600000.

      <config>
        <vmacore>
         <http>
          <readTimeoutMs>600000</readTimeoutMs>
         </http>
        </vmacore>
        ..
      </config>

    3. Stop and restart vCenter.

  • Problem uploading patch file in Firefox Web 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 plugin.
    Per the Adobe Bug Base (https://bugbase.adobe.com/index.cfm?event=bug&id=4037494), this issue affects only the Firefox browser and later versions of Chrome.

    Workaround: You can 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 of 18.)

  • After vApp registration, the VMware Integrated OpenStack icon still does not appear.
    Only a user with administrative privileges can register the VMware Integrated OpenStack vApp. However, if a user without administrative privileges tries to register the vApp, they are not alerted when that registration fails and as a result the VMware Integrated OpenStack might not appear in the Inventory panel.

    Workaround: Re-register the vApp using administrative credentials.

  • sudo viocli deployment getlogs command returns only OMS logs, omits OpenStack node logs.
    When you run this command, none of the logs for the OpenStack nodes are returned. This issue has been observed in deployments in which users changed the default deployment name during the installation process. Any value other than VIO results in this issue.

    Workaround:

    1. Complete the installation process, using the custom value for the deployment name.

    2. Login to the VMware Integrated OpenStack manager.

    3. Modify the /opt/vmware/vio/etc/viocli.conf file by changing the setting deployment=VIO to the same value you assigned during the installation process. For example:

      deployment=SAME_VALUE_ASSIGNED_DURING_INSTALLATION

Resolved Issues

  • Deployment fails with Failed to query IP address error.
    Fixed in VMware Integrated OpenStack 2.0.1

  • Member statuses not regularly updated only while reading pool stats.
    Fixed in VMware Integrated OpenStack 2.0.1

  • Recovery of multiple VMs fails, returns WSREP error.
    Fixed in VMware Integrated OpenStack 2.0.1

  • Glance API doesn't work after multi-VM recovery.
    Fixed in VMware Integrated OpenStack 2.0.1

  • Upgrade from VMware Integrated OpenStack 1.0.3 to 2.0 fails.
    Fixed in VMware Integrated OpenStack 2.0.1

  • No interface for setting Nova storage policy-based management
    Policy-based management for Nova storage is now configured in the custom.conf file. See New Features in this Release.