vReality » VMware

Enhance PowerShell and PowerCLI with Console

Tomi Hakala — Sun, 22 Apr 2012 15:21:41 +0000

I have always been annoyed with clumsy cmd.exe console in Windows OS, unfortunately Microsoft didn’t improve it at all even with PowerShell. Few days back I came across with Open Source utility Console which is a major improvement over standard cmd.exe console, I remember testing this utility many years ago but didn’t have much of use for it back then.

Console is a frontend replacement for cmd.exe, PowerShell or any other CLI on Windows, Console also works well with vSphere PowerCLI and in my opinion makes it much nicer to use.

vSphere PowerCLI in Console

Download latest Console version from http://sourceforge.net/projects/console/ and extract it to your preferred location.

Search for PowerCLI shortcut in your Windows Start menu, right click it and select Properties, select and copy Target entry on Windows clipboard for later use.

Execute Console utility and open Settings by pressing CTRL+S. Select Tabs and either edit existing tab configuration or add a new one. Enter Title for your tab and paste Shell entry from Windows clipboard.

If you like you can set Startup dir and Icon. PowerCLI icon is embedded into Windows executable and you need a tool such as IcoFX to extract it. Location of executable holding the PowerCLI icon can be found at Change Icon … button in PowerCLI properties window.

You can now launch PowerCLI from Console tabs menu.

vSphere 5.0 update 1 released

Tomi Hakala — Fri, 16 Mar 2012 04:37:35 +0000

VMware has just released first major updates for vSphere 5.0 product family, list of updated products is below.

VMware ESXi 5.0 Update 1 – Release Notes
VMware vShield 5.0.1 – Release Notes
VMware vCenter Server 5.0 Update 1 – Release Notes
VMware vCenter Site Recovery Manager 5.0.1 – Release Notes
VMware vCloud Director 1.5.1 – Release Notes
VMware vCenter Configuration Manager 5.5 – Release Notes
VMware vCenter Chargeback Manager 2.0.1 – Release Notes
VMware vCenter Server Heartbeat 6.4 Update 1 – Release Notes

Kaspersky to launch VMware vShield Endpoint security solution at CeBIT

Tomi Hakala — Fri, 17 Feb 2012 14:18:04 +0000

This week at VMware Partner Exchange in Las Vegas IT security company Kaspersky Lab publicly announced their Anti-Virus solution for VMware vShield Endpoint security framework. Kaspersky will join Bitdefender and Trend Micro as pioneers in Cloud Security by offering Anti-Virus solution to support VMware vShield Endpoint 5. VMware vShield Endpoint offloads Anti-Virus scanning from VM to a special virtual security appliance which frees computing resources and improves AV solution manageability by removing need to maintain full fledged AV agent in each protected VM.

Kaspersky Security for Virtualization will be officially launched at CeBIT trade fair in Hannover Germany on 6th of March 2012.

Citing Kaspersky Security for Virtualization annoucement

The launch of Kaspersky Security for Virtualization follows the highly successful introduction of Kaspersky Endpoint Security 8 in October 2011. It means that Kaspersky Lab will be able to offer customers a single, unified management and security platform across their entire virtual, physical and mobile environments. Combined with Kaspersky Lab’s sophisticated anti-malware protection, this unified approach will provide users with an unrivalled mix of easy administration and next-generation protection. More information about the portfolio can be found at: http://www.kaspersky.com/beready.

Using the vShield Endpoint Security framework, the centrally managed Kaspersky Security for Virtualization will automatically detect, scan, protect and update every virtual machine on the network, including virtual data centres, servers and desktops. New machines will be protected automatically when they are added to the network.

Full press release by Kaspersky Lab is available at http://www.kaspersky.com/about/news/product/2012/Kaspersky_Lab_announces_its_security_solution_for_virtual_environments

VMware vExpert 2012 nominations are now open

Tomi Hakala — Thu, 16 Feb 2012 09:46:14 +0000

VMware vExpert title nominations for year 2012 are now open! VMware vExpert title is VMware’s way to say thank you to individuals who have contributed something significant to VMware Community in past year, may it have been active blogging, public speaking, tools/scripts etc.

Yours truly was selected as VMware vExpert in 2011 and it has been great honor, and even greater honor was to be selected as first vExpert in Finland ever!

This year there are some changes in vExpert program, VMware has introduced more paths to vExpert title.

Evangelist Path
The Evangelist Path includes book authors, bloggers, tool builders, public speakers, and other IT professionals who share their knowledge and passion with others with the leverage of a personal public platform to reach many people. Employees of VMware can also apply via the Evangelist path.

Customer Path
The Customer Path is for internal evangelists and community leaders from VMware customer organizations. They have contributed to success stories, customer references, or public interviews and talks, or were active community contributors, such as VMUG leaders.

VPN (VMware Partner Network) Path
The VPN Path is for employees of our partner companies who lead with passion and by example, who are committed to continuous learning and to making their technical knowledge and expertise available to many. This can take shape of event participation, video, IP generation, as well as public speaking engagements.

With the program growing, our goal still remains the same: to honour individuals who go above and beyond their everyday job requirements to share their technical knowledge and expertise with others; to help enable these individuals to make an even greater impact in the world; and to keep a high standard of vExpert recipients.

See more about vExpert 2012 program and nomination form at http://communities.vmware.com/vexpert.jspa

Paravirtual adapters with VMware Workstation

Tomi Hakala — Sat, 11 Feb 2012 08:38:00 +0000

Did you know that you can use VMware paravirtual VMXNET3 and PVSCSI adapters with VMs running on VMware Workstation? Paravirtual adapters will improve networking and disk IO performance by using valuable CPU cycles more efficiently.

VMware paravirtual adapters are not available through VMware Workstation GUI, but you can enable them by tweaking Virtual Machine’s VMX configuration file with notepad. I have tested this with VMware Workstation 8, this may work also with Workstation 7.0 but I cannot guarantee it.

- Create a new VM or use existing VM, upgrade VMware Tools to latest available. If you wish to use PVSCSI adapter you must install PVSCSI driver in VMware Tools installer, it is not included in default install.

- Browse to VM configuration folder and open it’s .vmx configuration file in notepad

VMXNET3 network adapter

To change network device to VMXNET3 search for ethernet configuration option

ethernet0.virtualDev = "e1000"

change device type to vmxnet3

ethernet0.virtualDev = "vmxnet3"

And you may save .vmx file, VMXNET3 adapter is now available for use.

Paravirtual SCSI adapter

Changing SCSI adapter type is a bit trickier, process depends on the OS of your VM and which drivers it has available as standard. With Windows you need to add PVSCSI adapter as second SCSI adapter before you can remove LSI one, to do this you need to add new hard disk to your VM if you currently have only one as your system and data disk.

Windows version on VMware Tools default installation does not include PVSCSI driver, you must do custom install and configure PVSCSI driver to be installed. If you are unsure that you have PVSCSI driver installed re-run VMware Tools installer and select “modify” to verify.

Once you have necessary drivers installed and new hard disk for your VM open .vmx configuration file in notepad and search for new disk configuration parameters

scsi0:1.fileName = "TestVM-0.vmdk"

Edit second hard disk configuration to change its SCSI ID to 1:0 and add configuration for new PVSCSI controller

scsi1.present = "TRUE"
scsi1.virtualDev = "pvscsi"
scsi1:0.present = "TRUE"
scsi1:0.fileName = "TestVM-0.vmdk"

With these settings you can now boot up your Windows VM, once necessary drivers have been installed you may replace system disk LSI Logic adapter with pvscsi by editing .vmx configuration file.

scsi0.virtualDev = "lsilogic"

lsilogic may also be lsisas1068, depending on the Windows version in your VM.

And there you have it, VMware paravirtual adapters VMXNET3 and PVSCSI in VMware Workstation VM.

VMworld 2012 Europe dates changed

Tomi Hakala — Thu, 09 Feb 2012 12:17:31 +0000

VMworld 2012 Europe dates have changed since first announcement in Copenhagen, VMworld 2012 Europe will be held in Barcelona on October 9th to 11th. Although not officially announced yet, most likely venue for VMworld 2012 Europe is Barcelona International Convention Centre.

vSphere ESXi 5.0 Driver Rollup 2 released

Tomi Hakala — Thu, 09 Feb 2012 11:28:06 +0000

VMware has released ESXi 5.0 Driver Rollup version 2 which is a ESXi 5.0 installer with additional device drivers for products which are not supported in official ESXi 5.0 install image. vSphere ESXi 5.0 Driver Rollup install image is supported only for fresh installs, migrations from ESX 4.x or upgrades from ESXi 4.x are not supported with ESXi 5.0 Driver Rollup installer.

To name few devices which are supported in this install image are Areca RAID controllers, Brocade 1010 and 1020 CNAs, Cisco UCS Virtual Interface Card CNA, Intel 82580 and I350 NICs, Fusion-io ioDrive and QLogic CNAs. For full list of device drivers included in this release see VMware vSphere Hypervisor ESXi 5.0 Driver Rollup 2 Release Notes.

vSphere Hypervisor ESXi 5.0 Driver Rollup 2 is available at this link.

Configuring multi-NIC vMotion on vSphere 5

Tomi Hakala — Fri, 03 Feb 2012 09:26:24 +0000

vSphere 5 introduced support for utilizing multiple network interfaces per single host for vMotion transfer. This is very useful feature for systems which are limited to 1 Gigabit network as migrating multiple VMs off a host can take very long time with 1 Gigabit vMotion network. Multiple NIC vMotion also allow larger workloads to be migrated successfully when they could fail without in case of insufficient vMotion bandwidth.

Taking advantage of multiple NIC vMotion requires having multiple vMotion vmkernel interfaces on each host. You need to assign unique IP address for each of those vmkernel interface and you should bind each vmkernel interface to a different uplink NIC.

Configuring standard vSwitch for multi-NIC vMotion

To enable multiple NIC vMotion with standard vSwitch you could either use single vSwitch with multiple uplinks, or you could use multiple vSwitches with single uplink.

a. Single vSwitch with multiple uplinks

b. Multiple vSwitches with single uplink

vMotion vmkernel interface

Add new vmkernel interface and enable vMotion on it. vSphere 5 can load balance vMotion transfer over up 16 interfaces with 1 Gigabit NICs or up to 4 interfaces with 10 Gigabit NICs.

You can assign IP addresses from same subnet to all vMotion vmkernel interfaces, but IP address has to be unique on each interface.

Override switch failover order

If you have multiple vmkernel interfaces on same vSwitch you need to assign dedicated uplink for each vMotion portgroup. Go to the “NIC Teaming” tab on portgroup settings, enable “Override switch failover order” and configure only single vmnic as “Active Adapters”, any other adapters should be set as “Unused Adapters”.

Repeat this step for each vMotion vmkernel interface, assign unique vmnic adapter for each vMotion portgroup, eg. “vMotion 1” portgroup has “vmnic2” as active adapter and “vMotion 2” portgroup has “vmnic3” as active adapter.

Verifying multi-NIC vMotion functionality

ESXi 5 hosts will take advantage of multiple vMotion interfaces automatically once they have been properly set. Any single vMotion will be load balanced on all vMotion interfaces you have configured. To verify that vMotion load balancing takes place check ESXi host vmkernel.log, you should see multiple connections for single vMotion session.

Outgoing vMotion session

cpu1:10496)MigrateNet: 1155: 1328264432389309 S: Successfully bound connection to vmknic ’10.0.0.4′
cpu1:10496)VMotionUtil: 3118: 1328264432389309 S: Stream connection 1 added.
cpu1:10496)MigrateNet: 1155: 1328264432389309 S: Successfully bound connection to vmknic ’10.0.0.1′
cpu1:10496)VMotionUtil: 3118: 1328264432389309 S: Stream connection 2 added.

Incoming vMotion session

cpu1:10321)MigrateNet: 1155: 1328264187746848 D: Successfully bound connection to vmknic ’10.0.0.4′
cpu0:2666)MigrateNet: vm 2666: 1979: Accepted connection from <10.0.0.5>
cpu0:2666)MigrateNet: vm 2666: 2049: dataSocket 0x4100154e60c0 receive buffer size is 563272
cpu1:2666)VMotionUtil: 3118: 1328264187746848 D: Stream connection 1 added.
cpu1:2666)MigrateNet: vm 2666: 1979: Accepted connection from <10.0.0.2>
cpu1:2666)MigrateNet: vm 2666: 2049: dataSocket 0x4100154e6760 receive buffer size is 563272
cpu1:2666)VMotionUtil: 3118: 1328264187746848 D: Stream connection 2 added.

Before you implement this with standard vSwitches you might to want to read this article by Josh Townsend http://vmtoday.com/2012/02/vsphere-5-networking-bug-2-affects-management-network-connectivity/

How to use custom AD group with ESXi 5 AD integration

Tomi Hakala — Thu, 02 Feb 2012 17:52:14 +0000

Since vSphere 4.1 it has been possible to integrate ESXi user authentication with Active Directory. In vSphere 4.1 AD group which was use to grant root permissions on ESXi host was hard coded as “ESX Admins” so you had to change your AD group structure to match that. With vSphere 5 it is now possible to change which AD group members are granted root permissions on ESXi host, here is how.

Open Advanced Settings of your ESXi host

In ESXi host Advanced Settings browse to Config –> HostAgent and you will see "Config.HostAgent.plugins.hostsvc.esxAdminsGroup” setting which you can change to match your preference. Change takes place within a minute or so, ESXi host reboot is not necessary.

Please note that each ESXi host will store esxAdminsGroup setting locally once any member in that group logs successfully to a ESXi host, setting is stored in ESXi host local permissions configuration (see screenshot below). If you change esxAdminGroup setting you have to make sure that you check local permissions on each ESXi host and remove any references to old AD group you might have previously used.

Setting up NetFlow on vSphere distributed switch

Tomi Hakala — Wed, 01 Feb 2012 17:35:00 +0000

Many networking devices like routers and switches, implement a NetFlow protocol which is used to export information of passing network traffic to a specific NetFlow collector application for analysis and visualization. Back in days, VMware ESX 3.5 had experimental support for NetFlow but it was dropped for vSphere 4, with release of vSphere 5 VMware introduced full production ready NetFlow support for vNetwork distributed switches.

NetFlow will export only information about source, destination, protocol and volume of network traffic passing the distributed switch, it will not have any visibility to actual payload.

NetFlow Analyzer

Ability to export NetFlow data doesn’t do much as-is, you need NetFlow analyzer application in which you import NetFlow data from vSphere distributed switch. While searching for application to do this I stumped on ManageEngine NetFlow Analyzer which is available as free download for 30 day evaluation, http://www.manageengine.com/products/netflow/download.html.

ManageEngine NetFlow analyzer is available as Windows and Linux versions, I downloaded Windows version and had it running in no time as installation and configuration was very easy. Once installed I glanced though NetFlow Analyzer configuration for TCP port to which I should send NetFlow data from vDS. I found this quickly under “Admin”, “Server Settings”, “NetFlow Listener Port”.

As I knew IP address of my NetFlow Analyzer server and NetFlow listener port of application I was ready to proceed with vDS configuration.

vSphere Distributed Switch Configuration

NetFlow export is configured at distributed switch level, go to the networking view in vSphere Client click “edit settings” on switch you wish to export NetFlow data from. In switch Settings you can see “NetFlow” tab and on that page you will have following settings.

First setting you should configure is “Collector IP address”, that is the IP of your NetFlow analyzer or collector application. You also need to configure correct port as every NetFlow analyzer and collector may have different default settings.

By default each ESXi host will export NetFlow data by using their own management address, because of this you will see multiple sources of traffic in your NetFlow analyzer. If you wish to have only single source for all your distributed switch traffic, you can configure specific source IP address for your vDS. This IP should be entered in “VDS IP address” field. Please note that you need to allow access from your ESXi host management IP addresses to your NetFlow analyzer/collector no matter what IP address you would type in vDS IP address.

By default distributed switch will send information about active network flow while 60 seconds have passed since flow was initiated, if you wish to have data about new flows quicker you could lower the value on “Active flow export timeout” but I do not recommend it unless you fully understand all implications it might have. I do not, so I don’t try to explain it. Data of idle network flows will be exported after 15 seconds of initial packet has passed.

Exporting NetFlow data from a vDS which is passing a LOT of traffic might have performance hit on ESXi host CPU, if you do not mind having lower resolution on your NetFlow data you could increase “Sampling rate” value. By default it is set to 0 which means that every packet is inspected and included in NetFlow export. If you set “Sampling rate” to 2 it means that every other network packet is inspected and included in NetFlow export, and so on. Increasing sampling rate will improve performance if you are having CPU utilization issues but it will also decrease NetFlow data resolution.

As last setting there is “Process internal flows only” check box. By default distributed switch will export data about all traffic passing internally on vDS or passing to or from physical network. If you have NetFlow enabled on your physical network devices it could be unnecessary to send information about flows which are passing on physical network layer also, as those are already seen and reported by other network devices. In this case you could check “Process internal flows only” setting and have distributed switch to export data only about flows which is switched directly by vDS and not passed to physical network layer, this would decrease any overhead NetFlow data exporting might have on your ESXi hosts.

Inspecting NetFlow data

Once you have your NetFlow analyzer and distributed switch properly set you should eventually have some data about network traffic taking place in your virtual infrastructure. Below is a screenshot of ManageEngine NetFlow Analyzer output about my vSphere lab traffic, you can see larger version of image by clicking of it.