Jonathan Colon Feliciano

Using Flexcache volumes to accelerate Windows shares data access

Starting In Ontap 9.8 release NetApp decided to add support for the Windows SMB protocol to the FlexCache technology. At last…..

In this blog, I will create a source volume as origin and a flexcache volume on a remote cluster. In the lab example I will also validate the benefit offered by the ability to extend a central CIFS share natively.

I used the NetApp documentation as a reference to define what a Flexcache volume is and what it is used for.

A FlexCache volume is a sparsely populated volume that is backed by an origin volume. The FlexCache volume can be on the same cluster as or on a different cluster than that of the origin volume. The FlexCache volume provides access to data in the origin volume without requiring that all of the data be in the FlexCache volume. Starting in ONTAP 9.8, a FlexCache volume also supports SMB protocol.

NetApp Documentation Portal

To begin with, I used as a reference the following diagram showing an Active Directory domain with two sites named Gurabo and Ponce. Both sites have an Ontap cluster with version 9.8P4. Flexcache requires the creation of “Intercluster” type interfaces..

Note: The Ontap simulator was used for the lab.

The configuration I performed on the NAS-EDGE remote <vserver> was documented in case you are interested in seeing how to create a SVM from scratch. To access it just click on the “+” icon.

Prerequisites – vserver and network setup

Step I: Add the SVM NAS-EDGE to the remote cluster.

OnPrem-EDGE::> vserver create -vserver NAS-EDGE -rootvolume NAS_EDGE_root -aggregate OnPrem_DR_01_VM_DISK_1 
[Job 577] Job succeeded: Success                                               
Vserver creation completed.

OnPrem-DR::> 

Reference: vserver create

Step II: Add the logical network interfaces (LIF).

OnPrem-EDGE::> network interface create -vserver NAS-EDGE -lif NAS_EDGE_01 -address 10.10.33.20 -netmask-length 24 -home-node OnPrem-DR-01 -home-port e0c -service-policy default-data-files    

OnPrem-EDGE::> network interface create -vserver NAS-EDGE -lif NAS_EDGE_02 -address 10.10.33.21 -netmask-length 24 -home-node OnPrem-DR-02 -home-port e0c -service-policy default-data-files

OnPrem-EDGE::> network interface show -curr-port e0c -vserver NAS-EDGE 
            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
NAS-EDGE
            NAS_EDGE_01  up/up    10.10.33.20/24     OnPrem-EDGE-01 e0c     true
            NAS_EDGE_02  up/up    10.10.33.21/24     OnPrem-EDGE-02 e0c     true
2 entries were displayed.

OnPrem-EDGE::> 

Reference: network interface create

Step III: Network route creation.

OnPrem-EDGE::> network route create -vserver NAS-EDGE -destination 0.0.0.0/0 -gateway 10.10.33.254

OnPrem-EDGE::> network route show -vserver NAS-EDGE
Vserver             Destination     Gateway         Metric
------------------- --------------- --------------- ------
NAS-EDGE
                    0.0.0.0/0       10.10.33.254    20

OnPrem-EDGE::> 

Reference: network route create

Step IV: Add the DNS parameters to the SVM.

OnPrem-EDGE::> vserver services dns create -domains zenprsolutions.local -name-servers 192.168.5.1 -vserver NAS-EDGE 

Warning: Only one DNS server is configured. Configure more than one DNS server
         to avoid a single-point-of-failure.

OnPrem-EDGE::> vserver services dns show -vserver NAS-EDGE 

                        Vserver: NAS-EDGE
                        Domains: zenprsolutions.local
                   Name Servers: 192.168.5.1
                 Timeout (secs): 2
               Maximum Attempts: 1

OnPrem-EDGE::> 

Reference: vserver services dns create

Step V: Configure CIFS protocol and add the vserver to the local domain.

OnPrem-EDGE::> vserver cifs create -vserver NAS-EDGE -domain zenprsolutions.local -cifs-server NAS-EDGE              

In order to create an Active Directory machine account for the CIFS server, you
must supply the name and password of a Windows account with sufficient
privileges to add computers to the "CN=Computers" container within the
"ZENPRSOLUTIONS.LOCAL" domain. 

Enter the user name: administrator

Enter the password: xxxxxxxxxxxx

Notice: SMB1 protocol version is obsolete and considered insecure. Therefore it
is deprecated and disabled on this CIFS server. Support for SMB1 might be
removed in a future release. If required, use the (privilege: advanced)
"vserver cifs options modify -vserver NAS-EDGE -smb1-enabled true" to enable
it.

OnPrem-EDGE::> vserver cifs show                                                                
            Server          Status    Domain/Workgroup Authentication
Vserver     Name            Admin     Name             Style
----------- --------------- --------- ---------------- --------------
NAS-EDGE    NAS-EDGE        up        ZENPRSOLUTIONS          domain
2 entries were displayed.

OnPrem-EDGE::>

Reference: vserver cifs create

Step VI: Validate the SVM computer object creation in Active Directory (Powershell).

PS C:\Users\Administrator> Get-ADComputer -Identity NAS-EDGE

DistinguishedName : CN=NAS-EDGE,CN=Computers,DC=zenprsolutions,DC=local
DNSHostName       : NAS-EDGE.zenprsolutions.local
Enabled           : True
Name              : NAS-EDGE
ObjectClass       : computer
ObjectGUID        : 3cfec085-1417-4bac-bff7-d734e4e30049
SamAccountName    : NAS-EDGE$
SID               : S-1-5-21-2867495315-1194516362-180967319-2665
UserPrincipalName : 

PS C:\Users\Administrator> 

Step VII: Validate connectivity and name resolution (Powershell).

PS C:\Users\Administrator> ping NAS-EDGE.zenprsolutions.local
Ping request could not find host NAS-EDGE.zenprsolutions.local. Please check the name and try again.

PS C:\Users\Administrator> Add-DnsServerResourceRecordA -Name NAS-EDGE -IPv4Address 10.10.33.20 -CreatePtr -ZoneName zenprsolutions.local

PS C:\Users\Administrator> Add-DnsServerResourceRecordA -Name NAS-EDGE -IPv4Address 10.10.33.21 -CreatePtr -ZoneName zenprsolutions.local

PS C:\Users\Administrator> 
PS C:\Users\Administrator> nslookup NAS-EDGE.zenprsolutions.local
	primary name server = 192.168.5.1
	responsible mail addr = (root)
	serial  = 0
	refresh = 28800 (8 hours)
	retry   = 7200 (2 hours)
	expire  = 604800 (7 days)
	default TTL = 86400 (1 day)
Server:  SERVER-DC-01V.zenprsolutions.local
Address:  192.168.5.1

Name:    NAS-EDGE.zenprsolutions.local
Addresses: 10.10.33.20
	   10.10.33.21


PS C:\Users\Administrator> 

In order to start with the lab it is necessary to create an peer relationship between the local and remote vserver. To achieve this i use the command <vserver peer create> specifying the “applications” as “flexcache”.

Reference: vserver peer create.

Note: Previously, a cluster level peer relationship was performed with the <cluster peer create> command.

OnPrem-HQ::> vserver peer create -vserver NAS -peer-cluster OnPrem-EDGE -peer-vserver NAS-EDGE -applications flexcache 

Info: [Job 883] 'vserver peer create' job queued 

Once the peer relationship has been created between both vservers, you can continue to validate that the source volume was created as required. To validate the volume, the <volume show> command is used from the local cluster shell. In this lab I am going to use the volume named share.

OnPrem-HQ::*> volume show -vserver NAS                
Vserver   Volume       Aggregate    State      Type       Size  Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
NAS       NAS_root     OnPrem_HQ_01_SSD_1 online RW      20MB    17.66MB    7%
NAS       share        OnPrem_HQ_01_SSD_1 online RW      10.3GB   8.04GB   20%
19 entries were displayed.

OnPrem-HQ::*> 

Once the volume is identified, you can create the flexcache volume using the command <volume flexcache create>. It is important to mention that flexcache technology uses “FlexGroup” as a dependency when creating a volume. It is for this reason that the aggr-list option is used to specify which aggregates will be used to create the “FlexGroup” type volumes.

OnPrem-EDGE::> volume flexcache create -vserver NAS-EDGE -volume share_edge -aggr-list OnPrem_EDGE_0* -origin-vserver NAS -origin-volume share -size 10GB -junction-path /share_edge
[Job 595] Job succeeded: Successful.                                           

OnPrem-EDGE::>

From the remote cluster shell you can verify the created volume by using the <vol flexcache show> command.

OnPrem-EDGE::> vol flexcache show
Vserver Volume      Size       Origin-Vserver Origin-Volume Origin-Cluster
------- ----------- ---------- -------------- ------------- --------------
NAS-EDGE share_edge 10GB       NAS            shares            OnPrem-HQ

OnPrem-EDGE::> 

From the local cluster shell you can see the source volume with the command <volume flexcache origin show-caches>. The flexcache volume previously created can be validated in the command result.

OnPrem-HQ::*> volume flexcache origin show-caches
Origin-Vserver Origin-Volume  Cache-Vserver  Cache-Volume  Cache-Cluster
-------------- -------------- -------------- ------------- --------------
NAS            share         NAS-EDGE       share_edge    OnPrem-EDGE
1 entries were displayed.

OnPrem-HQ::*> 

Now i proceed to share the share_edge cache volume using the SMB protocol. The command <vserver cifs share create> is used with the option of <-path /share_edge> to specify the “junction-path” of the flexclone volume.

OnPrem-EDGE::> vserver cifs share create -vserver NAS-EDGE -share-name share_edge -path /share_edge

OnPrem-EDGE::>

Now you can see that the “Share” was created in the share_edge volume.

OnPrem-EDGE::> vserver cifs share show -share-name share_edge
Vserver        Share         Path              Properties Comment  ACL
-------------- ------------- ----------------- ---------- -------- -----------
NAS-EDGE       share_edge    /share_edge       oplocks    -        Everyone / Full Control
                                               browsable
                                               changenotify
                                               show-previous-versions

OnPrem-EDGE::> 

I have used the smbmap tool to validate that the shared folder can be accessed over the network.

[rebelinux@blabla ~]$ smbmap.py -H 10.10.33.20 -p "XXXXX" -d ZENPRSOLUTIONS -u administrator 
[+] IP: 10.10.33.20:445	Name: NAS-EDGE.zenprsolutions.local                            
        Disk                                                  	Permissions	Comment
	----                                                  	-----------	-------
	share_edge                                        	READ, WRITE	
	ipc$                                              	NO ACCESS	
	c$                                                	READ, WRITE	
[rebelinux@blabla ~]$

In the performed test I copied the “Very_Big_File.iso” file to each site cluster “SHARE” volume.

Note: I modified the original diagram to show how the clients are connected.

In this section you can see the commands used to connect the clients to the “SHARE” volume.

Note: Ubuntu Linux 20.04 was used for this lab scenario.

CLIENT-HQ-01V
root@CLIENT-HQ-01V:/home/godadmin# mount -t cifs -o username=administrator@zenprsolutions.local,password=XXXXXXXX //nas/shares /mnt/share/
root@CLIENT-HQ-01V:/home/godadmin# cd /mnt/share/
root@CLIENT-HQ-01V:/mnt/share# ls
RecApp-2021-02-20.webm   RecApp-2021-02-27.webm   Very_Big_File.iso   WSUS-Cleanup.ps1
root@CLIENT-HQ-01V:/mnt/share#

CLIENT-EDGE-01V
root@CLIENT-EDGE-01V:/home/godadmin# mount -t cifs -o username=administrator@zenprsolutions.local,password=XXXXXXXX //nas-edge/share_edge /mnt/share_edge/
root@CLIENT-EDGE-01V:/home/godadmin# cd /mnt/share_edge/
root@CLIENT-EDGE-01V:/mnt/share_edge# ls
RecApp-2021-02-20.webm   RecApp-2021-02-27.webm   Very_Big_File.iso   WSUS-Cleanup.ps1
root@CLIENT-EDGE-01V:/mnt/share_edge#
CLIENT-EDGE-02V
root@CLIENT-EDGE-02V:/home/godadmin# mount -t cifs -o username=administrator@zenprsolutions.local,password=XXXXXXXX //nas-edge/share_edge /mnt/share_edge/
root@CLIENT-EDGE-02V:/home/godadmin# cd /mnt/share_edge/
root@CLIENT-EDGE-02V:/mnt/share_edge# ls
RecApp-2021-02-20.webm   RecApp-2021-02-27.webm   Very_Big_File.iso   WSUS-Cleanup.ps1
root@CLIENT-EDGE-02V:/mnt/share_edge#

In this last step the <cp> command was used to copy the “Very_Big_File.iso” file from the cluster to a local folder on the client. To measure the elapsed time of transfer the Linux <time> command was used.

CLIENT-HQ-01V
root@CLIENT-HQ-01V:/mnt/share# time cp Very_Big_File.iso /home/godadmin/

real	2m7.513s
user	0m0.016s
sys	0m6.236s
root@CLIENT-HQ-01V:/mnt/share#
CLIENT-EDGE-01V
root@CLIENT-EDGE-01V:/mnt/share_edge# time cp Very_Big_File.iso /home/godadmin/

real	4m2.391s
user	0m0.021s
sys	0m6.902s
root@CLIENT-EDGE-01V:/mnt/share_edge#
CLIENT-EDGE-02V
root@CLIENT-EDGE-02V:/mnt/share_edge# time cp Very_Big_File.iso /home/godadmin/

real	2m16.169s
user	0m0.054s
sys	0m6.128s
root@CLIENT-EDGE-02V:/mnt/share_edge# 

Further on, the following table shows the elapsed time transfer of each test performed. As you can see the CLIENT-HQ-01V located at the Gurabo site has direct access to the shared folder at the origin volume helping to achieve a lower transfer time of 2m7.513s. The CLIENT-EDGE-01V is connected to the Ponce site using the shared folder from the flexcache volume where you can see that since the content was not initially in the cache the transfer time was higher 4m2.391s. This behavior is due to the need to load the entire contents of “Very_Big_File.iso” from the source volume over the InterCluster LIF connection. Finally the CLIENT-EDGE-02V had a transfer time similar to CLIENT-HQ-01V (2m16.169s) since the content of the “Very_Big_File.iso” file is already in the cache of the flexcache volume.

Client NameElapsed Time
CLIENT-HQ-01V2m7.513s
CLIENT-EDGE-01V4m2.391s
CLIENT-EDGE-02V2m16.169s

till next time!

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 flackbox.com

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.

OnPrem-HQ::> 

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
 Pool0
  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.

OnPrem-HQ::> 

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                                                  

OnPrem-HQ::> 

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.

OnPrem-HQ::> 

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                                            

OnPrem-HQ::>

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             

OnPrem-HQ::>

Summary

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

Serial Number: X-XX-XXXXXXXXXXXXXXXXXXXXXXXXXX
Owner: OnPrem-HQ-01
Installed License: Legacy Key
Capacity: -
Package           Type     Description           Expiration
----------------- -------- --------------------- -------------------
VE                license  Volume Encryption License 
                                                 -

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

OnPrem-HQ::> 

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
-----BEGIN CERTIFICATE----- 
Certificate Content
-----END CERTIFICATE-----
Please enter Private Key: Press <Enter> when done
-----BEGIN PRIVATE KEY-----  
Certificate Private Key Content
-----END PRIVATE KEY-----
You should keep a copy of the private key and the CA-signed digital certificate for future
reference.

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
-----BEGIN CERTIFICATE-----  
Certificate Content
-----END CERTIFICATE-----
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 192.168.7.201, port TCP/5696 and using the previously configured certificates.

OnPrem-HQ::> security key-manager external enable -vserver OnPrem-HQ -key-servers 192.168.7.201:5696 -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
------------------------------------------------
192.168.7.201:5696

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
----  -------  -------------------------------------------  ---------------
OnPrem-HQ-01
      OnPrem-HQ
               192.168.7.201:5696                           available
OnPrem-HQ-02
      OnPrem-HQ
               192.168.7.201:5696                           available
2 entries were displayed.

OnPrem-HQ::> 

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

OnPrem-HQ::> 

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.

Summary

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:

https://www.powershellgallery.com/packages/DataONTAP/9.8.0

[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 {

 param(

     #Declare the required variable

     [string]$lunpath

 )

 #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) {

 get-luninfo($lun)

 }

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.

Installation

[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.

MINIO_VOLUMES="/usr/local/share/minio/"

# 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. 

MINIO_ROOT_PASSWORD="<change me>"

EOT

[Downloading the application]

[root@VEEAM-MINIO ~]# wget https://dl.min.io/server/minio/release/linux-amd64/minio

[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 https://raw.githubusercontent.com/minio/minio-service/master/linux-systemd/minio.service -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

Requirements:

  • 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
[root@comp-01a:~]

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 <loadESXCheckCompat.py>. In this case the command confirmed that my platform is compatible.

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

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.
[root@comp-01a:~]

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

[root@comp-01a:~] /usr/lib/vmware/loadesx/bin/loadESX.py
DEBUG: LoadESX scripts are up to date.
INFO: Enabling QuickLaunch kernel preload
DEBUG: Using a ramdisk at /tmp/loadESX for intermediate storage
DEBUG: SYSTEM STORAGE IS ENABLED
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...
[root@comp-01a:~] 

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.

Summary

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.