Virtual Machines¶

Virtual machines run standalone on your organization's infrastructure. Use them for legacy applications, custom workloads, or anything that needs its own virtual hardware.

Your VMs are under COMPUTE & NETWORK > Virtual Machines in the console.

Key features¶

Create in a few steps: pick a size, an image, an optional SSH key and cloud-init.
Networking: attach a VM to several networks, with firewalls on each. Networks, firewalls and SSH keys can be your project's own or shared with it.
Power and resizing: start and stop VMs, and move a VM to a different size.
Backups: snapshot a VM and start new VMs from the snapshot.
Monitoring: CPU, memory, disk and network charts for Linux and Windows guests, once you run a metrics agent inside the VM (see Monitoring and metrics).
Console access: read the console log and open a browser-based remote console.
Import: bring servers that already run in your cloud under the platform.

Before you start¶

For a VM you can sign in to over SSH and that can reach the internet, set these up first, on the VM's infrastructure:

A network with DHCP on.
A router with an external gateway, with the network attached at the network's gateway IP as its Fixed IP. See Make a router the network's gateway.
A firewall that allows SSH in and traffic out (an Egress rule).
An SSH key.

Networks, firewalls and SSH keys can be your project's own or shared with it. You can also create a network or an SSH key from the wizard.

You also need at least one enabled size and image in the infrastructure's Catalog (if there are none, ask your organization administrator), and quota and permissions.

Create a virtual machine¶

Go to COMPUTE & NETWORK > Virtual Machines and click Create Virtual Machine.
Choose the project and the infrastructure. A name is optional; a VM without one is shown by its ID.
Pick a Size (vCPUs, RAM and disk) and an Image. The image's description gives the minimum RAM and disk it needs; pick a size with at least that much disk, or creation is refused. Sizes with a 0 GB disk skip this check. Your project's backups are offered as images too.
Optionally pick an SSH key. You can create one from the wizard with +. Without a key, you sign in through the remote console, which needs a password set by the image or your cloud-init.
Leave Monitoring on if you plan to run a metrics agent in the VM; it collects nothing without one (see Monitoring and metrics).
Optionally add a cloud-init configuration under Advanced (see Cloud-init).
Choose the Network the VM joins and the Firewalls to apply on it. Add more networks with Add another network; each network can be used once per VM. Networks, SSH keys and firewalls shared with your project are marked Shared. You can create a network with +: it uses the same form as Create Network, with DHCP off by default, so turn DHCP on.
Review and click Create VM. If a network you picked is still being created, you can create the VM once the network is active.

Cloud-init¶

Cloud-init configures users, packages, files and start-up commands on the VM's first boot only. Write or paste YAML starting with #cloud-config (up to 16 KB), or upload a .yaml, .yml or .txt file; Load example gives a working starting point.

To read it later, click Show cloud-init on the VM's Overview tab. Cloud-init often contains credentials: reading it is covered by mvms_get, and can also be granted on its own as mvms_cloudinit_get.

Reach your VM¶

From your own machine, you can reach a VM only if it is on a network reachable from where you are, for example an external network shared with your project that the VM is attached to. Otherwise, use the remote console.

Each network attachment gets an IP address automatically; you can't choose a fixed IP. The platform doesn't assign public (floating) IP addresses to VMs. A router with an external gateway gives a VM's networks outbound internet access, not inbound.

SSH¶

Sign in over SSH with the key you picked at creation, from a machine that can reach one of the VM's addresses through its firewalls. See Log in to a VM with your key.

Remote console¶

Click Open Console to open a browser-based console in a new tab. It works even before networking or SSH is set up, but you need a password for a user on the VM, set by the image or by your cloud-init.

Console logs¶

The Console Logs tab shows the VM's console output, useful for boot problems or following cloud-init. You can choose how many lines to show, and copy or download them.

The console and logs can be unavailable while the VM boots, is powered off or has an operation in progress.

Change a virtual machine¶

Changes work while the VM is Active or Degraded. Only one operation runs at a time; while it runs the VM shows Updating, and you can cancel it from Action History.

Power¶

Start VM and Stop VM power the VM on or off. There is no reboot action. The Power badge updates once the infrastructure reports the new state. If someone powers the VM on or off outside the platform, Sync restores the power state the platform expects.

Resize¶

Click Resize VM and pick a new size. Only enabled sizes with at least as much disk are offered, because a disk can't shrink. The VM reboots to apply the new size, so save your work first. Resizing doesn't change your quota usage.

Networks and firewalls¶

Open the Network Attachments tab and click Edit to add a network (with its firewalls), remove an attachment, or change the firewalls on an attachment. To move to a different network, remove the attachment and add the other network.

One network change at a time

The VM applies one network change at a time. If you add, remove or change several attachments in one Save, only the first may apply. Wait until the VM is Active again, then save the next change.

Removing every attachment leaves the VM with no network access.
Interfaces with port security turned off in your cloud (common on high-performance networks) can't have firewalls.
While your VM uses a shared network, firewall or SSH key, its owner can't stop sharing it with your project. See Sharing Resources.

Monitoring, name and description¶

Enable Monitoring / Disable Monitoring switches metrics collection; Edit VM changes the name and description.

What you can't change¶

The image, SSH key and cloud-init are fixed for the life of the VM. To change them, create a new VM, for example from a backup of the old one.

Backups¶

A backup is a snapshot of the VM's disk, kept as an image that new VMs can start from. Backups are private to the VM's project and count toward the mvms-snapshots quota until you delete them.

Take a backup: click Backup VM (or Create Backup on the Snapshots tab). The VM must be Active, powered on or off; a backup taken while it's stopped is the most consistent. Give it a name (or let one be generated), and keep Available right away on so it can be used as soon as it's ready. Under Minimum size you can set the least disk and RAM a VM started from it needs; by default it keeps the original image's minimums. Only one backup per VM can be in progress.

Restore: create a new VM and pick the backup as its Image. The backup must be active.

Delete a backup: use the delete icon on the VM's Snapshots tab. A backup outlives its VM: after the VM is deleted, its backups stay in the infrastructure's image catalog, where you can delete them too. You can't delete a backup while it is still being created or while a VM started from it still exists. Deleting can't be undone.

Monitoring and metrics¶

With monitoring on, the Metrics tab charts CPU, load, memory, swap, filesystems (per mount point), disk I/O, network traffic and uptime over the last 1 hour to 7 days. Load average and swap stay empty on Windows.

Monitoring needs an agent in your VM

The platform doesn't install anything inside your VM. When monitoring is on and your platform operator has enabled metrics collection, it publishes push credentials in the VM's metadata, and an agent running in the guest must read them and send the metrics. Until one does, the tab shows that no metrics are available yet.

Typical agents are node_exporter with vmagent on Linux, and windows_exporter with vmagent on Windows. Ask your platform operator for the reference installer or an image that includes it; you can run it by hand, from your cloud-init, or when you build an image.

Metadata keys for your own agent

The credentials are in the instance metadata service at http://169.254.169.254/openstack/latest/meta_data.json, under meta:

Key	Value
`ec_monitoring_url`	Prometheus remote-write endpoint to push to
`ec_monitoring_username`	Basic-auth username
`ec_monitoring_token`	Basic-auth password

When you disable monitoring, the keys are removed, so an agent that re-reads them stops sending.

Monitoring is on by default and doesn't affect your quota.

Import an existing server¶

You can bring a server that already runs in an OpenStack infrastructure under the platform instead of creating a new one.

On the Virtual Machines page, click Import Virtual Machine.
Choose the project and infrastructure, then pick the Server (read live from your cloud). Its name is filled in for you.
Click Import Virtual Machine.

The server's size, networks, firewalls and SSH key, and its image if your cloud still has it, must already be in the platform and available to the project; import missing ones first.

An imported VM starts Read-only: the platform tracks it but doesn't change it in your cloud, so power, resize, networks, monitoring and backups aren't available until management is enabled. If several projects import the same server, see Virtual machines imported by several projects. For read-only versus managed, taking ownership and the rest, see Imported Resources.

Delete or detach a virtual machine¶

Delete destroys the VM in the platform and in your cloud, with its data. It can't be undone.
Detach removes the VM from the platform but leaves the server running in your cloud. You can import it again later.

Both are in the VM's Actions menu, and you confirm by typing the VM's name. An imported VM can be deleted only after you take ownership of it. You can delete or detach a VM while it is Active, Degraded or in Error, as long as none of its backups is still being created. Its backups are kept.

Sync and lifecycle states¶

VMs use the resource statuses. A VM in Error can be deleted or detached; an imported one can also be taken ownership of, so you can delete it.

Sync re-applies the VM's configuration (size, networks, firewalls, monitoring and power state) to your cloud. Use it after a failed change or when the VM drifted, for example when someone powered it on or off outside the platform. It isn't available on a read-only imported VM.

Quotas¶

Each VM uses one managed-virtual-machines unit, whatever its size; each backup uses one mvms-snapshots unit. See Resource Quotas.

Permissions¶

Task	Permission
Create	`mvms_create` (with an SSH key: also `sshkey_attach` in the VM's project)
See a VM without its console, logs, cloud-init or metrics	`mvms_metadata_get`
Open the remote console	`mvms_console_get`
Read console logs	`mvms_logs_get`
Read cloud-init	`mvms_cloudinit_get`
See metrics	`mvms_metrics_get`
Start and stop	`mvms_power_update`
Resize	`mvms_resize_update`
Change networks and firewalls	`mvms_network_attachment_update`
Switch monitoring	`mvms_monitoring_update`
Edit name and description	`mvms_metadata_update`
Sync, cancel an action	`mvms_action_update`
Take, list and delete backups	`mvms_snapshot_create`, `mvms_snapshot_list`, `mvms_snapshot_delete`
Import	`mvms_import` (as Managed: also `mvms_control_update`)
Switch Read-only / Managed	`mvms_control_update`
Take ownership	`mvms_authority_update`
Delete / Detach	`mvms_delete` / `mvms_detach`

mvms_get includes the metadata, console, logs, cloud-init and metrics reads; mvms_update includes every change from power to sync. The create and import forms also need some organization-level permissions to pick where the VM runs: see What project members typically need. Full list: Permissions Reference.