VMs

Every virtual machine on this engine, whatever it belongs to. A VM built as part of a stack appears here too; the Stacks tab is where the shape of a deployment is visible, this is the flat list.

Add VM

Builds one VM from an image and a network that already exist. It is the plain case: a disk you already have, attached to a network you already have, sized and started. To build from a master image instead - cloning it, sizing it and starting it in one go - install a stack.

Boot image

The image this VM boots from. Only images that are yours and not already attached to another VM are offered; clone one on the Images tab if the list is empty.

Name

What the VM is called, in the list and to the engine. Left empty, it takes the name of the image it boots from.

Network

The network this VM is attached to. A VM needs one, so either pick a network that exists or have one made here - the three "new" entries make a network of that kind and attach it in a single step.

Memory

How much memory the VM gets, in MB. The list offers the usual sizes; any number can be typed instead, and the arrow keys step through the list.

vCPUs

How many virtual processors the VM gets. They are shared with everything else on the node it runs on, so more is not always faster.

Second disk

A second image attached alongside the boot disk, for data that should outlive the system disk. It has to be a different image from the one it boots.

CD-ROM

An ISO attached as a CD-ROM. Together with Boot from: CD-ROM this is how a VM is installed from an installer image rather than cloned from a master.

Boot from

Which device the VM tries first: its hard disk, its CD-ROM, or the network for a PXE install.

Firmware

BIOS or UEFI. Most images want BIOS; anything installed under UEFI has to keep booting that way, so this is not a setting to change on an existing VM.

Disk bus

How the disks are presented to the guest. Paravirtualized (virtio) is fastest and what every modern image expects; SCSI and IDE are for guests whose drivers are older than that.

Network card

How the network card is presented to the guest, on the same reasoning as the disk bus: virtio unless the guest cannot drive it.

vGPUs

How many virtual GPUs the VM gets, where the engine has GPUs to hand out and the account is allowed any.

Video memory

How much memory each vGPU gets, in MB. Zero lets the engine choose.

Node

Which compute node the VM runs on. Left to the engine, it goes wherever there is room; Keep it on that node pins it, which matters when its disk is on that node's own storage.

Autostart

Whether the VM is started again when the engine boots. Used for VMs that are part of the furniture rather than run on demand.

Console

A screen and keyboard attached to the VM, in the browser - the machine's own console, so it works before the guest is up, during boot, and when the network is broken.

Console opens it over the page; the icon beside it opens it in a window of its own. Where the VM's image has them, Manage and Terminal sit beside it: the VM's own management interface and a terminal in it, framed in the page or, with their icons, in a window of their own.

Power off

Cuts the power, rather than asking the guest to shut down. Anything not written to disk is lost, which is what makes it the last resort and Shutdown the first one.

Deleting a VM

Removes the VM and its configuration. The images it boots from and the networks it was attached to are kept - they are their own things, on their own tabs.

Contacts

Who to reach about this VM: the person it belongs to, the people running it day to day, and where its monitoring and backup alerts go. Alerts to takes several addresses, separated by commas.

A VM follows its stack's contacts, and a VM on its own follows the ones in Your settings, until one is changed here. Clearing a field puts the inherited value back.

Services

What the VM is for, and what to do when it stops doing it: which services it provides, and the procedures for recovering a failed one. Notes are at the bottom of the Info tab.

Usage

What the VM has in use now - its vCPUs, memory, storage and external addresses, and their cost per month where the engine shows costs. Your account's usage as a whole, against its quotas and month by month, is on Home.

Software

The VM's operating system and hostname, and the software installed on it.

Rescan finds what is installed on the VM. A running VM built from a stack with update integration is asked directly, and also says which packages have updates - an arrow and the new version in the list, marked security for security fixes - and whether it needs a restart for updates already installed. Otherwise its disk is opened read-only on the node it is on, which finds what is installed but not what is out of date; the VM keeps running either way. Clear forgets what was found.

Install updates and Install security updates appear when a scan has found some. The VM installs them itself, in the background - rescan a while later to see what is left. Packages it holds back are left alone. Everything your VMs run, together, is on Home.

Update schedule

How often the VM installs updates by itself - weekly, daily or hourly, and either everything or only security fixes. Only shown while it is running, and only for a VM built from a stack with update integration; one built from an older stack may not answer about updates until its stack's integration files are brought up to date.

Stack

The stack the VM belongs to, if any. Picking another moves it there, and None takes it out, to stand on its own - nothing about how it runs changes. A VM takes its contacts from its stack unless it has its own. See moving VMs between stacks.

Metrics

How the VM has been doing, from the last twenty minutes to the last month: CPU as a share of its own vCPUs, memory, and what its disk and network carry each second.

Everything is measured by the node the VM runs on, from outside it - nothing is installed in the VM. That is also why memory is what the VM has been given, not what its operating system is using, and why disk and network are its first disk and first network interface. A VM that is not running is not measured, so a stretch with no line is a stretch it was off. A month of history is kept.

The charts bring themselves up to date every minute. Live does it every ten seconds, which is how often a VM is measured; the charts end a few seconds short of now, at the last reading that is certain to be in.

Monitors

The checks made on this VM, and how each stands. A VM can have any number of them, and several of a kind - two pages on the same web server, say.

Nothing is installed in the VM for any of them. The network checks are made from the engine once a minute. Disk space is read off the VM's disks by the node it runs on, every twenty minutes; patch level is asked every hour, of a VM whose stack can say.

A check is called down when it has failed for two minutes, and up again as soon as it passes. Failing is a check that has just stopped passing and may yet recover. Going down and coming back are both mailed to the alert address - the VM's own, else its stack's, else your account's (see Contacts) - and shown here as they happen. A monitor left down is mentioned again once a day until someone presses the bell, which says it is known.

Pausing a monitor stops the checking. The time it is off counts neither for nor against it. A VM behind a gateway has no address the engine knows, so a network check on one has to be given the address to knock on, under More settings - any address but the engine's own and its nodes'.

Clicking a monitor opens what its last check found. For a page that is its status, its size, how long each part of fetching it took - connecting, the TLS handshake, waiting for the server - and the TLS it was served with; for any network check, a day of how long it took to answer; for disk space, each filesystem and a week of how full it was. What a web server says in its headers is not kept from one check to the next, so Fetch the headers now asks again and shows what comes back: a check made for the asking, not the last one made on schedule.

Certificates

A check over TLS notes when the certificate it was shown runs out. From a fortnight before, the monitor says so beside its name and the alert address is mailed - then, again a week on, and once more if it expires. The check itself goes on passing: a VM is asked by its address, which is not the name on its certificate, so the certificate is not what makes the check pass or fail.

Uptime

For a month, how much of the time each monitor was being checked it was up, how long it was down in all, and how many times it went down. This month so far is the default; thirteen months are kept. CSV downloads the month shown.