Deploy a MinIO Tenant¶
Table of Contents
This procedure documents deploying a MinIO object storage tenant using the MinIO integration for the VMware Data Persistence platform (DPp) in VCF 4.2.
MinIO takes full advantage of the vSAN Direct and vSAN SNA storage policies available with VMware DPp. This procedure assumes that the VCF deployment has one or more ESXi hosts with direct-attached storage, where a storage policy exists for either vSAN Direct or vSAN SNA.
Prerequisites¶
MinIO Plugin for vCenter¶
You must enable the MinIO plugin in vCenter prior to beginning this procedure. To enable the plugin, log into vCenter and select the cluster in which you want to deploy MinIO tenants.
Click Configure, then navigate to Supervisor Services and select Services. Locate the MinIO row and activate the radio button. Click Enable to enable the service.
ESXi Hosts with Local Storage¶
Each ESXi host must have sufficient compute, memory, and direct-attached local storage devices (SSD or HDD) to support each pod provisioned as part of the tenant. MinIO requires one available ESXi host for each MinIO server pod deployed as part of the tenant.
MinIO showcases best performance with locally-attached storage. MinIO therefore strongly recommends vSAN Direct storage policies when provisioning MinIO tenant. See Set Up vSAN Direct for vCenter with Tanzu for more complete instructions.
Namespace per MinIO Tenant¶
MinIO limits one MinIO tenant per namespace. Create a new namespace prior to beginning the procedure.
You can view and create namespaces in the vCenter interface by clicking the Namespaces tab for the cluster. Click New Namespace to create a new namespace for the MinIO tenant. After creating the namespace, return to the Namespaces tab and click on the namespace you created.
Click Edit Storage on the Storage card to attach the necessary vSAN Direct or vSAN SNA storage policies to the namespace. The MinIO tenant can only use storage policies attached to the namespace in which its deployed.
Click Add Permissions on the Permissions card to configure the necessary permissions for vCenter users. Specifically, only users with the Can Edit permission on the namespace can create MinIO tenants in the namespace.
Important
VCF allows setting namespace-level limitations on CPU, memory, and storage. MinIO tenants are subject to these limitations. For CPU limits specifically, VCF allows setting a frequency limitation. The MinIO tenant respects this limitation for every allocated vCPU. If the namespace CPU frequency limitation is too low, you may see performance throttling even if the tenant has a large number of allocated vCPU.
Procedure¶
1) Open the Tenant Creation Modal¶
From the vCenter interface, select the cluster in which you want to deploy the MinIO tenant.
Click the Configure tab, then open the MinIO section and select Tenants to open the MinIO Tenants view.
Click ADD to open the MinIO Tenant Creation modal.

2) Complete the Tenant Configuration Step¶

The Tenant Configuration step displays the following fields:
Name |
The name of the MinIO tenant |
---|---|
Namespace |
The namespace in which to deploy the tenant. The namespace must not contain any other MinIO tenants. |
Storage Class |
The VCF storage class for the MinIO tenant to use when provisioning volumes. MinIO strongly recommends using vSAN Direct storage policies for MinIO tenants. |
Advanced Mode |
Displays the following additional configuration modals:
|
Click Next to proceed to the next step.
3) Complete the Configure Step¶
Note
This section is only visible if you selected Advanced Mode in the Tenant Configuration section.

The Configure step displays the following fields:
Use custom image |
Enables using a custom Docker image for deploying pods on the MinIO Tenant. |
---|---|
MinIO’s Image |
The custom Docker image to use for deploying MinIO server pods Only visible if Use custom image is activated. |
Console’s Image |
The custom Docker image to use for deploying MinIO Console pods. Only visible if Use custom image is activated. |
Field |
Description |
---|---|
Set Custom Image Registry |
Enables using a private Docker repository for retrieving Docker images for deploying the MinIO tenant. |
Endpoint |
The URL endpoint for the private Docker repository. Only visible if Set Custom Image Registry is activated. |
Username |
The username for the specified Endpoint Only visible if Set Custom Image Registry is activated. |
Password |
The username for the specified Endpoint. Only visible if Set Custom Image Registry is activated. |
4) Complete the IDP Step¶
Note
This section is only visible if you selected Advanced Mode in the Tenant Configuration section.
MinIO has built-in identity management for managing identities on the tenant. MinIO also supports external IDentity Providers (IDP) for centralized access and permission management.
The :guilabel`IDP` section contains configuration settings for using an external IDentity Provider (IDP) for client authentication and authorization. Select the radio button that corresponds to the type of IDP you want the MinIO tenant to use. The default is None, or MinIO-managed identities.

OpenID |
Enables using an OpenID Provider for external management of client access to the MinIO Tenant. Mutually exclusive with Active Directory. |
---|---|
URL |
Specify the URL for the OpenID Provider. Ensure the configured network access rules grant the MinIO Tenant access to the specified URL endpoint. |
Client ID |
Specify the Client ID to use for connecting to the OpenID Provider. |
Secret ID |
Specify the Secret ID to use for connecting to the OpenID Provider. |

Active Directory |
Enables using Microsoft Active Directory or an LDAP service for external management of client access to the MinIO Tenant. Mutually exclusive with OpenID. |
---|---|
URL |
The endpoint for the Active Directory or LDAP service. Ensure the configured network access rules grant the MinIO tenant access to the specified URL endpoint. |
Skip TLS Verification |
Directs MinIO to skip verification of TLS certificates and connect to Active Directory or LDAP services presenting untrusted certificates (e.g. self-signed). |
Server Insecure |
Allows plain text connections to the Active Directory or LDAP server. |
User Search Filter |
Specify the LDAP query MinIO executes as part of client
authentication/authorization. For example: MinIO substitutes the username provided by the client into the
|
Group Search Base DN |
Specify the base Distinguished Name (DN) MinIO uses when querying for LDAP groups in which the authenticated user has membership. Specify multiple DNs as a semicolon-separated list. |
Group Search Filter |
Specify the LDAP query MinIO executes as part of client authentication/authorization. |
Group Name Attribute |
Specify the Common Name (CN) attribute MinIO uses when querying for LDAP groups in which the authenticated user has membership. |
5) Complete the Security Step¶
Note
This section is only visible if you selected Advanced Mode in the Tenant Configuration section.
The Security section contains configuration settings for automatic and custom TLS certificate generation for resources in the MinIO Tenant:

Enable TLS |
Enables TLS authentication for the MinIO Tenant. MinIO strongly recommends enabling TLS regardless of the deployment environment (e.g. development, staging, or production). |
---|---|
Autocert |
Enables automatic generation of self-signed certificates for use by resources in the MinIO Tenant. Clients may need to explicitly disable TLS certificate verification to connect to the MinIO Tenant, as self-signed certificates are typically not trusted by default. Only visible if Enable TLS is activated. |

Enable TLS |
Enables TLS authentication for the MinIO Tenant. MinIO strongly recommends enabling TLS regardless of the deployment environment (e.g. development, staging, or production). |
---|---|
Custom Certificate |
Enables specifying one or more pre-generated TLS x.509 certificates for use by resources in the MinIO Tenant. |
MinIO TLS Certs |
Specify a Key private key and Cert public
certificate. MinIO uses these certificates when configuring Pod TLS
and for enabling TLS with SNI support on each pod. Specifically,
MinIO copies all specified certificates to each MinIO server pod
and service in the cluster. When the pod/service responds to a TLS
connection request, it uses SNI to select the certificate with
matching You can specify additional certificates by clicking the Add One More button. |
Console TLS Certs |
Specify a Key private key and Cert public
certificate. MinIO uses these certificates when configuring Pod TLS
and for enabling TLS with SNI support on each pod. Specifically,
MinIO copies all specified certificates to each MinIO Console pod
and service in the cluster. When the pod/service responds to a TLS
connection request, it uses SNI to select the certificate with
matching |
6) Complete the Encryption Step¶
Note
This section is only visible if you selected Advanced Mode in the Tenant Configuration section.
The Encryption section contains configuration settings for Server-Side Encryption of Objects (SSE-S3) stored on the MinIO Tenant.

Enable Server Side Encryption |
Enables configuring SSE of objects on the MinIO Tenant. |
---|---|
Vault |
Enables SSE using Hashicorp Vault as the Key Management Service (KMS). |
Endpoint |
Specify the URL endpoint for the Vault service. Ensure the configured network access rules grant the MinIO Tenant access to the specified URL endpoint. |
Engine |
Specify the path of the Vault engine to use for storing keys generated for supporting SSE-S3. |
Namespace |
Specify the namespace on the Vault in which MinIO stores keys generated for supporting SSE-S3. |
Prefix |
Specify the string prefix to apply when MinIO stores keys generated for supporting SSE-S3. |
App Role |
Specify the credentials MinIO uses to perform AppRole authentication to the Vault server.
|
TLS |
Specify the TLS certificates to use when connecting to the Vault server.
|
Status |
Specify how often MinIO should check the status of the Vault server. Set Ping to the amount of time to wait between status checks. |

Enable Server Side Encryption |
Enables configuring Server-Side Encryption of objects on the MinIO Tenant. |
---|---|
AWS |
Enables SSE using Amazon Web Service Key Management System (AWS KMS) as the Key Management Service (KMS). |
Endpoint |
Specify the URL endpoint for the AWS KMS service. Ensure the configured network access rules grant the MinIO Tenant access to the specified URL endpoint. |
Region |
Specify the AWS region of the AWS KMS service. |
KMS Key |
The AWS KMS Customer Master Key (CMK) to use for cryptographic key operations related to SSE. |
Credentials |
Specify the credential to use when making requests to the AWS KMS service.
|

Enable Server Side Encryption |
Enables configuring Server-Side Encryption of objects on the MinIO Tenant. |
---|---|
Gemalto |
Enable SSE using Gemalto KeyVault or Thales CipherTrust as the Key Management Service. |
Endpoint |
Specify the URL endpoint for the KeyVault or CipherTrust service. Ensure the configured network access rules grant the MinIO Tenant access to the specified URL endpoint. |
Credentials |
Specify the credentials to use when making requests to the KeyVault or CipherTrust service.
|
TLS |
Specify the Certificate Authority |
7) Complete the Tenant Size Step¶
The Tenant Size section contains configuration settings for nodes in the MinIO Tenant:

Number of Nodes |
Specify the number of nodes to create for the MinIO Tenant. |
---|---|
Storage Size |
Specify the total amount of storage in the cluster. MinIO automatically calculates the number of volumes per node based on the specified storage size and the Storage Class selected in the Tenant Configuration step. The requested storage must be less than or equal to the available storage in the specified Storage Class. |
Memory per Node |
Specify the amount of RAM to allocate to each node on the MinIO Tenant. MinIO recommends a minimum of 2Gi of RAM per node. Click the exclamation mark ! hint to view recommended memory allocations based on total available storage. |
Erasure Code Parity |
The Erasure Code parity setting to apply to the MinIO tenant.
Defaults to For more complete documentation on erasure code parity, see Erasure Coding. |
The Resource Allocation section displays the results of the specified configuration settings:

Volumes per Node |
The number of Persistent Volume Claims (PVC) that MinIO generates per node in the Tenant. MinIO calculates this value based on the requested Storage Size and the number of available disks in the Storage Class. |
---|---|
Disk Size |
The requested storage capacity for each PVC that MinIO generates for the Tenant. MinIO calculates this value based on the requested Storage Size and the number of available disks in the Storage Class. |
Total Number of Volumes |
The total number of PVC that MinIO generates for the Tenant. MinIO calculates this value based on the requested Storage Size and the number of available disks in the Storage Class. |
Erasure Code Parity |
The Erasure Code parity selected during the 7) Complete the Tenant Size Step step. |
Raw Capacity |
The total raw capacity of storage based on the requested Storage Size. |
Usable Capacity |
The total estimated usable storage capacity based on the Erasure Code Parity. The actual usable capacity depends on the erasure code parity used in practice during regular workloads. For example, lowering the erasure code parity settings after creating the Tenant would increase the total estimated usable storage on the cluster. |
8) Review the Preview Configuration Step¶
The Preview Configuration section contains the details for the MinIO Tenant. Review the summary before proceeding to the next step.

The Name, Namespace, and Storage Class settings are derived from the 2) Complete the Tenant Configuration Step section.
The Nodes, Total Number of Volumes, Volumes per Node, Disk Size, Erasure Code Parity, Raw Capacity, and Usable Capacity settings are derived from the 7) Complete the Tenant Size Step section.
9) Review the Credentials Step¶
The Credentials section contains the credentials required for connecting to the MinIO Tenant and MinIO Console.

The MinIO’s Access Key and MinIO’s Secret Key are the credentials for the root MinIO user.
The Console’s Access Key and Console’s Secret Key are the credentials for accessing the MinIO Console.
MinIO displays the Access Keys once. Click the Copy Credentials button to copy the keys to your system clipboard. Store the keys in a secure location, such as a password-protected key vault.
Important
The MinIO Access Key and Secret Key credentials are associated to the root user for the MinIO Tenant. Any client which accesses the MinIO Tenant with these credentials has superuser access to perform any operation on the Tenant.
Click Finish to close the Create Tenant modal and return to the Cluster view.
10) Monitor Tenant Creation¶
You can monitor the Tenant creation from the Tenants subsection of the MinIO section of the cluster Configure tab. Click the radio button to the left of the tenant, then select Details.

The Tenant view shows the current state of the tenant.

The Current State describes the stage of Tenant deployment. The cluster Tasks view provides a more granular view of MinIO as it creates the required resources for the Tenant.
When the Current State reads as Initialized, the Tenant is ready to access.
11) Connect to your Tenant¶

The MinIO Endpoint displays the IP address to use for connecting to the MinIO Tenant.
You can specify this endpoint along with the MinIO Access Key and Secret Key
to connect to the Tenant and begin performing operations on it. For example,
the following operation uses the mc
command line tool to configure
an alias for the new MinIO Tenant and retrieve its status:
mc alias --insecure set vmw-minio-tenant ENDPOINT ACCESSKEY SECRETKEY
mc admin --insecure info vmw-minio-tenant
The --insecure
option allows connecting to an endpoint using
self-signed certificates, and may be required for Tenants created using
Autocert TLS certificate generation.
You can also connect to the MinIO Console by clicking the Console Endpoint URL and entering in the Console access key and secret key.
12) Modify vCPU Allocations for Tenant¶
VCF 4.2 defaults MinIO pods to 1vCPU. You can modify the number of vCPU allocated to each MinIO pod after deploying the tenant by doing the following:
Download and install the VMware Commandline Tools
Use
kubectl vsphere login
to create a context for accessing the VCF cluster.The vCenter user specified to the command must have permission to access and perform operations on the namespace in which the tenant is deployed. See Connecting to vCenter with Tanzu Clusters for more specific instructions.
Run the following command to modify the vCPU allocation for the tenant:
kubectl -n <NAMESPACE> patch tenant <TENANT-NAME> --type='json' \ -p='[ { "op": "replace", "path": "/spec/zones/0/resources/limits/cpu", "value": <CPU-LIMIT> }, { "op": "replace", "path": "/spec/zones/0/resources/requests/cpu", "value": <CPU-LIMIT> } ]'
Replace
<NAMESPACE>
with the namespace in which the tenant is deployed.Replace
<TENANT-NAME>
with the name of the MinIO tenant.Replace
<CPU-LIMIT>
with the number of vCPU to allocate to each tenant pod.
For tenants with multiple zones, re-issue the command and increment the value of
/spec/zones/0
for each zone in the tenant (spec/zones/1
,spec/zones/2
, etc.).