Upgrading vSphere 5.1 to vSphere 5.5- Part 6 Upgrading vSphere Web Client

In our last posts of this series we learnt :

Taking DB and SSL Certficates Backup

Upgrading vCenter SSO

Upgrading vCenter Inventory Service

Upgrading vCenter Server

Now its time to upgrade the web client. Before starting the upgrade process lets discuss the basics about vSphere Web Client

The vSphere Web Client allows you to connect to a vCenter server to manage your vSphere environment through a web browser. Web Client make its entry with version 5.0 but with limited functionality. With further release of vSphere versions Web Client was optimized a lot and now a days VMware is pushing hard to use vSphere web client instead of windows based VI client.

All the new features of vSphere 5.5 can only be performed using vSphere web client and it will not be available in the traditional windows client. In the future release of vSphere version VMware can totally take out the regular C# VI Client and the only choice left will be using Web Client to manage the Virtual Infrastructure. So let’s start upgrading our Web Client to enjoy the new features of 5.5.


1: Launch the installer from the installation directory and select vSphere Web client and hit install.


2: Select the installer language and hit OK.


3: Installer will detect an earlier version of web client installed and warn that it will be upgraded to version 5.5.  Ignore the warning and hit Next.


4: Accept the license agreement and hit Next.


5: Review the web client port information and hit Next.


6: Enter the password for SSO Administrator and hit Next.


7: Installer will present the fingerprint of SSO certificate. Click on Yes.


8: Click on install to start upgrading the web client.


9: Sit and relax and let installer finish the installation.


10: Once the installation is finished click on finish.


11: After the installation is finished a dialogue box will pop up telling us to wait for some time before using web client for the first time.


With this we have completed the upgrade of vSphere Web Client.

Hit Like or Rate this article if it is informative to you.

Posted in Vmware, vSphere Upgrade | 4 Comments

Upgrading vSphere 5.1 to vSphere 5.5- Part 5 Upgrading vCenter Server

In our last few posts we have walkthrough the process of

Taking DB and SSL Certficates Backup

Upgrading vCenter SSO

Upgrading vCenter Inventory Service

Now its time to upgrade the vCenter Server. So lets start


1: Launch the autorun.exe file from the installation directory and select vCenter Server and hit Install.


2: Select the installer language and hit OK.


3: Installer will detect previous version of vCenter Server already installed and warn you that it will be upgraded to version 5.5. Ignore the warning and hit Next.


4: Accept the License Agreement and hit Next.


5: You can provide the installation key during upgrade or else after Upgradation is complete.


6: If you did not supplied any key it will warn you that license key for previous version is no longer valid. Ignore the warning and click Next.


7: If you have chosed to use Windows Authentication during DSN setup it will take the credentials of currently login user and you can hit Next or else you have to specify DB username and password for your vCenter DB.


8: Select upgrade existing database as we have already backed up our DB.


9: Select vCenter Agent upgrade method.

If you select automatic then vCenter agent will be upgraded on all hosts in the vCenter Inventory. If you select manual method then you have to reconnect all the hosts to VC in order to upgrade the vCenter server agent.


10: Enter the vCenter Service Account Information

If you are using dedicated service account for administering your vSphere environment and currently login with that user then select use windows system local account or else provide the login credentials of the vCenter service account.


11: Review the vCenter ports and hit Next.


12: Select the inventory size depending upon your environment and hit Next.


13: Provide the SSO admin password and verify the lookup URL and hit Next.


14: Review the vCenter Inventory Service Information and hit Next.


15: For Customer Experience Improvement you can select Enable Data Collection. If you select this option vCenter will send some statistical data to VMware where the engineers can analyze it to make the services better.

Since this is my home lab I haven’t selected that option. Hit Install to start upgrading vCenter.


16: Let the installer finish the upgrade. In the meanwhile you can grab a cup of coffee as it will take some time to finish the upgrade process.















16: Hit Finish after installer has finished upgrading all the components.


With this we have completed upgrading our vCenter Server.

In our next post of this series we will walkthrough upgrading web client.

Hit Like or Rate this article if it is informative to you.

Posted in Vmware, vSphere Upgrade | 5 Comments

Upgrading vSphere 5.1 to vSphere 5.5- Part 4 Upgrading Inventory Service

In our last post we learnt

Taking DB and SSL Certficates Backup

Upgrading vCenter SSO

In this post we will focus on upgrading vCenter Inventory Service.

Before start upgrading the Inventory Service lets discuss some basics about what actually is the Inventory Service.

Inventory Service reduces direct client requests to the vCenter server with query caching, reducing the load on core vCenter Server processes. Generally only 10% of traffic to a vCenter Server consists of writes and most of the requests (90%) are read requests. So if we can cache those reads so that we don’t have to ask vCenter to retrieve from its database each time, we can see a significant improvement in response times; while also reducing the load on the more critical vCenter Server itself.

Inventory service stores vCenter server application and inventory data which enable us to search and access objects across linked vCenter Server systems. The main use case of the Inventory Service is to manage the vSphere Web Client inventory objects and property queries that the client requests when users navigate the vSphere environment.

So we have covered now the basics of Inventory service lets jump into upgrading it.

1: launch the autorun.exe from installation directory and select Inventory Service and hit install


2: Select the installer language and hit OK.


3: An earlier version of installed Inventory Service will be detected by installer and tell us that it will be upgraded to version 5.5. Hit Next


4: Accept the License agreement and hit Next.


5: Database selection option

To retain your existing database select “Keep my existing database” option or else if you want a brand new database select “Replace my existing database option”. Selecting this option will wipe out all the historical data from previous version of service (I guess no one want to do that otherwise what is the point of upgrading. we could have gone for clean install)


6: Enter the FQDN of your vCenter server (if Inventory Service is installed on same machine where all the components are installed)


7: Review and accept the default ports setting and hit Next.


8: Select the inventory size as per your environment and hit Next.


9: Enter the password for the SSO administrator account and click on Next


10: Click on Install button to start upgrading Inventory Service. If you have missed something you can review the settings back by clicking Back button.


11: Installer will present the fingerprint of SSO certificate. Hit Yes


12: Once installation is finished hit finish.


With this we have completed the upgradation of vCenter Inventory Service.

In our next posts of this series we focus on :

Upgrading vCenter Server

Upgrading vSphere Web Client

Hit Like or Rate this article if it is informative to you.

Posted in Vmware, vSphere Upgrade | 5 Comments

Upgrading vSphere 5.1 to vSphere 5.5- Part 3 Upgrading SSO

In previous post we have gone through some of the basic considerations which should be kept in mind before starting the upgrade process and also we learnt Taking DB and SSL Certificates backup

In this post we will start with upgrading the vCenter SSO

Before starting upgrading the Single Sign On lets discuss a bit about what has been changed in version 5.5.

SSO architecture has been restructured from the scratch in version 5.5. The new SSO architecture is based on a multi-master model where each instance is automatically kept up to date with it peers via built-in replication. You can create sites to provide logical groupings of registered resources that maybe geographical or organizational separate as well as support for multiple tenants.

Below are some of the key improvements and changes that are made in the vCenter Single Sign-on 5.5 as compared to previous versions:

  1. Dependency on the external Database has been removed
  2. Single Sign-on is now supports multi-master Model and it will be aware about sites. You will have ability to define sites.
  3. Replication between SSO is built-in and automatic
  4. No More Admin@System-Domain:  SSO administrator account has been changed to Administrator@vSphere.local  in 5.5.

Steps for upgrading Single Sign On

Navigate to the directory where you have unzipped the vCenter Server ISO and double click autorun.exe to launch the installer. Select Single Sign On and click on install as shown below.


You will get the warning about SSL certificate not expiration. We can ignore the below warning as have already backed up our SSL keys in previous step and will continue with installation.


The Installer detects that an earlier version of Single Sign-on is already installed on this system (version 5.1) and it will be upgrade to vCenter Single Sign-on 5.5.0. Click on Next


Accept the license agreement and click next.


Installer will detects the System Information. Review and correct if anything is wrong here before proceeding further. Click on Next


Setup will detect earlier version of SSO running. Hit next to continue installation.


Next screen will ask you for upgrade method. There are 3 types of Upgrade mode for the vCenter Single Sign-on:

First existing vCenter Single Sign-on Server: This option will Install or upgrade your first vCenter Single Sign-on Server

An additional existing vCenter Single Sign-on server in the existing site: This option is to upgrade an additional vCenter single Sign-on in an existing site.

An additional existing vCenter Single Sign-on with a new site: This option is to upgrade an additional vCenter server Single Sign-on server and create a new site.

Select the Checkbox “First existing vCenter Single Sign-on Server” because I want to upgrade my existing SSO and click on Next.


Supply the new password for administrator@vsphere.local account.  vsphere.local is a new domain that is created by vCenter SSO.


In the next screen enter the SSO site name. Since this is my VCAP lab so I named the site accordingly.


Review the Single Sign-on installation location. If you want to change the default location, click on change and select the destination location else click on Next


Review the Single Sign-on installation information and Click on Install.


Let the installer configure and install the new SSO.




The installer will take few minutes to complete the SSO upgrade. Once it is completed, click on Finish

SSO (10)

With this we have upgraded the vCenter SSO from version 5.1 to 5.5.

In the next posts of this series we will learn about

Upgrading vCenter Inventory Service

Upgrading vCenter Server

Upgrading vSphere Web Client

Hit Like or Rate this article if it is informative to you.

Posted in vSphere Upgrade | 5 Comments

Upgrading vSphere 5.1 to vSphere 5.5- Part 2 Database and SSL Certificates Backup

Before proceeding with upgrading vCenter 5.1 to vCenter 5.5, taking backup of the VC database and SSL certificates are very important so that if anything goes wrong we can revert back to original configuration anytime.

Database backup can be taken by you yourself or by your DB admin depending upon the type of environment where you are working. Generally in big corporates there are separate team which do all the DB activities, however, as a vSphere Admin you should know how to do basic DB activities. Backing up DB is very simple and straight forward task. I will walk through all the steps in this post to make it easier and simple to understand. So let’s start!!!

Before proceeding with taking backup we need to identify the SQL server name and Database Instance Name of your vCenter server database.

How to find out DB instance name

RDP to the server where your vCenter DB is installed and go to Start > Administrative Tools > Data Sources (ODBC) connections and launch ODBC Data Source Administrator.


Click on System DSN and then select Configure as shown below.


Click Next


Select how SQL server will verify authenticity of Login ID and Click Next. I usually prefers windows authentication but it may be different as in case of your environment.


In the next screen select your DB name from Change the Default database drop down menu.


Click Next and click finish on the next screen.


Now since you have the name of your DB instance, it’s time to take backup.

To take backup of VC DB you need SQL Server Management Studio installed on the server where DB is installed. If you don’t have it installed (as in my case) then first we have to install it before proceeding further.

Download the appropriate version of SQL Server management Studio from Microsoft.com. Launch the installer by double clicking it.




In the SQL Server Installation Center window select “New installation or add features” option as shown below.


Next select “New Installation or add shared features”


Select Management Tools option in next screen.


Accept the license agreement and click next.


You can skip the error reporting if you want (as it is my home lab)


Sit and relax and let the installation complete.



Next screen shows the completion of installation of SQL Server Management Studio.

Hit close and you are done.


After installation is complete launch the Management Studio from All Programs.


Select the SQL server instance name from the server name drop down menu.


Click on Browse for more if your vCenter DB instance name is not visible.


Select Network Servers tab and locate your DB instance and click OK.


Finally the screen should look like as shown below. Click on connect.


Expand the Databases option and select your DB instance name and right click it and select Tasks > Backup


A default Path in C:/Program file…..will be listed as place where backup file will be stored. You can define your own custom directory where you want to take backup by clicking on Add button on below screen.


Navigate to the directory where you want to keep your DB backup, as shown below.


In my case I created a directory named VC-DB-BKP in C drive. In file name field specify the name of the backup file and click ok.


Next screen will look like as below. Hit OK to start taking backup.


After completion of backup a dialogue box will pop stating backup has been completed successfully, as shown below


Verify the existence of backup file by navigating to directory specified for storing DB backup.


Next is to take backup of the vCenter Server SSL certificates before Upgradation. Below is the location of the SSL certificates on the vCenter server.

Windows 2008: C:\ProgramData\VMware\VMware VirtualCenter\SSL


Now we have completed the backup of vCenter server database and the SSL certificates. In the next posts of this series we will walk through:

Upgrading vCenter SSO

Upgrading vCenter Inventory Service

Upgrading vCenter Server

Upgrading vSphere Web Client

Hit Like or Rate this article if it is informative to you.

Posted in vSphere Upgrade | 5 Comments

Upgrading vSphere 5.1 to vSphere 5.5- Part 1 Basics

Yesterday I decided to upgrade my home lab from vSphere 5.1 version to vSphere 5.5 as part of my VCAP preparation (as VCAP 510 exam is no longer valid) and I decided to write a post on that so that it can be helpful for others as well.

The upgrade process is not much complex but you have to take certain considerations in mind before starting the upgrade process. With vSphere 5.5 VMware has done many changes and your environment should have that kind hardware/software which can support version 5.5.

We will be covering the upgrade process in following 5 steps

Taking DB and SSL Certficates Backup

Upgrading vCenter SSO

Upgrading vCenter Inventory Service

Upgrading vCenter Server

Upgrading vSphere Web Client

Before starting the upgrade lets look at the important considerations

1: Upgrade Considerations

There are 2 upgrades methods available:

Simple Install upgrade
The Simple Install upgrade will upgrade all the vCenter components (SSO + Inventory Service + vCenter Server + Web Client) on a single machine like a simple install will install all components on a single machine.

For more information on the Simple Install upgrade, see Methods of upgrading to vCenter Server 5.5 on a Windows operating system (2053130).

Custom upgrade
A custom upgrade might install different vCenter Server components on different machines or install a second vCenter Server system on the same machine. You also use Custom Install to upgrade an environment that is installed in different locations.

If you are upgrading vCenter Server from a version that includes vCenter Single Sign-On in multisite mode, and if the different vCenter Server systems use Linked mode, you must resynchronize first. You can then upgrade all vCenter Single Sign-On instances and maintain Linked Mode functionality. Linked Mode is required for a single view of all vCenter Server systems. Multisite vCenter Single Sign-On is supported only if all nodes are the same version.

2: Hardware Requirements

Refer this link to identify the hardware requirements for upgrading vSphere 5.1 to 5.5


3: Software Requirements:

vCenter Server Requirements

Ensure that your operating system supports vCenter Server. vCenter Server requires a 64-bit operating system, and the 64-bit system DSN is required for vCenter Server to connect to its database.

For a list of supported operating systems, see the VMware Compatibility Guide.

Pre-upgrade software requirements

  • vCenter Server requires the Microsoft .NET 3.5 SP1 Framework. If it is not installed on your system, the vCenter Server installer installs it.
  • vCenter Server 5.5 removes support for Windows Server 2003 as a host operating system.
  • vCenter Server 5.5 removes support for Windows Server 2008 SP1 as a host operating system. Upgrade Windows Server 2008 SP1 hosts to SP2 before upgrading vCenter Server to version 5.5.
  • If you plan to use the Microsoft SQL Server 2008 R2 Express database that is bundled with vCenter Server, Microsoft Windows Installer version 4.5 (MSI 4.5) is required on your system.

vSphere Web Client software requirements

Supported guest operating systems and browser versions for the vSphere Web Client


System Prerequisites

a) Verify that your system meets the requirements listed in Hardware requirements for vCenter Server, the vSphere Web Client, vCenter Inventory Service, and vCenter Single Sign-On.

b) Ensure that the required ports are open. For more information, Required ports for vCenter Server 5.5 (2051575).

c) If your vSphere system includes VMware solutions or plug-ins, ensure they are compatible with the vCenter Server version that you are upgrading to. For more information, see the VMware Product Interoperability Matrix .

d) Before you upgrade any vCenter Server that belongs to a Linked Mode group, remove it from the Linked Mode group. Upgrading vCenter Servers that are members of a Linked Mode group can cause the upgrade to fail, and can leave vCenter Servers in an unusable state. After you upgrade all members of a Linked Mode group to version 5.5, you can rejoin them.

e) Verify that the fully qualified domain name (FQDN) of the system where you will upgrade vCenter Server is resolvable.

f) Ensure that SSL certificate checking is enabled for all vSphere HA clusters. If certificate checking is not enabled when you upgrade, HA fails to configure on the hosts.

For more information, see Configure SSL Settings in the Sphere Web Client in the vCenter Server and Host Management Guide.

g) Ensure that all SSL certificates are still valid within the environment and have not yet expired. Default VMware Certificates are valid for 10 years, however, Certificate Authority (CA) signed certificates can vary.

h) You must log in as a member of the Administrators group on the host machine, with a user name that does not contain any non-ASCII characters.

i) Before the vCenter Server installation make sure following services are started on the system where vcenter server will be upgraded:

    • VMware Certificate Service
    • VMware Directory service
    • VMware Identity Manager Service
    • VMware KDC service
Posted in vSphere Upgrade | Leave a comment

Understanding NIC Teaming and Load Balancing Policies in virtual switch

NIC Teaming

In its simplest terms NIC teaming means that we are taking multiple physical NICs on a given ESXi host and combining them into a single logical link that provides bandwidth aggregation and redundancy to a vSwitch. NIC teaming can be used to distribute load among the available uplinks of the team.  A NIC teaming configuration can look like as shown in below screenshot:

9780133511086 1.16.2014

There are several Load Balancing policies available for the virtual switch. These are discussed as below:

1: Route Based on Originating virtual Port-ID: This is the default load balancing policy for a vSS or vDS. This policy doesn’t require any special configuration to be done at virtual switch level or physical switch level.

In this policy when a NIC is added to a VM or a new VM is provisioned with a NIC and comes online, VMkernel assigns a Port-ID to the virtual NIC of the VM. The outgoing traffic from the VM NIC will be routed through which uplink (physical adapter) of the team is determined by vSwitch using a modulo function where Port-ID of the VM NIC (virtual adapter of VM) is divided by total number of uplinks present in the team and the remainder obtained determines which uplink will be used to route the traffic of that VM NIC.

At a given time a VM NIC can use only one uplink to send out its traffic. In case of failure of the uplink the traffic of that VM NIC is rerouted (failed over) among one of the available uplink of the team. The selected uplink for a VM NIC can be changed if a VM changes its power state or is migrated using vMotion.



2: Route Based on Source MAC hash: This policy is similar to Route based on originating Port ID but with the difference that vSwitch uses the MAC address of the VM NIC to determine the uplink which will be responsible for taking outgoing traffic of that VM NIC.

In this policy also, a VM NIC can be assigned only one uplink to send traffic out at a given time but failover is supported in case that uplinks fails. This policy is available in both vSS and vDS.


3: Route Based on IP Hash: This is the only load balancing policy in which a VM NIC can send out traffic through more than one uplink at a given time. This policy requires a special configuration i.e. Ether-Channel or Port-Channel to be configured on physical switch.

There is one caveat in this policy. A VM NIC can utilize more than one uplink to send outgoing traffic when it is communicating with more than one destination (IP). If a VM is doing one to one communication i.e. communicating with only one destination IP, traffic will not be shared among the uplinks and only one of the uplink will be used to send the traffic out.


4: Route Based on Physical NIC Load: This load balancing policy is only available with vDS and by far is the most intelligent policy to distribute load among the uplinks in a teamed environment.

The assignment of uplinks to VM NIC’s is based on the originating Port-ID itself but before assigning any uplink vDS looks at the load on the physical adapters. The adapter which is least loaded will be assigned to the VM NIC for sending out traffic. If an adapter which was previously less utilized but suddenly becomes busy due to a heavy network activity on a VM NIC, then that VM NIC will be moved to a different physical adapter so as to keep balance among all uplinks as best as possible.

This load balancing policy use an algorithm to perform a regular inspection of load on the Physical NIC’s every 30 seconds. When the utilization of Particular physical uplink exceeds 75% over 30 seconds, the hypervisor will move VM’s traffic to another uplink adapter. This load balancing doesn’t require any additional configuration at the physical switch level.

load based on Physical NIC load-1

Graphic Thanks to VMwareArena.Com

5: use explicit failover order: This policy really doesn’t do any sort of load balancing. Instead, the first Active NIC on the list is used to route the outgoing traffic for all VM’s. If that one fails, the next Active NIC on the list is used, and so on, until you reach the Standby NICs.

Note: With Explicit Failover option if you have a vSwitch with many uplinks, only one of the uplink will be actively used at any given time.


Posted in Vmware | 2 Comments

VLAN tagging in VMware vSphere


In a physical environment all the servers have dedicated physical NIC that are connected to a physical switch. VLANs in physical world are usually controlled by setting the VLAN ID on the physical switch port and then setting the server’s IP address to correspond to that NIC’s VLAN.

But in a virtual environment, dedicating a physical NIC (pNIC) to each VM that resides on the host is not possible. In reality, a physical NIC of the Esxi host service many VMs, and these VM’s may need to be connected to different VLANs. So the method of setting a VLAN ID on the physical switch port doesn’t work.

To counter this issue, 802.1Q VLAN tagging comes in picture in virtual environment.

Before digging deep into 802.1Q VLAN tagging lets understand how networking works in a virtual environment.

An Esxi host typically can have more than one physical network adapters for redundancy, load balancing and segregation. The physical NICs (pNICs) are connected to physical switches and these pNICs are in turn assigned to vSwitches that are created on each Esxi host. Connecting pNICs to vSwitches is referred to as uplink connection. On vSwitch we create different Port groups which can be connected to the virtual NICs (vNICs) that are assigned to each VM on the host. Virtual machines can use any pNIC connected to a vSwitch and this is determined by the load balancing policies which define how pNICs are selected when routing traffic to and from a VM.

Shown below is a typical network in a virtual environment.


Using the traditional VLAN method of assigning a single VLAN ID to a physical NIC does not work very well in virtual environments because with this method, all the VMs on a vSwitch would have to use the same VLAN ID. But in most of the cases you need to route different VM’s through different VLAN’s so the traditional VLAN method is of less use in this scenario.

Another method which you can use is to create multiple vSwitches for each VLAN, but if you had many VLANs, you would need a great number of pNICs and even the modern day servers comes with limited number of physical network adapters.

To overcome this situation, 802.1Q VLAN tagging is used.

How 802.1Q VLAN tagging for vSphere VLANs works

802.1Q VLAN tagging allows use of multiple VLANs on a single physical NIC. This capability can greatly reduce the number of pNICs needed in the host. Instead of having a separate pNIC for each VLAN, you can use a single NIC to connect to multiple VLANs. Tagging works by applying tags to all network frames to identify them as belonging to a particular VLAN.

Types of 802.1Q VLAN tagging in VMware vSphere

There are several methods for tagging vSphere VLANs, but they are differentiated by where the tags are applied. Basically there are 3 types of tagging methods available in Vmware vSphere. These are explained as below:

1: Virtual Machine Guest Tagging (VGT)– With this mode, the 802.1Q VLAN trunking driver is installed inside the virtual machine. All the VLAN tagging is performed by the virtual machine with use of trunking driver in the guestS. Tags are understandable between the virtual machine networking stack and external switch when frames are passed to and from virtual switches. vSwitch only forwards the packets from Virtual machine to physical switch and will not perform any operation.

Prerequisite for configuring VGT
1) Port group of the virtual machine should be configured with VLAN ID 4095.

2) The physical switch port connecting the uplink from the Esxi server should be configured as Trunk port.

How to configure VGT

To configure VGT login into your guest O.S and select the network adapter for which you want to configure tagging. Open the properties of this adapter and click on configure in the popup window which opens. In the next window select the advance tab and select VLAN from list of configurable options and specify the VLAN ID through which traffic of this adapter needs to pass.




2: External Switch Tagging (EST) – In this mode, physical switches does the VLAN tagging. The tag is appended when a packet arrives at a switch port and stripped away when a packet leaves a switch port toward the server.

Since the tagging is done at physical switch so virtual switch have no information of this and you do not need to configure any VLAN at portgroup level. VM network Packet is delivered to physical switch without any tagging operation performed at virtual switch level.


est final

Note: There is one caveat in this approach. You can only create those many numbers of VLAN’s equal to number of physical NIC’s present/connected to your Esxi host.

Prerequisites for Configuring EST

1) Number of physical NIC’s = no of VLANs connected to ESX

2) The physical switch port connecting the uplink from the ESX should be configured as Access port assigned to specific VLAN.

Virtual Switch Tagging (VST) – In this mode, VLANs are configured on port groups of the virtual switch. The vNIC of the virtual machine is then connected to the appropriate port group. The virtual switch port group tags all outbound frames and removes tags for all inbound frames.

This approach reduces the number of Physical NIC’s on the server by running all the VLANs over one physical NIC. Since less physical NIC’s are used, it also reduces the number of cables from Esxi host to physical switch.

Best practice is to use NIC teaming and keep 2 NIC’s for redundancy.

Prerequisite for configuring VGT

The physical switch port connecting the uplink from the ESX should be configured as Trunk port.

VST mode is the one that is most commonly used for configuring VLANs in vSphere because it’s easier to configure and manage. It also eliminates the need to install a specific VLAN driver inside a virtual machine, and there is almost no performance impact from doing the tagging inside the virtual switches.

You can consult the below table to determine which will be the best tagging policy in your environment:


Graphics Thanks to http://www.vmwarearena.com/

Posted in Vmware | 3 Comments

Advanced Configuration options for VMware HA

In this post I am going to cover a few advance settings in HA which you can be used in deploying complex HA solutions. You may or may not be using these advance value in your environment but sometimes you have to use these values depending upon how your virtualization infrastructure is laid.

1: das.isolationaddress: – By default the IP address used to check host isolation is the default gateway of the VMkernel port on the host. You can add more IP addresses for the host to use during an isolation check. A total of 10 addresses can be used (0-9).

For setting up this value Select Cluster > Edit Settings > vSphere HA > Advanced Options



2: das.usedefaultisolationaddress:– this option has 2 values: True or False. When set to false a host will NOT use the default gateway as an isolation address. This may be useful when the default gateway of your host is an unpingable address, or a virtual machine, such as a virtual firewall


3: das.isolationShutdownTimeout:– use this option to specify the amount of time (in seconds) it will wait for a guest shutdown process that was initiating by invoking the isolation response, before HA will forcefully power off a virtual machine.

4: das.heartbeatDsPerHost:— set this to the number heartbeat datastores you want to use. If you have a need to configure more than two heartbeat datastores per host you can used this advanced setting. The value range of this setting is 2-5.

Create a custom slot size configuration

By default HA will take the largest CPU and memory reservation of virtual machines in a cluster to determine Slot size for the cluster/hosts. But we can force HA to use user defined value of CPU and memory to calculate slot size. There are two advanced settings that you can configure in order to create a custom slot size; one for CPU and one for memory

das.slotCpuInMHz : The value of CPU slot size in MHz.

das.slotMemInMB : Value of memory slot size in MB.

These advanced setting “das.slotCpuInMHz “and “das.slotMemInMB” allow you to specify an upper boundary for your slot size. If you have large reservations set on only a few VM’s it can cause setting large slot size and will waste resources in your cluster as most of your VM’s will be running without any reservation.

For e.g: When one of your VMs has an 8GB reservation this setting can be used to define for instance an upper boundary of 1 GB to avoid resource wastage and an overly conservative slot size.

Important Note: If the highest CPU and memory reservation is below the value as specified in advance settings, then HA will take the value which is minimum.


5 das.ignoreinsufficienthbdatastore:– Disables configuration issues created if the host does not have sufficient heartbeat datastores for vSphere HA. Default value is false.

6: das.vmCpuMinMHz:– Min amount of CPU that is guaranteed to a VM when that VM is failed over (restarted) after a host failure. If CPU reservation is set on a VM then this value wont work for that VM, but will work for those VM’s which have 0 MHz reservation set.

7 :das.vmMemoryMinMB:- Min amount of memory that is guaranteed to a VM when that VM is failed over (restarted) after a host failure. If Memory reservation is set on a VM then this value wont work for that VM, but will work for those VM’s which have 0 MB  reservation set.

The above 2 values are used with “Percentage Based Admission Control”

Posted in Vmware | Leave a comment

VMware vSphere 6.0 — What’s New?

vSphere 6.0 public beta has been released several months ago and in 2014 VMworld conference some of the new features have been announced. Due to NDA all the features were not disclosed. 

Multi-CPU Fault Tolerance

FT is going to support VM’s with 4 vCPUs and 64GB of RAM. A new feature called fast checkpointing uses a  mechanism to keep primary and secondary VMs in sync. The Record/Replay technology that was previously used is replaced by  Fast checkpointing in vSphere 6.0

 vMotion Enhancements
Earlier upto vSphere 5.5, vMotion was limited to the vCenter/Datacenter boundary but now in vSphere 6.0 vMotion can migrate Virtual Machines across vCenters, virtual switches and routed networks.

Virtual Datacenters
vSphere 6.0 goes one step further than resource Pools. A Virtual Datacenter aggregates CPU, Memory, Storage and Network resources.

vCenter Server Appliance (VCSA)

The VCSA has also been beefed up. With 5.1 you could manage 100 hosts and 3000 powered on VMs. vSphere 6 now allows 1000 hosts and 10,000 powered on VMs. Still Oracle is the only external database supported.

 vSphere Client

VMware has decided to keep on the VI Client for one more release, vSphere 6.0. After that they say it will definitely be gone. Although the Web Client continues to progress and speed up, customer feedback has been that they would like to continue to use the familiar older client for now. No new functionality is being added to the C# Client so although it will be supported, it is only able to manage an ever decreasing subset of vSphere functionality.

Content Library

A way to centrally store VM templates, vApps, ISO images and scripts. The function is similar to the Content Library of vCAC. Content Library’s are replicated over vCenter Server instances. The advantage is a central managed repository preventing for instance severalcopies of  templates of the same guest OS.

Posted in Vmware | 1 Comment

Replace Esxi host default certificate with CA-Signed Certificate

A default certificate is generated automatically for the ESXi host during installation. Because the certificate for the ESXi host was self-generated, it has not been signed and will not be given a trusted status when attempting to communicate with other servers and clients. Other network devices might not allow communication with the ESXi host until it is certified by a well-known CA. X.509 certificates are supported over SSL connections for the encrypted session.

NOTE: When replacing the default certificate of the ESXi host, if the vCenter Server stops managing the host, check whether the ESXi host has Verify Certificates enabled. If this is the case, reconnect the ESXi host to the vCenter Server using the vSphere Client.

The steps to add a CA-signed certificate are as follows:

Step 1. Log in to the ESXi host over SSH using Putty.

Step 2. Change the directories to /etc/vmware/ssl, and backup the certificate files:

# mv rui.crt rui.cert.orig

# mv rui.key rui.key.orig

Step 3. Go to the location where the new authenticated certificate rui.crt and key file rui.key are located and copy the certificate files to the directory /etc/vmware/ssl.

Step 4. Either restart the services using

# services.sh restart

or reboot the ESXi host.

Posted in Vmware | Leave a comment

Generate ESXi Host Certificates

VMware use standard X.509 version 3 certificates to encrypt session information sent over Secure Socket Layer protocol connections between the client and the server.

If you want to replace default certificates for vCenter Server and ESXi , the certificates you obtain for your servers must be signed and must conform to the Privacy Enhanced Mail (PEM) key format. The key used to sign certificates must be a standard RSA key with an encryption length that ranges from 512 to 4,096 bits. The recommended length is 2,048 bits.

Certificates signed by a commercial certificate authority, such as Entrust or VeriSign, are pre-trusted on the Windows operating system. However, if you replace a certificate with one signed by your own local root CA, or if you plan to continue using a default certificate, you must pre-trust the certificate by importing it into the local certificate store for each vSphere Client instance.

Certificate files located on an ESXi host are

  • Private key file: /etc/vmware/ssl/rui.key
  • Certification file: /etc/vmware/ssl/rui.crt

NOTE Use commercially signed certificates for systems that are exposed to the Internet.

When you replace default server certificates in a production environment, deploy the new certificates in stages, rather than all at the same time.

You will need to generate a new certificate if the ESXi host or vCenter Server certificate gets deleted, or if you change the hostname of the system. These would be the most common reasons to generate a new SSL certificate.

The steps to generate a new ESXi host certificate are detailed here:

Step 1. Log in to the ESXi shell as the root user.

Step 2. Back up any existing certificates, just in case.

# mv /etc/vmware/ssl/rui.crt /etc/vmware/ssl/rui.crt.old

# mv /etc/vmware/ssl/rui.key /etc/vmware/ssl/rui.key.old

NOTE: If the rui.crt and rui.key files do not exist then you do not need to back them up; you can just go to the next step.

Step 3. Generate the new certificates:

# /sbin/generate-certificates

Step 4. Reboot the ESXi host or restart the hostd process:

# /etc/init.d/hostd/restart

Posted in Vmware | Leave a comment

2014 in review

The WordPress.com stats helper monkeys prepared a 2014 annual report for this blog.

Here’s an excerpt:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 35,000 times in 2014. If it were a concert at Sydney Opera House, it would take about 13 sold-out performances for that many people to see it.

Click here to see the complete report.

Posted in Vmware | Leave a comment

Happy New Year 2015

Wish all my friends and their families a very Happy New Year 2015. Last year was amazing and time has flown by so quickly. I am glad that I met some wonderful guys in this journey.

I have received a lot of love and care from you guys who visit this blog and gain/exchange some knowledge. Continue your passion of learning something new everyday and keep challenging yourself every time. This year will again be fully loaded with lot of posts to share the knowledge which I acquire.

This year I will be concentrating more towards some advance level things in VMware vSphere as I am preparing for advance level exams now and learning some pretty good stuff. However you guys can write me anytime if you want a detailed post on any topic in vSphere.

Also I have planned to learn other VMware products such as Horizon View, Log Insight and vRealize Operations Manager. Currently learning Cisco UCS and Nexus also and will share some posts on these technologies soon. Stay tuned for latest updates.


Posted in Vmware | Leave a comment

Hardening Virtual Machines

By design, virtual machines (VMs) are isolated from other virtual machines. Part of the hardening process for each VM is to look at the security guidelines of the guest operating system for the VM.

Each VM has a .vmx file which is the main configuration file of a Virtual Machine. This file governs the behavior of the virtual hardware and contains many settings for the VM. There are two ways to view the parameters and values for the VM.

One way to view the config file, which is an .ascii file, is from a command line. In a Putty session, go to the directory containing the VM files:

# cd /vmfs/volumes/[storage]/[vm_name]/

[ storage] = the current datastore for the VM

[vm_name] = the name of the VM

Next, run a command ls to see the files in the VM’s encapsulated directory.

Now using command-line tools such as the vi editor, you can modify the VM’s .vmx config file. You can also use the vSphere Client to make additions or modifications to the VM’s configuration. You must restart the VM for most changes to take effect when you modify VM settings using this method.

Configuration settings can also be changed using the vSphere Client. Login to vCenter server or Esxi server and select the VM in question, right-click, and select Edit Settings > Options > General > Configuration Parameters (see below figure)


Limiting the Number of Consoles for the VM

By default, remote console sessions to a VM can be connected to by more than one user at a time. If an administrator is doing something from remote console, a non-administrator in the VM could connect to the console during the session and observe the administrator’s actions. Thus, to limit the number of entry points to a VM to a single point, you need to apply a security setting by adding the following line to the VM’s config file:


This will limit the number of simultaneous console connection to 1.

Prevent Virtual Disk Shrinking

The shrinking of a virtual disk reclaims space in the virtual disk. If this process is done repeatedly, the virtual disk can become unavailable and cause a denial of service. To prevent shrinking of virtual disks for a VM add the below values in its .vmx file.



If these values are set to true in the VM’s config file, the administrator cannot shrink the disk:

Restrict Copy and Paste to a Remote Console from the Clipboard

After you install VMware tools into a VM, you have the ability to copy and paste between the guest operating system and the computer where the remote console is running. VMware recommends that you keep the copy-and-paste ability to the VM disabled.Enter the following values in Virtual machine config file to restrict copy paste:



This is disabled by default since vSphere 4.1.

Control Virtual Hardware Usage

Non-root users and processes within VMs have the ability to connect or disconnect devices, such as CD-ROM drives or a USB controller. One way to disable the virtual hardware is to simply remove the device from the VM. However, if you do not want to remove the device but still want to prevent a user or process from connecting to the device within the guest operating system, you can add these lines to the VM .vmx config file:



Restrict the VMCI Interface

The Virtual Machine Communication Interface (VMCI) is designed to allow communication from VM to VM. The main objective of VMCI was to provide a socket based framework for a new generation of applications that will exist only on VMs. If VMCI is compromised, one VM could be used to attack another VM, so this value should be disabled, which is the default.

To display the status of VMCI, highlight the ESXi host, right-click the mouse, and select Edit Properties. The Virtual Machine Properties window displays, as shown in Figure 8-14. The Hardware tab lists all the hardware devices including the VMCI device, which is currently in the state of Unrestricted or disabled. See the below figure where VMCI is enabled:


Posted in Vmware | Leave a comment

Unmount Datastore RDM Luns with IScsi Session Deactivation

We will be using both storage adapter and storage contexts to identify and unmount an RDM.

Important Note: The RDM must be deleted from VM prior to this procedure.


Goto configuration->storage

Identify the lun path by matching the label in the runtime name and noting the controller, target and lun C1:T17:L0


Also verify the naa identifier for the lun for an extra sanity check.


Goto storage tab to view all datastores.


However RDM will not appear in the datastore tab. To see RDM switch to the devices tab.


Select the RDM and right click and select detach from the option.

A dialog box will appear. Hit OK if you are sure that you select the correct entity to be removed.


You can view the detach task progress in the task bar.


The storage devices window will show the device as unmounted and the path disabled.



These systems are using the round robin persistent storage path. The secondary device does not allow the method shown above to unmount the lun. The path shows in the storage adapter device and path list but not under storage. For all datastores only the first path is shown.

So to unmount the LUN from all device use the command line.

# esxcli storage nmp path list -d naa.6000eb38e8fb49de00000000000002a0


Runtime Name: vmhba37:C0:T17:L0

Device: naa.6000eb38e8fb49de00000000000002a0

Device Display Name: LEFTHAND iSCSI Disk (naa.6000eb38e8fb49de00000000000002a0)

Group State: off

Array Priority: 0

Storage Array Type Path Config: SATP VMW_SATP_DEFAULT_AA does not support path configuration.

Path Selection Policy Path Config: {current: no; preferred: no}


Runtime Name: vmhba37:C1:T17:L0

Device: naa.6000eb38e8fb49de00000000000002a0

Device Display Name: LEFTHAND iSCSI Disk (naa.6000eb38e8fb49de00000000000002a0)

Group State: active

Array Priority: 0

Storage Array Type Path Config: SATP VMW_SATP_DEFAULT_AA does not support path configuration.

Path Selection Policy Path Config: {current: yes; preferred: yes}

# esxcli storage core device set –state=off -d naa.6000eb38e8fb49de00000000000002a0

Problem still persists. We are unable to disable path. When “esxcli storage core device detached lists” command is used it returned the following:

# esxcli storage core device detached list                                         

Device UID                                                                            State

————————————  —————————

naa.6000eb38e8fb49de00000000000002a0              off

On trying from GUI itself following error was encountered:


Finally after doing some googling I came to find out we have to remove iscsi session.

# esxcli iscsi session list –name=iqn.2003-10.com.lefthandnetworks:vmgroup1:672:nusaldb02 –adapter=vmhba37


Adapter: vmhba37

Target: iqn.2003-10.com.lefthandnetworks:vmgroup1:672:nusaldb02

ISID: 00023d000001

TargetPortalGroupTag: 1

AuthenticationMethod: none

DataPduInOrder: true

DataSequenceInOrder: true

DefaultTime2Retain: 0

DefaultTime2Wait: 2

ErrorRecoveryLevel: 0

FirstBurstLength: 262144

ImmediateData: true

InitialR2T: false

MaxBurstLength: 262144

MaxConnections: 1

MaxOutstandingR2T: 1

TSIH: 103


Adapter: vmhba37

Target: iqn.2003-10.com.lefthandnetworks:vmgroup1:672:nusaldb02

ISID: 00023d000002

TargetPortalGroupTag: 1

AuthenticationMethod: none

DataPduInOrder: true

DataSequenceInOrder: true

DefaultTime2Retain: 0

DefaultTime2Wait: 2

ErrorRecoveryLevel: 0

FirstBurstLength: 262144

ImmediateData: true

InitialR2T: false

MaxBurstLength: 262144

MaxConnections: 1

MaxOutstandingR2T: 1

TSIH: 102

# esxcli iscsi session remove –name=iqn.2003-10.com.lefthandnetworks:vmgroup1:672:nusaldb02 –adapter=vmhba37

# esxcli iscsi session list –name=iqn.2003-10.com.lefthandnetworks:vmgroup1:672:nusaldb02 –adapter=vmhba37

# esxcli storage core device detached list

Device UID                            State

————————————  —–

naa.6000eb38e8fb49de00000000000002a0  off

Now one path is off the other dead

# esxcli storage nmp path list -d naa.6000eb38e8fb49de00000000000002a0


Runtime Name: vmhba37:C0:T17:L0

Device: naa.6000eb38e8fb49de00000000000002a0

Device Display Name: LEFTHAND iSCSI Disk (naa.6000eb38e8fb49de00000000000002a0)

Group State: off

Array Priority: 0

Storage Array Type Path Config: SATP VMW_SATP_DEFAULT_AA does not support path configuration.

Path Selection Policy Path Config: PSP VMW_PSP_RR does not support path configuration.


Runtime Name: vmhba37:C1:T17:L0

Device: naa.6000eb38e8fb49de00000000000002a0

Device Display Name: LEFTHAND iSCSI Disk (naa.6000eb38e8fb49de00000000000002a0)

Group State: dead

Array Priority: 0

Storage Array Type Path Config: SATP VMW_SATP_DEFAULT_AA does not support path configuration.

Path Selection Policy Path Config: PSP VMW_PSP_RR does not support path configuration.

Posted in Vmware | Leave a comment

A general system error occurred: internal error: vim.fault.InvalidLogin

A general system error occurred: internal error: vim.fault.InvalidLogin

When trying to reconnect a vCenter Managed ESXi Host, you receive the following message

A general system error occurred: internal error: vim.fault.InvalidLogin

There’s an easy fix to this issue.

Note: The following fix is not valid if you have enabled lockdown mode for your Esxi server.

  • Connect directly to the ESXi server with the vSphere Client,
  • Under Configuration Tab find and pick Security Profile.
  • Select Properties
  • Select VMware VirtualCenter Agent
  • Button Options
  • Press Stop
  • Start a Session to your vCenter Server with the vSphere Client
  • Try Reconnecting Host.

vCenter Server doesn’t find VirtualCenter Agent running on Esxi and deploys a new agent to server when it is reconnected in vCenter.

Posted in Vmware | Leave a comment

Connections and Ports in Esxi 5.x

Posted in Vmware | Leave a comment

Common system management issues in VMware Infrastructure

Troubleshooting the VMware VirtualCenter Server service when it does not start or fails
Stopping, starting, or restarting the VirtualCenter Server service
Troubleshooting the database data source used by VirtualCenter Server
Determining if a port is in use
Investigating the health of a VirtualCenter database server
Investigating Active Directory when it causes the VirtualCenter Server to stop or fail to start
Overview of migration compatibility error messages
Troubleshooting VMotion CPU feature requirement error messages
Diagnosing why VirtualCenter is not sending email alerts
Testing network connectivity with the Ping command
Diagnosing an ESX Server that is Disconnected or Not Responding in VirtualCenter
Changing an ESX Server’s connection status in VirtualCenter
Testing network connectivity with the Ping command
Testing port connectivity with the Telnet command
Verifying that the Management Service is running on an ESX host
Verifying that the VirtualCenter Agent Service is running on an ESX host
Restarting the Management agents on an ESX Server
Checking for resource starvation of the ESX Server service console
Diagnosing slow deployment of templates or clones from VirtualCenter
Troubleshooting slow template deployment on a single template
Checking for resource starvation of the ESX Server service console
Configuring the speed and duplex of an ESX Server host network adapter
Troubleshooting template deployment or cloning when it fails
Determining the correct version of sysprep to use
Ensuring VirtualCenter Server is the only VMware product installed on host
Ensuring the guest operating system type is set correctly
Diagnosing the Virtual Infrastructure Client when it fails to connect to an ESX host
Testing network connectivity with the Ping command
Verifying that the Management Service is running on an ESX host
Testing port connectivity with the Telnet command
Troubleshooting permissions errors when connecting to an ESX Server host with the Virtual Infrastructure client
Diagnosing the Virtual Infrastructure Client when it fails to connect to VirtualCenter
Testing network connectivity with the Ping command
Stopping, starting, or restarting the VirtualCenter Server service
Testing port connectivity with the Telnet command
Troubleshooting the VMware ESX Server Management Service when it will not start
Restarting the ESX Server Management service
Investigating disk space on an ESX host
Troubleshooting the firewall policy on an ESX Server
Checking for resource starvation of the ESX Server service console
Unable to connect to an ESX Server host using Secure Shell (SSH)
Testing network connectivity with the Ping command
Verifying that the Secure Shell Daemon is running on an ESX Server host
Enabling Root SSH Logins on ESX Server 3
Configuring the ESX Server host firewall for SSH
Testing port connectivity with the Telnet command
Diagnosing a VMware High Availability cluster configuration failure
Verifying a feature is licensed
Identifying issues with and setting up name resolution on ESX Server
Configuring name resolution for VMware VirtualCenter
Testing network connectivity with the Ping command
Verifying and reinstalling the correct version of VMware VirtualCenter Server agent
Diagnosing VMware VMotion failure at 10%
Unable to set VMkernel gateway as there are no VMkernel interfaces on the same network
Testing VMkernel network connectivity with the vmkping command
Testing network connectivity with the Ping command
Identifying issues with and setting up name resolution on ESX Server
Verifying time synchronization across environment
VMware VMotion fails if target host does not meet reservation requirements
Checking for resource starvation of the ESX Server service console
Troubleshooting migration compatibility error: Device is a connected device with a remote backing
Troubleshooting Virtual Machine loses network connection after VMware Vmotion
Testing network connectivity with the Ping command
Port security on the physical switch causes a loss of network connectivity
Diagnosing VMware VMotion failure at 90-95%
Restarting the Management agents on an ESX Server
Verifying time synchronization across environment
VMware VMotion fails if target host does not meet reservation requirements
Checking for resource starvation of the ESX Server service console
Identifying shared storage issues with ESX 3.x

Common Fault issues in VMware Infrastructure

Dealing with an unresponsive virtual machine
Confirming a virtual machine is unresponsive
Locating a virtual machine log files on an ESX host
Can’t stop or kill virtual machine
Identifying causes of not being able to power cycle ESX Server virtual machines
Ensuring a virtual machine is not inaccessible due to a VMware VirtualCenter issue
Troubleshooting a virtual machine that has become unresponsive because of an ESX host
Troubleshooting a virtual machine that is unresponsive because of configuration issues
Dealing with unresponsive guest OS issues
Ensuring a virtual machine is not inaccessible due to a VMware VirtualCenter issue
Stopping, starting, or restarting the VirtualCenter Server service
Virtual machine stops responding in a Power On state in VirtualCenter
Cannot Power on Virtual Machines, “Not enough licenses installed to perform operation” Error Message
Vmware VirtualCenter console displays handshake error.
Troubleshooting a virtual machine that has become unresponsive because of an ESX host
Verifying that ESX virtual machine storage is accessible
ESX Server virtual machines stop responding due to shared storage connectivity issues
Verifying sufficient free disk space for an ESX virtual machine
Investigating disk space on an ESX host
Identifying shared storage issues with ESX 3.x
Server stops responding and shows errors on a purple screen
Virtual machine does not power on because of missing or locked files
Ensuring your hardware is functioning correctly
[Internal] Third Party System Management agents in the Service Console
Troubleshooting a virtual machine that is unresponsive because of configuration issues
Troubleshooting a virtual machine that stops responding or fails when the CD-ROM entry is ATAPI
Virtual machine does not power on and there is high CPU reservation
Virtual machine stops responding during backup
Why snapshot removal can stop a virtual machine virtual machine for long time
Guest stops responding after connecting a USB CD-ROM
Dealing with unresponsive guest OS issues
Investigating operating system disk space
Do not use guest OS performance tools to monitor virtual machine performance
Using Windows Event Viewer to identify the cause of an unresponsive or failed virtual machine
Unable to shutdown Windows using Shutdown Guest option

Common Network issues in VMware Infrastructure

Network adapter does not appear in the Virtual Infrastructure Client
ESX Server host network adapter compatibility
Verifying the integrity of the physical network adapter
Troubleshooting a virtual machine that has no network connectivity
Verifying virtual network adapter is present and connected to the virtual machine
Verifying the networking within the guest operating system
IPSec within a Windows virtual machine
Network cable of a virtual machine appears unplugged
NIC team failover, failback, or VMotion results in loss of network connectivity
ESX Server host network adapter compatibility
Network performance issues
NIC teaming in ESX Server
Configuring promiscuous mode on a virtual switch or portgroup
Choosing a Network Adapter for Your Virtual Machine
ESX Server host or virtual machines have intermittent or no network connectivity
Verifying ESX Server hardware (System, Storage, and I/O) devices are supported
Verifying a network link
Configuring a VLAN on a portgroup
ESX Server Requirements for Link Aggregation
Configuring the speed and duplex of an ESX Server host network adapter
Verifying ESX Server host networking configuration on the service console
Port security on the physical switch causes a loss of network connectivity
Spanning tree protocol (STP) in an ESX Server environment
Verifying the integrity of the physical network adapter
Configuring VLANs in an ESX Server environment
Sample configuration of external switch VLAN tagging (EST Mode) and ESX Server
Sample configuration of virtual switch VLAN tagging (VST Mode) and ESX Server
Sample configuration of Virtual Guest VLAN Tagging (VGT Mode) on ESX server
Posted in Vmware | 1 Comment

SDRS Interview Questions

Ques 1: Can 2 datastores that are part of two differ datacenters be added to a datastore cluster?

Ans: No we can’t add datastores in a datastore cluster that are part of 2 different datacenters.

Ques 2: Can we add new datastores to a datastore cluster without incurring any downtime?

Ans: Yes we can add new datastores in a datastore cluster without having any downtime.

Ques 3: If a datastore is space utilization is above the configured threshold then is the initial placement of a new VM is possible on such datastore?

Ans: Yes initial placement is possible on datastore which has already crossed the utilization threshold if it is capable of storing the new VM. Initial placement is always a manual process and you will be prompted to select datastore out of a datastore cluster while creating a new VM or migrating a VM from a datastore which is not part of the datastore cluster onto a datastore which is part of the datastore cluster.

Ques 4: What are prerequisite migrations in terms of SDRS?

Ans: The set of migration recommendations generated by SDRS for existing VM’s before initial placement of a new VM are called pre-requisite migrations.

Ques 5: What is meant by Datastore cluster defragmentation?

Ans: When there is enough free space available at datastore cluster level but not enough space available per datastore for accommodating a new incoming VM then the datastore cluster is said to be defragmented. To place a new VM, SDRS will migrate existing VM’s from one datastore to other to free up enough space on a single datastore which can hold the newly created VM.

Ques 6: What is space utilization ratio difference and what is its default value? What is the purpose of defining space utilization ratio difference?

Ans: To avoid unnecessary migrations from one overloaded datastore to a datastore which is near the configured threshold, SDRS uses the space utilization ratio difference to determine which datastores should be considered as destinations for virtual machine migration.

By default the value is set to 5%. It means when there is a difference of 5% space utilization between 2 datastores then only a VM will be migrated from the datastore which is heavily loaded to other datastore which is less loaded.

Ques 7: Why migrations of powered-off VM is preferred by SDRS for load balancing a datastore cluster?

Ans: Migration of powered off VM is preferred by SDRS because there will be no changes going in the VM at the time of migration and SDRS don’t have to track which blocks have changed inside the VMDK of the VM when migration was going on.

Note: If swap file of VM is stored at user defined location and not inside the VM directory then SDRS will leave swap files untouched during migration of that VM.

Ques 8: What is VM.Observed.Latency in terms of SDRS?

Ans: It is the time elapsed between when a VM send I/O request and Esxi capturing that request and getting back response from the datastore.

Note: In vSphere 5.0 SDRS was only considering the time elapsed between an I/O request leaving Esxi and response coming back from datastore but in vSphere 5.1 the time is calculated right after an I/O request generated by VM and leaving it.

Ques 9: What is meant by “Performance Correlated Datastores”? How it affects SDRS in generating migrations recommendations?

Ans: Performance related datastores are those datastores that share same backend resources such as same disk group or same RAID group on storage array. By default SDRS will avoid migration recommendations for a VM between 2 performance correlated datastores because if one datastore is experiencing high latency then there might be chances that the other datastore carved out of same disk group or RAID group might experience same latency.

Note: in vSphere 5.0 SDRS was dependent on VASA to identify performance correlated datastores but in vSphere 5.1 SRDS leverages SIOC for the same.

Ques 10: What is default invocation period for SDRS and why it is not invoked at default time value for first time when SDRS is enabled on a datastore cluster?

Ans: The default invocation period for SDRS is 8 hours. But SDRS will not be invoked in 8 hours when first time it is enabled on a datastore cluster because it requires atleast 16 hours of historical data to make any space or I/O related migration recommendations. When 16 hours has been elapsed and SDRS have some data with it then it will be invoked after every 8 hours from then but will always analyze data from last 16 hours.

Ques 11: What are the different conditions under which SDRS is invoked?

Ans: Following can be the situations when SDRS will be invoked:

  • A datastore entering in maintenance mode.
  • A new datastore is added to datastore cluster.
  • A datastore exceeds its configured threshold.
  • During initial placement of a VM.
  • When SDRS is invoked manually by administrator
  • Datastore cluster configuration is updated.

Ques 12: How does Esxi hosts in a cluster learns what latency is observed by other Esxi hosts on a given datastore?

Ans: On each datastore a file named “iormstats.sf” is created and is shared among each Esxi connected to that datastore. Every Esxi host periodically writes its average latency and number of I/O for that datastore in this file. Each Esxi host read this file and calculates datastore wide average latency.

Ques 13: How to enable SIOC logging and how we can monitor SIOC logs?

Ans: SIOC logging can be enabled by editing the advance settings in vCenter server. You have to set the value of Misc.SIOCControlLogLevel parameter to 7.

Note: SIOC needs to be restarted to change the log level and it can be restarted by logging into Esxi host and use command /etc/init.d/StorageRM restart.

Ques 14: If someone has changed the SIOC log level then which file you will consult to find out so?

Ans: When log level of SIOC has been changed, this event is logged into /var/log/vmkernel log file.

Ques 15: Why it is not considered to be a best practice to group together datastores coming from different storage arrays in a single datastore cluster?

Ans: When datastores from different type of storage arrays are grouped together in a datastore cluster then performance of a VM varies on these datastores. Also SDRS will be unable to leverage VAAI offloading during VM migration between 2 datastores that are part of different storage arrays.

Ques 16: How SDRS is affected if extended datastores are used in a datastore cluster?

Ans: Extents are used to extend a datastore size but we should not use extended datastores in datastore cluster because SDRS disables I/O load balancing for such datastores. Also SIOC will be disabled on that datastore.

Ques 17: Can we migrate VM’s with independent disks using SDRS? If yes then how and if no then why?

Ans: By default SDRS doesn’t migrate VM’s with independent disks. This behavior can be changed by adding an entry “sdrs.disableSDRSonIndependentDisks” and set it value to false.

Note: This will work only for non-shared independent disks. Moving shared independent disks is not supported by SDRS.

Ques 18: How SDRS computes space requirement for thin provisioned VM’s?

Ans: For a thin provisioned VM, SDRS considers the allocated disk size instead of provisioned size for generating migration recommendation. When determining placement of a virtual machine, Storage DRS verifies the disk usage of the files stored on the datastore. To avoid getting caught out by instant data growth of the existing thin disk VMDKs, Storage DRS adds a buffer space to each thin disk. This buffer zone is determined by the advanced setting “PercentIdleMBinSpaceDemand”.

This setting controls how conservative Storage DRS is with determining the available space on the datastore for load balancing and initial placement operations of virtual machines.

SRDS will analyze data growth rate inside a thin provisioned VM and if it is very high, then SDRS attempts to avoid migrating such VM on datastores where it can cause exceed in space utilization threshold of that datastore in near future.

For more info follow the link


Ques 19: What is mirror drivers and how it works?

Ans: Mirror driver is used by SDRS to track the block changes in VMDK of a VM when storage migration of that VM was going on. During migration if some write operations are generated then mirror driver will commit these disk writes in both source and destination machine.

Mirror driver work at VMkernel level and uses Datamover to migrate VM disks from one datastore to other. Before mirror driver is enabled for a VM, VM is first stunned and then unstunned after enabling of mirror driver. Datamover uses “single pass block” copy of disks from source to destination datastore.

Ques 20: What are the types of datamovers which can be used by SDRS?

Ans: There are 3 types of datamovers which is used by SRDS:

  • Fsdm: This the legacy 3.0 datamover present in Esxi host. It is the slowest of all.
  • Fs3dm: This is the datamover which was introduced in vSphere 4.0. It is faster than legacy 3.0 datamover.
  • Fs3dm-hardware offload: This was introduced in vSphere 4.1 and it is the fastest datamover among all three. It leverages VAAI to offload disk migration task between to 2 datastores.

Ques 21: Why it is recommended to avoid mixing datastores with different block size in a datastore cluster? 

Ans: When the destination datastore is hosted on different storage array or has different block size as compared to source datastore then SDRS is forced to use “fsdm” datamover which is the slowest one.

Note: When source and destination datastore are from same storage array and have same block size, SDRS utilizes “fs3dm” datamover

When storage array has VAAI functionality and source and destination datastores are having same block size and are hosted on same storage array, SDRS used “fs3dm-hardware offload” datamover.

Ques 22: What are the enhancements that was made in SvMotion in vSphere 5.1 as compared to vSphere 5.0?

Ans: vSphere 5.1 allows 4 parallel disk copies/SvMotion process. Prior to vSphere 5.1 copying of disks were done serially. In 5.1 version, if a VM has 5 disks, then copy of first four disks will be done parallel and when copy of any of the disk out of 4 completes, 5th disk will be copied.

Ques 23: What is the max number of simultaneous SvMotion process associated with a datastore? How to change this value?

Ans: Max no of simultaneous SvMotion on a datastore is 8. This can be throttled by editing vpxd.cfg or from advance settings on vCenter server. In vpxd.cfg file modify the parameter “MaxCostPerEsx41DS”.

Ques 24: Why partially connected datastores should not be used in datastore cluster?

Ans: When a datastore cluster contains partially connected datastores, then I/O load balancing is disabled by SDRS on that datastore cluster. SDRS will do the load balancing only based on space utilization in such case.

Posted in Vmware | Leave a comment

Tracking VM Creation and Deletion events using PowerCLI

Below script is used to find the users who created or deleted the VM in the past 7 days.

Note: If you want to know the count for longer period then change the value of AddDays.

For VM creation

Get-VIEvent -MaxSamples ([int]::MaxValue) -Start (Get-Date).AddDays(-30) |

where {$_.Gettype().Name -eq “VmCreatedEvent” -or $_.Gettype().Name -eq “VmBeingClonedEvent” -or $_.Gettype().Name -eq “VmBeingDeployedEvent”} |

%{“{0} created by {1}” -f $_.VM.Name,$_.UserName}

 For VM Deletion

Get-VIEvent -MaxSamples ([int]::MaxValue) -Start (Get-Date).AddDays(-7) | where {$_.Gettype().Name -eq “VmRemovedEvent”} |  %{“{0} created by {1}” -f $_.VM.Name,$_.UserName}

Posted in PowerShell Scripts, Vmware | Leave a comment

vMotion Count using PowerCLI

Below script can help you to get the count of all vMotion events that has happened in the past 24 hrs.

If you want to calculate the count for longer period then change the number AddDays.

Get-VIEvent -Entity (Get-VM -Location $_) -MaxSamples ([int]::MaxValue) -Start (Get-Date).AddDays(-1) |
Where { $_.GetType().Name -eq “TaskEvent” -and $_.Info.DescriptionId -eq “VirtualMachine.migrate”} |
Measure-Object | Select-Object -ExpandProperty Count

Posted in PowerShell Scripts, Vmware | Leave a comment

Tracking SvMotion events with the help of PowerCLI

The Storage vMotion events can be tracked using the below script. You can use this script to the get the count of Storage vMotion events in the past 24 hrs.

Get-VIEvent -MaxSamples ([int]::MaxValue) -Start (Get-Date).AddDays(-1) |
Where { $_.GetType().Name -eq “TaskEvent” -and $_.Info.DescriptionId -eq “VirtualMachine.relocate” -or $_.Info.DescriptionId -eq “StorageResourceManager.applyRecommendation”} |
Measure-Object | Select-Object -ExpandProperty Count 

Posted in PowerShell Scripts, Vmware | Leave a comment

Multipathing and its Techniques

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. Multipathing provides:

  • Redundancy
  • Path Management (Failover)
  • Bandwidth Aggregation

Native Multipathing Plugin (NMP)

This is the default multipathing plugin which is provided by VMware and is included in Esxi server iso image. NMP has 2 sub-plugins:

  1. Storage Array Type Plugins (SATP): This plugin keeps information about all the available paths.
  2. Path Selection Policy (PSP): PSP defines which path will be selected based on the multipathing techniques used.

VMware SATPs

Storage Array Type Plug-Ins (SATPs) run in conjunction with the VMware NMP and are responsible for array specific operations. ESX/ESXi offers a SATP for every type of array that VMware supports. It also provides default SATPs that support non-specific active-active and ALUA storage arrays, and the local SATP for direct-attached devices.

Each SATP accommodates special characteristics of a certain class of storage arrays and can perform the array specific operations required to detect path state and to activate an inactive path. As a result, the NMP module itself can work with multiple storage arrays without having to be aware of the storage device specifics.

After the NMP determines which SATP to use for a specific storage device and associates the SATP with the physical paths for that storage device, the SATP implements the tasks that include the following:

  • Monitors the health of each physical path.
  • Reports changes in the state of each physical path.
  • Performs array-specific actions necessary for storage fail-over. For example, for active-passive devices, it can activate passive paths.

Important Note: When NMP is used then the Esxi host identifies the type of array by checking it against /etc/vmware/esx.conf file and then associates the SATP to that array based on the make and model of the array.

What does NMP do?

  • Manages physical path claiming and unclaiming.
  • Registers and de-registers logical devices.
  • Associates physical paths with logical devices.
  • Processes I/O requests to logical devices:
    • Selects an optimal physical path for the request (load balance)
    • Performs actions necessary to handle failures and request retries.
  • Supports management tasks such as abort or reset of logical devices.

We can also use 3rd party multipathing plugins which are provided by the storage vendors. Multiple third-party MPPs can run in parallel with the VMware NMP. When installed, the third-party MPPs replace the behavior of the NMP and take complete control of the path failover and the load-balancing operations for specified storage devices.

Pluggable Storage Architecture (PSA): PSA is a special VMkernel module which gives Esxi host the ability to use 3rd party multipathing software. Storage vendors provides their own multipathing plugins MPP which when installed on Esxi, works together with NMP so that failover and load balancing for that storage array can be optimized.

When coordinating the VMware NMP and any installed third-party MPPs, the PSA performs the following tasks:

  • Loads and unloads multipathing plug-ins.
  • Hides virtual machine specifics from a particular plug-in.
  • Routes I/O requests for a specific logical device to the MPP managing that device.
  • Handles I/O queuing to the logical devices.
  • Implements logical device bandwidth sharing between virtual machines.
  • Handles I/O queueing to the physical storage HBAs.
  • Handles physical path discovery and removal.
  • Provides logical device and physical path I/O statistics.

Multipathing Techniques: There are 3 main techniques of multipathing which is listed as below:

1: Most Recent Used (MRU): MRU selects the first working path which is discovered at the boot time. If the original path fails, the Esxi host switches to another alternative path and continues to use it unless it fails. If the original path which was discovered during boot times comes back online, Esxi host don’t failback on it.  MRU is used when LUN’s are presented from Active/Passive array.

2: Fixed: In this technique first working path (defined by administrator) is chosen at boot time. If the original path becomes unavailable or fails, Esxi host switches to another available path, but as soon as the original path comes back online again, Esxi host immediately fail back on that path. This technique is mostly used when LUN’s are presented from Active/Active storage array.

3: Round Robin: In Round Robin technique, Esxi host can use all available paths to connect to LUN’s and thus enables load distribution among the configured path. This technique can be used for both Active/Active and Active/Passive storage arrays.

  • For Active/Active arrays all the paths are used.
  • For Active/Passive, only those paths which are connecting to active controller, will be used.

Apart from these 3 techniques there is one more technique for multipathing which is discussed as below:

ALUA: Asymmetric arrays can process I/O request via both controllers at the same time, but each individual LUN is managed by a particular controller. If I/O request is received for a LUN via a controller other than its managing controller, then the traffic is proxied via it to the managing controller.

ALUA SATP plugin is used for asymmetric arrays. When an Esxi host is connected to ALUA capable array, the array can take advantage of the host knowing it has multiple storage processors and which paths are direct. This allow Esxi hosts to make better load balancing and failover decisions. There are 2 ALUA transition modes that an array can advertise:

  • Implicit: Array itself can assign and change managing controllers for each LUN.
  • Explicit: Here Esxi host can change LUN’s managing controller.
Posted in Vmware | Leave a comment

Virtual Machine Files Type

When you browse a VM folder on a datastore you find different types of files listed there . Each file has specific role in a VM functioning. We will learn here for which purpose which files are created. Typically you will find following types of files in a VM directory:

VMDK files – VMDK files names as (VMware Virtual Disk file) are the actual virtual hard drive for the virtual guest operation system. You can create dynamic or fixed virtual disks. With dynamic disks, the disks start small and grow as the disk inside the guest OS grows. With fixed disks, the virtual disk started out at the same (large) disk size decided initially while creating VM.

Log files – Log files are just that- a log of VM server activity for a single virtual server. Log files can be used only while doing any troubleshooting with a virtual machine. It can be more than 1 or 2 and modified each time while we Start, Suspend or reboot the Virtual Machine. 

VMX files – a VMX file is the primary configuration file for a virtual machine. When you create a new virtual machine and answer questions about the operating system, disk sizes, and networking, those answers are stored in this file. As you can see from the screenshot below, a VMX file is actually a simple text file that can be edited with Notepad.

VMEM – A VMEM file is a backup of the virtual machine’s paging file. It will only appear if the virtual machine is running, or if it has crashed.

VMSN files – these files are used for snapshots. A VMSN file is used to store the exact state of the virtual machine when the snapshot was taken. Using this snapshot, you can then restore your machine to the previous state as when the snapshot was taken.

VMSD files — A VMSD file stores information about snapshots metadata. You’ll notice that the names of these files match the names of the snapshots.

NVRAM files – These files are the BIOS for the virtual machine. The VM must know how many hard drives it has and other common BIOS settings. The NVRAM file is where that BIOS information is stored.

VMSS files – A VMSS file is VMware Suspended virtual machine state and it is created while you suspend any Virtual machine. It stores the information of the running application while suspending the machine.

VMXF Files – A VMXF file is VMware team member file which is created during creation of Virtual machine and its shows the information about the client MetaData Attributes & VMID.

Posted in Vmware | 2 Comments

VMware Compliance Checker

VMware’s free Compliance Checker for vSphere is a fully-functional product that provides detailed compliance checks against the VMware vSphere® Hardening Guidelines. For example, you can print Compliance Checker reports and run compliance checks across multiple ESX and ESXi servers at once.


VMware Compliance Checker can be downloaded from  Here

Key Features

Features of VMware Compliance Checker for vSphere:

  • Check compliance for multiple VMware ESX and ESXi servers concurrently — Run compliance check on up to five ESX or ESXi servers at a time and produce reports.
  • Supports VMware vSphere hardening guidelines — Perform checks on VMware ESX and ESXi servers to conform with the latest VMware vSphere hardening guidelines.
  • Roll up compliance assessment by benchmarks and by machines — After a compliance run, you can view the assessments by machines and by benchmark type.
  • Save and print assessment results — You can save, print and email the compliance assessment reports to your team for review and they can be saved for archival needs.
Posted in Vmware | Leave a comment

Registrations Opened for vExpert2015

The VMware vExpert program is VMware’s global evangelism and advocacy program. The program is designed to put VMware’s marketing resources towards your advocacy efforts. Promotion of your articles, exposure at our global events, co-op advertising, traffic analysis, and early access to beta programs and VMware’s roadmap. VMware will provide you with a unique vExpert id that will allow insights into analytics to help understand customer trends to assist you and keep your advocacy activities on track.

The awards are for individuals, not companies, and last for one year. Employees of both customers and partners can receive the awards. In the application, we consider activities from the previous year as well as the current year’s activities in determining who gets awards. We look to see that not only were you active but are still active in the path you chose to apply for.

Become a vExpert today and join the 3 million member customer ecosystem and amplify your efforts and ours. To apply read more information atblogs.vmware.com/vmtn/2014/11/vexpert-2015-applications-open.html

Application process

Here are the main steps from application to award announcement:

  • Application Path.Choose which path to becoming a vExpert most applies to you.
    • Evangelist Path. For book authors, bloggers, tool builders, public speakers, VMTN contributors, and other IT professionals who share their knowledge and passion with others with the leverage of a personal public platform to reach many people. Build up your presence in the social realm by maintaining a blog, speaking at events, writing white papers and books, participating in VMTN forums, etc. In general, we look for a sustained social presence in the previous year and current year.
    • Customer Path. For leaders from VMware customer organizations who have been internal champions in their organizations, worked with VMware to build success stories, act as a customer reference, given public interviews, spoken at conferences, or were VMUG leaders.
    • Partner Path. For employees of our partner companies who lead with passion and by example, who are committed to continuous learning through accreditations and certifications, and to making their technical knowledge and expertise available to many. VMware employee reference is required for this path.
  • Submit Application. Complete and submit your vExpert application. Be sure you have included all relevant information and links so that your application can be easily evaluated. Don’t be afraid to give us too much information. Please ready the full 2015 vExpert application announcement atblogs.vmware.com/vmtn/2014/11/vexpert-2015-applications-open.html
  • Application Review and Voting. All applications for the given time frame will be reviewed and voted on by the team corresponding to the application path selected (evangelist, partner, or customer).
  • Notification and Announcement. After the announcement a list of the individuals most recently awarded the title of vExpert will be posted in the vExpert forum and on the VMTN blog at blogs.vmware.com/vmtn on February 5th, 2015.
  • New vExperts will need to fill out the complete application and returning 2014 vExperts will only need to fill out the fastrack application.
Posted in Vmware | Leave a comment

How to install Spacewalk Server on Centos 6

Spacewalk is an open source Linux systems management solution. Spacewalk is the upstream community project from which the Red Hat Satellite product is derived.

Spacewalk manages software content updates for Red Hat derived distributions such as Fedora, CentOS, and Scientific Linux, within your firewall. You can stage software content through different environments, managing the deployment of updates to systems and allowing you to view at which update level any given system is at across your deployment. A central web interface allows viewing of systems, their associated software update status, and initiating update actions.

Additional Management Capabilities

Spacewalk provides provisioning and monitoring capabilities, allowing you to manage your systems throughout their lifecycle. Via Provisioning, Spacewalk enables you to kickstart provision systems and manage and deploy configuration files. The monitoring feature allows you to view the status off your systems alongside their software update status. Spacewalk also has virtualization capabilities to enable you to provision, control, manage, and monitor virtual KVM and Xen guests.

The supported database options are Postgres and Oracl, so in this case we are using Postgres. Follow the steps shown below to install Spacewalk Server on Centos 6

Download the spacewalk repo

[root@server]# wget http://spacewalk.redhat.com/yum/latest/RHEL/6/x86_64/spacewalk-repo-1.9-1.el6.noarch.rpm

Install the spacewalk repo

[root@server]# rpm –ivh spacewalk-repo-1.9-1.el6.noarch.rpm

Install the yum priorities plugin

[root@server ]# yum install yum-plugin-priorities

Install the rest of the required repo’s

[root@server]# rpm -Uvh http://mirrors.dotsrc.org/jpackage/5.0/generic/free/RPMS/jpackage-release-5-4.jpp5.noarch.rpm

[root@server]# rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

[root@server]# rpm -Uvh http://epel.mirror.net.in/epel/6/x86_64/epel-release-6-8.noarch.rpm

[root@server~]# rpm –ivh http://spacewalk.redhat.com/yum/1.7-client/RHEL/6/x86_64/spacewalk-client-repo-1.7-5.el6.noarch.rpm

Next you need to make a change to the jpackage repo

[root@server]# vim /etc/yum.repos.d/jpackage.repo

Look for the following section at the bottom


name=JPackage (free) for distro $releasever






You need to change the mirrorlist line so it looks like the following. The difference is the $releasever has been changed to 5.0


name=JPackage (free) for distro $releasever






Next Step is to Cleanup  YUM

[root@server]# yum clean all

Next install Postgres, set it to run on boot and run the initial configuration

[root@server~]# yum install postgresql postgresql-contrib postgresql-devel postgresql-server

[root@server~]# chkconfig postgresql on

[root@server~]# service postgresql initdb

[root@server~]# service postgresql start

 Create the database and user for Spacewalk

[root@server~]# su – postgres -c ‘PGPASSWORD=spacepw; createdb spacedb ; createlang plpgsql spacedb ; yes $PGPASSWORD | createuser -P -sDR spaceuser’

Now you need to configure the user to use an md5 password

[root@server~]# vim /var/lib/pgsql/data/pg_hba.conf

At the bottom of the config file you will see to following lines

# “local” is for Unix domain socket connections only

local                 all         all                                            ident

# IPv4 local connections:

host                 all         all               ident

# IPv6 local connections:

host                 all         all         ::1/128                        ident

Before those lines add the following:

local     spacedb           spaceuser         md5

host     spacedb           spaceuser      md5

host     spacedb           spaceuser         ::1/128             md5

local     spacedb           postgres           ident

Reload Postgres for the changes to take effect

[root@server~]# service postgresql reload

Now install Spacewalk. It will take some time on a minimal install it had to install over 400 dependencies.

[root@server~]# yum install spacewalk-postgresql

[root@server~]#  yum install spacewalk-setup-embedded-postgresql

Once it is installed run the Spacewalk setup

[root@server~]# spacewalk-setup –disconnected

You will first be prompted for the database information. Leave the location blank, the database is spacedb, the username is spaceuser and the password is spacepw

** Database: Setting up database connection for PostgreSQL backend.

Hostname (leave empty for local)?

Database? spacedb

Username? spaceuser

Password? spacepw

The rest you can use the defaults. The final step will be generating a SSL certificate, just enter your details as required

Access the web interface by going to https://IPADDRESS you will be prompted to create a user. Once done you are ready to start connecting client machines.

How to walk with spacewalk

Populate Spacewalk

The goal is to deploy a new machine with an os, this means the obvious next step is to populate spacewalk with a Red Hat derived Linux distribution of your choice.

First step is to mount the CentOS 6.1 iso’s somewhere on your spacewalk server. Make sure to get a full distro iso, this means that required directories like, for example, images/pxeboot do exist. The packages which belong to a distribution are administered in Spacewalk as software channels, so we first have to create a software channel before we can add/upload packages to it.

Create a new software channel by opening the spacewalk console and navigate to:

“Channels” -> “Manage Software Channels” -> “Create New Channel”

Enter a reasonable channel name (this is for display only, e.g: “CentOS 6.1 – 64 Bit”), a channel label (remember this name for later use,e.g: “centos6.1-x86_64″) and select the correct architecture (x86_64).

Next step is to populate spacewalk with the CentOS packages, this proces is started by issuing the following command:

rhnpush -v –channel=centos6.1-x86_64 –server=http://localhost –dir=/path/to/Packages

where “/path/to/Packages” is the absolute path of the Packages directory of the mounted iso.

CentOS 6.1 consists of two dvd’s, execute above step for both dvd’s.

The rhnpush process uploads all packages and registers them in spacewalk. On average, rhnpush processes packages at a rate of around 2000 packages per 30 minutes (ofcourse depending on the configuration of your host and vm). CentOS 6.1 contains almost 6200 packages so, it will take around one and a half hour to upload all packages from dvd1 and dvd2 to spacewalk.

The deployed linux system should to be able to connect to the spacewalk server and use it’s package and configuration management facilities it is recommended to include the spacewalk client packages in a spacewalk channel as well. Now we will upload the packages directly from the online repository into a child channel of the just created CentOS channel.

In the spacewalk console navigate to:

“Channels” -> “Manage Software Channels” -> “Create New Channel”

Enter a reasonable channel name ( e.g. : “Spacewalk Client 1.5 – el6 – 64 Bit”), a channel label (e.g.  “swclnt1.5-el6-x86_64″), the correct architecture (x86_64) and the correct parent channel (e.g. : “CentOS 6.1 – 64 Bit”).

Populating spacewalk with the spacewalk client packages directly from the online repository is started by issuing the following command:

spacewalk-repo-sync -c swclnt1.5-el6-x86_64 –url http://spacewalk.redhat.com/yum/1.5-client/RHEL/6/x86_64

The spacewalk client has a dependency on the python-hwdata-1.2-1.el6.noarch.rpm package from the epel repository. Download the python-hwdata-1.2-1.el6.noarch.rpm package from the epel repositor http://download.fedora.redhat.com/pub/epel/6/x86_64/

and upload it to the spacewalk client child channel using the command (assuming you downloaded the rpm to a folder named epel):

rhnpush -v –channel=swclnt1.5-el6-x86_64 –server=http://localhost -dir=epel

Create a distribution

For automating the installation of a Linux system a method called kickstart can be used. First, we have to setup a directory structure on the spacewalk server based on content of the CentOS dvd1 iso. From your CentOS 6.1 dvd1, copy the following directories:

  • images
  • isolinux
  • repodata


Next, open the spacewalk console and navigate to the following location:

systems -> kickstart -> distributions -> new distribution

Enter the following parameters for the new distribution:

  • Distribution label: centos6.1-x86_64
  • tree path: /var/distro-trees/centos6.1-x86_64
  • Base Channel: CentOS 6.1 – 64 Bit
  • Installer Generation: Red Hat Enterprise Linux 6

Next step is to create a kickstart profile for the channel and distribution. Open the spacewalk console and navigate to the following location:

systems -> kickstart -> create new kickstart profile

Enter the following parameters for the new kickstart profile:

  • Label: centos61-minimal
  • Base channel: CentOS 6.1 – 64 Bit
  • Kickstartable tree: centos6.1-x86_64
  • Virtualization type: none

To make sure the spacewalk client repository is used during kickstart, navigate to the following location:

systems -> kickstart -> profiles -> centos61-minimal -> operating system

Make sure the child channel swclnt1.5-el6-x86_64 is checked.

Also, have a look at the other tabs to have an idea of the configuration options which are available. Possible interesting area’s are:

  • Software: Adding extra packages or package groups in addition to the base installation. Add the package just by adding it on a new line, package groups can be added by an @-sign followed by the group name. A package can be excluded by an hyphen (-) followed by the package name
  • Kickstart details -> Details -> Kernel options: Adding and removing kernel options. You can add a kernel option, just by adding it’s key/value pair to the input field. Removal is done by just mentioning the kernel option preceded by an ! and giving it ~ as a value. For example, the value “!text=~ resolution=800×600″ in the kernel option box forces the use of the graphical installer (remove the text kernel option) and sets screen resolution to 800×600.
  • Kickstart details -> Advanced options: Allows detailed configuration of the kickstarted system. For example, to add an user,during installation, named weblogic with password weblogic01, tick the “user” checkbox and add the value “–name=weblogic –password=weblogic01 –plaintext” to the input field.
  • Kickstart details -> Variables: the usage of variables can be done by adding a key/value pair and refer to it in another tab. For example , to define the hostname during kickstart, add a key/value pair (hostname=appsrvr1) in the variables tab and refer to it in the Advanced options by adding “–hostname $hostname” to the network text box.

Let’s cobbler

Next step is to create an iso image to boot a new vm from.

Important note: In the next couple of steps we are going to deploy a new linux virtual machine. If the virtualization network setup supports a dns where the spacewalk server can be found by its hostname skip the next step.

In other words, your newly created vm must be able to find the spacewalk server using it’s hostname during boot/initial setup. If this is not the case or if you are unsure, please perform the following step to change the spacewalk hostname to its ip-address, if you are sure dns is in place you can skip this step:

In /etc/rhn/rhn.conf change the value of the parameter cobbler.host to the ip address of the spacewalk server.
In /etc/cobbler/settings change the value of the parameters server and redhat_management_server  to the ip-address of the spacewalk server.

On the spacewalk server, run the command (this only needs to be done once):

cobbler get-loaders

Next, start building the iso using the command:

cobbler buildiso

The result of the buildiso command is a file named generated.iso in the directory from where you issued the command.

Let’s kickstart

On your host, create a new virtual machine and provide it with the generated.iso file to boot from. Upon boot you will see a menu as shown below allowing you to specify the centos61-minimal setup to be installed.


Installation will take some time. After installation is finished we will configure this client to talk with spacewalk server.

Configuring spacewalk client

The following instructions are for configuring a Centos 6 box to talk to a Spacewalk server

Install the Spacewalk Client repo

[root@client~]# rpm -Uvh http://spacewalk.redhat.com/yum/1.7/RHEL/6/i386/spacewalk-client-repo-1.7-5.el6.noarch.rpm

Clean all the yum repos

[root@client~]# yum clean all

Install the required packages

[root@client~]# yum install rhn-client-tools rhn-check rhn-setup rhnsd m2crypto yum-rhn-plugin

Now you need to generate a activation key. The steps to do this are:

  1. Log into the Spacewalk web interface
  2. From the top navigation select Systems
  3. In the left navigation select Activation Keys
  4. In the top right hand corner click New Key
  5. Enter a name for this activation key and click Create Activation Key
  6. The activation key will then populate

On the client run the configuration tool. Replace the IP and activation key with those from your setup. Once done your computer will be visible in the list of systems in spacewalk.

[root@client~]# rhnreg_ks –serverUrl=http://x.x.x.x/XMLRPC –activationkey=1-414ace93e6c3e94c85aec54a653e761d

Note: x.x.x.x is your spacewalk server IP address

Posted in Linux/CentOS | Leave a comment

DRS Interview Questions

Q1: what is the default invocation period for DRS. Can we change this. If yes then how?

Ans: The default invocation period is 300 seconds (5 minutes). But this can be changed via the configuration file vpxd.cfg. We have to change the value of <pollperiodsec> as shown below:








Just change the value 300 to a custom value defined by you. The range of supported value is 60 secs to 3600 secs.

Q2: What is the role of VPXA in DRS?

Ans: VPXA is the vCenter agent that runs inside Esxi hosts and it enables a 2 way communication between Esxi hosts and vCenter Server. VPXA is responsible for:

  • Keeping the status of Esxi and VM’s in sync
  • It sends info to vCenter server when a VM’s power state is changed or a VM is vMotioned from one host to other.

DRS uses this information which is presented by Esxi hosts to vCenter server for calculating the load balance and proposed migrations in case of cluster imbalance.

Q3: Will DRS work if vCenter server is down? If no then explain why DRS is dependent on vCenter server.

Ans: No DRS will not work if vCenter Server is down.

DRS depends upon vCenter server for information like current power state of virtual machines, change in power state of any VM, number of datastores to which Esxi hosts are connected and the memory and cpu configurations of a VM.

DRS will use all these information while calculating the load on the cluster and proposing migration recommendations when a cluster needs to be balanced.

Q4: How DRS calculates there are imbalances in cluster? What are the things that DRS takes into account for determining this?

Ans: To calculate the cluster imbalance, DRS compares the Current Hosts Load Standard Deviation (CHLSD) to Target Hosts Load Standard Deviation (THLSD) and if


Cluster is considered as imbalanced.

CHLSD Calculation

DRS computes Normalized Entitlement (NE) of each Esxi hosts and the standard deviation associated with it. NE is nothing but calculation of how much resources are currently utilized out of total resources. NE is calculated by summing up dynamic entitlements (usage) of all VM’s that are running on an Esxi host and diving this by Esxi host capacity.

So, NE= Dynamic Usage of all VM’s / Total host capacity

THLSD Calculation

THLSD is derived from DRS migration threshold which is defined at the time of configuring DRS. Each threshold level sets different imbalance tolerance margin. The aggressive threshold sets a tight margin allowing for little imbalance, while conservative thresholds tolerates bigger imbalances.

Q6: What is DRS cost-benefit-risk approach?

Ans: DRS uses a cost benefit risk approach to load balance a cluster. Before presenting the migration recommendations for a VM to load balance a cluster, DRS calculates 3 things:

  • Cost: What will be the cost of migrating a VM from source to destination host? Cost here refers to the CPU and memory.

When a vMotion process in invoked on a VM, it reserves 30% of the cpu core (For 1 GB NIC) of that VM and 100% cpu core (For 10 GB NIC). This reservation is created on both source and destination host. This reserves resources can’t be allocated to any other VM while vMotion is in progress. This can put some pressure on an Esxi host when it is heavily loaded.

  • Benefits: What will be the resource benefit that an Esxi host will get after migrating a virtual machine to other Esxi ho st. If after the migration CHLSD value of the Esxi host comes down then DRS will consider that migration as benefit.
  • Risk: Risk accounts for possibility of irregular loads. Suppose a VM has inconsistent and spiky demands of resources, then migrating such VM’s is not a good move because may be at the time of migration VM resource demand was low but after completion of migration, VM’s resource demands suddenly increased. In this case it can cause the increase in destination Esxi hosts CHLSD and again DRS has to perform migration of that VM to bring down CHLSD of the Esxi host where that VM was migrated.

Note: DRS recommends migrations if Benefit obtained due to a migration < cost associated with that migration.

Q8: What are the factors that affect DRS recommendations?

Ans: Following are the factors which affect the DRS recommendations:

1- VM size and Initial Placement: When a new VM is created or a VM is powered on, DRS selects a host where this VM should be initially placed. DRS prefers the registered host as long as placement of that VM on this host will not cause cluster imbalance.

During placement of such VM’s DRS uses a worst case scenario because it doesn’t have historical data for that VM. DRS assumes both CPU and memory demand of this VM is equal to its configured size.

Oversized VM’s can temporarily cause cluster imbalance and can cause unnecessary migrations of active VM’s.

2- PollPeriodSec (Length of DRS Invocation): The default value of PollPeriodSec is 300 seconds. Range of PollPeriodSec is 60 sec to 3600 sec. shortening this period will cause increase in vCenter overhead as cluster imbalance will be calculated frequently.

Increasing this value decreases the frequency of cluster balance calculation and can leave your cluster imbalanced for longer period of times but allows for larger number of vMotions due to long invocation interval.

3- Simultaneous vMotion: vSphere 5.1 allows 8 concurrent vMotions on a single host with 10GbE capabilities. For 1GbE, 4 concurrent vMotion can takes place. Also multi-NIC vMotion is supported in vSphere 5.1 so multiple active NICs and their combined bandwidth can be used for migration of a VM. In such environment VM’s will be migrated quickly and cluster can be balanced in less time.

4- Estimated Total Migration Time: The migration time depends on variables like source and destination host load, active memory usage of VM, link speed and available bandwidth+ latency of the physical network used by vMotion Portgroup.

Q9: what are the use cases for VM-VM affinity rules and VM-VM anti affinity rules?

Ans: VM-VM affinity: This is useful when you require that 2 of your VM’s should always run together on an Esxi host. For E.g. Keeping front-end and back-end server of an application on same ESXi host to reduce network latency between the 2 VM’s.

Another use case will be running together same types of VM’s which are having same type of applications so as to get max benefits of transparent page sharing (TPS)

VM-VM anti-affinity: This is useful when you don’t want that 2 of your VM should run together. Keeping servers providing same kind of services on different host will provide resiliency

For e.g. You will not want your DC and ADC run together on same Esxi host because if that Esxi host goes down it can severely impact your environment as both DC and ADC server has gone down together.

Another use case will be running web-server farms or clustered DB-servers in a virtualized environment.

Also, keeping away 2 VM’s from each other which are very resource intensive to stop them from monopolizing resource usage.

Q10: What are the use cases of VM-Host affinity rules and VM-Host anti-affinity rules?

Ans: VM-Host affinity: This is useful when you want that your VM should run on a particular Esxi host only.

For e.g. running and oracle DB server which has socket based license. If your environment is having heterogeneous hosts than migrating such VM to a host which has different CPU configuration can violates your license and can cause trouble.

VM-Host anti affinity: This is useful when you want that a particular VM should not run on some particular Esxi hosts. For e.g. your environment has heterogeneous hosts and all the hosts don’t have Numa architecture and you want to get benefits of the vNuma inside your VM. In this case you would want your VM to run only on those servers which supports Numa.

Q11: Can DRS override “preferential or should rules”. If yes then how and if no then why?

Ans: Yes DRS can override should rules. When rules are configured inside DRS then DRS creates a rule list and provide migrations recommendations in accordance with the rules defined in rule list. But if the cluster imbalance cannot be solved even after running these migrations then DRS drops the rule list and re-run the load balance algorithm and  those migrations also which can break the should rules, in order to load balance a cluster in a better way.

Q12: CAN HA, DRS and DPM override “must or mandatory rules”?

Ans: No HA, DRS and DPM can’t override must rules.

Q13: What impact does must rule places on DRS, HA and DPM operations?

Ans: If a migration will cause violation of must rule then that migration will be cancelled by DRS.

IF DPM is trying to put a host in sleep mode for power saving but migration of VM’s running on this host can cause a must rule violation, it will prevent DPM to put that host in sleep mode.

If HA is trying to restart VM’s after a host failure but if restart of some VM’s on a particular host can cause must rule violation then HA will either restart those VM’s on some different host or could not restart them at all if no suitable host is available for failover.

Q14: If we have configured some rules (affinity or anti-affinity) in DRS the will those rules work if we disable DRS on a cluster?

Ans: Yes rules will be in affect even if we disable DRS without deleting the rules first.

Q15: If on a VM, VM-Host affinity should rule is configured then can we migrate that VM on an Esxi host that is not part of the DRS cluster?

Ans: No a VM can’t be migrated to an Esxi host that is not part of the DRS cluster.

Q16: What are the best practices for disabling DRS?

Ans: Before disabling DRS it is recommended to delete all affinity and anti-affinity rules and then proceed. Because if rules are not deleted and DRS is disabled, rules will be still in affect and can affect cluster operations.

Q17: What are the limitation that are put by DRS mandatory or must rules on a cluster?

Ans: If a mandatory rule is configured on a cluster then it can put following limitations:

  • Limit DRS to select hosts for load balancing
  • Limit HA to select host for failover
  • Limit DPM to select host to power off
  • It can affect ability of DRS to defragment the cluster resources. At the time of failover HA can seeks assistance for DRS and can ask to defragment resources if a single host is not able to provide adequate resources for failover.

Q18: If a new DRS rule is created but that rule is conflicting with any existing rule then which rule DRS will respect, old rule or new rule while performing DRS actions?

Ans: If a new rule is conflicting with an old rule then new rule will be disabled automatically. DRS will prefer respecting the old rule.

Q19: How many automation levels are there for a VM in respect to DRS? Can VM automation level override cluster automation level?

Ans: VM automation level can override cluster automation level. From a VM prospective there are 5 automation levels. These are:

  • Fully Automated: Load balance and Initial placement will be done by DRS automatically
  • Partially Automated: Load balance of the VM will be done manually but initial placement will be done automatically
  • Manual: VM migration as part of Load balancing and initial placement will be both manual. DRS will only generate recommendation for that VM and administrator has to manually approve this recommendation.
  • Default: VM will inherit the DRS automation level as defined at the cluster level.
  • Disabled: DRS will not perform any actions on that VM.

Disclaimer: Most of the things I have learned from Duncan’s and Frank’s book ” Clustering Deep-Dive”. I had shared here only the important concepts which are a bit partial. Recommend to read the book if you want to have in-depth understanding of DRS concepts.

Posted in Interview Questions, Vmware | Leave a comment

Collecting Horizon View logs with PowerShell script

If you are facing any issues in Horizon View environment and need to do troubleshooting it’s a very difficult task to cycle throughout all component logs. Also it’s a bit difficult to remember the location of every log file is across the different components.

I found a PowerShell script on internet which can ease your paint of collecting the log files for Horizon View environment.

This powershell script is written by VMware Architect Markt Ewert. This script automates the log files collection, including Connection Servers, Security Gateways, Desktops, View Composer and Transfer Servers.

# VMware View Log Collector v1.0
# Copyright 2013 VMware. All Rights Reserved.
# Collects VMware View 4.x/5.x log files from View servers and virtual desktops.
# Developed 2012-2013 by Mark F. Ewert, Architect – Technical Enablement

# This script has been well tested but is not supported.
# Run the script without any parameters for detailed help
# Get parameters passed on the command line
[string]$Mode = “”,
[string]$LogType = “”,
[string]$Desktop = “”,
[string]$LogRepository = “”,
[string]$TargetShare = “”

# Set Main variables
$ServerLogTypes = @(“debug”,”log”,”securitygateway”)
$DesktopLogTypes = @(“debug”,”log”,”pcoip_agent”,”pcoip_server”,”persona”)
$ComposerLogTypes = @(“vmware-viewcomposer.”,”vmware-viewcomposer-audit”)
$TransferServerLogTypes = @(“debug”,”log”)
$Modes = @(“server”,”desktop”,”composer”,”transferserver”)
If ($Modes -notcontains $Mode) {$Mode = “help”} # default to display help
If (($Mode -eq “server”) -and ($ServerLogTypes -notcontains $LogType)) {$LogType = “all”} # default to all server log types
If (($Mode -eq “desktop”) -and ($DesktopLogTypes -notcontains $LogType)) {$LogType = “all”} # default to all desktop log types
If ($Mode -eq “composer”) {$LogType = “all”} # collect all Composer logs by default
If (($Mode -eq “transferserver”) -and ($TransferServerLogTypes -notcontains $LogType)) {$LogType = “all”} # default to all transfer server log types
$CollectedCount = 0
$ConnectionServers = @()
$vCenterServers = @()
$TransferServers = @()
$SystemsWithLogs = @()
$LogTypes = @()
If (!$targetshare) {$TargetShare = “C$”} # default to C$ share
If (!$LogRepository) {$LogRepository = “”} # SET DEFAULT LOG REPOSITORY HERE
$2008_Win7_LogLocation = “ProgramData\VMWare\VDM\logs” # 2008\Windows 7 log location
$2003_WinXP_LogLocation = “\Documents and Settings\All Users\Application Data\VMware\VDM\logs” # 2003\Windows XP log location
$2008_Composer_LogLocation = “\Documents and Settings\All Users\Application Data\VMware\View Composer\Logs” # 2008 Composer log location
$2003_Composer_LogLocation = “\ProgramData\VMware\View Composer\Logs” # 2003 Composer log location
$TitleColor = “green”
$WarningColor = “yellow”
$AlertColor = “red”
# Load VMware View PowerCLI Snapin if not already loaded
if (!(get-pssnapin -name VMware.View.Broker -erroraction silentlycontinue)) {
add-pssnapin VMware.View.Broker

Function TitleScreen () {
# Display Title
Write-Host “VMware View Log Collector” -foregroundcolor $TitleColor
write-host “Mode: ” -nonewline; write-host “”$Mode -nonewline -foregroundcolor $WarningColor; write-host ” Log type to collect:” -nonewline; write-host “”$LogType -foregroundcolor $WarningColor

Function Wait4KeyPress () {
# Pause for key press
Write-Host “Press any key to continue …” -nonewline -foregroundcolor $WarningColor
$KeyPress = $host.UI.RawUI.ReadKey(“NoEcho,IncludeKeyDown”)

Function ShowHelp () {
Write-Host “VMware View Server Log Collector Help” -foregroundcolor $TitleColor
Write-Host “————————————-” -foregroundcolor $TitleColor
Write-Host “This script collects VMware View virtual desktop infrastructure log files,”
Write-Host “centralizing them on a CIFS file share. To simplify log analysis, the name”
Write-Host “of the system the logs were copied from is appended to the filename.”
Write-Host “The collector copies the latest, non-zero length log file. If the most recent”
Write-Host “two log files of a specific type are both zero length, none are copied.”
Write-Host “Program Modes” -foregroundcolor $TitleColor
Write-Host “————-” -foregroundcolor $TitleColor
Write-Host “Logs can be collected from View Connection\Security Servers, Virtual Desktops,”
Write-Host “Composer Servers and Transfer Servers. The type of system to collect logs from”
Write-Host “is specified using the ” -nonewline; write-host “-mode” -nonewline -foregroundcolor $WarningColor; write-host ” parameter. The following modes are supported:”
Write-host “server” -foregroundcolor $WarningColor
Write-host “desktop” -foregroundcolor $WarningColor
Write-host “composer” -foregroundcolor $WarningColor
Write-host “transferserver” -foregroundcolor $WarningColor
Write-Host “If no mode is selected, this help information is dislayed.”
Write-Host “Server, composer and transferserver modes automatically identify the servers to”
Write-Host “collect logs from by querying View (server,composer) or vSphere (transferserver)”
Write-Host “Desktop mode requires specification of a desktop. This can be done on the”
Write-Host “command line using the ” -nonewline; Write-Host “-desktop” -nonewline -foregroundcolor $WarningColor; Write-Host ” parameter. If none is specified the”
Write-Host “script will prompt for it.”
Write-Host “Log Types” -foregroundcolor $TitleColor
Write-Host “———” -foregroundcolor $TitleColor
Write-Host “Each mode supports different log types that can be collected as detailed below.”
Write-Host “Server” -nonewline -foregroundcolor $WarningColor; Write-Host ” log types: debug, log, securitygateway”
Write-Host “Desktop” -nonewline -foregroundcolor $WarningColor; Write-Host ” log types: debug, log, pcoip_agent, pcoip_server”
Write-Host “Composer” -nonewline -foregroundcolor $WarningColor; Write-Host ” log types: all (collects the two Composer logs)”
Write-Host “TransferServer” -nonewline -foregroundcolor $WarningColor; Write-Host ” log types: debug, log”
Write-Host “Log type: “-nonewline; Write-Host “all” -nonewline -foregroundcolor $WarningColor; Write-Host ” can also be specified to collect all types of logs from the”
Write-Host “target system(s). If no log type is specified or is specified incorrectly,”
Write-Host “the script defaults to: ” -nonewline; Write-Host “all” -foregroundcolor $WarningColor
Write-Host “Log Repository” -foregroundcolor $TitleColor
Write-Host “————–” -foregroundcolor $TitleColor
Write-Host “The script needs to be configured with a Log Repository to store the collected”
Write-Host “logs. Any CIFS-based file share is supported. The user account running the ”
Write-Host “script must have the Windows NTFS equivalent of ” -nonewline; Write-Host “Modify” -nonewline -foregroundcolor $WarningColor; Write-Host ” rights.”
Write-Host “The log repository can be specified on the command line using the”
Write-Host “parameter: ” -nonewline; Write-Host “-LogRepository” -nonewline -foregroundcolor $WarningColor; Write-Host “. The repository can also be set”
Write-Host “within the USER CONFIGURABLE VARIABLES section near the top of the script to”
Write-Host “prevent having to specify one each time the script is run. Be sure to enclose”
Write-Host “the repository in quotations if there are any spaces in the path.”
Write-Host “Target Share and Security” -foregroundcolor $TitleColor
Write-Host “————————-” -foregroundcolor $TitleColor
Write-Host “By default the script connects to each target system using the ” -nonewline; Write-Host “C$” -nonewline -foregroundcolor $WarningColor; Write-Host ” share and”
Write-Host “requires the user account running the script to be able to connect to this path.”
Write-Host “A different share can be specified using the ” -nonewline; Write-Host “-targetshare” -nonewline -foregroundcolor $WarningColor; Write-Host ” parameter.”
Write-Host “Log Locations” -foregroundcolor $TitleColor
Write-Host “————-” -foregroundcolor $TitleColor
Write-Host “The script collects logs from the standard VMware View log locations as”
Write-Host “detailed in: ” -nonewline; Write-Host “KB 1027744″ -nonewline -foregroundcolor $WarningColor; Write-Host ” by default. These locations can be changed using”
Write-Host “the respective variables also located within the USER CONFIGURABLE VARIABLES”
Write-Host “section near the top of the script.”
Write-Host “Examples” -foregroundcolor $WarningColor
Write-Host “——–” -foregroundcolor $WarningColor
Write-Host “logcollector.ps1 -mode desktop -desktop HRDSKTOP112 -logtype pcoip_server”
Write-Host “-logrepository \\nashost.domain.local\viewlogs”
Write-Host “logcollector.ps1 -mode server -logtype debug -logrepository”
Write-Host “\\fileserver.domain.local\log_repository”
Write-Host “logcollector.ps1 -mode server -logtype all -targetshare log_share”
Write-Host “-logrepository \\fileserver.domain.local\logs”
Write-Host “logcollector.ps1 -mode composer”
Write-Host “Powershell Requirements” -foregroundcolor $TitleColor
Write-Host “———————–” -foregroundcolor $TitleColor
Write-Host “All collection modes require the VMware View PowerCLI which is”
Write-Host “installed on each Connection Server by default. This script must”
Write-Host “be run on a Connection Server using an account that has Administrative”
Write-Host “rights to both the Connection Server and the View Infrastructure. When”
Write-Host “launching the script or opening a Powershell session to run the script”
Write-Host “be sure to launch it as an Administrator ” -nonewline; write-host “(Run as Administrator)” -foregroundcolor $WarningColor
Write-Host “Transferserver mode also requires the account running the script to”
Write-Host “have rights to connect to the vSphere vCenter Servers supporting the”
Write-Host “View Infrastructure and read the Notes associated with each Virtual Machine.”
Write-Host “This is required in order to identify the deployed Transfer Servers.”
Write-Host “Make sure the vSphere PowerCLI supporting the version of vSphere deployed”
Write-Host “has been installed on the Connection Server where this script will”
Write-Host “be executed.”
Write-Host “Script developed by: Mark F. Ewert, Architect – Technical Enablement, VMware” -foregroundcolor $WarningColor
Write-Host “Script copyright VMware 2013 – All Rights Reserved” -foregroundcolor $WarningColor

Function LogCollector ($SystemsWithLogs,$Mode,$LogType) {
ForEach ($System in $SystemsWithLogs) {
# First check if system is running Windows 2003 or 2008
If ($Mode -ne “composer”) {
$LogLocation = $2008_Win7_LogLocation
$FullLogPath = “\\”+$System+”\”+$TargetShare+”\”+$LogLocation+”\”
# Assume 2008 but check to see if it’s actually 2003
If (!(Test-Path -path $FullLogPath)) { # if 2008 log directory doesn’t exist, it’s 2003
$LogLocation = $2003_WinXP_LogLocation
$FullLogPath = “\\”+$System+”\”+$TargetShare+”\”+$LogLocation+”\”
Else { # must be composer mode
$LogLocation = $2008_Composer_LogLocation
$FullLogPath = “\\”+$System+”\”+$TargetShare+”\”+$LogLocation+”\”
# Assume 2008 but check to see if it’s actually 2003
If (!(Test-Path -path $FullLogPath)) { # if 2008 log directory doesn’t exist, it’s 2003
$LogLocation = $2003_Composer_LogLocation
$FullLogPath = “\\”+$System+”\”+$TargetShare+”\”+$LogLocation+”\”
# finish creating path and filename for log to collect
If ($LogType -ne “securitygateway”) {
$Log2Fetch = $FullLogPath+””+$LogType+”*”
Else {
$Log2Fetch = $FullLogPath+”PCoIP Secure Gateway\”+$LogType+”*”
# Fetch details for last two logs
$LogFiles = @()
$LogFiles = @(gci $Log2Fetch -ea SilentlyContinue | sort LastWriteTime | select -last 2)
If ($LogFiles) {
# Check for zero size logs handling situation where only one file was returned
If (!$LogFiles[1]) {
$LogFiles += $LogFiles[0]
$Size = Get-Item $LogFiles[1]
If ($Size.length -ne 0) {
[string]$LogFileAndPath = $LogFiles[1]
Else {
$Size = Get-Item $LogFiles[0]
If ($Size.length -ne 0) {
[string]$LogFileAndPath = $LogFiles[0]
Else {
# turn persona log type back into human understandable
If ($LogType -eq “vmvvp”) {$LogType = “persona”}
Write-Host “Warning: ” -nonewline -foregroundcolor $WarningColor; Write-Host “The two latest $LogType logs for $System are 0 bytes and will not be collected”
$LogFileAndPath = $null
Else {
# turn persona log type back into human understandable
If ($LogType -eq “vmvvp”) {$LogType = “persona”}
Write-Host “Warning: ” -nonewline -foregroundcolor $WarningColor; Write-host “No $LogType log was found on”$System
$LogFileAndPath = $null

# If there’s a recent non zero sized log file, collect it
If ($LogFileAndPath) {
[string]$LogFileName = $LogFileAndPath.SubString($FullLogPath.length)
$LogFileExtension = [System.IO.Path]::GetExtension($LogFileName)
$NewLogFileName = “”+$LogRepository+”\”+$LogFileName.TrimEnd($LogFileExtension)+”_-_”+$System+$LogFileExtension
Copy-Item -Path $LogFileAndPath -Destination $NewLogFileName
write-host “Success: ” -nonewline -foregroundcolor $TitleColor; write-host “$LogType log collected from”$System
# Increase count of collected logs
Return $CollectedCount

# Main Program

# Check to see if HELP was requested
If ($Mode -eq “help”) {

# Verify a Log Repository was specified

If (!$LogRepository) {
Write-Host “Please specify a repository the next time the script is”
Write-Host “executed or configure a default respository using the”
Write-Host “LogRepository variable in the USER CONFIGURABLE VARIABLES”
Write-Host “section near the top of the script.”

# Verify the Log Repository exists
If (!(Test-Path -path $LogRepository)) {
Write-Host “Please verify log repository settings before re-running the script.”

# Display Title Screen

# Server Mode
If ($Mode -eq “server”) {
# create PCoIP log repository sub-directory if it doesn’t already exist.
$SecureGatewayLogPath = $LogRepository + “\PCoIP Secure Gateway\”
If (!(Test-Path -path $SecureGatewayLogPath)) {New-Item $SecureGatewayLogPath -Type Directory}
# Get Connection Servers from View
$ConnectionServers = Get-ConnectionBroker
ForEach ($ConnectionServer in $ConnectionServers) {
$SystemsWithLogs += $ConnectionServer.broker_id
# set LogTypes to server log types
$LogTypes = $ServerLogTypes
Write-Host “View Servers: ” -nonewline; write-host “”$SystemsWithLogs -foregroundcolor $WarningColor

# Desktop Mode
If ($Mode -eq “desktop”) {
# Prompt for name of desktop if one was not entered on the command line
If ($Desktop) {
Write-Host “Desktop: ” -nonewline; write-host “”$Desktop -nonewline -foregroundcolor $WarningColor
While (!$Desktop) {
Write-Host “Enter Name of Desktop containing logs: ” -nonewline -foregroundcolor $WarningColor; $Desktop = Read-Host
$SystemsWithLogs = $Desktop
# set LogTypes to desktop log types
$LogTypes = $DesktopLogTypes

# Composer Mode
If ($Mode -eq “composer”) {
# Get the name of the View Composer server from View
$VC = Get-ViewVC
$ComposerURL = $VC.composerUrl
$Composer = $ComposerURL.TrimStart(“https://&#8221;)
$Composer = $Composer.SubString(0,($Composer.LastIndexOf(‘:’)+1))
$Composer = $Composer.Trim(“:”)
$SystemsWithLogs = $Composer
# set LogTypes to composer log types
$LogTypes = $ComposerLogTypes
Write-Host “View Composer IP Address: ” -nonewline; write-host “”$SystemsWithLogs -foregroundcolor $WarningColor

# Transfer Server Mode
If ($Mode -eq “transferserver”) {
# Load VMware vSphere PowerCLI Snapin if not already loaded
If (!(get-pssnapin -name VMware.VimAutomation.Core -erroraction silentlycontinue)) {
add-pssnapin VMware.VimAutomation.Core
Write-Host “Scanning vCenter(s) for Transfer Servers… Please Wait…” -foregroundcolor $WarningColor
# Get vCenter Server(s) from View
@($ViewVCs = Get-ViewVC)
ForEach ($ViewVC in $ViewVCs) {
$vCenterServers += $ViewVC.serverName
# Now get Transfer Servers from vCenter
ForEach ($vCenterServer in $vCenterServers) {
connect-viserver $vCenterServer -ea SilentlyContinue | Out-Null
@($VMs = Get-VM)
ForEach ($VM in $VMs) {
$Annotations = Get-Annotation -CustomAttribute “Transfer Server Status” $VM
If ($Annotations.Value) {
$SystemsWithLogs += $VM
# set LogTypes to transfer server log types
$LogTypes = $TransferServerLogTypes
# Display Title Screen
Write-Host “Transfer Servers: ” -nonewline; write-host “”$SystemsWithLogs -foregroundcolor $WarningColor
# Collect Logs
write-host “—————————————————-” -foregroundcolor $WarningColor
$LogCollectionAttempts = 0
If ($LogType -eq “all”) {
ForEach ($Log in $LogTypes) {
$LogType = $Log
# check for persona logtype and replace human understandable with actual
If ($LogType -eq “persona”) {$LogType = “vmvvp”}
If (!$SystemsWithLogs.count) {$LogCollectionAttempts++}
Else {$LogCollectionAttempts += $SystemsWithLogs.count}
$Count += LogCollector $SystemsWithLogs $Mode $LogType
$CollectedCount += $Count
Else {
# check for persona logtype and replace human understandable with actual
If ($LogType -eq “persona”) {$LogType = “vmvvp”}
$LogCollectionAttempts = $SystemsWithLogs.count
$CollectedCount = LogCollector $SystemsWithLogs $Mode $LogType
write-host “—————————————————-” -foregroundcolor $WarningColor

If ($CollectedCount) {
write-host “Total number of logs collected:” -nonewline; write-host “”$CollectedCount -foregroundcolor $WarningColor
write-host “Total number of log collection attempts:” -nonewline; write-host “”$LogCollectionAttempts -foregroundcolor $WarningColor
If ($LogCollectionAttempts -ne $CollectedCount) {
If (($LogCollectionAttempts – $CollectedCount) -eq 1) {
write-host “1” -nonewline -foregroundcolor $WarningColor; write-host ” log was not collected”
Else {
write-host ($LogCollectionAttempts – $CollectedCount)”” -nonewline -foregroundcolor $WarningColor; write-host “logs were not collected”
Else {
write-host “ALERT:” -nonewline -foregroundcolor $AlertColor; write-host ” NO LOGS WERE COLLECTED.”
write-host “Total number of log collection attempts:” -nonewline; write-host “”$LogCollectionAttempts -foregroundcolor $WarningColor

Posted in Vmware, Vmware Horizon | Leave a comment