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.
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
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 https://pannet.atlassian.net/l/c/cGX4mD1t
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
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
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
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.
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.
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 https://pannet.atlassian.net/l/c/KAAq7urt
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)
Attach or Detach Volume (see Manage volumes)
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.
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.
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 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>
--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.
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>
<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.
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>
<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.
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>
<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.
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>
<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.
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
The resizing is initiated by
openstack server resize --flavor <flavor> <server>
<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
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
A server reboot is performed by the command
openstack server reboot [--hard | --soft] [--wait] <server>
--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
--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
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.
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>
<server> are the image and server identifiers (name or ID).
An instance is powered on by the command
openstack server start <server>
and is shut down by
openstack server stop <server>
<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
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 220.127.116.11 as primary and 18.104.22.168 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
To modify the configuration file, change into that directory with the command
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
Note the interface name that you want to configure as it must be specified in the YAML file. To open the file with
sudo nano /etc/netplan/01-netcfg.yaml
The YAML file is sensitive to correct indentation (using spaces, not tabs) and has the format
<device-name>is the name of the interface
falsedepending on whether dynamic or static IP addressing is used
addressesspecifies IP address (range) of the device without netmask
gatewaygateway IP address to connect to an outside network
nameserversaddresses of DNS name servers
In this case, using DHCP and the two DNS servers, the file should look like in Figure 4.
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.
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
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
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 denotes “computer”). The default settings are usually acceptable, and these are installed after selecting
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
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.