I’ve received a request from a customer recently who wanted to configure all vCenter alarms to send a notification email. This instantly made me decide that PowerCLI was the best way to go rather than wasting a lot of valuable time in the vSphere client configuring the email notification alarms.

PowerCLI Automation Script:

I’ve created a quick and dirty script to do the job that I wanted to share with you. It’s probably not the fastest or the best optimized script, but it got the job done.

Get-AlarmDefinition | %{
   $_ | Set-AlarmDefinition -ActionRepeatMinutes (60 * 24);
   $_ | New-AlarmAction -Email -To "vcenteralerts@bwinparty.com" | %{
      $_ | New-AlarmActionTrigger -StartStatus "Green" -EndStatus "Yellow" -Repeat
      $_ | Get-AlarmActionTrigger | ?{$_.repeat -eq $false} | Remove-AlarmActionTrigger -Confirm:$false
      $_ | New-AlarmActionTrigger -StartStatus "Yellow" -EndStatus "Red" -Repeat
   }
}

Line 1: The script first retrieves all the alarms. You can easily adapt the script to update only a specific alarms by changing this line to include the name of the alarm you want to update like:

Get-AlarmDefinition "Datastore usage on disk"

or even all datastore alarms with:

Get-AlarmDefinition "Datastore*"

Line 2: The script then configures the alarm action repeat frequency to repeat the action every 24 hours. The value must be specified in minutes and the default value is to repeat every 5 minutes.

Line 3: On this line a new send notification email action is created to send an email to the email address vcenteralarms@customer.corp.

Line 4: This creates an alarm action trigger when the status changes from “Green” to “Yellow” or from “Normal” to “Warning”.

Line 5: During the creation of the send notification email alarm action, a default alarm action trigger is created. Because there’s currently no Set-AlarmActionTrigger cmdlet available, I decided that it’s easier to remove the default trigger rather than trying to change it from “Once” to “Repeat” by falling back to using the SDK methods. I warned you that it was quick and dirty

Line 6: finally this line creates an alarm action trigger when the status changes from “Yellow” to “Red” or from “Warning” to “Alert”.

Have Fun!

Related posts:

1. A new PowerCLI release and a New Year’s feature
2. PowerCLI: Disable/Enable HA and DRS
3. Managing VMware DRS rules using PowerCLI

Eric Siebert has opened up another top VMware & virtualization blogs poll over at vSphere-land.com.  Please take a moment and cast your vote  for your favourite 10 bloggers.  It’ll take only a couple of minutes of your time and you can win a copy of the Train Signal’s new vSphere 5 and View 5 video training courses.

So head on over to http://vote.vsphere-land.com to cast your vote and reward the best bloggers for their hard work and dedication by letting them know that you appreciate them. They deserve it!

Related posts:

1. Voting Time! – Top 25 VMware Virtualization Blogs
2. Ranked #27 in Eric Siebert’s Top VMware bloggers survey
3. Voted #29 top blogger on vSphere-land.com

PHD Virtual Backup and Replication 5.3, earlier demonstrated at VMworld 2011 by PHD Virtual, is coming soon. According to PHD Virtual it will be offering even faster backup and restore of virtual machines and new technologies that offer more flexibility for disaster recovery of your virtual environment.

NEW FEATURES

• New Job Processing Engine with I/O optimizations
• Up to 8 Concurrent Data Streams per VBA (Enterprise Edition)
• Virtual Machine Replication
• Virtual Machine Test Mode
• Mass Restore Virtual Machines
• Open Export of VM’s from Backup Storage to standard OVF
• Tape Friendly Backup Support

For more information have a look at the PHD5.3 Datasheet or watch the recently released demo video below.

Related posts:

1. How sure is your backup?
2. Moving your Virtual Center SQL database – Beware!
3. vSphere Client for iPad – Another step forward in mobile administration

I got a question on my previous post about the Get-EsxCli cmdlet, ESXCLI the PowerCLI way, from Alasdair Carnie who was having trouble using the Get-EsxCli cmdlet to mask luns at the ESXi host level. In this post I’ll show you how to accomplish LUN masking at the ESXi host level.

Note 1:
Before you read any further, please notice that the Get-EsxCli cmdlet is experimental. Also notice that in order to retrieve an esxcli instance you have to be connected directly to an ESX host.

Note 2:
When using the esxcli methods in PowerCLI, remember that you pay close attention to the definition of the specific method. You always have to provide a value for every parameter. If you don’t need to provide a value for a specific parameter, you have to specify the $null value.

Now that we are aware of these requirements, let’s create an additional claimrule to mask a LUN at the ESXi host level. Before we create a new claimrule, we’re going to have a look at the running claimrules on the ESXi host first.

Viewing the currently running claimrules

First we create an esxcli instance from PowerCLI

$esxcli = Get-EsxCli

To view the currently running claimrules, we need to call the list() method in the corestorage.claimrule branch.

$esxcli.corestorage.claimrule.list()

Note that I piped the output to ft, which is an alias of the Format-Table cmdlet, to forcibly show the output in table format. As you can see, there are two types of claimrule entries present. The “runtime” class is the rules currently running in the Pluggable Storage Architecture (PSA). The “file” class is a reference to the rules present in the /etc/vmware/esx.conf file. You’ll notice later on that after you create a claimrule it’s initially only listed in the “file” class until you explicitly load the new ruleset.

Adding a new claimrule

When you want to mask a LUN or path, you have to specify a claimrule for the MASK_PATH plugin. To view the available plugins run:

$esxcli.corestorage.plugin.list()

To add a new claimrule we need to call the add() method of the corestorage.claimrule branch. First let’s have a close look at the method’s definition.

$esxcli.corestorage.claimrule | gm

As you notice, the definition is hard to read, as it doesn’t fit in the screen. For this purpose you can better view the output in list format (Format-List or fl). To avoid showing a large list of all methods and properties, we narrow our output to include only the add() method using a where filter.

$esxcli.corestorage.claimrule | gm | where {$_.name -eq "add"} | fl

As you can notice there are a lot of parameters available for creating claimrules. Remember that you have to specify ALL of them. Parameters that aren’t required need to be specified as $null

For a detailed command description, see esxcli corestorage Command-Line Options.

For this purpose I’ve presented an iSCSI LUN to my ESXi host which is located at vmhba33:C0:T0:L0. To list the devices that are available to the ESXi host run the command:

$esxcli.corestorage.device.list()

As you can see, the last device listed is my iSCSI LUN.

To add a claimrule for the MASK_PATH plugin for this iSCSI device we issue:

$esxcli.corestorage.claimrule.add("vmhba33",$null,0,$null,$null,
    $null,$null,0,$null,"MASK_PATH",102,0,$null,"location",$null)

Note 1:
The previous command masks only one path to the iSCSI device (vmhba33:C0:T0:L0). If there are more paths available, you’ll need to add additional rules for each path to completely hide the device.

Note 2:
I specified 102 for the rule number as this is the next available number.

We can now verify the creation of our claimrule by listing the available claimrules again.

$esxcli.corestorage.claimrule.list()

Notice that the new claimrule is only available in the “file” class, but is not actively running. We need to first load the new ruleset into our system.

$esxcli.corestorage.claimrule.load()
$esxcli.corestorage.claimrule.list()

As you can see; our new claiming rule is now available in the “runtime” class and hence active.

Re-Claiming the LUN

We’re not quite there yet, as we need to perform one last step. Our iSCSI LUN is still claimed by the NMP plugin. We can verify this by listing the storage devices using:

$esxcli.corestorage.device.list()

Notice that the iSCSI LUN is still present. We need to unclaim the iSCSI LUN from the NMP plugin and run the claiming rules so that the iSCSI LUN can be claimed by our new masking rule.

$esxcli.corestorage.claiming.unclaim("vmhba33",0,$null,$null,
    $null,0,$null, $null,$null,0,"location",$null)
$esxcli.corestorage.claimrule.run()

Now we verify by listing the devices again.

$esxcli.corestorage.device.list()

As you can see, the iSCSI LUN is now masked and not available anymore.

Summarizing

Let’s summarize all the steps to add a claimrule for path vmhba33:C0:T0:L0

$esxcli.corestorage.claimrule.add("vmhba33",$null,0,$null,$null,
    $null,$null,0,$null,"MASK_PATH",102,0,$null,"location",$null)
$esxcli.corestorage.claimrule.load()
$esxcli.corestorage.claiming.unclaim("vmhba33",0,$null,$null,
    $null,0,$null,$null,$null,0,"location",$null)
$esxcli.corestorage.claimrule.run()

As you can see, it’s quite a hassle to mask a path or LUN at the ESXi host level and because of that is can be very error-prone. Also during a re-install this configuration is lost and you have to re-mask everything and can possibly run into issues. Masking LUNs at the ESXi host level has very specific use cases and should only be used as a last resort, when masking at the storage level isn’t a possible solution. That’s why I recommend against masking paths from the ESXi host level.

Best Practice
Perform LUN masking at the storage level

Unmasking the path

If you want to unmask the path, so that is will be available to the ESXi host again, use this code:

$esxcli.corestorage.claimrule.delete($null,102)
$esxcli.corestorage.claimrule.load()
$esxcli.corestorage.claiming.unclaim("vmhba33",0,$null,$null,
    $null,0,$null,$null,$null,0,"location",$null)
$esxcli.corestorage.claimrule.run()

Related posts:

1. ESXCLI the PowerCLI way
2. ESXi Tech Support Mode
3. Rescan VMware vSphere Hypervisor (ESXi) using PowerCLI simplified

One of the core features of VMware vSphere is the Distributed Resource Scheduler (DRS). VMware DRS is vSphere’s workload load balancer and relies on VMware vMotion technology to live-migrate workloads from one ESX host to another.

You can constrain the VMware DRS decisions by defining DRS Rules. As of vSphere 4.1 there are 2 type of DRS rules:

• VM-to-VM rules
• VM-to-Host rules (new in vSphere 4.1)

VM-to-VM rules

Until vSphere 4.1 you could only create VM-to-VM rules. This type of rule specifies the affinity between virtual machines (VMs). You can define both affinity- and anti-affinity rules.

Affinity rules

Affinity rules keep workloads together on the same ESX host. This is beneficial if for instance an application server needs fast access to its database that resides on another VM. Keeping both VMs together on the same host boosts performance as network traffic between the VMs won’t leave the ESX host. Note that if both servers are in different VLANs or subnets this benefit could be undone, as network traffic might need to be routed externally.

Anti-affinity rules

Anti-affinity rules separate workloads on different ESX hosts. This is beneficial if you have services running on multiple servers for redundancy, like domain controllers or Network Load Balancing (NLB) clusters. In these situations you want to make sure that the VMs are distributed over different ESX hosts. If one ESX host fails, the service would still be available through other VM(s) residing on other ESX hosts.

Using PowerCLI

You can manage the DRS rules through the properties of the Cluster (Remember that DRS is a vCenter cluster feature) using the vSphere Client, but you can also use PowerCLI. Using PowerCLI, DRS rules are retrieved with the Get-DrsRule cmdlet:

[vSphere PowerCLI] C:\Scripts> Get-DrsRule –Cluster CL01
Name            Enabled KeepTogether VMIDs
----            ------- ------------ -----
App01_Affinity  True    True         {VirtualMachine-vm-35672, VirtualM...
DC_Separate     True    False        {VirtualMachine-vm-35697, VirtualM...

Notice that only the VM IDs are returned for the configured VMs and not their names. You probably want the associated VM’s names to appear in your report instead of the VM IDs.

This can be accomplished using the New-VIProperty cmdlet:

New-VIProperty -Name VMs -ObjectType DrsVMAffinityRule -Value {
param($rule)
foreach($vm in $rule.VMIDs) {(Get-VM -Id $vm).Name}
}

[vSphere PowerCLI] C:\Scripts> Get-DrsRule –Cluster CL01 | Select Name,
>> Enabled, KeepTogether, VMs
Name           Enabled KeepTogether VMs
----           ------- ------------ ---
App01_Affinity    True         True {Arnim1, Arnim2}
DC_Separate       True        False {Arnim3, Arnim4}

You can now easily export your DRS rules for the sake of documentation or backup using the Export-CSV cmdlet.

[vSphere PowerCLI] C:\Scripts> Get-DrsRule –Cluster CL01 | Select Name,
>> Enabled, KeepTogether, VMs | Export-Csv CL01_Rules.csv

If you want to add a new rule, you can use the New-DRSRule cmdlet. To create a new DRS rule you need to specify the following mandatory parameters:

• Name: The name for the new DRS rule.
• Cluster: The cluster for which the new DRS rule applies.
• KeepTogether: Specify $true to create a new affinity rule, or $false to create a new anti-affinity rule.
• VM: The VMs to include in the new DRS rule

Let’s create a new anti-affinity rule for our proxy NLB cluster:

[vSphere PowerCLI] C:\Scripts> New-DrsRule –Name ProxyNLB_separate `
>> -Cluster CL01 –KeepTogether:$false –VM Proxy01,Proxy02

To verify the new rule, simply retrieve the DRS rules using the Get-DrsRule cmdlet again:

[vSphere PowerCLI] C:\Scripts> Get-DrsRule –Cluster CL01 | Select Name,
>> Enabled, KeepTogether, VMs
Name                       Enabled        KeepTogether VMs
----                       -------        ------------ ---
App01_Affinity                True                True {Arnim1, Arnim2}
DC_Seperate                   True               False {Arnim3, Arnim4}
ProxyNLB_Separate             True               False {Proxy01, Proxy02}

Removing a DRS rule is accomplished using the Delete-DrsRule cmdlet. This cmdlet requires you to specify a DrsVMAffinityRule object. This means that you can’t specify the rule by name, but you need to retrieve the rule object using the Get-DrsRule cmdlet first. Let’s remove the App01_Affinity rule:

[vSphere PowerCLI] C:\Scripts> Get-DrsRule –Cluster CL01 `
>> –Name App01_Affinity | Remove-DrsRule –Confirm:$false

VM-to-Host rules

vSphere 4.1 extended DRS functionality with DRS groups and the VM-to-Host rule type. With this type of rule you can specify the affinity between a group of VMs and a group of ESX hosts (inside a cluster). There are four rule types:

• Should
• Should not
• Must
• Must not

Mandatory rules (“Must” rules)

Mandatory rules are used in specific cases, such as licensing requirements. As an example let’s have a look to Oracle’s licensing requirements. Oracle states that in a virtual environment every socket in every ESX host in the cluster must be licensed, because the Oracle VM can potentially run on every host. Using a mandatory rule you can limit the Oracle VM to only run on the licensed ESX hosts.

Preferential rules (“Should” rules)

Preferential rules can be used in availability scenario’s, where a group of VMs is split across blade enclosures or racks. In the event of a loss of an enclosure or rack, the availability of the service or application is not jeopardized and HA is allowed to “violate” the preferential rule and restart the failed VMs on the surviving enclosures or racks. VMware HA isn’t aware of preferential rules because they aren’t communicated to HA by DRS.

Creating the new VM-to-Host type of rules is only available through the vSphere client and not using the standard VMware PowerCLI cmdlets at this time. But do not fear. I’ve created a couple of functions to allow you to automate this. The creation of a VM-to-Host rule is a three-step process:

1. Define a group of VMs (VMGroup)
2. Define a group of ESX hosts (HostGroup)
3. Create the VM-to-Host rule

Creating VMGroups

A VMGroup can be created using the New-DrsVmGroup function from Listing 1. To create a new VMGroup that contains virtual machines VM001 and VM002:

Get-VM VM001,VM002 | New-DrsVmGroup -Name "VmGroup01" -Cluster CL01

Listing 1

Function New-DrsVmGroup {
<#
.SYNOPSIS
  Creates a new DRS VM group
.DESCRIPTION
  This function creates a new DRS VM group in the DRS Group Manager
.NOTES
  Author: Arnim van Lieshout
.PARAMETER VM
  The VMs to add to the group. Supports objects from the pipeline.
.PARAMETER Cluster
  The cluster to create the new group on.
.PARAMETER Name
  The name for the new group.
.EXAMPLE
  PS> Get-VM VM001,VM002 | New-DrsVmGroup -Name "VmGroup01" -Cluster CL01
.EXAMPLE
  PS> New-DrsVmGroup -VM VM001,VM002 -Name "VmGroup01" -Cluster (Get-CLuster CL01)
#>

	Param(
		[parameter(valuefrompipeline = $true, mandatory = $true,
		HelpMessage = "Enter a vm entity")]
			[PSObject]$VM,
		[parameter(mandatory = $true,
		HelpMessage = "Enter a cluster entity")]
			[PSObject]$Cluster,
		[parameter(mandatory = $true,
		HelpMessage = "Enter a name for the group")]
			[String]$Name)

	begin {
	    switch ($Cluster.gettype().name) {
      		"String" {$cluster = Get-Cluster $cluster | Get-View}
      		"ClusterImpl" {$cluster = $cluster | Get-View}
      		"Cluster" {}
      		default {throw "No valid type for parameter -Cluster specified"}
		}
		$spec = New-Object VMware.Vim.ClusterConfigSpecEx
		$group = New-Object VMware.Vim.ClusterGroupSpec
		$group.operation = "add"
		$group.Info = New-Object VMware.Vim.ClusterVmGroup
		$group.Info.Name = $Name
	}

	Process {
		switch ($VM.gettype().name) {
      		"String" {Get-VM -Name $VM | %{$group.Info.VM += $_.Extensiondata.MoRef}}
      		"VirtualMachineImpl" {$group.Info.VM += $VM.Extensiondata.MoRef}
      		"VirtualMachine" {$group.Info.VM += $VM.MoRef}
      		default {throw "No valid type for parameter -VM specified"}
	    }
	}

	End {
		if ($group.Info.VM) {
			$spec.GroupSpec += $group
			$cluster.ReconfigureComputeResource_Task($spec,$true)
		}
		else {
      		throw "No valid VMs specified"
		}
	}
}

Creating HostGroups

Now that a VMGroup is created, you need to define a HostGroup. This can be accomplished using the New-DrsHostGroup function from Listing 2. To create a new HostGroup that contains ESX hosts ESX001 and ESX002:

Get-VMHost ESX001,ESX002 | New-DrsHostGroup -Name "HostGroup01" `
    -Cluster CL01

Listing 2

Function New-DrsHostGroup {
<#
.SYNOPSIS
  Creates a new DRS host group
.DESCRIPTION
  This function creates a new DRS host group in the DRS Group Manager
.NOTES
  Author: Arnim van Lieshout
.PARAMETER VMHost
  The hosts to add to the group. Supports objects from the pipeline.
.PARAMETER Cluster
  The cluster to create the new group on.
.PARAMETER Name
  The name for the new group.
.EXAMPLE
  PS> Get-VMHost ESX001,ESX002 | New-DrsHostGroup -Name "HostGroup01" -Cluster CL01
.EXAMPLE
  PS> New-DrsHostGroup -Host ESX001,ESX002 -Name "HostGroup01" -Cluster (Get-CLuster CL01)
#>

	Param(
		[parameter(valuefrompipeline = $true, mandatory = $true,
		HelpMessage = "Enter a host entity")]
			[PSObject]$VMHost,
		[parameter(mandatory = $true,
		HelpMessage = "Enter a cluster entity")]
			[PSObject]$Cluster,
		[parameter(mandatory = $true,
		HelpMessage = "Enter a name for the group")]
			[String]$Name)

	begin {
	    switch ($Cluster.gettype().name) {
      		"String" {$cluster = Get-Cluster $cluster | Get-View}
      		"ClusterImpl" {$cluster = $cluster | Get-View}
      		"Cluster" {}
      		default {throw "No valid type for parameter -Cluster specified"}
		}
		$spec = New-Object VMware.Vim.ClusterConfigSpecEx
		$group = New-Object VMware.Vim.ClusterGroupSpec
		$group.operation = "add"
		$group.Info = New-Object VMware.Vim.ClusterHostGroup
		$group.Info.Name = $Name
	}

	Process {
		switch ($VMHost.gettype().name) {
      		"String" {Get-VMHost -Name $VMHost | %{$group.Info.Host += $_.Extensiondata.MoRef}}
      		"VMHostImpl" {$group.Info.Host += $VMHost.Extensiondata.MoRef}
      		"HostSystem" {$group.Info.Host += $VMHost.MoRef}
      		default {throw "No valid type for parameter -VMHost specified"}
	    }
	}

	End {
		if ($group.Info.Host) {
			$spec.GroupSpec += $group
			$cluster.ReconfigureComputeResource_Task($spec,$true)
		}
		else {
      		throw "No valid hosts specified"
		}
	}
}

Creating VM-to-Host rules

Now that both VM- and HostGroup are created, you can start creating a VM-to-Host DRS rule. As mentioned before, there are rules to keep VMs on the specified set of Host or to keep them off these hosts. Using the New-DrsVmToHostRule function from Listing 3 you can create your VM-to-Host rule. By default the function will create an affine type of rule, unless you specify the opposite using the -AntiAffine switch parameter. The rule type is a preferential rule by default (“Should” rule) unless you specify the -Mandatoy parameter, which creates a mandatory rule (“Must” rule).

To create a mandatory anti-affinity rule (“Must Not” rule) between VMGroup01 and HostGroup01 to prevent the VMs from VMGroup01 to be executed on the ESX hosts in HostGroup01:

New-DrsVMToHostRule -VMGroup "VMGroup01" -HostGroup "HostGroup01" –Name `
    "VMToHostRule01" -Cluster CL01 -AntiAffine –Mandatory

Listing 3

Function New-DRSVMToHostRule{
<#
.SYNOPSIS
  Creates a new DRS VM to host rule
.DESCRIPTION
  This function creates a new DRS vm to host rule
.NOTES
  Author: Arnim van Lieshout
.PARAMETER VMGroup
  The VMGroup name to include in the rule.
.PARAMETER HostGroup
  The VMHostGroup name to include in the rule.
.PARAMETER Cluster
  The cluster to create the new rule on.
.PARAMETER Name
  The name for the new rule.
.PARAMETER AntiAffine
  Switch to make the rule an AntiAffine rule. Default rule type is Affine.
.PARAMETER Mandatory
  Switch to make the rule mandatory (Must run rule). Default rule is not mandatory (Should run rule)
.EXAMPLE
  PS> New-DrsVMToHostRule -VMGroup "VMGroup01" -HostGroup "HostGroup01" -Name "VMToHostRule01" -Cluster CL01 -AntiAffine -Mandatory
#>

	Param(
		[parameter(mandatory = $true,
		HelpMessage = "Enter a VM DRS group name")]
			[String]$VMGroup,
		[parameter(mandatory = $true,
		HelpMessage = "Enter a host DRS group name")]
			[String]$HostGroup,
		[parameter(mandatory = $true,
		HelpMessage = "Enter a cluster entity")]
			[PSObject]$Cluster,
		[parameter(mandatory = $true,
		HelpMessage = "Enter a name for the group")]
			[String]$Name,
			[Switch]$AntiAffine,
			[Switch]$Mandatory)

    switch ($Cluster.gettype().name) {
   		"String" {$cluster = Get-Cluster $cluster | Get-View}
   		"ClusterImpl" {$cluster = $cluster | Get-View}
   		"Cluster" {}
   		default {throw "No valid type for parameter -Cluster specified"}
	}

	$spec = New-Object VMware.Vim.ClusterConfigSpecEx
	$rule = New-Object VMware.Vim.ClusterRuleSpec
	$rule.operation = "add"
	$rule.info = New-Object VMware.Vim.ClusterVmHostRuleInfo
	$rule.info.enabled = $true
	$rule.info.name = $Name
	$rule.info.mandatory = $Mandatory
	$rule.info.vmGroupName = $VMGroup
	if ($AntiAffine) {
		$rule.info.antiAffineHostGroupName = $HostGroup
	}
	else {
		$rule.info.affineHostGroupName = $HostGroup
	}
	$spec.RulesSpec += $rule
	$cluster.ReconfigureComputeResource_Task($spec,$true)
}

As a general rule of recommendation: Use DRS rules, both VM-to-VM and VM-to-Host, sparingly, as every rule you create limits the choices DRS has to move VMs across ESX hosts. Also remember that mandatory rules stay in effect even when DRS is disabled! To disable mandatory rules, you need to disable them manually.

If you want to learn more about VMware DRS, I highly recommend reading the VMware vSphere 4.1 HA and DRS technical deepdive.

Related posts:

1. Rescan VMware vSphere Hypervisor (ESXi) using PowerCLI simplified
2. PowerCLI: Disable/Enable HA and DRS
3. ESXCLI the PowerCLI way

Who would’ve thought that 2011 would become such a great year for me? Earlier this year a dream came true with the release of our PowerCLI book on March 28th. Now, only 2 months after, another dream is about to happen. I think I can honestly say that I’m living my dream right now.

Well, it’s official.
I will be joining VMware as a Senior Consultant starting June 6th.

After almost 13 years, I’m leaving my current employer KEMBIT. During that period KEMBIT has always felt like family to me, so deciding to leave them was not that easy. On the other hand, working for VMware was something I could only dream about and I simply couldn’t refuse the offer.

I want to thank KEMBIT for the opportunity to let me grow my VMware knowledge and for their support and understanding. Thanks guys, it was a blast.

No related posts.

Now that our PowerCLI Book Raffle has ended and the lucky winner is published, I want to give you a full disclosure of the drawing process. Because our PowerCLI Book is about PowerCLI, what other tool than PowerShell could we use to perform the drawing process?

Twitter Fun

So first we need to retrieve all the twitter messages that people re-tweeted on Twitter. In order to do that we need to call the HTTP based Twitter search API. For more information on how to use the Twitter search API have a look at http://search.twitter.com/api/ This page shows us that the Twitter search API supports the Atom format through the Atom service URL “http://search.twitter.com/search.atom?q=<query>”. It also shows us the supported URL parameters. The most important parameters are:

• rpp: the number of tweets to return per page, up to a max of 100
• page: the page number to return, up to a max of roughly 1500 results (based on rpp * page

In order to perform a simple search, we only need to fill in the query parameter. We are interested in all messages that contain both “powerclibook” and “magictweet”. In order to search for tweets that contain both words, we need to concatenate them with the plus (+) sign, like http://search.twitter.com/search.atom?q=powerclibook+magictweet. To see the results you could simply paste that URL into your browser.
   

To capture the result in PowerShell, we need to create a WebClient object using:

$WebClient = New-Object System.Net.WebClient

To download the Twitter search results we use the DownloadString method like:

$WebClient.DownloadString("http://search.twitter.com/search.atom?q=powerclibook+magictweet")

The downloaded Atom result is actually an XML formatted string. In order to process the result as actual XML instead of a string we need to convert the string into the XML type. This is also referred to as type casting.

$searchResult = [xml]$WebClient.DownloadString("http://search.twitter.com/search.atom?q=powerclibook+magictweet")

So far so good. We now have our Twitter search results. We can retrieve the individual tweets through the .feed.entry property, however there are only 15 tweets present by default in our search results. This is where the additional -rpp parameter kicks in. Using this parameter we can override the default of 15 tweets per page to a maximum of 100 tweets per page. The returned number of tweets per page can also be found in the .feed.itemsPerPage property.  Let’s try the search again using the -rpp parameter:

$searchResult = [xml]$WebClient.DownloadString("http://search.twitter.com/search.atom?q=powerclibook+magictweet&rpp=100")

[vSphere PowerCLI] C:\scripts> $searchResult.feed.itemsPerPage

100What if we want to retrieve more than 100 results? This is where we get to use the -page parameter. With the -page parameter you define the page number that gets returned. The number of pages is determined by the total number of search results (maximum is 1500) divided by the results per page (rpp). Fortunately we don’t have to determine how many pages are available to us, because Atom provides a link model that allows us to easily browse pages. The Atom links are stored under the .feed.link property.

[vSphere PowerCLI] C:\scripts> $searchResult.feed.link

type                       href                       rel
----                       ----                       ---
text/html                  http://search.twitter.c... alternate
application/atom+xml       http://search.twitter.c... self
application/opensearchd... http://search.twitter.c... search
application/atom+xml       http://search.twitter.c... refresh

In order to retrieve the next page we only have to retrieve the appropriate URL from the .feed.link property and use that URL with the .DownloadString method of our WebClient.

$url = ($searchResult.feed.link | ?{$_.rel -eq "next"}).href  
$nextResult = [xml]$WebClient.DownloadString($url)  

Now we only need to put all the pieces together to retrieve all re-tweeted magic tweets.  

$WebClient = New-Object System.Net.WebClient  
$url = "http://search.twitter.com/search.atom?q=powerclibook+magictweet&rpp=100"  
$tweets=@()  
while ($url) {  
    $searchResult = [xml]$WebClient.DownloadString($url)  
    $tweets += $searchResult.feed.entry  
    $url = ($searchResult.feed.link | ?{$_.rel -eq "next"}).href  
}  

To make things easier and reusable, I’ve created a Search-Twitter function using this code.  

function Search-Twitter {
<#
.SYNOPSIS
  Finds tweets on Twitter
.DESCRIPTION
  This function finds tweets on Twitter that match the query provided by the -query parameter.
  A WebClient needs to be defined in the $Global:WebClient variable. If no WebClient is found, a default WebClient will be created.
.NOTES
  Author:  Arnim van Lieshout
.PARAMETER Query
  The search query
.PARAMETER All
  An optional switch parameter to retrieve the maximum number of tweets. By default only the first page will be returned
.EXAMPLE
  PS> Search-Twitter -Query "PowerCLI"
.EXAMPLE
  PS> Search-Twitter -Query "PowerCLI" -All
#>

	param(
		[Parameter(Mandatory = $true, Position = 0, HelpMessage = "Enter the search query")]
			[String]$Query,
			[Switch]$All
	)

	$url = "http://search.twitter.com/search.atom?rpp=100&q=$Query"

	if (!$WebClient) {$Global:WebClient = New-Object System.Net.WebClient}

	$messages = @()
	if ($All) {
		while ($url) {
			$searchResult = [xml]$WebClient.DownloadString($url)
			$messages += $searchResult.feed.entry
			$url = ($searchResult.feed.link | ?{$_.rel -eq "next"}).href
		}
	}
	else {
		$searchResult = [xml]$WebClient.DownloadString($url)
		$messages += $searchResult.feed.entry
	}

	$messages
}

Collecting The Magic Tweets

Using our newly crafted Search-Twitter function we collect the re-tweeted magic tweets and save some information about the tweet and the user in a custom object. Because the maximum number of returned search results is 1500 and search results aren’t kept forever on Twitter (the Twitter history only goes back to approximately four days), we run our script on a daily basis and export the results to an XML file.  

#COLLECT TWEETS
$WebClient = New-Object System.Net.WebClient  

$tweets = @()
foreach ($item in (Search-Twitter "powerclibook+magictweet" -All)) {
	$obj = "" | Select user_id, user, user_name, user_uri, profile_image_url, published, text, source

	$obj.user = $item.author.uri.split('/')[-1]
	$userInfo = [xml]$WebClient.DownloadString("http://api.twitter.com/1/users/show.xml?screen_name=$($obj.user)")
	$obj.user_id = $userInfo.user.id
	$obj.user_name = $userInfo.user.name
	$obj.user_uri = $item.author.uri
	$obj.profile_image_url = ($item.link | ?{$_.rel -eq "image"}).href
	$obj.published = [DateTime]$item.published
	$obj.text = $item.title
	$obj.source = $item.source

	$tweets += $obj
}

$tweets | Export-Clixml C:\Scripts\PowerCLIBookRaffle_$(get-date -Format yyy-MM-dd).xml

Notice that we also used the Twitter API to retrieve user information. We decided to use the Twitter user id as the user’s ticket number for our raffle. This way we can ensure that only one ticket per user is issued, regardless of the number of times the user re-tweeted the magic tweet.

The Draw

After collecting all the re-tweeted magic tweets, it’s time to draw one lucky winner. First we need to read all saved search results. Because we collected the tweets on a daily basis and some users re-tweeted the magic tweet multiple times, there are duplicates and we need to de-duplicate the collected tweets first before we can actually draw the winner. To keep the raffle fair, we also decided to exclude the authors from entering the draw.  

In order the retrieve our saved search results, we can simply import then using: 

#Import tweets
$tweets = @()
$tweets = Get-ChildItem "C:\Scripts\PowerCLIBookRaffle*" | Import-Clixml

Because of the duplicates, we need to de-duplicate the $tweets array. This can easily be achieved using the Sort-Object cmdlet. 

#Dedup tweets
$tweets = $tweets | Sort-Object -Property user_id -Unique

Next task is removing the authors.   

#Remove authors
$authors = @("alanrenouf","LucD22","avlieshout","jonathanmedd","glnsize")
$tweets = $tweets | ?{$authors -notcontains $_.user}

To simulate the process of mixing the tickets in the jar, we switched 2 random objects in the array multiple times. Using the code below we switched tickets 10.000 times:  

#Mix tickets
1..10000 | %{
	$random1 = Get-Random -Minimum 0 -Maximum $tweets.count
	$random2 = Get-Random -Minimum 0 -Maximum $tweets.count
	$tempObject = $tweets[$random1]
	$tweets[$random1] = $tweets[$random2]
	$tweets[$random2] = $tempObject
}

The last task to do is to actually draw the lucky winner:     

#Draw the lucky winner
$winner = $tweets | Get-Random
$winner

References

Twitter Search API Documentation – http://search.twitter.com/api/
Twitter Developer Documentation – http://dev.twitter.com/doc
The Atom Link model – http://www.xml.com/lpt/a/1434

Related posts:

1. PowerCLI Book Update
2. PowerShell / PowerCLI linkage
3. Rescan VMware vSphere Hypervisor (ESXi) using PowerCLI simplified

It has been quite a journey, but it has finally arrived. Today our book: “VMware vSphere PowerCLI Reference: Automating vSphere Administration” will be released by Sybex. The journey started about a year ago when Alan Renouf and Luc Dekens decided to write a PowerCLI book that should have a practical approach to vSphere administration. Later that year they contacted 3 co-authors to help them out in order to keep meeting the deadlines. The PowerCLI book team was born and the book was to be written by “4 vExperts and a MVP”.

From this point I would like to personally thank Alan and Luc for the opportunity to realize a dream. I would also like to personally thank Mary Ellen Schutz, Developmental Editor, for transforming my technical gibberish into readable and most importantly understandable language. Last but not least I would like to personally thank our Technical Editor, Stuart Radnidge. He left no script unturned and served as the gatekeeper, ensuring that any code you find in the book will run the first time, every time. You might think that’s all there is to it, but then you’re wrong. I’ve never written a book before and I was impressed by the number of people that were involved behind the scenes in this book thing. On the Sybex team there were numerous people involved including but not limited to: Editorial Manager, Acquisition Editor, Production Editor, Copyeditor, Indexer, Proofreader and Compositor. Without each of their contributions, this book would have never made it to the presses.

Target Audience

The book is, of course, primarily targeted at administrators of vSphere environments who want to automate tasks. But the subjects that we discuss in the book cover so many aspects of the management of a VMware vSphere environment that everyone who comes into contact with a VMware vSphere environment will be able to pick up something useful.

In our day-to-day contact with PowerCLI users, we noticed that most of them start with what we like to call the reporting phase. Thanks to the natural look and feel of PowerShell and PowerCLI, it is quite easy for beginners to produce impressive reports about their vSphere environment. That’s why we included several chapters on different types of reporting. The somewhat more advanced user will go into the configuration phase. That is the moment when you start changing settings on your virtual guests and in the vSphere servers. There are an extensive number of chapters for this phase in the book.

The ultimate phase you can achieve through the use of PowerCLI is the process automation phase. As an administrator, you are now going to automate complex processes in your vSphere environment. This process can range from automating the deployment of vSphere servers all the way to automating the switch to a disaster recovery center. Again, the book offers several chapters for this phase.

What’s inside

This book shows you how you can use PowerCLI to automate your administrator tasks—not an alphabetical listing of the 250+ PowerCLI cmdlets—but a practical guide with example scripts that you can use immediately in your environment. The chapters are organized in such a way that each of them reflects a specific type of task. You probably already have done most of these tasks more than once. Now, we will show you how to automate them. In other words, you script them once and run them multiple times.

The book consists of 5 parts:

Part I: Install, Configure, and Manage the vSphere Environment
Chapter 1 through Chapter 4 show you how to automate the installation and configuration of your VMware vSphere environment. They include the vCenter server, the ESX and ESXi servers, storage, and networking as well as some advanced vSphere features like host profiles and dvSwitches.

Part II: Managing the Virtual Machine Life Cycle
Chapter 5 through Chapter 9 tackle all the automation aspects of guests—from creating a virtual machine over linked clones and svMotion all the way to vApps. We will show you how to mass-deploy a number of guests and how to manipulate snapshots.

Part III: Securing Your vSphere Environment
In Chapter 10 through Chapter 13, we discuss the security aspects of your VMware vSphere environment. First, we show you how to handle backups and restores. Then, we continue with the automation of your disaster recovery. Patching and hardening of your environment conclude this part.

Part IV: Monitoring and Reporting
Chapter 14 through Chapter 17 show how you can automate all the reporting aspects of your VMware vSphere environment. These chapters discuss how to report on the physical hardware, virtual hardware, and the configuration parameters; how to gather statistical data for performance and capacity planning reports; how to create an audit trail; and how to monitor the environment.

Part V: Scripting Tools and Features
In Chapter 18 through Chapter 23, we expand on the automation scripts themselves. We’ll show you how you can schedule your scripts, how to use the methods and properties from the SDK in your scripts, and how to use Onyx to help you with the SDK methods and properties. You’ll learn how to run your scripts in graphical environments like PowerGUI, and how to provide your own graphical interface for your scripts. We also introduce PowerWF Studio, a novel way to work with PowerShell and the PowerCLI snap-in.

A complete table of contents can be found on www.powerclibook.com or even better, have a look inside the book on amazon.

As you might already know, we created a dedicated website at www.powerclibook.com, to provide you with any additional information regarding our book. If you have any book related questions, please visit our PowerCLI book forum and let us know.

We hope that you will enjoy reading this book as much as we did writing it.

Related posts:

1. Setting custom attributes with VMware PowerCLI
2. Rescan VMware vSphere Hypervisor (ESXi) using PowerCLI simplified
3. PowerCLI Book Update

Today VMware announced the release of the vSphere Client for iPad. The first great thing is that you can download the vSphere Client for iPad from Apple’s iTunes Store for FREE! The second great thing is that it looks really awesome and the interface is very intuitive.

VMware is taking mobility very seriously as this is their second application specifically for the iPad. Recently VMware released the VMware View Client for iPad. The vSphere Client for iPad isn’t meant to be a fully functional equivalent for the existing Windows client, but allows you to do the most common tasks, according to VMware. With the current release, the functionality offered by the vSphere Client for iPad is:

• Search for vSphere hosts and virtual machines
• Monitor the performance of vSphere hosts and virtual machines
• Manage virtual machines with the ability to start, stop and suspend
• View and restore virtual machines’ snapshots
• Reboot vSphere hosts or put them into maintenance mode
• Diagnose vSphere hosts and virtual machines using built-in ping and traceroute tools

The ability to manage your vSphere environment with a mobile device isn’t new, as VMware already provides the vCenter Mobile Acces (vCMA) virtual appliance. If you’re familiar with this vCMA, you might recognize the vSphere Client for iPad’s functionality. In fact it’s built on top of this vCMA. The vCMA is required in order for the vSphere Client for iPad to function and can be obtained from VMware free of charge at http://labs.vmware.com/flings/vcma The latest version of the vCMA has now SSL configured by default, to make sure your connection is secure. Because you connect to the vCMA virtual appliance using standard SSL, you can easily use the vSphere Client for iPad to connect to the vCMA through a firewall to manage your vSphere environment.

Setting up your environment

Part 1: Configure vCMA Virtual Appliance

1. Extract the zip file to a temporary directory, for example c:\temp. The files contained in the zip file include:
   • vCenterMobileAccess-1.x.y.z.ovf
   • system.vmdk
2. Launch the vSphere client and log into your vSphere Host or vCenter Server.
3. In the inventory view, select the menu File -> Deploy OVF Template…
4. Select “Deploy from a file or URL”, browse to the OVF file, and follow the wizard next steps.
5. In the “End User License Agreement” page, read the license agreement completely and click on the “Accept all license agreements” and continue the steps.
6. In the “Name and Location” page, provide the name for your Virtual Machine.
7. Once the wizard completes, a virtual machine will be created. Select the virtual machine and power it on.
8. You can then add the appliance to your DNS server. This step has to be done manually; you can use only the IP address if you prefer but you can also enter a host name for the appliance.

VMware also released a video to show you how to setup the vCMA.

NOTE: After the vCMA virtual appliance is deployed, you might notice that it is still at virtual hardware level 4. I guess that’s done for backwards compatibility. You can upgrade the vCMA virtual appliance to virtual hardware level 7, if you deployed it on vSphere.

With the vCMA in place, it’s time to get the vSphere Client for iPad set up.

Part 2: Configure & use the iPad app

1. Download the vSphere Client for iPad application from the iTunes Store.
2. Once the vCMA virtual appliance powers on, on the home screen of the iPad go to “Settings”, scroll down and tap on “vSphere Client”. Now enter the IP Address of the vCMA virtual appliance in the “Web Server” field (see image).
   
3. Ensure your iPad has connectivity to the vCMA virtual appliance. This may entail configuring the iPad’s built-in VPN client. Consult Apple’s documentation on configuring the built-in VPN client.
4. Launch the vSphere Client for iPad application and enter the host, username and password for the vCenter Server or vSphere Host you wish to connect to
   

VMware also released a video to show you how to configure and use the vSphere Client for iPad

First impression

I haven’t had the opportunity to play with the vSphere Client for iPad myself. Watching the video provided by VMware, I was really impressed by the interface’s look and feel, but I also noticed a couple of shortcomings. When you’re logged into your environment, you are presented with a list of hosts that are available to you. What about your clusters? If you have a problem in a cluster, do you know which hosts belong to that cluster? Or just the other way around; when I have a problem with a host, I want to know which cluster (and client) is affected.

Monitoring your host is still limited to the core four: CPU usage%, Memory usage%, Disk KBps and Network KBps. The same is true for virtual machine monitoring. Additional information like memory ballooning or swapping is still missing, which is something you would definitely be interested in when performance is bad and I also haven’t seen an option to view alarms

Another thing I noticed is the big Restore button on the virtual machine’s snapshots when viewing the virtual machine’s page. Shouldn’t this read “Go to” or “Revert to”? I don’t know wether I favour Go to, Revert or Restore, but I do favour consistency amongst the vSphere Clients. Again missing functionality is the ability to create or delete snapshots. Also the ability to migrate a virtual machine to another host is missing in this release.

Conclusion

The vSphere Client for iPad is definitely a 1.0 product, looking at functionality at this stage. But don’t get me wrong; I do like this product and I think it has a lot of potential. The look and feel of the interface is great and very intuitive, but more functionality needs to be added to be truly useful. But again I think it’s a great application and VMware has put a lot of effort in designing the interface specifically for mobile devices. I think you should definitely add it to your management gear. You never know when it might come in handy. That said, don’t underestimate the power of the vCMA. Some of the shortcomings I mentioned earlier are available directly from the vCMA. Just point the browser on your iPad to the IP address or DNS name of the vCMA. When logged into the vCMA, you’ll notice the ability to migrate virtual machines, see your clusters, view and run scheduled tasks, view alarms, view the virtual machine’s settings, create snapshots, and so forth. I think it’s very likely that this functionality will be added to the vSphere Client for iPad in one of  the future releases. VMware is planning to release updates on a IOS-frequency instead of vSphere-frequency, so my guess is that this app will evolve quickly and we don’t have to wait that long for fucntionality like vMotion to become available.

VMware has opened a community site for the vSphere Client for iPad. You can visit the iPad Client community at http://communities.vmware.com/community/vmtn/vsphere/ipadclient, where you can go for support and additional information.

Related posts:

1. Brocade Network Advisor Management Plug-in for VMware vCenter
2. Critical 2009 last-minute ESX3.5 patches
3. PowerCLI 4.0 Update 1- Another leap forward

While preparing some disaster recovery (DR) tests, I had to add and remove a couple of LUNS from several ESX hosts in different clusters. Doing so,  I had to rescan a lot of host bus adapters (HBA) several times. As I hate doing repetitive tasks in a graphical user interface (GUI), I always find myself quickly turning to the PowerCLI console. The PowerCLI command to rescan an ESX host is somewhere hidden in the Get-VMHostStorage cmdlet. This isn’t the most logical location and every time I have to perform a rescan operation I have to search for the correct command line syntax.

Today I decided to simplify that process and created a little PowerCLI function to simplify this task. The function I created is called Rescan-VMHost and accepts an ESX host name or host object as input parameter.

Rescan-VMHost ESX01

The function also accepts host names or host objects from the pipeline. The optional -IncludePeers switch rescans all hosts in the given ESX host’s cluster additionally.

Get-VMHost ESX01 | Rescan-VMHost -IncludePeers

As an extra bonus feature the function also accepts a cluster object as input parameter and will rescan all ESX hosts in the given cluster.

Get-Cluster CL01 | Rescan-VMHost

Pretty cool huh?
I’ve already used this little function a lot and hope you find a use case for it too.

One last thing. Although the title of this post might suggest that this function works on ESXi only, that is NOT the case. The function will work on both ESXi and ESX, but since VMware decided to go solely with ESXi and refers to it as the VMware vSphere Hypervisor, I decided to follow that path and hence the post’s title.

function Rescan-VMHost {
<#
.SYNOPSIS
  Performs a rescan operation on a specified ESX host or cluster
.DESCRIPTION
  This function rescans an ESX host or it's complete cluster when the -IncludePeers parameter is specified.
.NOTES
  Author: Arnim van Lieshout,
.PARAMETER Entity
  Specifies the hostname, host object or cluster object to perform the rescan operation on.
.PARAMETER IncludePeers
  Specifies that all the hosts in the host's cluster should be rescanned instead of only the host itself.
.EXAMPLE
  PS> Rescan-VMHost ESX001
.EXAMPLE
  PS> Get-VMHost ESX00* | Rescan-VMHost -IncludePeers
.EXAMPLE
  PS> Get-Cluster CL01 | Rescan-VMHost
#>

	Param (
		[parameter(valuefrompipeline = $true, mandatory = $true,
		HelpMessage = "Enter an ESX(i) entity")]
			[PSObject]$Entity,
		[Switch]$IncludePeers)

	process {
		switch ($Entity.gettype().name) {
      		"String" {
				if ($IncludePeers) {Get-VMHost -Name $Entity | Rescan-VMHost -IncludePeers}
				else {Get-VMHost -Name $Entity | Rescan-VMHost}
			}
      		"VMHostImpl" {
				if ($IncludePeers) {
					foreach ($VMHost in Get-Cluster $Entity.Parent | Get-VMHost) {
						$VMHost | Get-VMHostStorage -RescanAllHba
					}
				}
				else {
					$Entity | Get-VMHostStorage -RescanAllHba
				}
			}
      		"ClusterImpl" {
				foreach ($VMHost in $Entity | Get-VMHost) {
					$VMHost | Get-VMHostStorage -RescanAllHba
				}
			}
      		default {throw "No valid object type for parameter -VMHost specified"}
	    }
	}
}

Related posts:

1. ESXi Tech Support Mode
2. PowerCLI 4.1 namespace changes
3. Collect VMware ESX Host PCI Device Information