Create a VM

A classic VM is a normal Linux server: its own kernel, its own disk, cloud-init on first boot, and a console. If you have used a cloud instance before, none of this will surprise you.

Before you start you need an image to boot from. If you have not cached one yet, creating the machine fetches it. See First-run setup and Images and templates.

A storage pool is not a prerequisite. A host with a spare disk should have one, and the Storage page will say so, but a host whose only disk is its system disk keeps machine data there and is fully supported. See Storage pools for both cases.

Create one

1. Open Instances and start a new VM.

2. Pick an image and size the machine.

   Choose a distribution, then a release under it, then set vCPUs, memory, and disk size. A release the host does not hold yet is fetched as part of creating the machine. The disk is a full copy of the image and can be larger than the original, so size it for what the workload will actually store. It cannot be smaller than the image: ask for less and the host gives you the image’s own size instead, and reserves that larger figure against the pool. The size you see committed is therefore the size the machine can grow into. Under Disk Size the form also states how much of the pool is free, and warns there when the size you asked for, with any new data volumes and the batch count, will not fit. A request the pool plainly cannot hold is refused with a 409 as it arrives, before any machine is created, and the reason is stated in GiB. That check is a floor and reserves no space, so a create it lets through can still fail at provisioning.

3. Attach it to a network.

   Leaving the default is right for most hosts: the VM joins the host’s default VM network and gets an address from your existing DHCP server. To pin an address instead, switch the interface to a static IPv4 address and set the gateway and DNS servers yourself.

4. Set up access.

   Apply a template, or fill in the hostname, user, SSH keys, and password directly. This is what cloud-init consumes the first time the machine boots.

5. Boot it.

   Leave Boot after creation on and the machine starts as soon as it is built.

First-boot accounts

The form pre-fills a freshly generated password every time you open it, so two machines created from the defaults never share a credential. You can read it back later from the Cloud-init panel on the instance, so the randomness does not lock you out.

A few behaviours are worth knowing before you change the defaults.

• A root account with a password can log in over SSH. Leaving the root login option on Follow the image with a password set enables password login, because most cloud images ship configured to refuse it.
• An account with no password gets passwordless sudo. Granting sudo to an account that has no password to type would otherwise promise something the guest cannot deliver. An account with a password still has to enter it.
• Disabling root turns sudo on by default for the account you create in its place, since a machine with no root and no way to escalate is a machine you cannot administer.

Some combinations are refused outright rather than producing a machine nobody can reach: root disabled with no password and no SSH key, root disabled while also permitting root login, an empty password, and reusing a system account name such as daemon or www-data. Resetting a distribution’s own default user, such as debian or ubuntu, is allowed.

Auto update installs, but does not reboot

Turning on automatic updates installs upgrades on first boot and leaves the reboot to you. Rebooting on its own could cut first-boot setup off partway through, and there is no delay that is safe on every image.

Reaching the machine

The Instances list shows the VM moving to running, then reports the address it was observed at. SSH to that address with the credentials you configured.

If the state stays at booting, the machine started but was never seen on the network. Open its console from the VM detail page and look at the boot output. A VM the host can observe is eventually marked failed rather than left claiming to be healthy. One the host cannot observe stays in booting instead, because silence is not evidence; restarts in quick succession are what mark it failed.

Options worth knowing

Option	Where it lives	Why you would use it
Additional interfaces	Network	Attach a VM to more than one network. Interface 1 (eth0) is the primary; every other interface is a block of its own below it
MAC address, MTU, bandwidth cap	Network	Pin an identity, match what a segment expects, or cap throughput. Every interface carries a cap, not only the primary
Anti-spoof and port isolation	Network	Restrict what the machine may send, and stop it talking to its neighbours
Data volumes	Additional hardware	Give the machine disks beyond its system disk
PCI passthrough	Additional hardware	Hand a host device to the guest
vCPUs	Resources	Up to 254 per machine. The ceiling is what the boot firmware has been tested to, not a capacity limit, so it will not be raised casually
Max vCPUs and Max memory (online growth)	Resources, under Advanced	Headroom for growing the machine while it runs. Both are fixed when the machine boots, so a machine created without them can only be resized by a reboot
CPU pinning	Resources, under Advanced	Bind vCPUs to specific host CPUs for latency-sensitive workloads
Nested virtualization	Resources, under Advanced	Let the guest run its own hypervisor, for a VM inside the VM or a container runtime that needs it
Disk I/O limits	Resources, under Advanced	Cap IOPS and bandwidth so one machine cannot starve the others
Console auto-login	Access	Get a console session without a password, useful when you are still setting up access
Guest agent (QGA)	Access	Let the host ask the guest for its address and take a consistent snapshot of a running machine. On by default
Saved keys	Access	Fill in a public key already saved under Keys instead of pasting it again. Save a new key… adds one from a dialog over this form, without leaving it

Neither ceiling is set by default, and that is deliberate: the guest allocates memory for the processors it is allowed to grow to, so headroom you declare is memory the host cannot give to anyone else. Declare it on the machines you know you will resize, and leave it out of the rest.

The Guest agent (QGA) switch is on by default. A machine without it still works; the loss is limited to what has to ask the guest. If the image does not ship the agent, the machine installs it from its package mirror on the first boot and connects it back to the host. Turn it off for a host with no internet access, or for an image that must not install packages: nothing about the agent then goes into the seed, and the instance’s Cloud-Init panel reads Guest agent setup: Off. A machine created before the switch existed reads as on, and so does a create request that leaves the field out.

Additional hardware is a collapsed section at the foot of the form holding data volumes and PCI passthrough: the choices most people never make. If a template pre-filled a data volume, it opens by itself, so nothing is applied that you cannot see.

To create more than one machine at once, set How many in the Count block. The block is on the form whether or not you picked a template. See Images and templates.

Only one interface may carry a gateway

If you attach several interfaces, give exactly one of them a gateway. Two default routes make the guest pick one at random, which shows up later as a machine that is reachable only some of the time.

Changing a VM later

Shape changes such as vCPUs, memory, and network attachment are made while the machine is created or stopped, not while it runs. Anti-spoof and port isolation are the exception: those take effect immediately, without a reboot.