26A02a

Youngkyoo Kim10:03 AM
Below are the steps to upgrade from open-source MinIO to the commercial AIStor. Could you please review and validate them?

MinIO -> AIStor Migration Steps

[version Info]
minio v7.0.0 -> aistor operator helm v5.4.0
minio v7.0.0 -> aistor objectstore helm v1.0.13
directpv v4.1.4 -> directpv 5.1.0 (helm v0.4.1)

[Environment variables]
export HELM_RELEASE=wxminio-tenant
export NAMESPACE=tenant-wxminio
export TENANT=wxminio

1. Pre-Check
   1) mc admin info minio
   2) kubectl get pod -A | grep minio
   3) kubectl directpv list volumes
   4) kubectl directpv list drives
   
2. BackUp
   1) kubectl get tenant -n $NAMESPACE $TENANT -o yaml > tenant-backup.yaml
   2) kubectl get secrets -n $NAMESPACE -o yaml >> tenant-backup.yaml
   3) kubectl get directpvvolumes -o yaml > dpvvol_bak.yaml
   4) kubectl get directpvdrives -o yaml > dpvdri_bak.yaml
   5) helm get values -n $NAMESPACE $HELM_RELEASE > helm-values-backup.yaml
   6) helm get values -n $NAMESPACE $HELM_RELEASE --all > helm-values-all-backup.yaml
   
3. Upgrade helm, mc, kubectl-directpv
   1) mv helm /usr/local/bin/
   mv mc /usr/local/bin/
   mv kubectl-directpv /usr/local/bin/
   2) helm version
   mc --version
   kubectl directpv --version
   
4. Upgrade DirectPV
   1) kubectl directpv uninstall
   2) helm install directpv aistor-upgrade/directpv -n directpv
   3) kubectl get all -n directpv
   4) kubectl directpv list drives
   5) kubectl directpv list volumes
   
5. Upgrade AIStor
   1) vi license.yaml
   2) helm upgrade --install --take-ownership -n aistor objectstore-operator aistor-upgrade/aistor-operator -f license.yaml
   3) kubectl get pods -n aistor
   4) kubectl create configmap private-registry-ca --from-file=ca.crt=./sddc-nexus.crt -n aistor
   5) kubectl edit deployment object-store-operator -n aistor
   ...
   volumeMounts:
   - name: custom-ca-volume
   mountPath: /etc/ssl/certs/private-registry-ca.crt
   subPath: ca.crt
   readOnly: true
   ...
   volumes:
   - name: custom-ca-volume
   configMap:
   name: private-registry-ca
   
6. Upgrade Objectstore
   1) kubectl create role default --verb=get,list,watch,create --resource=pods,tenants,statefulsets,services,secrets
   2) kubectl create rolebinding pod-creator-binding --role=default --serviceaccount=NAMESPACE:default -n $NAMESPACE 3) kubectl run aistor-migration --rm -it --restart=Never \ --image=quay.io/minio/aistor/operator-migration:RELEASE.2026-01-23T16-29-10Z --namespace=NAMESPACE \
   -- generate-helm --namespace $NAMESPACE > objectstore-values.yaml
   4) vi objectstore-values.yaml
   ...
   image:
   repository: nexus-sddc.datalake.skhynix.com:12000/minio/aistor/minio
   tag: RELEASE.2026-02-07T07-43-34Z
   pullPolicy: IfNotPresent
   ...
   secrets:
   name: myminio-env-configuration
   existingSecret: false
   5) helm uninstall -n $NAMESPACE $HELM_RELEASE
   6) kubectl get tenant -n $NAMESPACE
   7) kubectl get pvc -n $NAMESPACE
   8) helm install -n $NAMESPACE $TENANT aistor-upgrade/aistor-objectstore -f objectstore-values.yaml --take-ownership
   9) kubectl get pods -n $NAMESPACE -w
   10) kubectl get objectstore -n $NAMESPACE
   
7. Delete MinIO Operator ==> Please review this section.
   1) helm uninstall -n minio-operator minio-operator
   
8. Post Check
   1) mc alias set minio http://:30101
   2) mc admin info minio
   3) echo "test" > /tmp/test.txt
   mc cp /tmp/test.txt minio//
   mc ls minio//
   mc rm minio//test.txt
   
9. Rollback ==> Please review this section.
   1) helm uninstall -n $NAMESPACE $TENANT
   2) helm install -n $NAMESPACE $HELM_RELEASE minio/tenant -f helm-values-backup.yaml --version 7.0.0
   

F
Felvine Sakwe10:14 AM
@Youngkyoo Kim , taking a look

F
Felvine Sakwe02:50 PM
hi

Attachment
aistor-migration-guide.pdf
710.71 KB PDF

@Youngkyoo Kim , i created a PDF migration guide for you , using my tested and confirmed validations

Cluster
k3s v1.31.4 running , 3 nodes connected via socket_vmnet:

Storage
Each node has 4× 1 GB NVMe drives ( NVMe Ctrl, formatted XFS), totaling 12 drives across the cluster
All managed by DirectPV using the directpv-min-io StorageClass

DirectPV source: v4.1.4, installed via kubectl plugin
DirectPV target: v5.1.0, installed via Helm chart minio/directpv:0.4.1

MinIO / AIStor
MinIO Operator (source): v7.0.0
MinIO Tenant: wxminio : 3 servers × 4 volumes = 12 DirectPV PVCs
AIStor Operator: v5.4.0 : Helm chart minio/aistor-operator
AIStor Objectstore: v1.0.13 : Helm chart minio/aistor-objectstore

License
ENTERPRISE

Also i see you mentioned here : https://subnet.min.io/issues/16475 ( you have already performed the upgrade in the development environment )
Please use this pdf guide as an additional layer to your Migration

Raul-Mircea Crivineanu05:08 PM
cc @Daniel

March 30th, 2026Toggle date menu

R
RIA CHOI01:42 PM
Hi, I have an additional question.

In Step 4 (“Upgrade DirectPV”) of the PDF you provided, how can we ensure that the node server is deployed only on nodes labeled with directpv-enable=true?

Also, for the MinIO server deployment, since Pods are scheduled based on PVCs and the PVCs are not deleted during the upgrade, is it correct that we do not need to specify a separate node selector?

Currently, out of 79 worker nodes, MinIO servers are deployed on 18 nodes.

P
Praveen02:36 PM
In Step 4 (“Upgrade DirectPV”) of the PDF you provided, how can we ensure that the node server is deployed only on nodes labeled with directpv-enable=true?

You can customize the helm chart values and use node-selectors there to make node-server deployed only on node with the respective labels. Please check https://docs.min.io/enterprise/minio-directpv/installation/upstream/#custom-chart-values

Also, for the MinIO server deployment, since Pods are scheduled based on PVCs and the PVCs are not deleted during the upgrade, is it correct that we do not need to specify a separate node selector?

For minio pods? No, not required.. upgrade will not change any node selectors on the objectstore CRD

R
RIA CHOI02:55 PM
I understand, thank you.

Kranthi02:58 PM
👍

TodayToggle date menu

A
Ali Yaldaz01:42 AM
Hello @RIA CHOI ,
I saw that in your steps you're going to delete directpv plugin and install with helm.
Please don't delete directpv, it will delete CRD's as well so you may encounter mapping problems.
Please follow up this documentation: https://docs.min.io/enterprise/minio-directpv/installation/upgrade/#upgrade-directpv-csi-driver-from-41x-to-latest

Daniel05:47 AM
Hello @RIA CHOI and @Youngkyoo Kim

I've been running the migration from MinIO OSS Operator 7.0.0 to AIStor Operator RELEASE.2026-03-18T17-36-17Z

and I do have some pointers and differences with your instructions on some problems I faced

Please bear with me, these are going to be long:

Step 1: Pre-Check
Instructions: mc admin info, kubectl get pod, kubectl directpv list volumes/drives
Actual: Identical. No differences.

Step 2: Backup
Instructions: Backup tenant YAML, secrets, DirectPV volumes/drives, helm values.
Actual: Identical. No differences.
Recommendation: Also back up the {tenant}-env-configuration secret explicitly, just in case

Step 3: Upgrade helm, mc, kubectl-directpv
No changes

Step 4: Upgrade DirectPV
Instructions:

1) kubectl directpv uninstall
2) helm install directpv aistor-upgrade/directpv -n directpv
3-5) Verify
Actual — Key Differences:

CRD ownership conflict. The old kubectl-directpv install creates CRDs with field manager kubectl-directpv-oss. When Helm tries to install, its server-side apply conflicts with these field managers. The instructions do not mention this.
Required workaround:

Label and annotate all DirectPV CRDs for Helm ownership before helm install
Force-apply CRDs with --server-side --field-manager=helm --force-conflicts
Use --skip-crds or pre-apply CRDs from helm template output
Namespace deletion timing. kubectl directpv uninstall deletes the directpv namespace. You must wait for the namespace to fully terminate before running helm install, otherwise Helm fails with "namespace is being terminated".
Recommendation: Backup DirectPVDrives and DirectPVVolumes

kubectl get directpvdrives.directpv.min.io -o yaml > directpvdrives.yaml
kubectl get directpvvolumes.directpv.min.io -o yaml > directpvvolumes.yaml
Required addition: Wait loop for namespace termination between uninstall and install.

Step 5: Upgrade AIStor Operator
No changes

Step 6: Upgrade ObjectStore
Instructions:

1) kubectl create role/rolebinding for migration pod
2) kubectl run aistor-migration ... > objectstore-values.yaml
3) vi objectstore-values.yaml (set image, secrets)
4) helm uninstall old tenant
5) kubectl get tenant (verify gone)
6) kubectl get pvc (verify PVCs persist)
7) helm install aistor-objectstore with generated values
8-9) Verify pods and objectstore
Actual — Key Differences:

volumeSize vs size. The migration tool generates volumeSize: 512Mi but the aistor-objectstore Helm chart expects size: 512Mi. If not corrected, the chart defaults to 10Gi, which does not match existing PVCs, not sure if this was because I was on macOS.
Required fix: sed -i 's/volumeSize:/size:/' objectstore-values.yaml after running the migration tool. Need to confirm with @Ramon Klein

Secret deletion on helm uninstall. helm uninstall of the old tenant deletes the {tenant}-env-configuration secret. The migration tool generates existingSecret: true, which tells the AIStor chart to use an existing secret. But the secret no longer exists.
Required fix: Back up the secret before helm uninstall and recreate it after. Or change existingSecret: false and provide accessKey/secretKey in the values file (but this creates a new secret with a different format).

This is a gap in the instructions -- Step 6.4 says to set secrets.existingSecret: false but the migration tool sets it to true for a reason (to reuse the existing config). The secret must be preserved or recreated.

Operator backoff after secret error. If the AIStor operator encounters the missing secret error, it enters exponential backoff and may take 5+ minutes to retry. Restarting the operator deployment (kubectl rollout restart) forces immediate reconciliation.
Required addition: After recreating the secret, restart the operator if pods don't appear within ~30 seconds.

Image tag. The instructions set a specific AIStor MinIO image. The AIStor operator also provides a default image in its NOTES output. When image: is commented out in the generated values (as the migration tool does), the operator uses its built-in default, which is typically the latest version bundled with that operator release. This worked correctly without manual image override.
Step 7: Delete MinIO Operator
No changes

I ran the exercise a couple of times, and used helm with version v4.1.3

We are checking on the kubectl directpv uninstall part, apparently is not needed, so you can also skip that command, I would strongly recommend this

But I'm gonna test if it can be skipped as going from DirectPV via krew to DirectPV helm gave me some trouble