> For the complete documentation index, see [llms.txt](https://platform9.com/kb/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://platform9.com/kb/pcd/networking/vm-network-port-attachment-failure-and-high-cpu-usage-on-ovndb.md).

# VM Network Port Attachment Failure and High CPU Usage on OVNDB

### Problem <a href="#problem" id="problem"></a>

PCD environment is experiencing a critical failure in VM network port attachment operations, preventing virtual machines from connecting to the network. The service is consuming 88-95% CPU, causing it to become unavailable for legitimate API requests.

{% code title="OVN Logs" %}

```
|poll_loop|INFO|Dropped 79 log messages in last 94 seconds (most recently, 91 seconds ago) due to excessive rate
|poll_loop|INFO|wakeup due to 0-ms timeout at ../ovsdb/jsonrpc-server.c:616 (95% CPU usage)
```

{% endcode %}

{% code title="ostackhost Logs" %}

```
nova.exception.PortInUse: Port <PORT_UUID> is still in use.
```

{% endcode %}

### Environment <a href="#environment" id="environment"></a>

* Private Cloud Director Virtualization - v2025.4 and Higher
* Private Cloud Director Kubernetes – v2025.4 and Higher
* Self-Hosted Private Cloud Director Virtualization - v2025.4 and Higher
* Self-Hosted Private Cloud Director Kubernetes - v2025.4 and Higher

### Cause <a href="#cause" id="cause"></a>

The OVN Database (OVN-DB) service has entered a non-responsive state characterised by a high-CPU spin loop.

### Diagnostics <a href="#diagnostics" id="diagnostics"></a>

{% hint style="info" %}
Step 2 -3 only accessible and applicable for the Self-Hosted Private Cloud Director.&#x20;

For SaaS environments, please reach out to Platform9 support.
{% endhint %}

1. VM deployment fails with the below exception shown on the `pf9-ostackhost` logs located on the hypervisor at location `/var/log/pf9/`.

   <pre data-title="ostackhost Logs"><code>nova.exception.PortInUse: Port &#x3C;PORT_UUID> is still in use.
   </code></pre>
2. Review the `ovn-ovsdb-sb-0` pod logs from the workload region namespace.

   ```
   $ kubectl logs -n <WORKLOAD_NAMESPACE> <OVN_OVSDB_POD_NAME>
   ```
3. Validate the above pod logs and check CPU usage messages like those shown in the below snippet.

   ```
   |poll_loop|INFO|wakeup due to 0-ms timeout at ../ovsdb/jsonrpc-server.c:616 (95% CPU usage)
   ```

## Resolution

{% hint style="info" %}
Only accessible and applicable for the Self-Hosted Private Cloud Director.&#x20;

For SaaS environments, please reach out to Platform9 support.
{% endhint %}

1. Take the backup of OVNDB database.

   ```
   $ kubectl cp <WORKLOAD_NAMESPACE>/<OVN_OVSDB_NB_POD_NAME>:/var/lib/ovn/ovnnb_db.db  ./ovnnb_db_backup.db
   $ kubectl cp <WORKLOAD_NAMESPACE>/<OVN_OVSDB_SB_POD_NAME>:/var/lib/ovn/ovnsb_db.db ./ovnsb_db_backup.db
   ```
2. Once backup is taken, execute compaction command

   ```
   $ kubectl exec <OVN_OVSDB_NB_POD_NAME> -n <WORKLOAD_NAMESPACE> -- ovn-appctl -t /var/run/ovn/ovnnb_db.ctl ovsdb-server/compact
   $ kubectl exec <OVN_OVSDB_SB_POD_NAME> -n <WORKLOAD_NAMESPACE> -- ovn-appctl -t /var/run/ovn/ovnsb_db.ctl ovsdb-server/compact
   ```
3. Enable memory compaction on the below pods

   ```
   $ kubectl exec <OVN_OVSDB_NB_POD_NAME> -n <WORKLOAD_NAMESPACE> -- \
     ovn-appctl -t /var/run/ovn/ovnnb_db.ctl ovsdb-server/memory-trim-on-compaction on

   $ kubectl exec <OVN_OVSDB_SB_POD_NAME> -n <WORKLOAD_NAMESPACE> -- \
     ovn-appctl -t /var/run/ovn/ovnsb_db.ctl ovsdb-server/memory-trim-on-compaction on
   ```
4. Restart the below pods

   ```
   $ kubectl delete <OVN_OVSDB_NB_POD_NAME> -n <WORKLOAD_NAMESPACE>
   $ kubectl delete <OVN_OVSDB_SB_POD_NAME> -n <WORKLOAD_NAMESPACE>
   ```

## Validation

{% hint style="info" %}
Step 1-2 is applicable for the Self-Hosted Private Cloud Director.&#x20;

For SaaS environments, please reach out to Platform9 support.
{% endhint %}

1. Check the pods' status; it should be running

   ```
   $ kubectl get pods -n <WORKLOAD_NAMESPACE>  | grep -i ovn
   ```
2. Review the `ovn-ovsdb` pod logs from the workload region namespace and confirm if no high CPU usage messages are logged in these pods.

   ```
   $ kubectl logs -n <WORKLOAD_NAMESPACE> <OVN_OVSDB_POD_NAME>
   ```
3. Deploy a new VM and review the `pf9-ostackhost` logs from the hypervisor (host); it no longer logs `Port <PORT_UUID> is still in use` messages.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://platform9.com/kb/pcd/networking/vm-network-port-attachment-failure-and-high-cpu-usage-on-ovndb.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.