Skip to content

Sync CNV runbook GuestFilesystemAlmostOutOfSpace.md (Updated at 2026-02-03 12:16:09 +0000 UTC) #396

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
hco-bot wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Sync CNV runbook GuestFilesystemAlmostOutOfSpace.md (Updated at 2026-02-03 12:16:09 +0000 UTC) #396

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 13 additions & 13 deletions alerts/openshift-virtualization-operator/GuestFilesystemAlmostOutOfSpace.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,9 +7,9 @@ of available disk space.

The alert has the following severity levels:

- **Warning**: Triggers when file-system usage is between 85% and 95% for 5
- **Warning**: Triggers when file system usage is between 85% and 95% for 5
minutes.
- **Critical**: Triggers when file-system usage exceeds 95%.
- **Critical**: Triggers when file system usage exceeds 95%.

The alert provides details about the specific file system (`disk_name`), its
mount point (`mount_point`), the VMI name, and namespace.
Expand All @@ -29,7 +29,7 @@ application or system failure.

## Diagnosis

1. Check the file-system usage metrics for the VMI:
- Check the file-system usage metrics for the VMI:

```bash
# Get the domain name of the VMI
Expand All @@ -41,7 +41,7 @@ application or system failure.
$ oc exec -it <pod-name> -n <namespace> -- virsh qemu-agent-command <domain-name> '{"execute": "guest-get-fsinfo"}'
```

2. You can also connect to the VMI by using the `virtctl` console to inspect
- You can also connect to the VMI by using the `virtctl` console to inspect
disk usage in the guest OS:

```bash
Expand Down Expand Up @@ -87,30 +87,30 @@ disk usage in the guest OS:
$ virtctl restart <vm-name> -n <namespace>
```

This step causes the disk.img to be resized to match the new PVC size.
While this is primarily needed for filesystem volumes, it's recommended
to always restart for consistency.
This step resizes the disk.img to match the new PVC size.
While this is primarily needed for file system volumes, restarting to
apply changes in generally recommended.

### Long-term Solutions

1. **Set up log rotation and cleanup policies** within guest operating systems.
- **Set up log rotation and cleanup policies** within guest operating systems.

2. **Use appropriate volume sizes** when provisioning VMs based on expected
- **Use appropriate volume sizes** when provisioning VMs based on expected
workload requirements.

3. **Consider using dynamic storage provisioning** with StorageClasses that
- **Consider using dynamic storage provisioning** with StorageClasses that
support volume expansion.

4. **Implement automated cleanup scripts** or maintenance tasks within VMs to
- **Implement automated cleanup scripts** or maintenance tasks within VMs to
manage disk space proactively.

5. **Review and optimize application storage patterns** to minimize unnecessary
- **Review and optimize application storage patterns** to minimize unnecessary
disk usage.

If the issue persists or the file system continues to fill up rapidly after
cleanup, investigate the root cause such as application bugs, excessive logging,
or unexpected data growth.

If you cannot resolve the issue, log in to the
[Customer Portal](https://access.redhat.com) and open a support case,
[Red Hat Customer Portal](https://access.redhat.com) and open a support case,
attaching the artifacts gathered during the diagnosis procedure.