The VMware PowerPack has now come back under the PowerGUI installation wizard and is part of PowerGUI 2.3 which can be downloaded from the PowerGUI site here.

Lest I start in again on how much I love PowerGUI and PowerCLI for managing your VMware environment, let’s just revisit the topic here.

Connect-VIServer YOURvCENTERNAME

$Information = @()
Foreach ($VM in (Get-VM | Sort Name | Get-View)){
$MyDetails = "" | Select-Object VMName,VMXLocation
$MyDetails.VMName = $VM.Name
$MyDetails.VMXLocation = $VM.Config.Files.VmPathName
$Information += $MyDetails
}
$Information |Export-Csv -NoTypeInformation C:output.csv

This little report is a nice bit of insurance to have, let me tell you…

Connect to your vCenter server and specify a host (I’m going host-by-host here since I’m working on a cluster already in production, maintenance-mode’ing each host as I got):

> Connect-VIServer vcenterhostname

Then, to see which path is set to fixed, the default:

> Get-VMHost esxhostname | Get-ScsiLun -LunType disk

Which nets me this:

CanonicalN ConsoleDeviceName LunType CapacityMB MultipathPolicy
ame
---------- ----------------- ------- ---------- ---------------
naa.600... /vmfs/devices/disks/naa.600... disk 417792 RoundRobin
naa.600... /vmfs/devices/disks/naa.600... disk 71680 Fixed
naa.600... /vmfs/devices/disks/naa.600... disk 417792 RoundRobin
naa.600... /vmfs/devices/disks/naa.600... disk 512000 Fixed
....

So in this case, where I’ve got an active/active array and want RoundRobin everywhere, the fix is simple and a lot less painful than going through the GUI:

> Get-VMHost esxhostname | Get-ScsiLun -CanonicalName “naa.6006*” | Set-ScsiLun -MultipathPolicy “roundrobin”

Which nets me this:

CanonicalN ConsoleDeviceName LunType CapacityMB MultipathPolicy
ame
---------- ----------------- ------- ---------- ---------------
naa.600... /vmfs/devices/disks/naa.600... disk 417792 RoundRobin
naa.600... /vmfs/devices/disks/naa.600... disk 71680 RoundRobin
naa.600... /vmfs/devices/disks/naa.600... disk 417792 RoundRobin
naa.600... /vmfs/devices/disks/naa.600... disk 512000 RoundRobin
....

Specifying the canonical name keeps the scope of any changes we’re making here to my FC LUNs. Hats off to Paul Woodward for keeping my repetitive stress injury to a minimum this morning by keeping me out of the GUI. Thank you!

• the awesome Backup & Replication 5
• Monitor Plus and Business Reporter

If you’re running a home lab, you kind of owe it to yourself to get a simple install of their products up and running. Diving more and more into their monitoring tools, as well as having Replication save my butt on a remote office move recently, I’ve got nothing but high regard for what Veeam offers to the virtualization community – and today? What it offers the virtualization community for free. Props to virtualization.info for the heads up!

Connect-VIServer vcenterhost

$VMFolder = @()
Foreach ($VM in (Get-VM |Get-View)){
$Details = "" |Select-Object VM,Path
$Folder = ((($VM.Summary.Config.VmPathName).Split(']')[1]).Split('/'))[0].TrimStart(' ')
$Path = ($VM.Summary.Config.VmPathName).Split('/')[0]
If ($VM.Name-ne $Folder){
$Details.VM= $VM.Name
$Details.Path= $Path
$VMFolder += $Details
}
}
$VMFolder |Export-Csv -NoTypeInformation C:Mismatch.csv

Simply replace vcenterhost with your vCenter’s name and go for it.

In trying to tighten up some monitoring issues in the current environment I’m working in, I did what most people would think to do – I turned on some alarms in vCenter, specifically “Host connection and power state.” I kinda want to know when hosts just drop off the face of the planet, right? To get a feel for how this environment is running, I had that alert send me an email when it detected a host disconnect – and started getting 20-30 alerts a day. I then saw that all my hosts were fine. They weren’t dropping or disconnecting. Well, this is going to take some work, right? Read on…

Turns out, there’s a VMware KB article that speaks to these alerts that suggests increasing a SSL timeout value in the hostd config file at /etc/vmware/hostd/config.xml. This seems to helpful for us, having many hosts with varying states of WAN connectivity to vCenter. Adding that timeout is pretty simple – specifically, you find the first set of <ssl> tags, and add the following line:

<handshakeTimeoutMs> 120000 </handshakeTimeoutMs>

Your config.xml file will end up looking like this:

<ssl>
<doVersionCheck> false </doVersionCheck>
<useCompression>true</useCompression>
<handshakeTimeoutMs> 120000 </handshakeTimeoutMs>
</ssl>

Once you save off your config.xml file, go ahead and restart hostd:

service mgmt-vmware restart
service vmware-vpxa restart

If you want to make sure that this change has taken effect, tail the hostd log at /var/log/vmware/hostd.log and look for the following line:

[2010-12-06 08:48:48.489 F66D86D0 info 'App'] Vmacore::InitSSL: doVersionCheck = false, handshakeTimeoutUs = 120000000

Adding that timeout value of 120000 milliseconds (or 2 minutes) seems to have drastically reduced the number of false alarms I’m seeing. As for the effect of adding this timeout? According to VMware support, this simply gives an ESX host a little bit more time to respond before vCenter will alert you on it connection. You obviously don’t have to go to 2 minutes right off the bat - experiment with lower timeout thresholds to find the sweet spot for specific, problematic hosts.

One of the best features of the latest PowerGUI / VMware Infrastructure Management release? An incredibly useful dropdown list of common vSphere gotchas to look for (click the thumbnail for a list of ‘em). As I come on board a new organization with a more diverse administration personnel model for vSphere, this list of queries has enabled me to very quickly identify some problems that could grow into larger issues – and to fix them almost as quickly.

Finding a terabyte of orphaned .vmdk files just made me a pretty valuable employee today…

"C:Program Files (x86)VMwareInfrastructureVirtual Infrastructure ClientLauncherVpxClient.exe" -u domainusername

This will launch the client with the user name pre-populated with domainusername, which is super handy for me since I log into all of my vCenters using an admin account. Other switches:

-s hostname to specify a specific host or IP address

-p password to specific a password. Used with -u, ie: -u username -p password

Much thanks to Jason Boche’s original post on this, which is now saving me some typing every day…

According to VMware support, ESX will not  go any further in trying to shut down your VM – it will not just kill the process of that VM running in memory. If ESX can’t perform a graceful shutdown of a VM it will stop trying to get that VM process shut down.

That’s an important thing to understand and remember and directly speaks to what we saw: when some of our ESX hosts regained network connectivity, we had the classic split-brain scenario. We would open the console to a VM, see a BSOD, and power off the VM – and then almost immediately see the running operating system in that same console window. What we were watching was the BSOD process on the formerly-isolated ESX host being stopped, replaced by the healthy process of the VM when it was brought up on one of the surviving hosts.

So some take-away from this event?

• Once we realized that we had lost both the Service Console connection and the NFS datastore connection, we simply should have taken note of what VMs were still running in memory by using esxtop and then powered off the ESX host until the network outage was resolved. The other surviving hosts were already booting up the VMs. The key here, obviously, is that this is a manual process – if this outage occurred and resolved itself before we could get to the isolated hosts we’d still end up with a split-brain problem.
• We might want to reconsider our use of NFS and it’s dependence on network connectivity to the datastores. This major outage interrupted TCP/IP traffic at many different layers of the network, to the point where NIC redundancy and failover did not occur. It’s been my experience that FC SAN, while more expensive, also has been more robust and less prone to outages – the vast majority of our outages involving ESX have been Ethernet-related problems.

• Support for deleting snapshots while the VM is running
• Support for multi-monitor guest setups in the GUI for Windows guests
• RDP video acceleration
• Memory ballooning to dynamically in- or decrease the amount of RAM used by a VM (64-bit hosts only)

As you might already know, VirtualBox is my favorite virtualization product for the desktop because of it’s rich feature set and support for both Windows and Mac. I recently scored over a 90% on my VCP exam in no small part to the ability to run a Windows VM on my Mac, allowing me to mobilize my study environment with ease. If you’re looking to simply get into virtualization with ease, and for free, VirtualBox is definitely worth the download and minimal install footprint.

http://www.virtualbox.org/