Monthly Archives: September 2015

SSL certificates allow developers to interact with an OpenStack cloud with the confidence that their communications are encrypted. In VMware Integrated OpenStack, we enable SSL encryption, by default, for users to access the various endpoints securely. In addition, we make it easy to generate your certificate signing request (CSR) and to apply the certificate after it is received from your trusted Certificate Authority (CA).

When you first install VMware Integrated OpenStack, it is running with a self-signed certificate. In order to work with the CLI or API, you would need to use the OS_CACERT parameter during authentication. In addition, your web browsers will report that the identity of the site is not verified and will not trust the certificate that the OpenStack dashboard presents.

We strongly recommend that users obtain a certificate from a trusted CA for their production deployments. To that end, we make the CSR generation process easy for our users. The user simply logs in to the VMware Integrated OpenStack management server VM via SSH, and runs the following command:sudo viocli deployment cert-req-create

The CSR will be generated and displayed to the screen. Copy the CSR output, including the “BEGIN” and “END” lines, and paste it to a file. Submit this file to your CA.

When the signed certificate is returned, use the following syntax to apply it:sudo viocli deployment cert-update -p -f /Your_Certificate_Path/cert.crt

The VMware Integrated OpenStack automation code then proceeds to deploy the certificate for use in your environment. When the process is complete, you can use the OpenStack CLIs and APIs without the OS_CACERT attribute, and your web browsers will trust the OpenStack dashboard as shown in Figure 1.

At VMworld US 2015, there was a new-and-improved hands-on lab (HOL-SDC-1620). Now, it’s available to all users on the public HoL site. Kudos to the HoL Lab Captains who got the new lab completed in time for the event: Marcos Hernandez, Jonathan Cham, Nathan Ness, and Tim Green!

At VMware, we aim to simplify deployment, consumption, and operations for OpenStack administrators. With the new-and-improved OpenStack with VMware vSphere and NSX lab, we do a great job of emphasizing all three areas for users to evaluate. Check it out today!

Shortly before VMworld US 2015, we shared with you some of the great new features coming to VMware Integrated OpenStack 2.0. Today, we are excited to announce that VIO 2.0 is generally available. As before, this release is free for all Enterprise Plus customers, and there are two install options:

Full install

Upgrade

Yes, you read that right, it is possible to seamlessly upgrade your VMware Integrated OpenStack 1.0 (Icehouse) release to version 2.0 (Kilo). We modeled our upgrade process, summarized in Figure 1, after the Blue-Green strategy made popular by Jez Humble, Dave Farley, and Martin Fowler.

Figure 1: VMware Integrated OpenStack Blue-Green Upgrade Strategy

Check out the following video to see a VMware Integrated OpenStack upgrade in action:

In our previous post, we discussed how developers can quickly provision application infrastructure using instances and images in OpenStack. Today, we’ll discuss an important topic: Networking! How do we configure the networks that OpenStack instances use to communicate with each other and with the outside world?

The VDS option is appropriate for simple networking use cases. That is, your instances only need to communicate on a few VLANs with no need for advanced functionality like overlapping IP addresses, neutron-provided layer 3 routing, etc. The NSX option allows for advanced networking use cases including private networks for tenants, attaching floating IPs to your instances, etc.

For the purposes of this article, we will focus on the VMware NSX option. Configuring VDS networking is a fairly simple process, and we’ll point out the difference in the configuration process where applicable.

The first step in setting up your OpenStack network service is configuring your external, or provider, network. This is the VLAN provisioned for your instances to have access to the outside world. The external network is configured by a user with administrator permissions using either the Horizon GUI or the neutron API/CLI.

When configuring the external network for the VMware NSX networking option, the provider network type is “Port Group”. The physical network is the port group ID (dvportgroup-50110 in my example) for the external network you defined in vSphere. See Figure 1 for a configuration example.

Figure 1: External network configuration for VMware NSX Networking

If you are working with the VDS networking option instead of the VMware NSX option, you specify the provider network type as “VLAN” with the physical network labeled simply “dvs”. The VLAN ID is specified in the Segmentation ID textbox. The “Shared” option must be selected so that your tenants can use this network when booting instances (See Figure 2 for a configuration example). VMware Integrated OpenStack will use this information to automatically create a port group on the VDS that you specified when you deployed OpenStack control plane.

Figure 2: External network configuration for VMware VDS Networking

Once your external network is defined, you define a subnet the external OpenStack network. Make sure to uncheck the “Enable DHCP” option, to specify the network address and gateway, and to specify the IP allocation range in case the entire subnet isn’t available for use.

Now that your external network configuration is complete, your tenants can allocate IP addresses for their instances using the OpenStack GUI, APIs, or CLIs as seen in our previous blog post.

The following video provides a detailed walkthrough of configuring OpenStack networks.