OLVM AIops MCP server

<!-- mcp-name: io.github.AIops-tools/olvm-aiops -->

OLVM AIops

Disclaimer: Community-maintained open-source project. Not affiliated with, endorsed by, or sponsored by Oracle or the oVirt project. "Oracle", "Oracle Linux" and "oVirt" are trademarks of their owners. MIT licensed.

AI-powered operations for Oracle Linux Virtualization Manager (OLVM) and oVirt 4.5, over the engine REST API, with a built-in governance harness — an audit log that MCP and CLI calls both write to, a token/runaway budget guard, and descriptive risk tiers. Built for teams that run OLVM (often next to another hypervisor platform) and want an agent to answer "what needs attention?" with evidence from the engine, not guesses. Built on httpx and the MCP SDK, not on the pycurl-based engine SDK.

Read-only in this release: inventory, health, capacity and diagnosis.

Engine actions are asynchronous — the engine answers complete long before a

VM or host reaches its target state — so write tools are held back until each

can confirm its own outcome. Do NOT use for XCP-ng — use xcpng-aiops. Do NOT

use for Proxmox VE — use proxmox-aiops.

What this tool does, and does not, decide

It reads an OLVM / oVirt engine accurately and records every call. It does not decide what an agent may change — that belongs to the engine account you connect it with. Give that account a read-only role (such as ReadOnlyAdmin) and the engine itself enforces it.

The one thing the tool guarantees is that nothing is silent: every call, over MCP and over the CLI alike, lands an audit row in ~/.olvm-aiops/audit.db.

Running a smaller / local model? See agent-guardrails.md for what the tool already guarantees and a ready-made system prompt for the rest.

What it answers

17 MCP tools: 15 reads and diagnoses, plus the harness's undolist / undoapply (which have nothing to undo in a read-only release).

Each diagnosis ranks findings worst first; every finding carries the measured signal, a cause, an action and an explicit rank. Transient states are not reported as failures: a host the engine is installing or rebooting is "in progress", alert 9000 on a host without fencing hardware is informational, and an event the host, VM or data center has since recovered from is marked superseded. Events older than 24 hours (eventswindowhours) are history, not findings, and every warning-or-worse event inside the window lands in exactly one diagnosis — engine-wide alerts such as certificate expiry and missing backups included.

Built from a live engine, not from the docs

Every read was written against, and every fixture captured from, a live Oracle Linux Virtualization Manager 4.5.5-1.73.el9 engine with Keycloak enabled. Things that engine does, which this tool accounts for:

Shortened. The full README is on GitHub.