Deploying Workloads

Overview

Virtual machine instances (instances or VMs for short), virtual private cloud (VPC, private networks), images, and disks are organized in projects. These project resources are accessible only by users who are granted IAM roles in the project or its parent silo.

The permissions to create, update, or delete project resources are limited to users with the “collaborator” or “admin” role in the project. Project admin can, in addition, modify project name, description, IAM roles, and delete the project.

VM instances can be provisioned with machine images made available by the project or silo administrators and collaborators. A VM may have one or multiple private network interfaces and, optionally, external IP addresses. You can use the default VPC and subnet that come with every project or other custom VPCs/subnets you or others set up in the project.

Creating Virtual Machines

The first step of VM provisioning is making a boot disk with the desired operating system image, plus any additional blank disks to be used by the VM. When provisioning a new instance on the Oxide Console, these new disk requests are performed automatically as part of the instance creation. If you use the API to create a VM, you have the option to provision it with new or existing disks.

In a create VM request, the following attributes must be specified:

  • Project name

  • VM name

  • Boot disk name (the first one in the disks array attribute)

  • Number of virtual CPUs (maximum 64)

  • Memory size (in bytes, minimum 1 GiB)

Other optional attributes for a VM may include:

  • Additional disks to attach

  • Network interfaces (options: default, specific VPC subnets, or none)

  • External IP addresses (options: ephemeral IP, floating IP(s))

  • Overriding hostname

  • User data for cloud-init (e.g. data and scripts for bootstrapping, maximum 32 KiB)

  • Start machine indicator

The following attributes are configured to system default values when they are not specified in the provisioning request:

  • Network interfaces: default, i.e. private IP assigned from the VPC and subnet named default

  • External IP: none, i.e. no inbound external IP address assigned (note: the VM will still have outbound internet access via built-in NAT)

  • Hostname: set to the VM name

  • Start machine: boot up the VM by default

In addition to the cloud-init user data, additional VM metadata such as hostname and SSH public keys are written to a CIDATA volume with base64 encoding. The VFAT volume is mounted during boot time to pass the metadata to cloud-init and is unmounted afterwards.

Making Boot Disks

You can create boot disks from operating system images or machine snapshots created on the Oxide rack. External cloud images in RAW format can also be uploaded to the rack via disk or image import. The data source for import must be a file accessible from your workstation file system.

Each boot disk can only be attached to one VM at a time. To allow a boot disk to become a reusable image for other workloads, you can make disk snapshots and create images from them. Oxide Console and CLI both provide a one-step process for turning an external file into a rack image, essentially combining these three actions:

  1. import external file to disk

  2. make disk snapshot

  3. create image from snapshot

Upload Image

More details about the use of images, disks and snapshots can be found under Creating and Sharing Images and Managing Disks and Snapshots.

Related API References

Accessing Virtual Machines

Linux VM Access via SSH

Public keys for SSH access can be managed by individual users via the Oxide Console (Profile Settings), API, or CLI. For VMs that have images configured with cloud-init, the keys passed into them at provisioning time are inserted into the ~/.ssh/authorized_keys file automatically, allowing users with the matching key pairs to SSH into the VM. Log files for cloud-init can be found under /var/log to troubleshoot any errors encountered during the init process.

Important
Before accessing the VM via SSH, ensure that the SSH service is properly configured on the VM and firewall rules are set to allow inbound TCP connectivity on the appropriate port. The private key also needs to have the appropriate file permissions set.

Linux VM Access via Serial Console

Another way to access VM instances is through the serial console available on the Console. Oxide API also provides two options for serial console access:

  1. streaming console output continuously

  2. querying the serial buffer based on a byte offset (relative to the beginning of the instance’s life or backward from the most recent output).

Related API References

Last updated