Skip to content

Author: Jonathan Colon Feliciano

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.

HomeLab – How to disable vSphere Cluster Services (vCLS)

In vSphere 7 update 1 VMware added a new capability for Distributed Resource Scheduler (DRS) technology consisting of three VMs called agents. The agent VMs form the quorum state of the cluster and have the ability to self-healing. So if you turn off or delete the VMs called vCLS the vCenter server will turn the VMs back on or re-create the VMs again. For HomeLab purposes this new feature consumes CPU resource, Memory and disk space which although minimal is not worth having a configuration that adds nothing to a test and development environment.

In this blog I will be showing how to remove this feature but it is important to emphasize not to implement this change in production environments. The following image show the minimum amount of vCLS VMs used in vCenter 7U1.

Note: vSphere DRS depends on the status of vCLS services as of vSphere 7.0 Update 1.

As you can see in my case the RegionA01-COMP cluster is composed of two ESXi servers where there are three vCLS VMs.

The first thing you need to do is to identify the cluster domain ID that is required to be able to add an advanced value in the vCenter configuration. This ID can be identified in two ways: From vCenter or using Powershell with PowerCLI.

vCenter: In this part you can get the cluster ID by navigating to the [Hosts and Clusters] tab then select the cluster you are going to edit where you can see that the ID is in the URL address of the browser.

PowerCLI: Using Powershell with the VMware.PowerCLI module you can obtain the cluster ID by invoking the <Get-Cluster> command. As shown in the result of the command you can see the value of the Id <domain-c81> for the cluster named RegionA01-COMP.

PS /home/rebelinux> Get-Cluster RegionA01-COMP | FL

ParentId                        : Folder-group-h23
ParentFolder                    : host
HAEnabled                       : True
HAAdmissionControlEnabled       : True
HAFailoverLevel                 : 1
HARestartPriority               : Medium
HAIsolationResponse             : DoNothing
VMSwapfilePolicy                : WithVM
DrsEnabled                      : True
DrsMode                         : FullyAutomated
DrsAutomationLevel              : FullyAutomated
CryptoMode                      : OnDemand
CollectiveHostManagementEnabled : False
Name                            : RegionA01-COMP
ExtensionData                   : VMware.Vim.ClusterComputeResource
Id                              : ClusterComputeResource-domain-c81

PS /home/rebelinux>

Once we have the cluster ID which in my case is <domain-c81> we proceed to add the configuration in vCenter by navigating to [Advanced Settings => Configure => Edit Settings].

In this screen add the <config.vcls.clusters.domain-domain-cID.enabled> value which in my case would be <config.vcls.clusters.domain-c81.enabled> with the value of “false” in the “Value” field.

Once the value is added the VMs of type vCLS will be removed from the cluster as you can see in the image as the VMs no longer exist.

In the following image you can see the tasks performed by vCenter to remove the vCLS VMs.

Hasta luego!!!