Sunday, March 31, 2019

Memory Virtualization: Management & Reclaiming - Section I

Memory resource provisioning is one of the biggest challenges for IT administrators and virtualization designers. Although the provision of CPU is the major factor in the virtual infrastructure, most of the time there is lesser attention to CPU, because many applications that are deployed in virtualization need more memory, not the processor. And also today CPU technologies are very powerful, but applications like SQL and Oracle for some of their processes need more memory. Lack of enough memory resources may restrict the development of many virtual infra, so what should we do in this situation, before providing more physical resources for our hypervisors? 
There are many technologies to handle the problem of memory over-commitment  such as Swapping and Ballooning and VMware ESXi use some of them to confronting these issues. in this post I will review act and importance both mentioned mechanism:

1. Virtual Memory Ballooning is just a memory reclaiming technique that lets the VMkernel retrieve idle memory pages. When the ESXi host has less than 6% free memory (actually >=6%), Ballooning will come into the ring to handle out of memory problem! If a VM has many idle pages, its host borrows them to use as the temporary overhead for the VMs with more memory demand because probably they have some memory-intensive processes. 
When a virtual machine wants to release some of the old used page files dedicated from host physical memory, does not remove it exactly, just change the address space pointer of the allocated memory list to the free memory list. So VM with Balloon Driver (vmmemctl.sys) can decide which pages (idle pages) can be reclaimed back to the host (up to 65% of VM guest memory) and which ones are needed for itself yet (already used pages) without involving host in this decision procedure. Now time for inflating step to happen.
If you disable memory ballooning driver inside the guest OS, VM will not be aware of host memory state and amount of available or unused physical memory and hypervisor cannot understand how much memory can take it back for other VMs memory requests.

2. Host Swapping is another mechanism used in low memory status, but unlike the Ballooning, it does not relate to VM guest OS. Host Swapping (or vRAM) has occurred If the host has less than 2% free memory and needs to provide more memory resources for memory-intensive VMs, so hypervisors should have enough swap space. although swapping is a reliable way against memory over-commitment, but it may cause total performance degrading because the efficiency of generated swap files is highly depended on IOPS rate of datastore specified for swapping, So if we don't provision suitable Disks (Like SSD) for swap files, it can lead to low performance.
There is one crucial point: If Memory Compression could happen, there is no need for hypervisor swap procedure execution. (I will discus more about it later on another post)
Remember, ESXi Host's memory will stay in share state until total required memory for them (memory requests) is greater than available physical memory (over-commitment), So if we want to prevent this situation before ballooning activation, we need to do these jobs:
1. Estimate carefully about overall required memory and also provide at least 25% more memory in the design phase.
2. Use VMware DRS in cluster-level resources to distribute VMs between hosts and balance resource usage, then no need to worried about low-memory. It's recommended to provision equal memory for all of ESXi hosts.
3. Use Resource Pools, especially in cluster-level and reserved estimated memory for mission-critical application and high resource-demand VMs and ensure they access to enough resources. Also, reserved memory is protected against memory reclaiming, even contention happened.
4. Do Not disable Balloon Driver, because it's the best intelligent memory reclamation technique. but if you want to do that, you can do it via the vSphere Client setting (Remove sched.mem.maxmemctl entry from .vmx file) or Guest OS Windows Registry (Set value of HKLM\SYSTEM\CurrentControlSet\services\VMMEMCTL from 2 to 4)

Thanks to frank Danneman for this post in the VMware blog about memory reclaiming, I will talk more about VMware memory management technologies in the next section. For more information, you can refer to below links:

Tuesday, March 12, 2019

VMware VDI (Horizon View) Troubleshooting - Part II



Now it's time to investigate more deeply about troubleshooting of VMware Horizon View. In this post, I want to continue speaking about the LDAP structure and data of the VDI server. If you look at the first post of this series, I talked how to connect to View LDAP with windows MMC: ADSI Edit. Now I will show you which VDI objects belong to which one of OUs in Directory Service hierarchy of VMware View:

 1. OU=Server Groups specified a list of desktop pools in the Horizon environment.
2. OU=Servers contain all the VMs (Desktops that have been deployed by every desktop pool.
3. OU=Data Disk listed all of the generated virtual disks belong to each of the desktop.
4. OU=Groups contains all of predefined Admin groups and manually added roles in horizon administration console with their allowed permissions mentioned into the pae-AdminRolePermissions attribute of defined object.
5. OU=Applications is about all added virtual APPs to Horizon environment, for example by an Application Pool of an RDS Farm. Each of the created Apps are listed here. 
Now let's review sub_OUs of OU=Properties:


1. If you configured the View event database, you can see the related object in sub_OU of OU=Database as a pae-EventDatabase class. Database server type and instance name, configured TCP Port, Database name and also events longevity are the main attributes of this class of object.
2. OU=Server is about Horizon View servers class as the pae-VDMProperties class. OU=Server, OU=LVM contains VDI servers (as same as the last mentioned object class) that are related to Linked-Mode Desktop Pools.
3. OU=VirtualCenter listed configured vCenter servers (VC) and composer servers (SVI) with object class type of pae-VirtualCenter. You can also check specified connection credential and URL addresses of each server: https://VC:443/sdk and https://SVI:18443
4. OU=Global contains some important objects such as:
4-1 CN= Common with some important attributes about VDI management, like Pod Name (or Cluster Name that has been generated from computer name of first / primary installed connection server), timeout of console session and connected desktop desktop, Maximum session time duration, Syslog related configuration, Pre-forced logoff message for Horizon endpoint users, IPSec mode and etc.
4-2 CN=License with hashed-form of imported license key for VMware Horizon View. 
4-3 CN=Keys contains RADIUS configs, some session timeouts like RDP, VDM Gateway and Security servers, Security Server Pairing settings and etc.
I tried to mention some useful and critical OUs of VMware Horizon View LDAP structure on this post, if you think I forgot to review another important objects of View LDAP, I will be appreciated to tell me about it.

Saturday, March 2, 2019

VMware ESXI SNMPv3 CLI Configuration - Fast Guide

 Hello everybody, because of importance of ESXi host monitoring in virtual environment (or SDDC) management, today i want to demonstrate a fast guide for ESXi SNMP version3 configuration by ESXCLI. (Remember it will be done only by CLI not GUI) SNMP protocol v1 & v2 are not secured, because they do not support encryption and work only with a clear-text community string, while it's a security compromise to never use them anyway. I had given a promise in this post on security recommendation series to write a specific post about how to configure SNMPv3 on ESXi, so let me begin and don't waste the time anymore:


# esxcli system snmp get                        "Show the current ESXi SNMP config"
# esxcli system snmp set -r                     "Reset to default setting"
# esxcli system snmp set -e 1                 "Enable SNMP"
# esxcli system snmp set -a SHA1           "Select SHA1 Protocol"
# esxcli system snmp set -x AES128       "Select AES128 Encryption"
# esxcli system snmp set -E  Eng_ID       "Set System Engine ID"
# esxcli system snmp hash -A Auth_str  -X Priv_Str  -r 

It will generate intended hash strings, then select & copy both of them to use in the next command:
# esxcli system snmp set -R Mon_User/SHA1/hash1/AES128/hash2/Eng_ID

Also you can change some default settings, such as port and log level:
# esxcli system snmp set -p 161                            "Set SNMP Port"
# esxcli system snmp set -l warning                       "Define Log Level"

And some optional settings are included of: 
# esxcli system snmp set -C Asset_Manager           "Set Contact Information"
# esxcli system snmp set -L  Node_Location           "Set Asset Location Info"
 








Now let's check its configuration once more again:

# esxcli system snmp get

So last setting is something like this picture.
I hope it will be helpful guide for you guys, for more information please refer to VMware Links about SNMP Configuration:

I will start a new journey soon ...