Latest Posts



Translate

Total Pageviews

Saturday, 31 October 2015

Managing IBM Power and Z Systems via vRealize Automation

One of the challenges in creating hybrid cloud is stitching different infrastructure fabrics into a unified infrastructure platform. The other challenge is achieving automation at infrastructure level as well as at application level. IBM and VMware have joined forces to address these challenges in the industry to enable customers to manage different IBM and VMware infrastructure fabrics through a single solution. This integration is part of vRealize Automation product and is available out of the box in the latest vR Automation 6.2.3 release. vRealize Automation can now manage different IBM Power platforms by interacting with IBM PowerVC, and it can also manage System-Z platform by integrating with IBM Cloud Manager (ICM). vRealize Automation makes calls to OpenStack enabled API of IBM PowerVC and IBM Cloud Manager (ICM) to deliver this functionality.
Currently available functionality in vR Automation 6.2.3 release is –
1) OpenStack endpoint for PowerVC or IBM Cloud Manager (ICM)
2) Data collection on VM (LPARs) resources (CPU, memory) and network states
3) Creation of new LPARs based on image information available inside PowerVC or ICM
4) Deployment design via vR Automation blueprint model
5) Service brokerage via vR Automation self service catalog with flexibility to customize deployments at request time
6) Support for the endpoint in vR Automation fabric groups and reservations
7) Power related lifecycle actions – PowerOn, PowerOff, Restart

Source:-
https://blogs.vmware.com/management/2015/10/managing-ibm-power-z-systems-via-vrealize-automation.html

How to Migrate Citrix XenApp to VMware Horizon 6 - New Document Available

Wednesday, 28 October 2015

What's New in Site Recovery Manager a.k.a SRM 6.1?


·  Storage policy-based management: Site Recovery Manager 6.1 simplifies the process of adding and removing protection to virtual machines. It features new storage-profile protection groups that:
  • Utilize vSphere storage profiles to identify protected datastores and automate the process of protecting and unprotecting virtual machines and adding and removing datastores from protection groups.

  • Enable integration with vRealize Automation to perform self-service provisioning of SRM protection to applications in a private cloud environments.
·  Integration with VMware NSX: Integration with VMware NSX 6.2 lets you use network virtualization to simplify the creation and execution of recovery plans and accelerate recovery.
  • By leveraging new NSX logical switches that span vCenter boundaries, Site Recovery Manager allows you to automatically map network resources across the sites when creating a recovery plan, which lowers operational expenses and reduces time to protection.

  • After failover, network and security settings including IP addresses, security groups, firewall settings and edge configurations are preserved on recovered virtual machines, further decreasing recovery times.
·  Zero-downtime application mobility: Site Recovery Manager 6.1 can orchestrate cross-vCenter vMotion operations at scale using recovery plans when using a supported metro-distance stretched storage solution as underlying replication.
  • Site Recovery Manager users can perform disaster avoidance and data center migrations without downtime and accelerate disaster recovery time.

  • Stretched-storage users can experience the benefits of Site Recovery Manager, such as centralized recovery plans, automated non-disruptive testing and orchestrated virtual machine recovery.
For More Info download PDF from here



Tuesday, 27 October 2015

What's New in vCloud 8 for Service Providers?

  • vSphere 6.0 support: vCloud Director for Service Providers 8.0 adds support for vSphere 6.0 in backward compatibility mode.
  • NSX support: vCloud Director for Service Providers 8.0 adds support for NSX 6.1.4 in backward compatibility mode. This means that tenants' consumption capability is unchanged and remains at the vCloud Networking and Security feature level of vCloud Director 5.6.
  • Organization virtual data center templates: Allows system administrators to create organization virtual data center templates, including resource delegation, that organization users can deploy to create new organization virtual data centers.
  • vApp enhancements: Enhancements to vApp functionality, including the ability to reconfigure virtual machines within a vApp, and network connectivity and virtual machine capability during vApp instantiation.
  • OAuth support for identity sources: Support added for OAuth2 tokens.
  • Tenant throttling: : Prevents a single tenant from consuming all of the resources for a single instance of vCloud Director and ensures fairness of execution and scheduling among tenants.
Source:-
VMware Release Notes

Thursday, 15 October 2015

Fault Tolerance Requirements, Limits, and Licensing in vSphere 6.x


Before using vSphere Fault Tolerance (FT), consider the high-level requirements, limits, and licensing that apply to this feature.

The following CPU and networking requirements apply to FT.
CPUs that are used in host machines for fault tolerant VMs must be compatible with vSphere vMotion or improved with Enhanced vMotion Compatibility. Also, CPUs that support Hardware MMU virtualization (Intel EPT or AMD RVI) are required. The following CPUs are supported.

Intel Sandy Bridge or later. Avoton is not supported.
AMD Bulldozer or later.
Use a dedicated 10-Gbit logging network for FT and verify that the network is low latency.

In a cluster configured to use Fault Tolerance, two limits are enforced independently.

das.maxftvmsperhost

The maximum number of fault tolerant VMs allowed on a host in the cluster. Both Primary VMs and Secondary VMs count toward this limit. The default value is 4.

das.maxftvcpusperhost

The maximum number of vCPUs aggregated across all fault tolerant VMs on a host. vCPUs from both Primary VMs and Secondary VMs count toward this limit. The default value is 8.

The number of vCPUs supported by a single fault tolerant VM is limited by the level of licensing that you have purchased for vSphere. Fault Tolerance is supported as follows:

vSphere Standard and Enterprise. Allows up to 2 vCPUs
vSphere Enterprise Plus. Allows up to 4 vCPUs

Note
FT and legacy FT are not supported in vSphere Essentials and vSphere Essentials Plus.

Source:
VMware Documentation

Wednesday, 14 October 2015

App HA Most FAQ

Question:- Is there a new product that replaces vSphere AppHA?

Answer:- There is no replacement for the vSphere AppHA feature, customers can use vSphere Data Protection, HA, Fault Tolerance, and Replication to protect their environments along with supported third-party products.

Question:- Are there alternative third party products available?

Answer:- Yes, for AppHA scenarios customers can use third-party applications, such as ApplicationHA from Symantec.

Note: VMware does not recommend any specific third-party application.

Source:-
VMware Documentation

Resxtop Command is not working

Issue: After successfully logging into an ESXi host, the command prompt is returned immediately and resxtop is not loaded.


Reason: This is known issue with vMA

Workaround/Solution:

Run the command:-

sudo mv /usr/lib/vmware-rcli/lib/ /usr/lib/vmware.

After running the command, you can connect to your ESXi host by using resxtop.

Source:-
https://www.vmware.com/support/developer/vima/vma55/vma_55_relnotes.html
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2064386&src=vmw_so_vex_ragga_1012

Tuesday, 13 October 2015

The esxtop utility causes high CPU load (2000829)

Symptoms

  • The esxtop utility is very slow to redraw and display data.
  • The console world indicates 100% load.
  • ESX console shows the esxtop process generating the high CPU load.
  • ESX host is sluggish and unresponsive.
  • Stopping the esxtop utility reduces the CPU load to normal.

Resolution

Running the esxtop utility in interactive mode on an ESX host with a large number of LUNs may cause high CPU load.

The esxtop utility scans for new objects on every snapshot by default. When there are a large number of LUNs present, the scan process takes longer to complete. The default interval between each snapshot is 5 seconds. If a scan for new objects takes longer than 5 seconds, the utility queues those scans and it may appear frozen.

To avoid this issue, run the esxtop utility with the -l switch. The -l switch locks the esxtop objects to those available in the first snapshot and does not scan for new ones on every snapshot.

Run this command to use the -l switch:
# esxtop -l

Note: 
Running # esxtop -help  returns this information on the -l switch:
# esxtop -help
 
usage: esxtop [-h] [-v] [-b] [-l] [-s] [-a] [-c config file] [-R vm-support-dir-path]
[-d delay] [-n iterations][-export-entity entity-file] [-import-entity entity-file]

-l locks the esxtop objects to those available in the first snapshot.
 
Source:-
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2000829&src=vmw_so_vex_ragga_1012

Change Layout Settings in vSphere 6.x Web Client

Question: How can someone change the Layout settings in vSphere 6.x Web Client?
Answer:- So here are the steps:-
1. Login in to vSphere Web Client.
2. Click on the Down arrow available next to your username > Select layout settings


3. Then select whatever the Panes you want to HIDE or DISPLAY. You can drag and drop the Panes to change their location and as well as you can Reset to default layout


Thursday, 8 October 2015

VMware SDK for Perl in vMA

Question :- In vMA, VMware SDK for the Perl is pre-installed then what is path to access those perl scipts?

Answer :- Steps to use those Perl Scripts is given below:-
1. SSH to vMA
2. Login with vi-admin user
3. Then navigate to this path:-
/usr/lib/vmware-vcli/apps/
4. Then you will get the directory structure like this:-
5. Open the relevant directory that you need and then access the perl scripts like the example is given below:-
$ /usr/lib/vmware-vcli/apps/general/credstore_admin.pl add --server vcenterdr.example.com --username example\\vsphereadmin --password vspherepassword
New entry added successfully
Source:-
http://www.routereflector.com/

Wednesday, 7 October 2015

Converting between CPU summation and CPU % ready values (2002181)

Purpose

Some documents, such as VMware's whitepaper Performance Troubleshooting for vSphere 4.1 refer to the CPU ready value as a summation value. Other documents, such as the vSphere Datacenter Administration Guide, refer to the CPU ready value as a percentage value. Therefore, you may need to convert between CPU ready summation and CPU ready percentage values to troubleshoot some performance issues.


Resolution

To convert between the CPU ready summation value in vCenter's performance charts and the CPU ready % value that you see in esxtop, you must use a formula.
The formula requires you to know the default update intervals for the performance charts. These are the default update intervals for each chart:
  • Realtime: 20 seconds
  • Past Day: 5 minutes (300 seconds)
  • Past Week: 30 minutes (1800 seconds)
  • Past Month: 2 hours (7200 seconds)
  • Past Year: 1 day (86400 seconds)

CPU ready %

To calculate the CPU ready % from the CPU ready summation value, use this formula:
(CPU summation value / (<chart default update interval in seconds> * 1000)) * 100 = CPU ready %
Example: The Realtime stats for a virtual machine in vCenter might have an average CPU ready summation value of 1000. Use the appropriate values with the formula to get the CPU ready %.
(1000 / (20s * 1000)) * 100 = 5% CPU ready

CPU ready summation value

To convert the CPU ready % into a CPU ready summation value, reverse the calculation and use this formula:
(CPU ready % / 100) * <chart default update interval> * 1000 = CPU summation value
Example: If a virtual machine has a CPU ready % of 5m, its CPU ready summation value on the Realtime performance chart is calculated like this:
(5 / 100) * 20s * 1000 = 1000 CPU ready

Additional Information

CPU ready %

As a shortcut, you can use the following formulas for the default chart update intervals to get the CPU ready %:
  • Realtime: CPU summation value / 200
  • Past Day: CPU summation value / 3000
  • Past Week: CPU summation value / 18000
  • Past Month: CPU summation value / 72000
  • Past Year: CPU summation value / 864000
Example: A realtime CPU summation value of 1000 is divided by 200 to give a CPU ready % of 5.

CPU ready summation value

As with the longer version of the formula, reverse the formula and multiply (rather tha dividing) to calculate the CPU ready summation value:
  • Realtime: CPU ready % * 200
  • Past Day: CPU ready % * 3000
  • Past Week: CPU ready % * 18000
  • Past Month: CPU ready % * 72000
  • Past Year: CPU ready % * 864000
Example: If you have a CPU ready % 5, multiply it by 200 to get a Realtime CPU ready summation value of 1000.
Calculator Link:-





Source:-
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2002181&src=vmw_so_vex_ragga_1012