NetApp Aggregate Encryption (NAE) in ONTAP

© 2021 NetApp

Previously in a post I explained how to set up an encrypted volume using an encryption key manager (KMS) specifically from the company HyTrust. In this specific case each volume is encrypted individually using independent keys. A disadvantage of this method is that it affects the possibility of increasing the efficiency levels of data reduction such as compression, compaction and de-duplication (cross-volume-dedupe).

To eliminate this disadvantage the NetApp gurus came up with the idea of applying the encryption feature at the aggregate level by allowing volumes residing within the same aggregate to share the encryption key. This technology is known as “NetApp Aggregate Encryption” (NAE). This allows customers the option to take advantage of storage efficiency technologies in conjunction with the encryption process.

Now it’s time to talk about how we can create an encrypted aggregate in Ontap but first of all… What is an aggregate within Ontap?

Using the NetApp Knowledge Base portal as a reference:

An aggregate is a collection of disks (or partitions) arranged into one or more RAID groups.  It is the most basic storage object within ONTAP and is required to allow for the provisioning of space for connected hosts.

NetApp Knowledge Base
© 2021

Step 1: Validate Ontap requirements.

In order to use the encryption option at the aggregate level, it is required to have a version of Ontap 9.6 or higher also make sure the required licenses are installed in the cluster. In this case we use the command <version> to validate the current version of the cluster and the command <license show -package VE> to display the license information.

OnPrem-HQ::> version
NetApp Release 9.9.1RC1: Fri Apr 30 06:35:11 UTC 2021
OnPrem-HQ::> license show -package VE -fields package,owner,description,type  
  (system license show)
serial-number                  package owner         description               type    
------------------------------ ------- ------------- ------------------------- ------- 
X-XX-XXXXXXXXXXXXXXXXXXXXXXXXX VE      OnPrem-HQ-01 Volume Encryption License license 
X-XX-XXXXXXXXXXXXXXXXXXXXXXXXX VE      OnPrem-HQ-02 Volume Encryption License license 
2 entries were displayed.


Note: I previously done the external KMS setup in Ontap. Link

Step 2: Validate the available “Spare” discs.

To begin with, there are two ways to encrypt an aggregate; initially when it is created or the live conversion of an existing one. Initially I will be creating a new aggregate and then in another tutorial I will show you how easy is to convert an existing one. To create an aggregate you need to have disk drives available or in the “spare” state as NetApp commonly calls it.

The <storage aggregate show-spare-disks> command allows us to see how many partitioned disks are available on the node where i will create the new encrypted aggregate. In this particular case you can see that there are 24 partitioned disks using the “Root-Data1-Data2” option. To learn more about this disk strategy please follow the link below:

ADP(v1) and ADPv2 in a nutshell, it’s delicious!

 © 2021 Chris Maki
OnPrem-HQ::> storage aggregate show-spare-disks -original-owner OnPrem-HQ-01 
Original Owner: OnPrem-HQ-01
  Root-Data1-Data2 Partitioned Spares
                                                              Local    Local
                                                               Data     Root Physical
 Disk             Type   Class          RPM Checksum         Usable   Usable     Size Status
 ---------------- ------ ----------- ------ -------------- -------- -------- -------- --------
 VMw-1.1          SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.2          SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.3          SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.4          SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.5          SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.6          SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.7          SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.8          SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.9          SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.10         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.11         SSD    solid-state      - block           11.63GB   3.35GB  26.67GB zeroed
 VMw-1.12         SSD    solid-state      - block           11.63GB   3.35GB  26.67GB zeroed
 VMw-1.13         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.14         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.15         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.16         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.17         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.18         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.19         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.20         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.21         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.22         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.23         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.24         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
24 entries were displayed.


Step 3: Create an encrypted aggregate.

To create the encrypted aggregate we use the <storage aggregate create> command with the option <encrypt-with-aggr-key true> turned on. In this case we create a secure aggregate composed of 23 disks “partitions”.

Note: For this example the RAID type “Dual Parity” was used.

OnPrem-HQ::> storage aggregate create -aggregate OnPrem_HQ_01_SSD_1 -diskcount 23 -node OnPrem-HQ-01 -raidtype raid_dp -encrypt-with-aggr-key true 

Info: The layout for aggregate "OnPrem_HQ_01_SSD_1" on node "OnPrem-HQ-01"
      would be:
      First Plex
        RAID Group rg0, 23 disks (block checksum, raid_dp)
                                                            Usable Physical
          Position   Disk                      Type           Size     Size
          ---------- ------------------------- ---------- -------- --------
          shared     VMw-1.1                   SSD               -        -
          shared     VMw-1.2                   SSD               -        -
          shared     VMw-1.3                   SSD         11.61GB  11.64GB
          shared     VMw-1.4                   SSD         11.61GB  11.64GB
          shared     VMw-1.5                   SSD         11.61GB  11.64GB
          shared     VMw-1.6                   SSD         11.61GB  11.64GB
          shared     VMw-1.7                   SSD         11.61GB  11.64GB
          shared     VMw-1.8                   SSD         11.61GB  11.64GB
          shared     VMw-1.9                   SSD         11.61GB  11.64GB
          shared     VMw-1.10                  SSD         11.61GB  11.64GB
          shared     VMw-1.18                  SSD         11.61GB  11.64GB
          shared     VMw-1.16                  SSD         11.61GB  11.64GB
          shared     VMw-1.13                  SSD         11.61GB  11.64GB
          shared     VMw-1.14                  SSD         11.61GB  11.64GB
          shared     VMw-1.15                  SSD         11.61GB  11.64GB
          shared     VMw-1.19                  SSD         11.61GB  11.64GB
          shared     VMw-1.20                  SSD         11.61GB  11.64GB
          shared     VMw-1.21                  SSD         11.61GB  11.64GB
          shared     VMw-1.17                  SSD         11.61GB  11.64GB
          shared     VMw-1.22                  SSD         11.61GB  11.64GB
          shared     VMw-1.11                  SSD         11.61GB  11.64GB
          shared     VMw-1.12                  SSD         11.61GB  11.64GB
          shared     VMw-1.23                  SSD         11.61GB  11.64GB
      Aggregate capacity available for volume use would be 219.5GB.
Do you want to continue? {y|n}: y
[Job 817] Job succeeded: DONE                                                  


Once created it is required to validate the aggregate, to do so you must use the command <storage aggregate show> by filtering the result with the <encrypt-with-aggr-key> option.

OnPrem-HQ::> storage aggregate show -fields aggregate,size,availsize,usedsize,state,node,raidstatus,encrypt-with-aggr-key 
aggregate           node          availsize raidstatus      size    state  usedsize encrypt-with-aggr-key 
------------------- ------------- --------- --------------- ------- ------ -------- --------------------- 
OnPrem_HQ_01_SSD_1 OnPrem-HQ-01 219.5GB   raid_dp, normal 219.5GB online 480KB    true                  
OnPrem_HQ_02_SSD_1 OnPrem-HQ-02 209.3GB   raid_dp, normal 219.5GB online 10.12GB  false                 
aggr0_OnPrem_HQ_01 OnPrem-HQ-01 1.11GB    raid_dp, normal 22.80GB online 21.69GB  false                 
aggr0_OnPrem_HQ_02 OnPrem-HQ-02 1.11GB    raid_dp, normal 22.80GB online 21.69GB  false                 
4 entries were displayed.


In the command result you can see that the aggregate was created with encryption capability enabled.

Step 4: Create a volume within the encrypted aggregate.

Unlike volume-level encryption NVE, when using aggregate-level encryption it is not required to specify the encrypt option to create the volume. The command <vol create> creates an encrypted volume by default when the volume resides in an aggregate configured with NAE.

OnPrem-HQ::> vol create -vserver SAN -volume Secure_Vol -aggregate OnPrem_HQ_01_SSD_1 -size 10GB -space-guarantee none 
[Job 818] Job succeeded: Successful                                            


By using the <vol show> command with the <encryption-state full> filter option you can see the volume was created encrypted by default.

OnPrem-HQ::> vol show -encryption-state full -aggregate OnPrem_HQ_01_SSD_1 -fields Vserver,Volume,encrypt,encryption-type,encryption-state 
vserver volume     encryption-type encrypt encryption-state 
------- ---------- --------------- ------- ---------------- 
SAN     Secure_Vol aggregate       true    full             



In this tutorial I showed you how to configure the aggregate level encryption technology within Ontap that allows us to use a unique security key to create encrypted volumes. This allows us to use data reduction technologies in conjunction with security mechanisms that enhance or strengthen the security posture of the organization.

NetApp Volume Encryption Setup with External Key Manager

Using NetApp documentation as a reference:

NetApp Volume Encryption (NVE) is a software-based technology for encrypting data at rest one volume at a time. An encryption key that can only be accessed by the storage system ensures that the data on the volume cannot be read if the underlying device is reused, returned, lost or stolen.

NetApp Documentation

In this tutorial I explain how easy it is to configure and manage this impressive security feature.

Before starting to configure this feature it is necessary to have an existing “Key Management Service”. For the purpose of this tutorial I will use the “HyTrust KeyControl” KMS which I previously explained in the blog. If you want to know more about it, read the following post.

Step 1: Create a client certificate for authentication purposes:

Go to [KMIP > Client Certificate] and select Create Certificate in the Actions menu.

Select a name for the certificate and press Create.

Once the certificate has been created, it should be stored in a safe place.

The downloaded file contains the Client and Root CA certificate needed to configure the KMS option in Ontap.

Step 2: Validation of the Ontap cluster

The important things to consider before you can configure this security feature are the cluster status and the necessary license to support the encryption feature.

The cluster show command displays the overall status of the Ontap cluster.

OnPrem-HQ::> cluster show 
Node                  Health  Eligibility
--------------------- ------- ------------
OnPrem-HQ-01         true    true
OnPrem-HQ-02         true    true
2 entries were displayed.

The system node show command displays the node health and the system model.

OnPrem-HQ::> system node show
Node      Health Eligibility Uptime        Model       Owner    Location  
--------- ------ ----------- ------------- ----------- -------- ---------------
OnPrem-HQ-01 true true           00:18:10 SIMBOX
OnPrem-HQ-02 true true           00:18:08 SIMBOX
2 entries were displayed.

With the system license show command you can validate the license installed on the cluster. Here you can see that the volume encryption license is installed on both nodes.

OnPrem-HQ::> system license show -package VE

Owner: OnPrem-HQ-01
Installed License: Legacy Key
Capacity: -
Package           Type     Description           Expiration
----------------- -------- --------------------- -------------------
VE                license  Volume Encryption License 

Owner: OnPrem-HQ-02
Installed License: Legacy Key
Capacity: -
Package           Type     Description           Expiration
----------------- -------- --------------------- -------------------
VE                license  Volume Encryption License 
2 entries were displayed.


Step 3: Configuration of the KMS certificate in Ontap:

As stated in the NetApp documentation:

The cluster and the KMIP server use KMIP SSL certificates to verify each other’s identity and establish an SSL connection. Before setting up the SSL connection to the KMIP server, you must install the KMIP client SSL certificates for the cluster and the public SSL certificate for the KMIP server’s root Certificate Authority (CA).

NetApp KMIP Documentation

To install the KMIP client certificate on the NetApp cluster, run the following commands:

Note: The contents of the certificates are extracted from the previously downloaded files. The ONTAPEncryption.pem and cacert.pem files contain the necessary information.

OnPrem-HQ::> security certificate install –vserver OnPrem-HQ -type client –subtype kmip-cert
Please enter Certificate: Press <Enter> when done
Certificate Content
Please enter Private Key: Press <Enter> when done
Certificate Private Key Content
You should keep a copy of the private key and the CA-signed digital certificate for future

The installed certificate's CA and serial number for reference:
CA: HyTrust KeyControl Certificate Authority
serial: C9A148B9

The certificate's generated name for reference: ONTAPEncryption
OnPrem-HQ::> security certificate install -vserver OnPrem-HQ -type server-ca -subtype kmip-cert 

Please enter Certificate: Press <Enter> when done
Certificate Content
You should keep a copy of the CA-signed digital certificate for future reference.

The installed certificate's CA and serial number for reference:
CA: HyTrust KeyControl Certificate Authority
serial: 60A148B6

The certificate's generated name for reference: HyTrustKeyControlCertificateAuthority

Step 4: Configure the NetApp Volume Encryption solution:

For this tutorial it is necessary to configure an external “KMS” key management server so that the storage system can securely store and retrieve authentication keys for the NetApp Volume Encryption (NVE) solution.

Note: NetApp recommends a minimum of two server for redundancy and disaster recovery.

The following command allows you to add the KMS server to the Ontap system using the IP address, port TCP/5696 and using the previously configured certificates.

OnPrem-HQ::> security key-manager external enable -vserver OnPrem-HQ -key-servers -client-cert ONTAPEncryption -server-ca-certs HyTrustKeyControlCertificateAuthority 

OnPrem-HQ::> security key-manager external show                                                                                                                                           

                  Vserver: OnPrem-HQ
       Client Certificate: ONTAPEncryption
   Server CA Certificates: HyTrustKeyControlCertificateAuthority
          Security Policy: -

Key Server

It is important to validate that the KMS service is “available” before proceeding to create encrypted volumes. The security key-manager external show-status command does allow you to validate the status of the service.

OnPrem-HQ::> security key-manager external show-status

Node  Vserver  Key Server                                   Status
----  -------  -------------------------------------------  ---------------
2 entries were displayed.


Step 5: Create an encrypted volume (NVE)

In this part of the tutorial we must validate that the configuration is correct by creating an encrypted volume inside Ontap. For this step I will use the vol create command using the encrypt true option.

OnPrem-HQ::> vol create TEST_Encryption -vserver SAN -size 10G -aggregate OnPrem_HQ_01_SSD_1 -encrypt true 
[Job 763] Job succeeded: Successful 

With the vol show command i can verify that the volume has been created with the encryption option.

OnPrem-HQ::> vol show -encryption -vserver SAN -encryption-state full 
Vserver   Volume       Aggregate    State      Encryption State
--------- ------------ ------------ ---------- ----------------
SAN       TEST_Encryption OnPrem_HQ_01_SSD_1 online full


Step 6: Validate the Encryption information on the KMS server.

In the last step we must enter the administration portal of the “HyTrust KeyControl” application to validate that the encryption keys are stored in the platform. To validate this information go to the menu [KMIP > Objects] where you can validate that the keys were created after the creation of the volume within Ontap.


In this tutorial I show you how to configure the KMS service within Ontap that allows us to create encrypted volumes. This simple solution allows us to increase or improve the security posture in our organization.

NetApp PowerShell Toolkit – Get Lun Mapping Information

Recently in a post on the NetApp forum a user asked for help to create a function in Powershell using the DataOntap libraries. Here I show you how we use these libraries to join multiple objects with information related to the LUNs assigned in NetApp.

A curious fact about this request is that natively Ontap libraries do not allow you to filter the required information and that it can be displayed in a single table. For this we create an object within PowerShell where we can build the format of the information and that this has a more logical sense.

NetApp libraries can be installed from the PowerShell Gallery:

[Code of the <get-luninfo> function.]

Import-Module dataontap

#Connect to Ontap Storage

Connect-NcController -Name <cluster> -Vserver <vserver>

#Get the list of LUNs

$luntable = Get-NcLun | Select-Object Path -ExpandProperty Path

#Declare Function

function get-luninfo {


     #Declare the required variable



 #Check if the lun is mapped to any Host (IGROUP)

 if (get-nclunmap $lunpath) {

     #get the lun information

     $lunid = Get-NcLunmap $lunpath | Select-Object LunId -ExpandProperty LunId

     $lunigroup = get-nclunmap $lunpath | Select-Object InitiatorGroup -ExpandProperty InitiatorGroup

     $vserver =  Get-NcLun $lunpath | Select-Object Vserver -ExpandProperty Vserver

     $lunigrouptype = Get-NcIgroup -Name $lunigroup | Select-Object InitiatorGroupType -ExpandProperty InitiatorGroupType

     $lunigrouptypeOS = Get-NcIgroup -Name $lunigroup | Select-Object InitiatorGroupOsType -ExpandProperty InitiatorGroupOsType

     $lunigroupAluaEna = Get-NcIgroup -Name $lunigroup | Select-Object InitiatorGroupAluaEnabled -ExpandProperty InitiatorGroupAluaEnabled

     $initiators = Get-NcIgroup -Name $lunigroup | Select-Object Initiators -Unique -ExpandProperty Initiators

     $initiatorstatus = @()

     #Loop to find the initiators online status

     foreach ($in in $initiators.Initiators.InitiatorName) {

         $status = Confirm-NcLunInitiatorLoggedIn -VserverContext $vserver -Initiator $in | Select-Object Value -ExpandProperty Value

         $initiatorstatus += @(@{Initiator="$in";Online="$status"})


     foreach ($object in $initiatorstatus) {

         $initiatoronline += $object.ForEach({[PSCustomObject]$_})


     #Create a Object to better display and Glue the Information

     $obj = New-Object -TypeName PSObject

     $obj | add-member -MemberType NoteProperty -Name "vServer" -Value $vserver

     $obj | add-member -MemberType NoteProperty -Name "Lun ID" -Value $lunid

     $obj | add-member -MemberType NoteProperty -Name "IGROUP Name" -Value $lunigroup

     $obj | add-member -MemberType NoteProperty -Name "IGROUP TYPE" -Value $lunigrouptype

     $obj | add-member -MemberType NoteProperty -Name "IGROUP TYPE OS" -Value $lunigrouptypeOS

     $obj | add-member -MemberType NoteProperty -Name "IGROUP ALUA ENABLE" -Value $lunigroupAluaEna

     $obj | add-member -MemberType NoteProperty -Name "Lun Path" -Value $lunpath

     #$obj | add-member -MemberType NoteProperty -Name "Initiator Info" -Value $initiatoronline


     #Return the Formated Information

     Write-Output $obj | FT

     Write-Output $initiatoronline


 # If the LUN isnt mapped to any HOST, display the available information.

 else {

     $vserver =  Get-NcLun $lunpath | Select-Object Vserver -ExpandProperty Vserver

     $obj = New-Object -TypeName PSObject

     $obj | add-member -MemberType NoteProperty -Name "vServer" -Value $vserver

     $obj | add-member -MemberType NoteProperty -Name "Lun Path" -Value $lunpath

     $obj | add-member -MemberType NoteProperty -Name "Lun Mapping" -Value "Lun Not Mapped"

     Write-Output $obj | FT -Wrap -AutoSize



#Calling the Function

foreach ($lun in $luntable) {



Example of the retrieved information

Installing Minio on Centos Linux 8

The Problem

In the last few months I have been studying for the “VEEAM VMCE Arquitect” certification and one of the requirements is to implement the “Scale Out Backup Repository” option. A simple way to achieve this is by using the Minio service.

About Minio

Minio is an open source object storage service compatible with the Amazon S3 cloud storage service. Applications that have been configured to communicate with Amazon S3 can also be configured to communicate with Minio, allowing Minio to be a viable alternative to S3.


[Adding the minio user]

[root@VEEAM-MINIO ~]# useradd -r minio-user -s /sbin/nologin

[Creating the configuration file]

[root@VEEAM-MINIO ~]# cat <<EOT >> /etc/default/minio

# Volume to be used for MinIO server.


# Use if you want to run MinIO on a custom port.

MINIO_OPTS="-C /etc/minio --address <your_server_ip>:9000"

# User for the server.

MINIO_ACCESS_KEY="<change me>"

# Password for the server

MINIO_SECRET_KEY="<change me>"

# Root user for the server. 

MINIO_ROOT_USER="<change me>"

# Root secret for the server. 



[Downloading the application]

[root@VEEAM-MINIO ~]# wget

[root@VEEAM-MINIO ~]# chmod +x minio #assigning privileges to run

[root@VEEAM-MINIO ~]# mv minio /usr/local/bin #moving executable to directory

[root@VEEAM-MINIO ~]# chown minio-user:minio-user /usr/local/bin/minio #changing user permissions

[Creating directories and assigning permissions]

[root@VEEAM-MINIO ~]# mkdir /usr/local/share/minio

[root@VEEAM-MINIO ~]# chmod 755 /usr/local/share/minio

[root@VEEAM-MINIO ~]# chown minio-user:minio-user /usr/local/share/minio

[root@VEEAM-MINIO ~]# mkdir /etc/minio

[root@VEEAM-MINIO ~]# chown minio-user:minio-user /etc/minio

[Downloading and activating Minio service]

[root@VEEAM-MINIO ~]# wget -O /etc/systemd/system/minio.service

[root@VEEAM-MINIO ~]# systemctl daemon-reload

[root@VEEAM-MINIO ~]# systemctl enable minio

[Initializing and verifying the service]

[root@VEEAM-MINIO ~]# systemctl start minio

[root@VEEAM-MINIO ~]# systemctl status minio

[Allowing traffic through the local firewall]

[root@VEEAM-MINIO ~]# firewall-cmd --zone=public --add-port=9000/tcp --permanent

[root@VEEAM-MINIO ~]# firewall-cmd --reload

HomeLab – How to enable VMware TPS for greater virtual machine consolidation

In this blog, I will be talking about how you can optimize RAM utilization in your “HomeLab”. The main objective of this tutorial is that you can achieve higher levels of consolidation while running your labs.

“Transparent Page Sharing” (TPS) is a method by which duplicate copies of memory pages are consolidated. In other words, the concept of TPS is somewhat similar to deduplication. This helps the ESXi server to free up repeated memory blocks of a virtual machine allowing for increased levels of consolidation.

Memory Deduplication

If you want to know a little more about TPS, its benefits and risks, you can access the following link “Transparent Page Sharing (TPS) in hardware MMU systems”. Although it is known that the use of TPS can be a security risk, it is my understanding that it may not pose a significant risk in a test environment such as ours. I provide a reference for this information:

In a nutshell, independent research indicates that TPS can be abused to gain unauthorized access to data under certain highly controlled conditions. In line with its “secure by default” security posture, VMware has opted to change the default behavior of TPS and provide customers with a configurable option for selectively and more securely enabling TPS in their environment. 

Disabling TPS in vSphere – Impact on Critical Applications

Note: I show you how to change this value using Powershell because it allows you to make the change to multiple servers at the same time.

To begin we must verify what value is currently configured on the ESXi servers. To accomplish this task i use the <Get-VMHost> command to extract the information of the servers connected to the vCenter. The result is then sent to the <Get-AdvancedSetting -Name Mem.ShareForceSalting> command which allows us to extract the value configured in the “Mem.ShareForceSalting” variable.

PS /home/blabla> Get-VMHost | Get-AdvancedSetting -Name Mem.ShareForceSalting | Select-Object Entity,Name,Value,Type | Format-Table -Wrap -AutoSize

Entity                          Name                  Value   Type
------                          ----                  -----   ----
esxsvr-00f.zenprsolutions.local Mem.ShareForceSalting     2 VMHost
comp-02a.zenprsolutions.local   Mem.ShareForceSalting     2 VMHost
comp-01a.zenprsolutions.local   Mem.ShareForceSalting     2 VMHost

PS /home/blabla> 

In this particular example the ESXi servers are configured with a default value of #2. Using the VMware documentation as a reference this value indicates that the “Inter-VM” TPS feature is disabled.

To activate the TPS “Inter-VM” function you can use the command <Set-AdvancedSetting> with the value of #0. It is worth to mention that this command can be activated with the VMs powered on or without the server being in maintenance.

PS /home/blabla> Get-VMHost -Name esxsvr-00f.zenprsolutions.local | Get-AdvancedSetting -Name Mem.ShareForceSalting | Set-AdvancedSetting -Value 0        

Perform operation?
Modifying advanced setting 'Mem.ShareForceSalting'.
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): Y

Name                 Value                Type                 Description
----                 -----                ----                 -----------
Mem.ShareForceSalting 0                    VMHost               

PS /home/blabla> 

Once again you can validate with the <Get-AdvancedSetting> command if the configured value is the one i specified previously.

PS /home/blabla> Get-VMHost | Get-AdvancedSetting -Name Mem.ShareForceSalting | Select-Object Entity,Name,Value,Type | Format-Table -Wrap -AutoSize

Entity                          Name                  Value   Type
------                          ----                  -----   ----
esxsvr-00f.zenprsolutions.local Mem.ShareForceSalting     0 VMHost
comp-02a.zenprsolutions.local   Mem.ShareForceSalting     2 VMHost
comp-01a.zenprsolutions.local   Mem.ShareForceSalting     2 VMHost

PS /home/blabla> 

For this test i turned on 23 virtual machines (Windows) to bring the server in contention mode so that i can see what benefits the TPS has. This result I show you below represents the memory statistics of the ESXi server obtained with the command <esxtop>. Here you can see the statistics before i configured the “TPS Inter-VM” function with the value #2. The variable that is in bold “PSHARE/MB” represents the value of shared memory that the server currently has, i.e. only TPS is being used in “Intra-VM” mode. This variable has a value of 1400/MB.

2:58:11pm up 50 min, 722 worlds, 23 VMs, 45 vCPUs; MEM overcommit avg: 1.10, 1.10, 0.99
PMEM  /MB: 65398   total: 2139     vmk,60782 other, 2358 free
VMKMEM/MB: 65073 managed:  1265 minfree,  7501 rsvd,  57572 ursvd,  high state
PSHARE/MB:    1648  shared,     248  common:    1400 saving

Now i move on to validate the benefit of having the “TPS Inter-VM” feature enabled. As you can see in the following result of the <esxtop> command there was a substantial saving (32097/MB) of memory. This allowed us to increase the consolidation ratios of our “HomeLab”.

3:36:46pm up  1:29, 1024 worlds, 23 VMs, 45 vCPUs; MEM overcommit avg: 1.05, 1.05, 0.95
PMEM  /MB: 65398   total: 2262     vmk,60078 other, 3057 free
VMKMEM/MB: 65073 managed:  1265 minfree,  9092 rsvd,  55980 ursvd, clear state
PSHARE/MB:   33038  shared,     941  common:   32097 saving

Hasta Luego Amigos!

HomeLab – vSphere 7 update 2 QuickBoot with Nested ESXi

In this bog, I will be validating if the “ESXi QuickBoot” feature works in Nested mode i.e. running ESXi in a VM. First of all you must know exactly how QuickBoot works and all the requirements it has. To do this I will use the VMWare portal documentation as a reference:

Quick Boot is a vSphere feature that speeds up the upgrade process of an ESXi server.  A regular reboot involves a full power cycle that requires firmware and device initialization.  Quick Boot optimizes the reboot path to avoid this, saving considerable time from the upgrade process.

Understanding ESXi Quick Boot Compatibility
© 2021 VMware


  • The manufacturer’s platform must be compatible
  • All device drivers must be supported

Limitations in vSphere 7.0

  • TPM is disabled

Limitations in vSphere 6.7:

  • TPM is disabled
  • There are no VMs with passthrough devices configured.
  • No vmklinux drivers loaded on ESXi.

The VMware documentation includes a list of server manufacturers that support this technology for reference see the link in the VMware documentation “knowledge Base”.

For ESXi 7.0 or newer versions, you can check the “hardware” compatibility here:

In this lab I will test QuickBoot using Nested Virtualization. It is important to clarify that this is a test/dev scenario. To use this technology in production environments it is needed to activate the QuickBoot option from “VMware Update Manger” or the renamed “Lifecycle Manager”. If you are interested I leave a video here “Updates Installation with vSphere ESXi QuickBoot”.

[root@comp-01a:~] esxcli hardware platform get
Platform Information
   UUID: 0x27 0xa8 0x30 0x42 0xa3 0xf9 0x54 0xcf 0xe2 0xa3 0x10 0x1d 0xfd 0xb8 0x21 0xd0
   Product Name: VMware7,1
   Vendor Name: VMware, Inc.
   Serial Number: VMware-42 30 a8 27 f9 a3 cf 54-e2 a3 10 1d fd b8 21 d0
   Enclosure Serial Number: None
   BIOS Asset Tag: No Asset Tag
   IPMI Supported: false

The first step to activate QuickBoot is to validate the server compatibility. For this it is mandatory to connect via SSH to the ESXi server to execute the command <>. In this case the command confirmed that my platform is compatible.

[root@comp-01a:~] /usr/lib/vmware/loadesx/bin/
This system is compatible with Quick Boot.

Once the server is validated as compatible, we can activate the QuickBoot function with the command <loadESXEnable -e>.

[root@comp-01a:~] /bin/loadESXEnable -e
INFO: LoadESX Enabled
INFO: Precheck options:
INFO:   All prechecks are enabled.

The final step to activate the QuickBoot function would be to load the “QuickLaunch” configuration by using the command <>.

[root@comp-01a:~] /usr/lib/vmware/loadesx/bin/
DEBUG: LoadESX scripts are up to date.
INFO: Enabling QuickLaunch kernel preload
DEBUG: Using a ramdisk at /tmp/loadESX for intermediate storage
INFO: Target version: 7.0.2-0.0.17867351
DEBUG: Install boot module "vmware_e.v00" with size 0x2ec40
DEBUG: Install boot module "vmware_f.v00" with size 0x1e3582f
DEBUG: Install boot module "vsan.v00" with size 0x25f08a8
DEBUG: Install boot module "vsanheal.v00" with size 0x80ebe0
DEBUG: Install boot module "vsanmgmt.v00" with size 0x18957cc
DEBUG: Install boot module "xorg.v00" with size 0x358c40
DEBUG: Install boot module "gc.v00" with size 0xe077
DEBUG: Install boot module "imgdb.tgz" with size 0x192800
DEBUG: Install boot module "state.tgz" with size 0x21a00
INFO: loadESX is ready ...
INFO: Performing QuickLaunch kernel preload...

I am including two videos so you can see the speed of the QuickBoot technology when the server is rebooted.

VMware vSphere Normal Boot

VMware vSphere QuickBoot

Hytrust KeyControl – Key Management Server Setup

HyTrust KeyControl enables encryption users to easily manage their encryption keys at scale. HyTrust is the only KMS vendor that VMware invested in. It is available as an OVA, for fast installation and configuration in VMware vCenter. In this post i show you how to easily install and configure this KMS service in a vSphere enviroment.

Step 1 – Deploying the OVA Package

Browse to the location where the OVA file located.

Type the name for the new VM.

Select where to run the new VM.

Review the hardware requirement.

Accept the license agreement

Select the VM configuration. In my case because is a lab setup the demo configuration is selected.

Note: Not recommended for production environment.

Select the Storage and Network where the new VM will be running.

Specify the VM Netwok parameters.

Step 2 – Configuring the newly deployed KMS appliance.

Power on the newly deployed VM server. It will ask you to specify a password for the htadmin account. Enter a new password for htadmin and press OK.

Wait for the configuration process to complete

Go to the KMS management console by acceding https://<kms-ip-address> then provide the default credentials.

Complete the configuration wizard by selecting the instance type and specify a new password.

Optional – Configure Email notification.

Download and save the Admin Key to a secure location.

Note: This key is primarily used for recovery purpose

Step 3 – Enable the KMIP Service

The Key Management Interoperability Protocol (KMIP) enables communication between key management systems and cryptographically-enabled applications, including email, databases, and storage devices. Select KMIP in the top banner bar. Go to State and put it on Enabled. Then open Protocol and select Version 1.1 from the drop-down list. As a final step go to Restrict TLS and select Enabled to make sure traffic is on the TLS 1.2 protocol. Click the Apply button now to apply the new settings.


We have now added and configure the KMS server which gives us some extra security possibilities for our infrastructure or cryptographically-enabled applications.

VMware vSphere Native Key Provider

This is one of my favorite feature in vSphere 7 Update 2. VMware now provides the capability to use a new native key provider for encryption. Allowing us to use vSAN encryption, VM encryption and vTPM natively without the requirement to deploy a external Key provider. In the past this capability can only be provided by using a 3rd party solutions like Hytrust KeyControl. In this post i will explain how ease is to configure and deploy this awesome new feature.

Go to [Configure > Key Providers] to add the local key provider.

Select [ADD > Add Native Key Provider].

Provide a Name and press [ADD KEY PROVIDER].

Backup the Master keys.

Save the Native key Provider in a secure location. Optionally protect the key file with a strong password.

Verify the ESXi Server Host Encryption Mode is [Enable].

Test the configuration by encrypting an existing VM.

Change the default “VM Storage Policy” to [VM Encryption Policy].

Now the VM is encrypted with the Native Key Provider. Really Awesome Feature.