What’s New in vSphere 6.5

VMware announced today the release of vSphere 6.5. With that comes a slew of features and functionality, here give you a quick update about vsphere 6.5 improvement and new features & enhancements.

New Features

vCenter server appliance 6.5 (VCSA)

Migration

vCenter Server Appliance is no longer an issue as the installer has a built in Migration Tool. the steps are easy to migrate and support both CLI and GUI methods.

Improved Appliance Management

Center Server Appliance 6.5 is the improved appliance management capabilities. The vCenter Server Appliance Management Interface continues its evolution and exposes additional health and configurations.

VMware Update Manager

This will be huge for customers who have been waiting to migrate to the vCenter Server Appliance without managing a separate Windows server for VUM.

Native High Availability

New native high availability solution that is available exclusively for the vCenter Server Appliance. This solution consists of Active, Passive, and Witness nodes which are cloned from the existing vCenter Server. Failover within the vCenter HA cluster can occur when an entire node is lost (host failure for example) or when certain key services fail. For the initial release of vCenter HA an RTO of about 5 minutes is expected but may vary slightly depending on load, size, and capabilities of the underlying hardware.

Built-in Backup / Restore

New in vCenter Server 6.5 is built-in backup and restore for the vCenter Server Appliance. This new out-of-the-box functionality enables customers to backup vCenter Server and Platform Services Controller appliances directly from the VAMI or API, and also backs up both VUM and Auto Deploy running embedded with the appliance.

HTML5-based vSphere Client

vSphere 6.5 is fully supported version of the HTML5-based vSphere Client that will run alongside the vSphere Web Client. The vSphere Client is built right into vCenter Server 6.5 (both Windows and Appliance) and is enabled by default.

Resource Management – HA, FT and DRS

Slightly restructured 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.

Improved Admission Control Policies : 

VM Restart Priorities: new restart priorities added such as highest and lowest in addition to High, medium, low which available from previous versions.

HA Orchestrated Restart: Enforce VM to VM dependency chains. This is great for multi-tier applications the require VMs to restart in a particular order. (DB, App and then Web Vm).

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.

vSphere HA Admission Control

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.

DRS Advanced Options

M Distribution: 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.

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.

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

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

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

For more information , please visit http://blogs.vmware.com/

VMware and AWS to partner to provide new Hybrid Cloud

VMware Cloud on AWS , announced at a press conference in San Francisco, will bring cloud-optimized versions of vSphere, VSAN and NSX software to the cloud platform. When users spin up a VMware environment on AWS, they'll get a cluster running the entire Software-Defined Data Center stack in the public cloud.

The service, which is currently in technical preview, will be operated and supported by vmware, running on purpose-built hardware in AWS's data Centers.

It's move that makes AWS more appealing for VMware customers looking to run applications on a hybrid cloud. Users will be able to manage the public cloud deployments, like their on-premises VMware deployments, using VMware's vCenter software.

Vmware SRM fail-over issues

Most Common issue we are facing test failovers is a problem mounting the snapshot datastores at the recovery site.

A typical error message may be "Failed to Create Snapshots of Replica Devices" or Time out 300 seconds while waiting for SRA to complete "discoverDevices" command. 

Always we are facing issue with related to the SRA and some tweaks can be made to the timeout setting.

To change advanced settings using vsphere or web client.

storageProvider.hostRescanRepeatCnt to 2
storageProvider.hostRescanTimeoutSec to something higher than 300.  
storageProvider.waitForAccessibleDatastoreTimeoutSec to something higher than 30, and again it depends.

I hope this information will help you, thanks for reading my blog.

VMware Site Recovery Manager (SRM) - advanced settings

I was facing configuration issue with Site Recovery Manager (SRM) for my customers, I often configure some advanced settings that let me avoid cosmetic errors or recovery failure.

This topic is cover those advanced settings to change advanced settings using vsphere or web client.

Note: By design, during an upgrade, SRM does not retain any advanced settings that you configured in the previous installation. Some advanced settings may require unprotect VM and protect it again because its apply only to virtual machines that you protect after you changed the settings. Please always follow documentation to a SRM version that you configure as VMware likes adding or changing some advanced settings.

Top 20 ESXi articles for July 2016

Here is our Top 20 ESXi articles list for July 2016. This list is ranked by the number of times a VMware Support Request was resolved by following the steps in a published Knowledge Base article.

1.     Uploading diagnostic information for VMware through the Secure FTP portal

2.     Support Contracts FAQs

3.     Commands to monitor snapshot deletion in ESXi/ESX

4.     How to purchase and file Pay Per Incident support for VMware products

5.     Uploading diagnostic information for VMware using FTP

6.     Downloading, licensing, and using VMware products

7.     Licensing VMware vCenter Site Recovery Manager

8.     Determining Network/Storage firmware and driver version in ESXi/ESX 4.x, ESXi 5.x, and ESXi 6.x

9.     ESXi 5.x with E1000e adapter fails with purple diagnostic screen

10.   Recreating a missing virtual machine disk descriptor file

11.   Using the VMware Knowledge Base

12.   Product offerings for vSphere 5.x

13.   ESXi hosts are no longer manageable after an upgrade

14.   Installing patches on an ESXi 5.x/6.x host from the command line

15.   Enabling or disabling VAAI ATS heartbeat

16.   Restarting the Management agents in ESXi

17.   Permanent Device Loss (PDL) and All-Paths-Down (APD) in vSphere 5.x and 6.x

18.   Consolidating snapshots in vSphere 5.x/6.0

19.   “maximum consolidate retries was exceeded for scsix:x” error in ESXi

20.   Build numbers and versions of VMware ESXi/ESX

The post Top 20 ESXi articles for July 2016 appeared first on Support Insider.

VMware vSphere vCenter Log location

Here i have shared the vmware vsphere vCenter log location , this will help you to troubleshoot and solve the problems.

vCenter 5.x / 6.x

The vCenter Server logs are placed in a different directory on disk depending on vCenter Server version and the deployed platform:

vCenter Server 5.x and earlier versions on Windows XP, 2000, 2003: %ALLUSERSPROFILE%Application DataVMwareVMware VirtualCenterLogs

vCenter Server 5.x and earlier versions on Windows Vista, 7, 2008: C:ProgramDataVMwareVMware VirtualCenterLogs

vCenter Server 5.x Linux Virtual Appliance: /var/log/vmware/vpx/

vCenter Server 5.x Linux Virtual Appliance UI: /var/log/vmware/vami

Note: If the service is running under a specific user, the logs may be located in the profile directory of that user instead of %ALLUSERSPROFILE%.

All Paths Down (APD) and Permanent Device Loss (PDL)

vSphere ESXi datastores there are two distinct states a device can be in when storage connectivity is lost; All Paths Down (APD) or Permanent Device Loss (PDL). For each of these states, the device is in an All Paths Down condition, but how they are handled is different. All Paths Down (APD) is a condition where all paths to the storage device are lost or the storage device is removed. The state is caused because the change happen in an uncontrolled manner, and the VMkernal core storage stack does not know how long the loss of access to the device will last. The APD is a condition that is treated as temporary (transient), since the storage device might come back online; or it could be permanent, which is referred to as a Permanent Device Loss (PDL).

The Permanent Device Loss (PDL) is the permanent removal of a device. This is typically caused by a storage administrator removing a LUN at the storage array, either by unmapping or deleting it. The VMkernal core storage stack knows the device is not coming back because the storage array informs the host of a PDL state through a SCSI command response. The removal is considered permanent when all paths have the PDL error

There are two variants of PDL, planned and unplanned:

• Planned PDL is when the administrator follows the recommend workflow to remove a storage device (Unmounting a LUN or detaching a datastore/storage device from multiple VMware ESXi 5.x/6.0 hosts)

• Unplanned PDL is when the storage administrator just removes a storage device (at the storage array)

A device may return from a PDL, but there is no guarantee of data consistency at that point.

When a LUN is removed from an ESXi host without preparing the host, there is a potential for them to enter an All Paths Down (APD) state that will become host and virtual machine impacting; the hosts may disconnect from vCenter Server and the ESXi servers would require a reboot to resolve the problem. To address this issue, in vSphere 5.1 there was an advanced setting introduced called APDHandlingEnabled, which defaults to 1. When this setting is enabled, the host continues to retry non-VM I/O commands to a storage device in the APD state for a limited period only. If this value is set to 0, the behavior of retrying failing I/Os forever will be imposed. 

A configurable timer with a default of 140 seconds starts when a host first detects a datatstore is in All Paths Down (APD). Hostd will mark the datastore as inaccessible with an APD Started reason. The timeout parameter controls how many seconds the ESXi host will retry non-VM I/O commands to a device before determining the device is unreachable.

After the timer expires, the datastore will be identified as APD Timeout, pending non-VM I/O will be aborted and hostd will mark the datastore as inaccessible with an APD Timeout reason. Any further non-VM I/O will be fast failed with a status of NO_Connect.

This will ensure hostd does not become unresponsive, and prevents ESXi hosts disconnecting from vCenter Server.

You might want to increase the value of the timeout if there are storage devices connected to your ESXi host, which might take longer that 140 seconds to recover from a connection loss. You can enter a value between 20 and 99999 seconds.

What about the Guest OS initiated I/O? The Guest OS is responsible for retrying or aborting it's own outstanding I/O. vSphere has a feature to make VMX file writes more resilient, VMX I/O updates to the config file are atomic which mitigates corruption to the VMX file during an APD. It is initially written to a tmp file, and then swapped with the actual vmx.

Now that we have a better understanding of All Paths Down, lets create an alarm for APD Timeouts. vCenter Alarms can be specified for a particular object and it will apply to all the child-objects beneath in the vCenter server tree. In this instance, we are going to create an alarm to specific event that applies to all the ESXi hosts.

To start, we are going to go into the vSphere Web Client and go to the Manage tab and click on the Alarm Definitions view. In the Definitions view, we are going to click on the green + button to create a new alarm.

On the General view, we are going to give our alert a name and description. You will set the Monitor For to specific event occurring on this object, for example VM Power On and then click Next.

Next we are going to add the trigger. The Event is going to be esx.problem.storage.apd.timeout with the Status of Alert.

On the Actions view, this is where we are going to setup the action taken when the alert hits a threshold.