How to maintain a Quake AI VM over its lifetime

Keep a production VM healthy over months of use: change its flavor when load grows, expand attached storage, reboot safely, rotate logs, and decommission the instance without leaving orphaned resources.

Resize or change flavor#

Resize changes vCPU, RAM, and bandwidth caps. Because Quake AI instances boot from a persistent Cinder volume, flavor resize does not grow the root disk; extend the boot volume separately when you need more disk space.

Take an instance snapshot before a major resize so you can roll back if the new flavor misbehaves.

Grow storage#

Expand a data volume at the control plane, then grow the partition and filesystem in the guest.

Extend an attached volume:

Follow How to extend a volume at Cinder microversion 3.42 or later for online extend, or detach, extend, and reattach when online extend is unavailable.

Grow the filesystem in the guest:

lsblk
sudo growpart /dev/sdb 1
sudo resize2fs /dev/sdb1
df -h /mnt/data

To add capacity with a new volume instead of extending an existing one, create and attach a volume with How to create a volume, then mount it as described in How to operate a running Quake AI VM.

Reboots and maintenance windows#

Coordinate reboots with application owners. Kernel reboots after patching are covered in How to patch and update a Quake AI VM.

Drain connections before you reboot production services (stop the app, remove the instance from your reverse-proxy or edge origin pool, or pause traffic at your edge).

Log rotation and disk hygiene#

Quake AI does not clean guest disks. Monitor usage and rotate logs before partitions fill.

df -h
sudo journalctl --disk-usage
sudo du -xh /var/log | sort -h | tail -10

Configure logrotate for application logs under /etc/logrotate.d/. Trim old journal entries when /var/log/journal grows large:

sudo journalctl --vacuum-time=7d

Set an alert in your monitoring stack when any mount exceeds 80% utilization.

Decommission the VM#

When you retire a workload, capture state you need, detach resources you want to keep, then delete the instance.

1. Snapshot for archival (optional): Create an instance snapshot if you need a restore point or golden image.
2. Preserve data volumes: detach volumes you want to keep with openstack server remove volume INSTANCE_NAME VOLUME_NAME or the Console Detach action. Delete only volumes that are truly disposable.
3. Release floating IPs tied to this workload: if you allocated a floating IP for this instance's SSH or public traffic, disassociate and release it. Keep floating IPs used by NAT, reverse proxies, edge origins, or other instances.
4. Delete the instance:

Related documentation#

• How to operate a running Quake AI VM: day-2 connect and storage tasks
• How to patch and update a Quake AI VM: OS updates and kernel reboots
• How to create an instance snapshot: rollback and archival snapshots
• How to back up and restore a Quake AI VM: offsite copy and restore drill after snapshots
• How to extend a volume: grow block storage at the control plane
• Automated backups with object storage: file-level backup patterns