GCP / Guide 7

Compute Engine VMs

Machine types, disks, availability, patching with VM Manager, the Ops Agent, and saving money on VMs.

Compute Engine is where most Google Cloud operations work still happens, and often where most of the bill is. This guide covers the day-to-day: knowing what's running, choosing machine types and disks, availability, patching, monitoring, and spending less.

Know what you have

Start with an inventory across every project. Get-GcpVMInventory.ps1 lists every VM with machine type, status, IPs, disks, service account, Shielded VM and OS Login settings, and the owner and cost labels. Quick checks from the shell:

# Running VMs in a project
gcloud compute instances list --project=prj-notes-test --filter="status=RUNNING" `
    --format="table(name, zone.basename(), machineType.basename(), networkInterfaces[0].networkIP, labels.owner)"

# VMs stopped for more than 30 days still pay for their disks and any reserved IPs
$cutoff = (Get-Date).AddDays(-30).ToString('yyyy-MM-dd')
gcloud compute instances list --filter="status=TERMINATED AND lastStopTimestamp<$cutoff" `
    --format="table(name, zone.basename(), lastStopTimestamp)"

(TERMINATED is Google's name for a stopped VM. It can be started again.)

Choose the machine type

• Custom machine types (on E2, N2, N4 and others) let you pick vCPUs and memory separately, so a workload that needs 6 vCPUs and 20 GB doesn't pay for 8 vCPUs and 32 GB.
• Arm (Axion) machine types are usually cheaper for Linux workloads that run on Arm: most open-source stacks and containers do.
• Rightsize with data. Compute Engine's machine type recommendations (Recommender) suggest smaller types from 8 days of utilisation. Install the Ops Agent so memory is included, not just CPU.

Disks

Disks can be resized upwards online, but never shrunk, so start smaller. Delete the unattached disks and old snapshots Find-GcpOrphanedResources.ps1 finds, and set auto-delete on disks that shouldn't outlive their VM.

Availability

• Live migration moves most VMs to other hosts during Google's maintenance without a reboot. Set the maintenance policy to MIGRATE (the default for most types); GPU VMs and some others must restart instead.
• A single VM lives in one zone. For anything that must stay up, run a managed instance group (MIG) behind a load balancer, preferably a regional MIG spread across three zones.
• Use MIGs even for a fixed size: autohealing with a health check recreates a failed VM automatically, and rolling updates replace VMs from a new instance template without downtime.
• Instance templates describe how a VM is built (image, machine type, service account, Shielded VM, labels, startup script). Keep them in Terraform and build every VM from one.
• Stateful servers that can't be load-balanced need backups (Guide 8) and, for fast failover, regional disks or database replication.

Patching with VM Manager

VM Manager handles OS patch management, OS inventory and OS configuration through the OS Config agent, which is preinstalled on most Google-provided images. Turn it on for the project (or organisation) and:

• Patch compliance shows which VMs are missing critical and security updates, by OS.
• Patch deployments run on a schedule against VMs selected by label and zone, for example production weekly on Sunday night, test on Wednesday, with a rollout that patches one zone at a time.
• Pre- and post-patch scripts stop and start services, or take the VM out of a load balancer.
• Replace rather than patch where you can: MIGs rolled onto a newly patched image built by a pipeline.

# Weekly patch job for VMs labelled environment=prod, one zone at a time
gcloud compute os-config patch-deployments create prod-weekly --file=.\prod-weekly.yaml

# Which VMs report to VM Manager (OS inventory present)
gcloud compute os-config inventories list --location=us-east1-b --format="table(name.segment(5), osInfo.shortName, osInfo.version, updateTime)"

Monitoring agents

Compute Engine sends CPU, network and disk operations to Cloud Monitoring without an agent, but not memory or disk space: those need the Ops Agent, which collects both metrics and logs (Windows event logs, syslog, and application logs for common software such as Apache, IIS, MySQL and SQL Server). Install it across a project with an OS policy in VM Manager, or with the agent policy command, so new VMs get it automatically. Guide 9 covers the alerts to set on it.

Save money on Compute Engine

• Sustained use discounts apply automatically to N1, N2, N2D and some other series when a VM runs for a large part of the month. Nothing to buy; newer series such as E2, N4 and C4 don't get them but have lower list prices.
• Stop non-production VMs out of hours. A VM running 12 hours on weekdays costs about 36% of one running all month. Compute Engine instance schedules do this natively per project; Invoke-GcpVMPowerSchedule.ps1 does it by label across projects. Stopped VMs still pay for disks.
• Rightsize, then commit with committed use discounts (Guide 10).
• Spot VMs cost a fraction of the on-demand price for work that can be interrupted: batch, CI runners, stateless workers in a MIG.
• Windows and SQL Server licences are a large part of the price. Check whether bring-your-own-licence on sole-tenant nodes or a smaller SQL edition applies.

Troubleshooting without SSH or RDP

• Serial port output (gcloud compute instances get-serial-port-output) shows the boot log, which explains most VMs that won't come up.
• Screenshot (the VM's details page) shows the console screen, useful for Windows.
• Interactive serial console gives a text login to fix a broken network or SSH configuration. It's off by default; turn it on per VM only when needed, and keep the organisation policy that disables it elsewhere.
• Connectivity Tests answer "is it the firewall?" in a minute (Guide 4).
• Troubleshoot SSH in the console runs a set of checks (firewall, IAM, OS Login, guest agent) and tells you which one fails.