Your First OpenStack VM

By Paul Heinlein | Jul 12, 2016 (updated Jul 18, 2016)

Congratulations! You’ve setup OpenStack and you can get to its web interface.

Now what?

I found the process of setting up a new VM less than intuitive. I hope this not-so-brief howto will help others who likewise find it difficult to get started.

My Setup

The nodes in my first OpenStack installation had two ethernet interfaces:

  1. a 1G interface routable to the rest of our LAN; in OpenStack parlance, it became a “provider network” used for floating IP addresses,
  2. a 10G interface connected to a non-routed subnet and used for all administrative traffic and OpenStack-internal networks.

I used packstack to automate my installation, but it took me a while to get the provider network settings correct; the directions for doing so are so dependent on your local setup that it’s unlikely that the process I followed will be generally applicable. (Read: you’re on your own here.)

Checklist

Here is an overview of the items you need in place for a functional VM:

  • User account
  • Project membership
  • Security group [recommended]
  • SSH key pair(s) [recommended]
  • Floating IP [recommended]
  • Project network
  • Subnet on project network
  • Router between subnet and public network
  • OS image
  • Cloud-init script [optional]

As a regular user, you cannot create your own account or project; use the admin account to create a user account and project for yourself.

Once you’ve assembled and completed the items in the checklist, you’ll be ready to launch a VM.

Access & Security

The first items—Security Group, SSH key pair, and Floating IP—are tabs in the same menu item:

  1. Login with your user credentials.
  2. In the very top menu bar, toward the left is a drop-down list of projects to which you’re assigned. Make sure you select the project in which you’ll be doing work.
  3. In the left-hand menu frame, navigate to Project > Compute > Access & Security.

Security Group

By default, your new VM will be closed off to inbound traffic, meaning you won’t be able to use SSH (or anything else, for that matter) to access it. All you’ll have is console access – and some cloud images don’t allow even that. OpenStack has security groups that govern IPv4 and IPv6 packet filters (firewall). So you’ll probably want to setup a basic set of packet filtering rules that allow at least minimal access to your VM(s).

In the Access & Security pane, select the Security Group tab.

The default rule allows only outbound access from your VM, which is nice but probably not sufficient.

Before going further, I’ll note that you can mix and match Security Groups. So you can either put all the rules governing your VM into a single Security Group or you can combine several simple rules into a complex set.

OpenStack provides some built-in rules for often used services like HTTP, HTTPS, SSH, MYSQL, etc. It also provides rules that allow all inbound traffic from different IP protocols: TCP, UDP, ICMP. Finally, it will allow you to craft custom rules where you define IP protocol, port number(s), and source address(es).

For this example, I’ll create two rules: a basic one that allows outbound access, ICMP inbound (so you can ping the VM), and SSH inbound. Then I’ll create a second one just for web services.

The basic rule can be used by itself or in conjunction with other groups, though it will duplicate the functionality of the ‘default’ group so you don’t ever need to use the default group if you’re using this one.

  1. Select Create Security Group button.
  2. Give group a name and description.
  3. In the main list of Security Groups, press the new group’s Manage Rules action button.
  4. By default, you’ll get rules allowing egress. Keep them.
  5. Select the Add Rule button.
  6. In the Rule drop-down menu, select All ICMP. Keep the other defaults (ingress, CIDR, 0.0.0.0). Press the Add button.
  7. Select the Add Rule button again.
  8. In the Rule drop-down menu, select SSH. Keep the other defaults (CIDR, 0.0.0.0). Press the Add button.

The web services rule is strictly an add-on rule. You’ll want to combine it with the default Security Group or the basic one you just created.

  1. Select Create Security Group button.
  2. Give group a name and description.
  3. In the main list of Security Groups, press the new group’s Manage Rules action button.
  4. Delete the default egress rules.
  5. Select the Add Rule button.
  6. In the Rule drop-down menu, select HTTP. Keep the other defaults (CIDR, 0.0.0.0). Press the Add button.
  7. In the Rule drop-down menu, select HTTPS. Keep the other defaults (CIDR, 0.0.0.0). Press the Add button.
  8. [Optional] In the Rule drop-down menu, select Custom TCP Rule. Direction: ingress. Open Port: Port. Port: 8080. Remote: CIDR. CIDR: 0.0.0.0. Press the Add button.

At this point you have two custom Security Groups ready to assign to your VMs. The number of Security Groups you can create is limited by your project’s administrative quota.

SSH key pair

In some cases, you won’t need an SSH key pair to access your VM, but sooner or later you’ll want one.

In the Access & Security pane, select the Key Pairs tab.

You have two options. You can import your existing public key or OpenStack can generate a key pair for you. The latter process is fairly self-explantory; start it by selecting the Create Key Pair button in the upper-right of the screen.

To import an existing public key, which is probably the tack I’d recommend if you already have one in use,

  1. Select the Import Key Pair button (upper-right of screen)
  2. Assign your key a name (e.g., home-key)
  3. Copy your public key (probably in ~/.ssh/id_rsa.pub and paste it into the Public Key box, removing the comment string (see note).

Note: An RSA key consists of three strings: type, key, comment. For example: ssh-rsa AAAAB3Nz...YdA home-key. (In the example, the key portion has been severely elided for clarity.) When pasting the key into the Public Key box, you must remove the comment string (home-key in my example).

Floating IP

When you set up your VM, it will live on a subnet that’s internal to the OpenStack cluster. Assuming you follow the instructions below, the VM will have outbound access to the Internet, but it will not have an IP address reachable from other hosts on your network.

To assign a VM an address you can reach from, say, your desktop machine, you’ll need to assign it a Floating IP.

  1. In the Access & Security pane, select the Floating IPs tab.
  2. Press the Allocate IP To Project button.
  3. From the Pool drop-down menu, select Public. (It’s probably the only choice available.)

The new address should show up in the list of Floating IPs without a Mapped Fixed IP Address entry and with a Status of Down. The number of Floating IPs you can allocate is limited by your project’s administrative quota.

Networking

The next few items govern the networking environment for your VM(s).

  1. Login with your user credentials.
  2. In the very top menu bar, toward the left is a drop-down list of projects to which you’re assigned. Make sure you select the project in which you’ll be doing work.
  3. In the left-hand menu frame, navigate to Project > Network.

Network

A project can have multiple networks, each with multiple subnets, but each project needs at least one network containing at least one subnet. The first job is to create a new network.

  1. Navigate to Project > Network > Networks.
  2. Press the Create Network button.
  3. Assign the network a name; there’s no convention for network naming (yet).
  4. Ensure Admin State is UP.
  5. Assuming you want to assign a subnet to this network, ensure the Create Subnet box is checked.
  6. Press the Next button.

Subnet

Continuing the directions in the last section, create a subnet.

  1. Assign the new subnet a name (again, no convention yet).
  2. Assign it an address using CIDR notation, e.g., 10.40.40.0/24.
  3. By default, the subnet’s gateway IP address will be the first usable address in the CIDR block you assigned (so 10.40.40.1 in my example). You can change the gateway address if there’s some other convention you’d like to use, but the Gateway must exist within your CIDR block.
  4. Press the Next button.

Now you’re going to assign specific details to your subnet.

  1. You almost certainly want to keep the Enable DHCP box checked.
  2. The allocation pool or pools must live in your CIDR block. Each line should contain the beginning and ending addresses of a pool separated by a comma, ‘’e.g.’’, 10.40.40.10,10.40.40.254.
  3. Use real DNS Name servers (one per line). Take a look at your /etc/resolv.conf file (on Unix-y machines) if you’re unsure about their identity.
  4. It’s unlikely you’ll need to specify Host Routes unless you’ve got a really gnarly set of virtual subnets and routers you need to access.
  5. Press the Create button.

Router

Once you have a subnet, you’ll probably want to route it to the Internet. By default, your new subnet will access the wider network via NAT, so you don’t have to worry about that. Your next step is to create a router.

  1. Navigate to Project > Network > Routers
  2. Press the Create Router button.
  3. Assign the router a name (no convention).
  4. Ensure Admin State is UP.
  5. Pick a network from the External Network drop-down list; there may be only one choice (Public).
  6. Press the Create Router button.

Finally, you need to assign your router a local subnet.

  1. Your new router should appear in the list of routers. Press the link in the Name column.
  2. Press the Interfaces link on the details page.
  3. Press the Add Interface button.
  4. Select the new network/subnet you created in the earlier steps from the Subnet drop-down menu.
  5. Leave the IP Address blank unless you know for certain that it needs a static assignment.

OS Image

The OpenStack folks provide links to several OS images.

CentOS and Ubuntu are, of course, useful for general Linux operations. The CoreOS image can be handy for deploying containers. The cirros image is mostly for testing; it’s very easy and fast to deploy, though I doubt you’d want to use it in production.

  1. Login with your normal user account.
  2. Navigate to Project > Compute > Images
  3. Press the Create Image button
  • Assign the image a name (e.g., Debian 8.5.0)
  • Provide a description if you’d like
  • In the Image Source drop-down menu, choose Image Location
  • In the Image Location box, enter a URL, e.g., http://cdimage.debian.org/cdimage/openstack/current/debian-8.5.0-openstack-amd64.qcow2
  • In the Format menu, choose the correct format (which would be QCOW2 for my example URL)
  • Leave Architecture blank
  • For Minimum Disk, enter 2048 (or whatever is appropriate)
  • Form Minimum RAM, enter 512 (or whatever is appropriate)
  • Press the Create Image button.

In the Images list, you should be able to watch the construction of your new image.

cloud-init Script

Images that can be used in OpenStack are equipped with cloud-init scripts that can be used to customize an image when it’s first launched. These scripts can do everything from install non-standard application packages, create user account, launch daemons, and even write arbitrary files. The documentation shows the variety of tasks that can be accomplished.

You can see my CentOS- and Ubuntu-specific scripts here on this site.

Ubuntu note: Having a cloud-init script is necessary for the stock Ubuntu images. While a standard launch with a specified SSH key pair will indeed install your specified key(s) in /root/.ssh/authorized_keys, the stock setup won’t actually let you login as root. Without a normal user account with sudo access, you won’t be able to log into an Ubuntu image.

Launch VM

Login with your user credentials and make sure you’re working in the correct project.

  1. Navigate to Project > Compute > Instances
  2. Press the Launch Instance button in the upper-right of the main pane.
  3. Details: Give your instance a name. If you increase the Count option beyond one (1), your instances will be given a numeric suffix. If you call your instance myvm and launch just one instance, it will be called simply myvm. If you launch, say three instances, you’ll get myvm-1 through myvm-3.
  4. Source: A new instance will probably start from an Image (rather than a snapshot). Choose your OS image.
  5. Flavor: Select the resources allocated to your VM. These resources will be counted against the project’s quota.
  6. Networks: Choose your project network, not the public network.
  7. Security Groups: Add one or more Security groups to govern IP access.
  8. Key Pair: Add one or more public keys to be installed in administrative account. Different images use different default accounts. You’ll have to read the documentation for your image if you plan on using this default account.
  9. Configuration: Paste your cloud-init script into the box or point the widget at a file containing it.
  10. Press the Launch Instance button.

Post Launch

Once your VM shows up in the main instance list, you can assign it a Floating IP address, view the boot logs, and interact with the machine’s main console.

Assign Floating IP

  1. Navigate to Project > Compute > Instances
  2. In the Actions drop-down menu for your VM, select Associate Floating IP.
  3. From the IP Address drop-down menu, choose one of the Floating IPs you’ve reserved for your project.

Once that address is assigned, and assuming your Security Group(s) allow it, you should be able to SSH into the Floating IP address.

View Boot Log

  1. Navigate to Project > Compute > Instances
  2. Click the name of your VM in the Instance Names column.
  3. Click the Log tab.
  4. You should see a text representation of the current console output. If your initialization process is a long one, you may need to refresh your browser to keep up with the process.

Console

  1. Navigate to Project > Compute > Instances
  2. Click the name of your VM in the Instance Names column.
  3. Click the Console tab.
  4. You should see an embedded VNC console. You may need to press the gray bar (with the “Connected…” text) and then press Enter before you see anything. If you haven’t set a password for any accounts, you may not be able to login from the console.

Splashdown

After your VM has served its purpose, you can delete them. (There’s no undelete, by the way.)

  1. Navigate to Project > Compute > Instances
  2. Select the VM(s) to delete.
  3. Press the Delete Instances button and confirm the operation.
  4. Sleep soundly knowing that your VMs are long gone.

Openstack