Congratulations! You’ve setup OpenStack and you can get to its web interface.
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.
The nodes in my first OpenStack installation had two ethernet interfaces:
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.)
Here is an overview of the items you need in place for a functional VM:
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.
The first items—Security Group, SSH key pair, and Floating IP—are tabs in the same menu item:
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.
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.
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.
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,
~/.ssh/id_rsa.puband 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).
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.
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.
The next few items govern the networking environment for your VM(s).
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.
Continuing the directions in the last section, create a subnet.
Now you’re going to assign specific details to your subnet.
/etc/resolv.conffile (on Unix-y machines) if you’re unsure about their identity.
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.
Finally, you need to assign your router a local subnet.
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.
2048(or whatever is appropriate)
512(or whatever is appropriate)
In the Images list, you should be able to watch the construction of your new image.
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.
Login with your user credentials and make sure you’re working in the correct project.
myvmand launch just one instance, it will be called simply
myvm. If you launch, say three instances, you’ll get
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.
Once that address is assigned, and assuming your Security Group(s) allow it, you should be able to SSH into the Floating IP address.
After your VM has served its purpose, you can delete them. (There’s no undelete, by the way.)