Create and manage virtual machines

Creation of a virtual machine (VM), also interchangeably called server (in OpenStack CLI) or instance (in Horizon), is the first step in setting up a DT Cloud Services cloud-based service where the basic steps are described in Quick Start . In this section, we will describe some options related to creation and management of VMs.


A server can be created from images, volumes or snapshots. The document Quick Start describes how to create a server from an existing image.

Note that the OpenStack server create command takes optional arguments in addition to the ones discussed in this chapter. Please see the OpenStack documentation for the full API details. A server can be created from different sources, which is described next.

Create virtual machine from image

The DT Cloud Services portal allows the user to choose between a number of pre-built public images. In many situations, however, you may rather wish to create an instance from a custom image. More details on how to create and upload a custom image is described in how-to Manage images

Figure 1 shows the dependence between different resource types which therefore indicates the workflow of creating a virtual machine.

Figure 1. Resource types related to compute instances.

From an uploaded custom image, you can create a server directly, just like from a public image. The OpenStack command is

openstack server create --flavor <flavor-id> --image <image-id> --nic net-id=<network-id> --security-group <security-group-id> --key-name <key-name> <name>

To obtain lists of available object identities, run in turn

openstack flavor list
openstack image list
openstack network list
openstack security group list
openstack keypair list

The two first arguments determine the configuration and build source of the instance, and the following three define the minimum networking and access requirement for the remote connection. Note that for these objects, their names can be used in place of their identities in the OpenStack commands. The mandatory last argument <name> is a chosen name for the server.

To access a newly created instance, SSH has to be enabled. The necessary permissions are set in the security group associated with the instance. It is good practice to define separate security groups for different server types. Say we have a security group called SSH-only, with only SSH traffic enabled in addition to the rules in the default security group. This is the minimum permissions necessary to establish the SSH access to the instance. More details on security groups can be found in how to Configure security.

Create virtual machine from volume

To create a server from a volume (block storage), the volume has to be created from an image, which makes it bootable, see

Create an instance from the bootable volume by

openstack server create --flavor <flavor-id> --volume <volume-id> --nic net-id=<network-id> --security-group <security-group-id> --key-name <key-name> <name>

The only difference in command syntax is that the source argument is changed from image to volume. An advantage of creating an instance from a volume is that the volume is not deleted when the instance is deleted.

Create virtual machine from snapshot

A snapshot is an image created from a running instance. Snapshots have two important use cases:

  • Backup and migration: by creating a snapshot, the main disk of your instance can be saved to an image from which a new instance can be booted with the disk data retained.

  • Templates: a base image can be customized and saved to be used as a template for new instances.

A snapshot of an instance can be created either from Horizon or from the OpenStack CLI by

openstack server image create --name <image-name> <server-id>

Snapshots are instantaneous copies of a running instance storage, which may lead to inconsistent data if the running instance is not aware of the snapshot being taken.

OpenStack relies on QEMU to manage and provide synchronization with running instances, allowing certain actions before taking a snapshot. This synchronization is enabled when the image has the property hw_qemu_guest_agent set to yes.

On a previously created private image, you can set the properties using the command

openstack image set --property hw_qemu_guest_agent=yes <image-id>

The properties of a snapshot or image can be printed by

openstack image show -f value -c properties <image-id>

A server can be created from the snapshot like from any other image as described in how-to Create and manage virtual machines section Create virtual machine from image.

Set availability zone

The availability zone can be passed as an argument when the virtual machine is created. Assigning servers to different availability zones ensures a certain level of geographical redundancy. This has to be done at creation time using the argument --availability-zone <zone>, where <zone> is az1, az2 or az3.

Add security group

To be able to access the virtual machine, it is necessary to have the proper security group assigned to it. The security group is usually passed as an argument during creation. Otherwise, a security group can be assigned by the command

openstack server add security group <server> <security-group>

or through Horizon under Compute/Instances/Actions, selecting Edit Security Groups, see Configure security.

Deployment with Heat

The deployment of identical servers can be facilitated with a Heat orchestration template (HOT). For a plain server, the template is simple, and contains only a single resource under resources, with its arguments listed under properties. Here, Heat references existing network, key pair and security group in the tenant.

Single server template

Heat templates are written in YAML (or JSON) format. The supported functions and syntax are dependent on the template version. The following simple template for VM deployment specifies its resource type and properties, that correspond to OpenStack CLI arguments.

heat_template_version: 2018-08-31

description: Simple parametrized template for server deployment

    type: string
    description: Name of server
    default: <name>

    type: string
    description: Key pair used by server
    default: <key-name>

    type: string
    description: Image server is based on
    default: <image-name>
    type: string
    description: Flavor server is based on
    default: <flavor-name>
    type: string
    description: Network used by server
    default: <network-name>

    type: string
    description: Security group assigned to server
    default: <security-group-1>

    type: OS::Nova::Server
      name: {get-param: server_name}
      key_name: {get-param: key_pair}
      image: {get-param: server_image}
      flavor: {get-param: server_flavor}
        - network: {get-param: private_network}
      security_groups: [{get-param: sec_group_1}]

After saving the HOT with the property parameters filled in as, say, create_server.yaml, it is used with the command (from the same directory where the template was saved)

openstack stack create --template create_server.yaml <stack-name>

Default parameter values specified in the template can be overwritten in the creation command with the argument --parameter, for example,

openstack stack create --parameter "server_name=server2" --template create_server.yaml <stack-name>

The argument is given in quotation marks and multiple parameters are separated with semi-colon.

Verify deployment

At any time, the status of the deployment can be inspected with

openstack stack list

The OpenStack CLI provides some details related to the cause of failure in the creation report, which is printed with

openstack stack show <stack-name>

A stack is deleted with

openstack stack delete <stack-name>

More details on using Heat can be found in

Manage virtual machines

After a virtual machine has been created, it can be managed through Horizon or CLI commands. The operations include

  • Associate or Disassociate Floating IP (see Configure network)

  • Attach or Detach Interface (see Configure network)

  • Edit Instance

  • Attach or Detach Volume (see Manage volumes)

  • Update Metadata

  • Console - launch a web console in a browser (requires TLS)

  • View Log - show system logs

  • Instance run state actions: Pause, Suspend, Shelve, Resize, Lock/Unlock, Reboot options, Rebuild and Delete

The instance run states are illustrated in Figure 2. Each node represents a state and the edges denote the commands used to make it enter into the respective state.

Figure 2. Compute instance run states with associated command.

Association of floating IP addresses and managing interfaces and volumes are described in other parts of this documentation.

Through Horizon, many of the possible operations on instance are available (Figure 3). Under Edit Instance and Edit Security Groups it is possible to change the instance name and add or remove security groups. Labels can be added under Update Metadata. There are two types of data: Glance Metadata Catalog or user defined data, that can be added using the Custom option. The server management actions from the OpenStack client are described below. Some of the optional arguments to the commands have been omitted.

Figure 3. Horizon menu with instance management actions.

Server set/unset

Instances have metadata associated which are distributed in JSON format. Some of the data is essential for operating the instance, such as the ssh key, whereas other information is set by OpenStack but not necessarily important, such as the instance's UUID. Users can set their own metadata to associate whatever information they need to the instance.

There are two files provided for each version: meta_data.json and network_data.json. The meta_data.json file contains nova-specific information, while the network_data.json file contains information retrieved from neutron.

The metadata can be accessed from within an instance with the HTTP GET request


The metadata is a set of key-value pairs that can be modified through the OpenStack client by

openstack server set --property <key=value> <server>

where --property <key=value> is the data to be to added or changed for the server with identifier <server>. The command accepts multiple properties by repeating the argument.

A special syntax exists for the server name

openstack server set --name <new-name> <server>

A property is removed from the data set by

openstack server unset --property <key> <server>

The command accepts multiple properties.

Server pause/unpause

An instance can be paused, where its state is stored in RAM and it continues to run in a “frozen” state, by

openstack server pause <server>

with <server> being the server identifier (name or ID). Several instances can be paused in a single command by adding more server identifiers. A paused instance is brought back to normal operation by

openstack server unpause <server>

which can also take multiple server identifiers.

Server suspend/resume

An instance can be suspended, where its VM state and memory are written to disk, and the VM is stopped. Similar to hibernation, its memory and vCPU become available for other tasks or new instances. This state can be used to free up resources or to perform maintenance. This is done by

openstack server suspend <server>

with <server> being the server identifier (name or ID). Several instances can be suspended in a single command by adding more server identifiers. A suspended instance is brought back to normal operation by

openstack server resume <server>

which can also take multiple server identifiers.

Server shelve/unshelve

An instance that will not be needed for some time can be shelved, or temporarily removed from the hypervisors. This state can be used to free up resources. This is done by

openstack server shelve <server>

with <server> being the server identifier (name or ID). Several instances can be shelved in a single command by adding more server identifiers. A shelved instance is brought back to normal operation by

openstack server unshelve <server>

which can also take multiple server identifiers.

Server lock/unlock

An instance can be locked by administrators to prevent other users to perform administration actions on it (such as the actions listed in this section). This is done by

openstack server lock <server>

with <server> being the server identifier (name or ID). Several instances can be locked in a single command by adding more server identifiers. A locked instance is unlocked by

openstack server unlock <server>

which can also take multiple server identifiers. A complete list of actions prevented on a locked instance can be found at OpenStack Server concepts.

Server resize

It is possible resize an instance by changing its flavor. After resizing, the instance needs to be rebuilt and restarted.

The operation has two steps: creating a new server based on a different flavor and copying the disk contents into the new server. This is done by two commands: resize followed by either confirm or revert.

The resizing is initiated by

openstack server resize --flavor <flavor> <server>

where <flavor> is the new flavor ID and <server> the instance name or ID. The command gives the guest operating system a chance to perform a controlled shutdown before the instance is powered off and resized.

This process can take some time, during which the instance is in status resize. After resizing it will be in status verify_resize until the resizing has been confirmed (or reverted), which is done by

openstack server resize confirm <server>

After confirmation, the instance enters into status active.

In case the resizing fails or does not work as expected, it can be reverted by

openstack server resize revert <server>

Again, the instance in the old flavor enters into status active.

Server reboot

A server reboot is performed by the command

openstack server reboot [--hard | --soft] [--wait] <server>

The argument --hard performs a reboot equivalent to unplugging the power from a physical server and plugging it back in before rebooting. During the process the instance is in the status hard_reboot.

The argument --soft performs a reboot by sending a reboot signal to the operating system to shut down all processes gracefully. If the reboot type argument is omitted, this is the default reboot type. During the process the instance is in the status reboot.

With the argument --wait, OpenStack waits for the reboot to complete before accepting any further commands. The server identifier <server> can be name or ID.

Server rebuild

Rebuilding an instance removes all data on the server and places it with the specified image. The server ID, flavor and associated IP addresses remain unchanged. This is done with

openstack server rebuild --image <image> <server>

where <image> and <server> are the image and server identifiers (name or ID).

Server start/stop

An instance is powered on by the command

openstack server start <server>

and is shut down by

openstack server stop <server>

with <server> being the server identifier (name or ID). The stop command is equivalent to powering down the server from the operation system, for example by the command shutdown -h. When the OpenStack Compute manager detects that the VM has been powered down, it changes the server status to shutoff.

Server delete

The command

openstack server delete <server>

deletes an instance with <server> being the server name or ID. The server should first be powered off and all its associated resources detached before deleting it.

Setting Domain Name Servers

DNS IP addresses can be configured in the subnet. Alternatively, these addresses can be configured on the server. The Google name servers can be used for this, for example IP address as primary and as secondary DNS server. The method to set the DNS IP address varies with Linux flavor. The method used for Ubuntu 18.04 LTS or later is described next.

In Ubuntu from version 18.04 LTS, Netplan is used for network configuration. Netplan is based on YAML, and the network data is simply added as text to a configuration file in YAML format. The file can be opened and edited with a text editor like vi or Nano, which both are available in the Ubuntu distribution.

The configuration files are located at /etc/netplan/*.yaml. Ubuntu server automatically generates a Netplan configuration file for system-networkd named 01-netcfg.yaml.

To modify the configuration file, change into that directory with the command

cd /etc/netplan

In that directory, there is likely only the single automatically generated file


You can create a new file or edit this default file. Should you decide to edit the existing file, it is good practice to make a copy with the command

sudo cp /etc/netplan/01-netcfg.yaml /etc/netplan/01-netcfg.yaml.bak

First, find the name of the active network interfaces that you want to configure. The interfaces are listed with

ip a

Note the interface name that you want to configure as it must be specified in the YAML file. To open the file with nano, enter

sudo nano /etc/netplan/01-netcfg.yaml

The YAML file is sensitive to correct indentation (using spaces, not tabs) and has the format

  version: 2
  renderer: NetworkManager/networkd
      dhcp4: true/false
        addresses: [<IP address/netmask>]
        gateway: <IP address>
        nameservers: [<IP address 1>, <IP address 2>]


  • <device-name> is the name of the interface

  • dhcp4 is set true or false depending on whether dynamic or static IP addressing is used

  • addresses specifies IP address (range) of the device without netmask

  • gateway gateway IP address to connect to an outside network

  • nameservers addresses of DNS name servers

In this case, using DHCP and the two DNS servers, the file should look like in Figure 4.

Figure 4. Netplan configuration file for networking using DHCP and Google DNS servers.

Before applying the change, we can test the configuration by the command

sudo netplan try

This will validate the configuration before applying it. If the test succeeds, the command output looks like in Figure 5, where you can accept the changes by pressing <ENTER> before the timer expires.

Figure 5. Testing a new configuration file.

Should the new configuration file fail, Netplan will automatically revert to the previous working configuration.

It is also possible to apply the configuration file directly with the command

sudo netplan apply

Having more than one interface, you can create separate YAML files for each interface and naming them with a sequential prefix, like 02-netcfg.yaml and so on. Netplan applies the configuration after the prefix, so the 01 file will be applied before the 02 file.

In older Ubuntu versions, the configuration file /etc/network/interfaces is used for interface configuration.

Setting the locale and time zone

To avoid annoying error messages during later installation or configuration steps, it is a good idea to set the locale as a part of the server preparation. This is done in the two steps

sudo apt install language-pack-en-base
sudo dpkg-reconfigure locales

The second command opens a dialog with language and locale options. The dialog in Ubuntu does not allow any menu selections directly, but installs the packages listed in the files under /var/lib/locales/supported.d/. As recommended, UTF-8 encoded language support should be selected. On the second menu, the first choice is the generic locale C.UTF-8 (where C denotes “computer”). The default settings are usually acceptable, and these are installed after selecting <OK> twice.

The time zone on the server is managed by the utility


which without arguments prints the current date, time and time zone settings. To find a suitable time zone, list the options with

timedatectl list-timezones

and set the time zone with (for example)

sudo timedatectl set-timezone Europe/Berlin

It is possible to set the real-time clock (RTC) to local time instead of universal time (with sudo timedatectl set-local-rtc 1), but this is not recommended since the local time is not updated. When keeping the RTC in universal time, the time stamps in the log files will be in universal time too.