# How to maintain a Quake AI VM over its lifetime
Source: https://docs.quake.ai/docs/compute/how-to/maintain-vm
Markdown: https://docs.quake.ai/docs/compute/how-to/maintain-vm.md
---
# 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.
Quake AI performs control-plane actions such as resize, reboot, and volume attach. You perform in-guest work such as growing filesystems, rotating logs, and cleaning disk. Quake AI does not auto-resize filesystems, auto-clean disks, or run managed maintenance windows for customer VMs.
- A running Linux VM with SSH access
- Sudo inside the guest
- For resize operations, a maintenance window that tolerates a brief restart
## 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](/docs/compute/how-to/create-snapshot) before a major resize so you can roll back if the new flavor misbehaves.
1. Open **Compute** > **Instances** and select the instance.
2. From the instance action menu, choose **Resize Instance** (wording may vary by Console version).
3. Select the target flavor and confirm. The instance reboots during the resize.
4. When the instance returns to **Active**, verify the workload.
Verify the instance is active, then resize:
```bash
openstack server show INSTANCE_NAME -c status -c flavor
openstack server resize --flavor NEW_FLAVOR INSTANCE_NAME
openstack server resize confirm INSTANCE_NAME
openstack server show INSTANCE_NAME -c flavor -c status
```
If the resize fails, revert:
```bash
openstack server resize revert INSTANCE_NAME
```
See [Instances CLI reference](/reference/compute/instances-cli) for resize notes on volume-backed instances.
## 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](/docs/block/how-to/extend-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:**
```bash
lsblk
sudo growpart /dev/sdb 1
sudo resize2fs /dev/sdb1
df -h /mnt/data
```
Replace `/dev/sdb` with your device and partition numbers from `lsblk`.
```bash
lsblk
sudo growpart /dev/sdb 1
sudo xfs_growfs /mnt/data
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](/docs/block/how-to/create-volume), then mount it as described in [How to operate a running Quake AI VM](/docs/compute/how-to/operate-running-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](/docs/compute/how-to/patch-and-update-vm).
1. Open **Compute** > **Instances**, select the instance, and choose **Reboot** or **Hard Reboot** from the action menu.
2. Wait for status **Active**, then verify the workload.
Soft reboot:
```bash
openstack server reboot INSTANCE_NAME
```
Hard reboot when the guest is unresponsive:
```bash
openstack server reboot --hard INSTANCE_NAME
```
In-guest reboot (same effect when SSH works):
```bash
sudo reboot
```
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.
```bash
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:
```bash
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](/docs/compute/how-to/create-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:**
1. Open **Compute** > **Instances**, select the instance, and choose **Delete Instance**.
2. Confirm deletion.
```bash
openstack server delete INSTANCE_NAME
```
Release a floating IP that belonged only to this workload:
```bash
openstack floating ip list
openstack floating ip delete FLOATING_IP
```
## Related documentation
- [How to operate a running Quake AI VM](/docs/compute/how-to/operate-running-vm): day-2 connect and storage tasks
- [How to patch and update a Quake AI VM](/docs/compute/how-to/patch-and-update-vm): OS updates and kernel reboots
- [How to create an instance snapshot](/docs/compute/how-to/create-snapshot): rollback and archival snapshots
- [How to back up and restore a Quake AI VM](/docs/compute/how-to/backup-and-restore): offsite copy and restore drill after snapshots
- [How to extend a volume](/docs/block/how-to/extend-volume): grow block storage at the control plane
- [Automated backups with object storage](/docs/quickstart/automated-backups): file-level backup patterns