Minimize the VM start time

If you require your VMs to boot as quickly as possible, minimize your virtual machine (VM) start time with the instructions on this page. Minimizing the start time comes at the cost of resource efficiency—your project consumes additional resources, and has an increased security surface.

Before you begin

To use gdcloud command-line interface (CLI) commands, ensure that you have downloaded, installed, and configured the gdcloud CLI. All commands for Distributed Cloud use the gdcloud or kubectl CLI, and require an operating system (OS) environment.

Get the kubeconfig file path

To run commands against the org admin cluster, ensure you have the following resources:

Locate the org admin cluster name, or ask your Platform Administrator (PA) what the cluster name is.
Sign in and generate the kubeconfig file for the org admin cluster if you don't have one.
Use the path to the kubeconfig file of the org admin cluster to replace ORG_ADMIN_KUBECONFIG in these instructions.

Request permissions and access

To perform the tasks listed in this page, you must have the Project VirtualMachine Admin role. Follow the steps to verify that you have the Project VirtualMachine Admin (project-vm-admin) role in the namespace of the project where the VM resides.

Keep disk connections alive

When a VM starts, initiating a connection from the VM's node to the VM's disk takes a few seconds. To make the VM start up faster, the disk connection must be kept alive when the VM is shut down so that the disk connection doesn't reinitiate on subsequent VM starts. To achieve this, when you run the command to enable disk connection keep-alive the system automatically creates a dummy pod that mounts all the VM's disks.

Enable disk connection keep-alive

To keep disk connections alive for a VM called VM_NAME in the project PROJECT, run the following command. When you do, the system automatically creates the dummy pod:

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG patch virtualmachines.virtualmachine.gdc.goog VM_NAME -n PROJECT --type merge --patch $'
metadata:
  annotations:
    disk.virtualmachine.gdc.goog/enable-connection-keep-alive: "true"
'

Replace the variables throughout these instructions, using the following definitions.

Variable	Definition
`ORG_ADMIN_KUBECONFIG`	The org admin cluster `kubeconfig` file path.
`VM_NAME`	The name of the VM.
`PROJECT`	The GDC project in which the VM resides.

When the disk connection keep-alive is enabled, a pod named disk-connection-keep-alive-VM_NAME is created in the same project as the VM. The next VM restart is faster, as are subsequent start times, because the VM's disk connections are kept alive by the pod.

Set up disk connection keep-alive affinity

The Kubernetes scheduler might select a different node for the VM when it restarts. To reduce the chances of that happening, configure an inter-VM affinity rule between the VM and the keep-alive pod. Configure this to happen automatically:

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG patch virtualmachines.virtualmachine.gdc.goog VM_NAME -n PROJECT --type merge --patch $'
metadata:
  annotations:
    disk.virtualmachine.gdc.goog/add-connection-keep-alive-affinity: "true"
'

This adds a preferred-affinity setting on the VM to the keep-alive pod.

Caveats

There are two caveats to keeping disk connections alive:

The keep-alive pod incurs additional resource usage:
- It counts towards the limit of the number of pods per node.
- It uses an additional IP address that is assigned by Kubernetes.
- It uses a negligible additional amount of CPU and memory.
The security surface increases, because the node where the keep-alive pod is present always has the VM's disks attached, even when the VM is shut down.

Use BIOS firmware

In GDC, starting a VM with Unified Extensible Firmware Interface (UEFI) firmware is slower than starting a VM with BIOS firmware.

To ensure that the start time is minimal, set the VM's firmware type to BIOS:

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG patch virtualmachines.virtualmachine.gdc.goog VM_NAME -n PROJECT --type merge --patch $'
spec:
  firmware:
    type: bios
    enableSecureBoot:
'

If the VM is running, restart it using the instructions to restart the VM.

Caveats

The caveat to using BIOS firmware is that it doesn't support secure boot.

Use a large boot disk

To minimize the VM start time, attach a boot disk with a size of 500 GB or greater to the VM.