In this post we will learn how to achieve multipathing when using software iSCSI adapters to connect to Storage Array.

What is Multipathing?

Multipathing is having more than one path to storage devices from your server. At a given time more than one paths are used to connect to the LUN’s on storage device. It provides the ability to load-balance between paths when all paths are present and to handle failures of a path at any point between the server and the storage. Multipathing is a de-facto standard for most Fibre Channel SAN environments.

Multipathing for software iSCSI

For environments which uses software iSCSI to connect to Storage Array, multipathing is possible at the VMkernel network adapter level, but it is not the default configuration. The default iSCSI configuration creates only one path from the software iSCSI adapter (vmhba) to each iSCSI target.

To enable failover at the path level and to load-balance I/O traffic between paths, we have to configure port binding to create multiple paths between the software iSCSI adapters on Esxi servers and the storage array.… Read More

Today I was reading a whitepaper on VMware FT and came across some cool facts. In this post I am going to share some excerpts from that whitepaper.

Server virtualization has become very popular and grown very fast in last few years and enterprise started to use virtualization more and more to gain the benefits provided by virtualization such as:

1: Higher server consolidation ratios.

2: Better resource utilization (Using DRS).

3: Lower power consumption (Leveraging DPM).

4: Increased workload mobility via technologies such as vMotion and svMotion.

Features such as Distributed Resource Scheduler (DRS) and Distributed Power Management (DPM) are giving organizations a flexibility to go for a even higher consolidation ration than ever before. DRS is now a very trusted feature and almost all organizations are happy to use it in fully automated mode which was not the case earlier when DRS was introduced by VMware.

DRS and DPM complement the hardware evolution trends by applying dynamic resource allocation to lower the capital and operating costs in a datacenter.… Read More

VMware vCenter Multi-Hypervisor Manager

VMware vCenter Multi-Hypervisor Manager (MHM) is a vCenter component that provides an integrated platform for managing VMware and third-party hypervisors from a single interface.

The list of supported hypervisors can be summarized as below:

1. Microsoft Hyper-V Server 2012
2. Microsoft Hyper-V for Windows Server 2012
3. Microsoft Hyper-V Server 2008 R2
4. Microsoft Hyper-V for Windows Server 2008 R2
5. Microsoft Hyper-V for Windows Server 2008

MHM supports heterogeneous hypervisors in VMware vCenter Server and it let administrators to choose which hypervisor meets a specific business unit’s needs within an organization. When a third-party host is added to vCenter Server, all virtual machines (VMs)  that exist on the host are discovered automatically and added to the third-party hosts inventory. Administrators can modify permissions, adjust server configurations, provision new VMs, migrate VMs from Hyper-V to ESXi and power hosts off and on.

Operations Supported by MHM:

• Manage Hyper-V hosts and virtual machines (VMs) from vCenter.

over commitment in its simplest term means allocating more resources to virtual workloads then what is available at physical level. Most common resources that are over committed are memory and cpu.

A simple example of over commitment can be running 3 VM each with 4 GB RAM on an Esxi host which has only 8 GB RAM. In this case we have allocated 12 GB RAM to all VM’s collectively but at physical level (Esxi host) we have only 8 GB RAM available.

It is a general belief by most novice VMware admins that allocating more resources to virtual machines means better performance. When I started working with VMware I also used to think in the same way.

It was the vSphere Optimize and Scale training, where I learned this is not true and how over commitment can badly affect VM performance.

In this post I am trying to demonstrate the negative affects of CPU over commitment.… Read More

In part-1 of this series we have configured the vCO settings and added vCenter Server where we will be executing the workflows from vCO.

In this part we will see how to use vCO to execute the workflows. A lot of pre-defined workflows are already integrated in vCO and you can import or create your custom workflows as well.

If you have missed earlier posts of this series click on below link to get started:

Part-1-Installing & Configuring vCO

Login to vSphere Web-Client to get started

1: Open your web-browser and type https://vCenterFQDN:9443/vsphere-client/

2: We will find our vCO server under the vCenter Orchestrator plug-in.

3. Lets start with a very basic workflow of creating a new VM.

Click Workflows and expand the Library to see all the pre-configured workflows.
Expand vCenter –> Virtual Machine Management –> Basic
Right click “Create simple virtual machine”

4. A new window will pop-up where you have to provide the inputs.… Read More

vCenter Orchestrator (vCO) is a cool product from VMware which allows you to create tasks and automated workflows which and be run directly within vSphere Web Client or the vCenter Orchestrator Client.

vCO brings automation to the next level and helps admins, engineers to orchestrate and integrate your cloud with the rest of management systems.

There are a number of pre-made workflows integrated in vCO to get you started. Almost any task that can be performed in vCenter can be automated through vCO. With the use of AD integration, API’s and other 3rd party plugin’s vCO becomes more powerful and can save a lot of time for the VMware admins.

Workflows can be anything from simple workflows that contain a single task to say create a virtual machine, to complicated workflows containing many tasks that might build an entire solution and integrate with 3rd party plugins.

vCO is included with vCenter Server and it’s free!  … Read More

Today when I booted my lab I saw some issues with one of the host and the summary page of host was showing the below error

“The vNetwork Distributed Switch configuration on some hosts differed from that of the vCenter Server.”

The cause of this issue can be explained as follows:

When we install distributed switch and add hosts to the vDS a hidden switch is created on all hosts and a copy of  vDS database is copied to each host with information on the switch. This database is synched every 5 minutes.

vDS are created and managed from vCenter as it holds the management plane and the the part of vDS which get installed on per host level is called IO plane. So if ever vCenter Server is down it will not affect the VM traffic on the host and you will only loose management capabilities.

Selecting the vDS and navigating to host tab will show you a warning (under VDS status) that your host is out of sync.… Read More