> For the complete documentation index, see [llms.txt](https://docs.weka.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.weka.io/kubernetes/weka-operator-deployments/migrate-standalone-csi-to-weka-operator-embedded.md).

# Migrate standalone CSI to WEKA Operator-embedded

## Unified CSI management

The legacy WEKA CSI plugin functions as a standalone Helm chart deployment. In this model, the plugin lifecycle, including updates and configuration changes, requires independent management of the Helm release.

Transitioning to an Operator-embedded deployment provides a unified management model. The WEKA Operator assumes control of the CSI lifecycle, which simplifies maintenance. During this transition, the Operator takes over the CSI plugin management without affecting existing PersistentVolumes (PVs) or PersistentVolumeClaims (PVCs).

### Operational impact

The migration process affects cluster operations as follows:

* **Volume integrity:** Existing PVCs and PVs remain intact. Uninstalling the standalone plugin only prevents new volume provisioning and mounting until the migration completes.
* **Management availability:** CSI operations, such as creating or deleting PVCs and gathering metrics, are blocked until the embedded CSI is active.

### Migration limitations

Identify specific environment constraints that affect the migration process.

* **Mixed mount environments:** Kubernetes clusters that combine stateless client mounts outside CSI with CSI mounts and Operator-managed clients do not support non-disruptive upgrades. Use reboot-based upgrades, or manually unmount and remount volumes during the client provisioning cycle.
* **Agent removal:** The WEKA agent cannot be removed from a server while active mounts are present. Plan agent removal only after unmounting all volumes or during a coordinated maintenance window.

{% hint style="warning" %}
Avoid direct mounts on Kubernetes servers outside the CSI plugin. Direct mounts can cause issues during upgrades and server reboots.
{% endhint %}

## Migrate the CSI plugin

Back up existing Helm values for both the Operator and the CSI plugin.

**Before you begin**

Before starting the migration, ensure the environment meets these criteria:

* **Operator version:** The WEKA Operator version is 1.7.0 or later.
* **Original installation:** The standalone CSI plugin was installed using the `csi-wekafs` Helm chart.
* **Maintenance window:** A maintenance window is scheduled to account for a potential IO stall during CSI cutover.
* **Backups:** Back up existing Helm values for both the Operator and the CSI plugin.

**Procedure**

1. **Upgrade the Operator:** Upgrade the WEKA Operator to version 1.7.0 or later. The embedded CSI plugin remains disabled by default after the upgrade to prevent interference with the standalone installation.
2. **Uninstall the standalone CSI:** Remove the Helm-based CSI installation.

   ```bash
   helm uninstall csi-wekafs -n <namespace>
   ```
3. **Configure the CSI group name:** Set the `csiGroup` parameter in the WekaClient specification. This maintains compatibility with the `csi.weka.io` driver name and ensures existing StorageClasses and PVs function without modification.

   ```yaml
   spec:
     csiConfig:
       csiGroup: csi
   ```
4. **Enable the embedded CSI:** Update the Operator configuration to enable the embedded CSI plugin.
   1. Retrieve existing flags:

      ```bash
      helm get values weka-operator
      ```
   2. Run the helm upgrade with the retrieved flags:

      ```bash
      helm upgrade weka-operator <chart> --set csi.installationEnabled=true [other existing flags]
      ```
5. **Verify the deployment:** Validate the status of the migration and all components.

<table><thead><tr><th width="150.36370849609375">Component</th><th>Validation command</th></tr></thead><tbody><tr><td>Deployment status</td><td><code>kubectl get wekaclient &#x3C;client-name> -n &#x3C;namespace> -o jsonpath='{.status.csiDeployed}'</code></td></tr><tr><td>Storage classes</td><td><code>kubectl get storageclass</code></td></tr><tr><td>Controller status</td><td><code>kubectl get deployment -n</code></td></tr><tr><td>Node pods</td><td><code>kubectl get pods -n &#x3C;csi-namespace> -l component=csi-weka-csi-node</code></td></tr></tbody></table>

**Related topic**

[WEKA CSI Plugin](/appendices/weka-csi-plugin.md)


---

# 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 current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.weka.io/kubernetes/weka-operator-deployments/migrate-standalone-csi-to-weka-operator-embedded.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.