Thursday, 10 November 2016

What’s New in vSphere 6.5: Host & Resource Management and Operations

3 comments

vSphere 6.5 brings a number of enhancements to ESXi host lifecycle management as well as some new capabilities to our venerable resource management features, DRS and HA.  There are also greatly enhanced developer and automation interfaces, which are a major focus in this release.  Last but not least, there are some notable improvements to vRealize Operations, since this product is bundled with certain editions of vSphere.  Let’s dig into each of these areas.

Enhanced vSphere Host Lifecycle Management Capabilities

With vSphere 6.5, administrators will find significantly easier and more powerful capabilities for patching, upgrading, and managing the configuration of VMware ESXi hosts.
VMware Update Manager (VUM) continues to be the preferred approach for keeping ESXi hosts up to date, and with vSphere 6.5 it has been fully integrated with the VCSA.  This eliminates the additional VM, operating system license, and database dependencies of the previous architecture, and now benefits from the resiliency of vCenter HA for redundancy.  VUM is enabled by default and ready to handle patching and upgrading tasks of all magnitudes in your datacenter.
Host Profiles has come a long way since the initial introduction way back in vSphere 4!  This release offers much in the way of both management of the profiles, as well as day-to-day operations.  For starters, an updated graphical editor that is part of the vSphere Web Client now has an easy-to-use search function in addition to a new ability to mark individual configuration elements as favorites for quick access.
vsphere65-host-profile-editorAdministrators now have the means to create a hierarchy of host profiles by taking advantage of the new ability to copy settings from one profile to one or many others.
Although Host Profiles provides a means of abstracting management away from individual hosts in favor of clusters, each host may still have distinct characteristics, such as a static IP address, that must be accommodated.  The process of setting these per-host values is known as host customization, and with this release it is now possible to manage these settings for groups of hosts via CSV file – undoubtedly appealing to customers with larger environments.
Compliance checks are more informative as well, with a detailed side-by-side comparison of values from a profile versus the actual values on a host.  And finally, the process of effecting configuration change is greatly enhanced in vSphere 6.5 thanks to DRS integration for scenarios that require maintenance mode, and speedy parallel remediation for changes that do not.
Auto Deploy – the boot-from-network deployment option for vSphere – is now easier to manage in vSphere 6.5 with the introduction of a full-featured graphical interface.  Administrators no longer need to use PowerCLI to create and manage deploy rules or custom ESXi images.
ad-gui-tab-animation
New and unassigned hosts that boot from Auto Deploy will now be collected under the Discovered Hosts tab as they wait patiently for instructions, and a new interactive workflow enables provisioning without ever creating a deploy rule.
Custom integrations and other special configuration tasks are now possible with the Script Bundle feature, enabling arbitrary scripts to be run on the ESXi hosts after they boot via Auto Deploy.
Scalability has been greatly improved over previous releases and it’s easy to design an architecture with optional reverse proxy caches for very large environments needing to optimize and reduce resource utilization on the VCSA.  And like VUM, Auto Deploy also benefits from native vCenter HA for quick failover in the event of an outage.
In addition to all of that, we are pleased to announce that Auto Deploy now supports UEFI hardware for those customers running the newest servers from VMware OEM partners.
It’s easy to see how vSphere 6.5 makes management of hosts easier for datacenters of all sizes!

Resource Management – HA, FT and DRS

vSphere continues to provide the best availability and resource management features for today’s most demanding applications. vSphere 6.5 continues to move the needle by adding major new features and improving existing features to make vSphere the most trusted virtual computing platform available.  Here is a glimpse of the what you can expect to see when vSphere 6.5 later this year.

Proactive HA

Proactive HA will detect hardware conditions of a host and allow you to evacuate the VMs before the issue causes an outage.  Working in conjunction with participating hardware vendors, vCenter will plug into the hardware monitoring solution to receive the health status of the monitored components such as fans, memory, and power supplies.  vSphere can then be configured to respond according to the failure.
Once a component is labeled unhealthy by the hardware monitoring system, vSphere will classify the host as either moderately or severely degraded depending on which component failed. vSphere will place that affected host into a new state called Quarantine Mode.  In this mode, DRS will not use the host for placement decisions for new VMs unless a DRS rule could not otherwise be satisfied. Additionally, DRS will attempt to evacuate the host as long as it would not cause a performance issue. Proactive HA can also be configured to place degraded hosts into Maintenance Mode which will perform a standard virtual machine evacuation.

vSphere HA Orchestrated Restart

vSphere 6.5 now allows creating dependency chains using VM-to-VM rules.  These dependency rules are enforced if when vSphere HA is used to restart VMs from failed hosts.  This is great for multi-tier applications that do not recover successfully unless they are restarted in a particular order.  A common example to this is a database, app, and web server.
In the example below, VM4 and VM5 restart at the same time because their dependency rules are satisfied. VM7 will wait for VM5 because there is a rule between VM5 and VM7. Explicit rules must be created that define the dependency chain. If that last rule were omitted, VM7 would restart with VM5 because the rule with VM6 is already satisfied.
orchha
In addition to the VM dependency rules, vSphere 6.5 adds two additional restart priority levels named Highest and Lowest providing five total.  This provides even greater control when planning the recovery of virtual machines managed by vSphere HA.

Simplified vSphere HA Admission Control

Several improvements have been made to vSphere HA Admission Control.  Admission control is used to set aside a calculated amount of resources that are used in the event of a host failure.  One of three different policies are used to enforce the amount of capacity is set aside.  Starting with vSphere 6.5, this configuration just got simpler.  The first major change is that the administrator simply needs to define the number of host failures to tolerate (FTT).  Once the numbers of hosts are configured, vSphere HA will automatically calculate a percentage of resources to set aside by applying the “Percentage of Cluster Resources” admission control policy.  As hosts are added or removed from the cluster, the percentage will be automatically recalculated.  This is the new default configuration, but it is possible to override the automatic calculation or use another admission control policy.
Additionally, the vSphere Web Client will issue a warning if vSphere HA detects a host failure would cause a reduction in VM performance based on the actual resource consumption, not only based on the configured reservations.  The administrator is able to configure how much of a performance loss is tolerated before a warning is issued.

admission-controlFault Tolerance (FT)

vSphere 6.5 FT has more integration with DRS which will help make better placement decisions by ranking the hosts based on the available network bandwidth as well as recommending which datastore to place the secondary vmdk files.
There has been a tremendous amount of effort to lower the network latency introduced with the new technology that powers vSphere FT. This will improve the performance to impact to certain types of applications that were sensitive to the additional latency first introduced with vSphere 6.0. This now opens the door for even a wider array of mission critical applications.
FT networks can now be configured to use multiple NICs to increase the overall bandwidth available for FT logging traffic.  This is a similar configuration to Multi-NIC vMotion to provide additional channels of communication for environments that required more bandwidth than a single NIC can provide.

DRS Advanced Options

Three of the most common advanced options used in DRS clusters are now getting their own checkbox in the UI for simpler configuration.
  • VM Distribution: Enforce an even distribution of VMs. This will cause DRS to spread the count of the VMs evenly across the hosts.  This is to prevent too many eggs in one basket and minimizes the impact to the environment after encountering a host failure. If DRS detects a severe imbalance to the performance, it will correct the performance issue at the expense of the count being evenly distributed.
  • Memory Metric for Load Balancing: DRS uses Active memory + 25% as its primary metric when calculating memory load on a host. The Consumed memory vs active memory will cause DRS to use the consumed memory metric rather than Active.  This is beneficial when memory is not over-allocated.  As a side effect, the UI show the hosts be more balanced.
  • CPU over-commitment: This is an option to enforce a maximum vCPU:pCPU ratios in the cluster. Once the cluster reaches this defined value, no additional VMs will be allowed to power on.

drs-settingsNetwork-Aware DRS

DRS now considers network utilization, in addition to the 25+ metrics already used when making migration recommendations.  DRS observes the Tx and Rx rates of the connected physical uplinks and avoids placing VMs on hosts that are greater than 80% utilized. DRS will not reactively balance the hosts solely based on network utilization, rather, it will use network utilization as an additional check to determine whether the currently selected host is suitable for the VM. This additional input will improve DRS placement decisions, which results in better VM performance.

SIOC + SPBM

Storage IO Control configuration is now performed using Storage Policies and IO limits enforced using vSphere APIs for IO Filtering (VAIO). Using the Storage Based Policy Management (SPBM) framework, administrators can define different policies with different IO limits, and then assign VMs to those policies. This simplifies the ability to offer varying tiers of storage services and provides the ability to validate policy compliance.

sioc-spbmContent Library

Content Library with vSphere 6.5 includes some very welcome usability improvements.  Administrators can now mount an ISO directly from the Content Library, apply a Guest OS Customization during VM deployment, and update existing templates.
Performance and recoverability has also been improved.  Scalability has been increased, and there is new option to control how a published library will store and sync content. When enabled, it will reduce the sync time between vCenter Servers are not using Enhanced Linked Mode.
The Content Library is now part of the vSphere 6.5 backup/restore service, and it is part of the VC HA feature set.

Developer and Automation Interfaces

The vSphere developer and automation interfaces are receiving some fantastic updates as well. Starting with the vSphere’s REST APIs, these have been extended to include VCSA and VM based management and configuration tasks. There’s also a new way to explore the available vSphere REST APIs with the API Explorer. The API Explorer is available locally on the vCenter server itself and will include information like what URL the API task is available to be called by, what method to use, what the request body should look like, and even a “Try It Out” button to perform the call live.
api-explorerMoving over to the CLIs, PowerCLI is now 100% module based! There’s also some key improvements to some of those modules as well. The Core module now supports cross vCenter vMotion by way of the Move-VM cmdlet. The VSAN module has been bolstered to feature 13 different cmdlets which focus on trying to automate the entire lifecycle of VSAN. The Horizon View module has been completely re-written and allows users to perform View related tasks from any system as well as the ability to interact with the View API.
The vSphere CLI (vCLI) also received some big updates. ESXCLI, which is installed as part of vCLI, now features several new storage based commands for handling VSAN core dump procedures, utilizing VSAN’s iSCSI functionality, managing NVMe devices, and other core storage commands. There’s also some additions on the network side to handle NIC based commands such as queuing, coalescing, and basic FCOE tasks. Lastly, the Datacenter CLI (DCLI), which is also installed as part of vCLI, can make use of all the new vSphere REST APIs!
Check out this example of the power of DCLI’s interactive mode with features like tab complete:

dcli

Operations Management

There’s been some exciting improvements on the vSphere with Operations Management (vSOM) side of the house as well. vRealize Operations Manager (vR Ops) has been updated to version 6.4 which include many new dashboards, dashboard improvements, and other key features to help administrators get to the root cause that much faster and more efficient. Log Insight for vCenter has been also updated, and will be on version 4.0. It contains a new user interface (UI) based on our new Clarity UI, increased API functionality around the installation process, the ability to perform automatic updates to agents, and some other general UI improvements. Also, both of these products will be compatible with vSphere 6.5 on day one.
Digging a little further into the vR Ops improvements, let’s first take a look at the three new dashboards titled: Operations Overview, Capacity Overview, and Troubleshoot a VM. The Operations dashboard will display pertinent environment based information such as an inventory summary, cluster update, overall alert volume, and some widgets containing Top-15 VMs experiencing CPU contention, memory contention, and disk latency. The Capacity dashboard contains information such as capacity totals as well as capacity in use across CPU count, RAM, and storage, reclaimable capacity, and a distributed utilization visualization. The Troubleshoot a VM dashboard is a nice central location to view individual VM based information like its alerts, relationships, and metrics based on demand, contention, parent cluster contention, and parent datastore latency.
vrops-dash
One other improvement that isn’t a dashboard but is a new view for each object, is the new resource details page. It closely resembles the Home dashboard that was added in a prior version, but only focuses on the object selected. Some of the information displayed is any active alerts, key properties, KPI metrics, and relational based information.
vrops-details
Covering some of the other notable improvements, there is now the ability to display the vSphere VM folders within vR Ops. There’s also the ability to group alerts so that it’s easy to see what the most prevalent alert might be. Alert groups also enable the functionality to clear alerts in a bulk fashion. Lastly, there are now KPI metric groups available out of the box to help easily chart out and correlate properties with a single click.
Courtesy : Charu Chaubal
Blog post: http://blogs.vmware.com/vsphere/2016/10/whats-new-in-vsphere-6-5-host-resource-management-and-operations.html

Introducing vSphere 6.5

1 comments


VMware announces vSphere 6.5, the latest version of its industry-leading virtualization platform.  This new release of vSphere features a dramatically simplified experience, comprehensive built-in security, and a universal app platform for running any app.
vSphere 6.5 accelerates the customer transition to digital transformation and cloud computing by addressing key challenges:
1.     Environments growing increasingly complex,
2.     Growing IT security threats, and
3.     The need to support both existing and new apps and services.
Let’s take a look at some of the key capabilities.

Dramatically Simplified Experience

vSphere 6.5 elevates the customer experience to an entirely new level. It provides exceptional management simplicity, operational efficiency, and faster time to market
vSphere 6.5 makes the vCenter Server Appliance the fundamental building block of a vSphere environment. The core vSphere architecture is built around this easy to deploy and manage approach that reduces operational complexity by embedding key functionality into a single location. Capabilities such as vSphere host management (with a fully integrated vSphere Update Manager), file-based backup and recoverynative VCSA high availability, and much more are now embedded in this new one-stop appliance model. Users can now be more efficient as there is no longer a need to interface with multiple components.  Additionally, because everything is centralized, vCenter Server Appliance generates a tremendous amount of optimization and innovation, including an over 2x increase in scale and 3x in performance.  Upgrading to this building block will be easier than ever before as users can now convert from their traditional Windows deployment into the new appliance model using the new vCenter Server Appliance Migration tool.

vcsa-highlights

vCenter Server Appliance: The fundamental building block of a vSphere environment
In this release, vSphere 6.5 also takes an API-first approach to foster a more business-centric and highly agile environment. In a world where infrastructure as code is becoming a requirement rather than just nice to have, a programmable infrastructure layer is now essential. vSphere 6.5 introduces new REST-based APIs for VM Management that vastly improve both the user and partner experience by enabling finer control of virtual infrastructure for apps. You can now do much more with less lines of code with these new simple APIs.
The final component that allows vSphere 6.5 to deliver a simplified experience is the graphical user interface itself. The highly anticipated new HTML5-based vSphere Client provides a modern user interface experience that is both responsive and easy to use.   Many customers have already experienced this vSphere Client as part of a Fling on VMware Labs, and thus far the response has been overwhelming positive.
HTML5-based vSphere Client: GUI that enables fast performance and cross-platform compatibility
HTML5-based vSphere Client: GUI that enables fast performance and cross-platform compatibility

Comprehensive Built-in Security

With increased threats, comprehensive built-in security becomes more critical than ever before. vSphere 6.5 natively provides secure data, infrastructure, and access at scale via its operationally simple, policy-driven model. Protecting all three areas is essential for digital transformation and the evolution of any given business.
To secure data, vSphere 6.5 offers a new VM-level disk encryption capability designed to protect against unauthorized data access. VMware’s approach is both universal and scalable, with the ability to encrypt any VM disk regardless of guest OS, and the ability to manage encryption at scale using the familiar vSphere storage policy framework. Combined with the new encrypted vMotion capability, vSphere can safeguard both data at-rest and data in-motion.
To assure the security of the underlying infrastructure, vSphere 6.5 also adds a secure boot model to protect both the hypervisor and the guest operating system. It helps prevent images from being tampered with and prevents the loading of unauthorized components.
vSphere 6.5 also delivers enhanced audit-quality logging capabilities that provide more forensic information about user actions. IT can now better understand who did what, when, and where if an investigation into anomalies or security threats requires it.
vSphere 6.5 is the core of a secure SDDC and works seamlessly with other SDDC products to provide a complete security model for infrastructure.
Comprehensive Built-in Security: Secure Data, Secure Infrastructure, and Secure Access
Comprehensive Built-in Security: Secure Data, Secure Infrastructure, and Secure Access

Universal App Platform

vSphere is a universal app platform that supports both traditional and next-generation apps. While these two worlds are vastly different, both require infrastructure with the scale, performance, and availability to meet key business objectives.
vSphere has always been pushing the limits on what apps it can support.  Initially it was all about test/dev but then quickly expanded coverage business critical apps as well.  Later, it included Desktop Virtualization and 3D graphics.  Now we are seeing more modern apps being virtualized including Hadoop, Spark, Machine Learning, HPC and cloud native apps.
To run any app, vSphere 6.5 expands its workload coverage model by focusing on both scale-up and scale-out next-gen apps that are increasingly built using evolving technology building blocks, such as containers.   In this release, VMware delivers vSphere Integrated Containers, the easiest way for vSphere users to bring containers into an existing vSphere environment. vSphere Integrated Containers delivers an enterprise container infrastructure that provides the best of both worlds for the developers and vSphere operations teams. Containers are now just as easy to enable and manage as virtual machines. No process or tool changes are required.
VMware vSphere Integrated Containers helps customers to transform their businesses with containers without re-architecting their existing infrastructure. It is comprised of three components – the Engine which provides the core container run-time, Harbor which is an enterprise registry for container images, and Admiral which is a portal for container management by dev teams. vSphere Integrated Containers enables IT operations teams to provide a Docker compatible interface to their app teams, running on their existing vSphere infrastructure and features tight integration with VMware NSX and VMware Virtual SAN to support best-in-class network automation and scale out, high performance persistent storage, respectively.
vSphere Integrated Containers: Delivering the best of both worlds for IT and Developers
vSphere Integrated Containers: Delivering the best of both worlds for IT and Developers

vSphere 6.5 also lets you run apps from any cloud, including your data center or in public cloud environments. vSphere 6.5 is not only the heart of the Software-Defined Data Center, it’s also the foundation of VMware’s cloud strategy. vSphere 6.5 is available in both the private cloud and as a service through a public cloud. The newly announced VMware Cloud Foundation and VMware Cloud on AWS are both built on vSphere 6.5.
As the ideal platform for apps, cloud, and business, vSphere 6.5 reinforces the customer’s investment in VMware. vSphere 6.5 is one of the core components of VMware’s SDDC and a fundamental building block for VMware’s cloud strategy. With vSphere 6.5, customers can now run, manage, connect, and secure their applications in a common operating environment, across clouds and devices.

Courtesy: http://blogs.vmware.com/vsphere/2016/10/introducing-vsphere-6-5.html

Thursday, 6 October 2016

Troubleshooting Storage Performance in vSphere

0 comments

When we troubleshoot performance related issues, the first think which would hit our mind it "Storage". So let's have a sneak peak about the basic troubleshooting of the storage related issues. 

Poor storage performance is generally the result of high I/O latency. vCenter or esxtop will report the various latencies at each level in the storage stack from the VM down to the storage hardware.  vCenter cannot provide information for the actual latency seen by the application since that includes the latency at the Guest OS and the application itself, and these items are not visible to vCenter. vCenter can report on the following storage stack I/O latencies in vSphere.

 Storage Stack Components in a vSphere environment
LatencyInStorageStack
GAVG (Guest Average Latency) total latency as seen from vSphere
KAVG (Kernel Average Latency) time an I/O request spent waiting inside the vSphere storage stack. 
QAVG (Queue Average latency) time spent waiting in a queue inside the vSphere Storage Stack.
DAVG (Device Average Latency) latency coming from the physical hardware, HBA and Storage device.

To provide some rough guidance, for most application workloads (typically 8k I/O size, 80% Random, 80% Read) we generally say anything greater than 20 to 30 ms of I/O Latency may be a performance concern. Of course as with all things performance related some applications are more sensitive to I/O latency then others so the 20-30ms guidance is a rough guidance rather than a hard rule. So we expect that GAVG or total latency as seen from vCenter should be less than 20 to 30 ms.  as seen in the picture, GAVG is made up of KAVG and DAVG.  Ideally we would like all our I/O to quickly get out on to the wire and thus spend no significant amount of time just sitting in the vSphere storage stack,  so we would ideally like to see KAVG very low.  As a rough guideline KAVG should usual be 0 ms and anything greater than 2ms may be an indicator of a performance issue. 
So what are the rule of thumb indicators of bad storage performance? 
•             High Device Latency: Device Average Latency (DAVG) consistently greater than 20 to 30 ms may cause a performance problem for your typical application. 
•             High Kernel Latency: Kernel Average Latency (KAVG) should usually be 0 in an ideal environment, but anything greater than 2 ms may be a performance problem.

Poor storage performance is generally the result of high I/O latency, but what can cause high storage performance and how to address it?   There are a lot of things that can cause poor storage performance
– Under sized storage arrays/devices unable to provide the needed performance
– I/O Stack Queue congestion
– I/O Bandwidth saturation, Link/Pipe Saturation
– Host CPU Saturation
– Guest Level Driver and Queuing Interactions
– Incorrectly Tuned Applications
– Under sized storage arrays 

As I mentioned above the key storage performance indicators to look out for are 1. High Device Latency  (DAVG consistently greater than 20 to 30 ms) and 
2. High Kernel Latency( KAVG greater than 2 ms). Once you have identified that you have High Latency you can now proceed to trying to understand why the latency is high and what is causing the poor storage performance. In this post, we will look at the top reason for high Device latency.
The Top reason for high device latency is simply not having enough storage hardware to meet your application’s needs (Yes, I have said it a third time now), that is a sure fire way to have storage performance issues.  It may seem basic, but too often administrators only size their storage on the capacity size they need to support their environment but not on the Performance IOPS/Latency/Throughput that they need.   When sizing your environment you really should consult your Application and Storage Vendor’s best practices and sizing guidelines to understand what storage performance your application will need any what your storage hardware can deliver.
How you configure your storage hardware, the type of drives you use, the raid configuration, the number of disk spindles in the array, etc… will all affect the maximum storage performance your hardware will be able to deliver.  Your storage vendor will be able to provide you the most accurate model and advice for the particular storage product you own, but if you need some rough guidance you can use the guidance provided in the chart below.
  Untitled-1 copy

The slide shows the general IOPs and Read & Write throughput you can expect per spindle depending on the RAID configuration and/or drive type you have in your array.    Also frequently I’m asked what is the typical I/O profile for a VM, the guidance varies greatly depending on the applications running in your environment, but a “typical” I/O workload for a VM would roughly be 8KB I/O size, 80% Random, 80% Read.  Storage intensive applications like Databases, Mail Servers,  Media Streaming, … have their own I/O profiles that may differ greatly from this “typical” profile.
One good way to make sure your storage is able to handle the demands of your datacenter, is to benchmark your storage.  There are several free and Open Source tools like IOmeter that can be used to stress test and benchmark your storage.  If you haven’t already taken a look at the I/O Analyzer tool delivered as a VMware Fling,  you might want to take a peek at it.  I/O Analyzer is a virtual appliance tool that provides a simple and standardized approach to storage performance analysis in VMware vSphere virtualized environments ( http://labs.vmware.com/flings/io-analyzer ).
Also when sizing your storage make sure your storage workloads are balanced “appropriately” across the paths in the environment, across the controllers and storage processors in the array and balanced and spread across the appropriate number of spindles in the array.  I’ll talk a bit more about “appropriately” balanced later on in this series as it varies depending on your storage array and your particular goals/needs.     
Simply sizing your storage correctly for the expected workload, in terms of size and performance capabilities, will go very far to making sure you don’t run into storage performance problems and making sure your Device Latency (DAVG) is less than that 20-30ms guidance.  

Source & Courtesy: http://blogs.vmware.com/vsphere/2012/06/troubleshooting-storage-performance-in-vsphere-part-3-ssd-performance.html


Thursday, 1 September 2016

What is the difference between PCPU Used and PCPU Utilized?

0 comments

I’m often asked the question when looking at vSphere statistics – “What is the difference between PCPU Used and PCPU Utilized and why don’t they match?” Let’s take a look as it can be somewhat complex.
First lets start with some definitions:
  • Time Stamp Counter (or TSC) – is a 64 bit register available on all modern processors that counts clock cycles at a consistent rate and is not affected by changes in clock frequency.
  • Unhalted Cycles – another count of ‘all’ clock cycles, but this one is dependent on the clock frequency and therefore the rate can change if the clock frequency changes (due to things like power management or Hyper-Threading).
  • Wall Clock Time – refers to elapsed real world time.
Okay now lets define our two counters using the above definitions:
  • PCPU utilized (which is TSC based) = (non-idle state TSC cycles)/wall clock time
  • PCPU used (which is unhalted cycle based) = (unhalted cycles)/wall clock time
So assuming a non Hyper-Threaded system, and no power management is being used, PCPU utilized = PCPU used.
Lets look at how Power Management affects these counters:
If power management is enabled and the cpu runs at a lower frequency, unhalted cycles will be smaller than TSC cycles, hence “PCPU used < PCPU utilized”. On the other hand, if turbo mode is activated and the cpu is running with a higher frequency, “PCPU used > PCPU utilized”.
Lets also look at how Hyper-Threading affects these counters:
For Hyper-Threaded systems, each core has two PCPUs and PCPU utilized is calculated using the same way as non-Hyper-Threading systems.
PCPU used is accounted differently:
  • If only one PCPU is busy within a core, for this PCPU, PCPU used =  (unhalted cycles)/wall clock time  * 50%, which means ESX assumes one Hyper-Thread only  uses half of the core capacity .
  • If both PCPUs within the core are busy, for each PCPU, PCPU used = (unhalted cycles)/wall clock time  * 62.5%, which means ESX assumes two Hyper-Thread threads will achieve 125% of core capacity.
So why two different counters and when should I use them?
PCPU utilized indicates how much time a PCPU was busy with time being even, where as PCPU used shows the total amount of work that’s been done while being influenced by technologies like Hyper-Threading and power management. I leverage PCPU utilized for my planning and analysis activities and PCPU used for troubleshooting activities.  We expose a lot of counters so always be sure you know what they mean before using them to ensure accuracy and great performance data.
http://blogs.vmware.com/vsphere/2013/01/what-is-the-difference-between-pcpu-used-and-pcpu-utilized.html

Wednesday, 10 February 2016

How to increase the log retention in Orchestrator Server ( server.log)

2 comments
When you are debugging the Orchestrator related issues in mid/large deployments , it is expected that the server.log file rotates rapidly. 
In this case we need to increase the log file size and the rotation interval. Below are the steps to make changes to the config file to capture large number of files for troubleshooting. 
Config File Location : 
Appliance deployment: /etc/vco/app-server/log4j.xml
Windows deployment: <install_Location>\app-server\conf\log4j.xml

Steps: 
1. Edit the file log4j.xml
2. Locate the <appender class="org.apache.log4j.RollingFileAppender" name="FILE"> section
3. Increase the size of the log file to 10 MB  <param name="MaxFileSize" value="10240KB"/>  
4. Increase the  number files to be retained before rotation <param name="MaxBackupIndex" value="5"/>

Cheers :-) 

Friday, 7 August 2015

Configuring SNMP traps for the vCenter Server

0 comments


Steps to configure the vCenter Server to generate SNMP traps:

A.In the Home page of vSphere Client
B.Select vCenter Server Settings 
C.Select SNMP configuration
D.Enable one of the SNMP receivers
E. Provide the details for : 

  • Receiver URL : Provide the host name of the Management Server (target SNMP server / monitoring tool) which will be connected to the VMware vCenter Server.(VMware vCenter Server sends the SNMP traps to this Management Server)
  • Configure port 162 as the SNMP port.
  • Community String: Provide community string (default string is "public") SNMP versions v1/v2/v3 are supported


That is all that is needed for the configuration.  Now you need to configure alarm for generating SNMP traps in the vCenter server. When ever there is a change in the environment ( host state change, VM state change ,etc) the trigger will be generated and send an alert to the monitoring server. 

Configure the Alarms

After you have setup the external SNMP server, vCenter Server can now ready to send SNMP traps to it. There are  alarms in vCenter Server that are configured to send traps by default. So your SNMP server should receive alarms as soon as you have the SNMP setup.

Steps: 


  • Add an alarm to monitor the changes related to VM state and vCenter Server status, and then adding the appropriate action (ie, send a notification trap).
  • In the Home page of the VMware vSphere Client, select Hosts and Clusters and right-click on the VMware vCenter Server, data-center or an individual virtual machine to set the alarm. You can set the alarm at an individual virtual machine level, at the data center level, or at the entire VMware vCenter Server level. It is recommended to set it at the VMware vCenter Server level.
  • In the General tab, provide alarm details with alarm type set for monitoring the virtual machines. Enter the details as listed in the following table:
  • Alarm Name :Provide the name of the alarm.
  • Description :Provide additional information about the alarm.
  • Alarm Type :Select Virtual Machines in the Monitor drop-down list.
  • Select Monitor for specific events occurring on this object, for example, VM powered On option. Ensure that Enable this alarm check box is selected.
  • In the Triggers tab, add the required triggers to monitor the states of the virtual machine. For example, VM created, VM migrated, VM powered on, VM powered off, VM suspended, and so on.





Provide information on when to send the notification trap.

In the Actions tab of the Alarm Settings panel, click Add to add a new action. In the Action drop-down list, select Send a notification trap option. 

That's it. You now will be able to see the alerts in the monitoring tool dashboard. 

Cheers ! 

Wednesday, 25 March 2015

Explore vsphere 6.0

1 comments
VVols
Perhaps the most wanted feature in vSphere 6 is Virtual Volumes, or VVOLs. VVOLs extends the VMware software-defined storage (SDS) story to its storage partners, and completely changes the way its hypervisor consumes storage; it radically changes how storage is presented, consumed and managed by the hypervisor. No longer is virtual machine (VM) storage bound by the attributes of the LUN, as each VM disk (VMDK) can have its own policy-driven SLA. VMware has a passel of storage vendors on board to equip its storage, with the ability to offer VVOLs storage to the VMware hypervisor. I'm sure this feature will get much press and customer attention in the coming days.

vMotion
vSphere vMotion just got 10 times better, and a lot more interesting. For one thing, it supports live VM migration  across vCenter servers, and over long distances. It used to support round trip times (RTTs) of 10 ms, but now supports RTTs of 100 ms. A ping from Portland, Ore., to Boston, Mass., is 90 ms; so, in theory, you could move a live VM across the entire United States using vMotion. I'm not sure which of these I find more interesting: long distance vMotion, Cross vCenter vMotion or how shared storage will span a continent.

Fault Tolerance
Multi-processor fault tolerance is a feature unique to the VMware hypervisor. It allows a workload to run simultaneously on two different ESXi servers; if a server or VM goes down, the other one will continue running the load uninterrupted. This feature, until today, only supported one vCPU; now it can protect a four-vCPU VM in the Enterprise Plus version, and a 2-vCPU VM in other editions. VMware stressed the fact that to be effective, a 10Gb connection is required between the ESXi servers. From what the engineers have told me, this required a major rewrite of the FT code base.

Bigger VMs
The VMware VMs have gotten even bigger. VMware has doubled the number of vCPUs a VM can have from 64 to 128, and has quadrupled the amount of RAM from 1TB to 4TB. This opens up some unique possibilities; consider, for example, resource-intensive applications, such as the SAP HANA memory database.

As more powerful hosts come online, vSphere will be ready to support them, because an ESXi host is capable of supporting 480 CPU and 6TB of RAM.

vSphere now supports 64-node clusters. This change has been a long time coming, and it's good that VMware finally is supporting larger clusters. This should be a big boon to the 1,000-plus VMware customers running Virtual SAN.

Instant Clone 
VMware has a feature called Instant Clone that I'm dying to try in my lab, as it creates clones 10 times faster than vSphere does presently. This is a welcome relief for all the test and dev shops that have been hampered, waiting for a clone to finish.
A new feature in the stack is vSphere Content Library. For those who have ISOs, VM templates and virtual appliances stored in multiple locations, this will be a nice central repository that can be synchronized and accessed from different sites and vCenter instances. In its initial release, vSphere Content Library has basic versioning and a publish-and-subscribe mechanism to keep things in sync.

On the network side, vSphere now supports Network I/O control on a per-VM basis, and can reserve bandwidth to guarantee SLAs.

Ready for VDI
VMware has also thrown in support for NVIDIA GRID vGPU, which will allow an individual VM to take advantage of all the goodness of a physical vGPU housed in an ESXi server. vSphere has had vDGA for a while, but whereas it tied a GPU to one guest, vGPU allows the GPU to share among eight. A lot of the people I've talked to have been waiting for this feature.

This change shows how serious VMware is about the virtual desktop infrastructure market, as it joins soft 3D, vSGA and vDGA as a way to make desktop VMs more performant.

As I mentioned before, this release is, for the most part, evolutionary rather than revolutionary -- and there's nothing wrong with that. Yes, it has VVOLs, and it might be the game changer the community believes it to be. But I also hope that people finally fully utilize fault tolerance to protect critical applications, use long-distance vMotion to move workloads as needed and create some truly monstrous VMs to run their in-memory databases.

vSphere 6 demonstrates that VMware wants to maintain its leadership in hypervisor development.