Archive for the ‘PowersHell’ Category

Well, now I have upgrade to vSphere 4 U1, I’m just doing an upgrade of the PowerCLI (VMware’s addition of some 200+ cmdlets together with access to the VMware SDK too). I’m avid fan and believe in the powers of PowerCLI. Although I wouldn’t claim to be the warrior monk status of Hal, Luc or Al…

PowerCLI has been overhauled with a whole new raft of cmdlets which will go a long way to shortening my PS1 scripts. That said I don’t when I’m gonna get the time replace my lengthy referrences to much short cmdlets.

If you want to download and install the latest PowerCLI you will find it here:

http://communities.vmware.com/community/vmtn/vsphere/automationtools/windows_toolkit

I’ve been looking at the new cmdlets and trying to make a hit list one’s I should look at first. So what my personal favourites/highlights by looking at the release notes:

• Managing the failover and load-balancing policies of VirtualSwitch and VirtualPortGroup objects with Get-NicTeamingPolicy and Set-NicTeamingPolicy. Previously, these setting were only accessible by navigating the complicated SDK environment
• Working with host storages and iSCSI HBA devices with Get-VMHostHba, Set-VMHostHba, Get-iScsiHbaTarget, New-iScsiHbaTarget, Remove-iScsiHbaTarget, Set-iScsiHbaTarget, and Set-VMHostStorage. Previously, these setting were only accessible by navigating the complicated SDK environment
• Upgrading hosts with Install-VMHostPatch
• Running BAT (Windows) and BASH (Linux) scripts with Invoke-VMScript. I think these cmdlets maybe very useful in the SRM environment.

• Uploading firmware packages with Set-VMHostFirmware.
• Extending, cloning, inflating, and reallocating virtual hard disks with Copy-HardDisk, New-HardDisk, and Set-HardDisk. I’m hoping these cmdlets will able tell me if my virtual disk is eagerzeroedthick – the format valid for VMware Fault Tolerance. The conversion process can take sometime – so it will be helpful to know because it factors into your maintenance windows.

[Er, actually spell checked this (for once) so removed the very worse of my typos/spelling...)

I was training last week - VMware View product. To be truthful it’s not product I’m especially enamoured off. I find its admin tool crude and limiting especially… users don’t seem to mind it however, but then they don’t really give a crap what the broker is, so long as they get their desktop and email. Anyway, I’m expecting/hoping for good things in the next release - not that I would know anything about that - I can’t get on the beta programme despite having more v’s after my name than is really seemly (vExpert, VCP, VCI, vImportant).

Anyway, grumbling aside - one of my student pitched a usage case to me and asked me if I thought VMware View could deliver. In the first instance you would want to recommend “Lab Manager” for this guys usage case - but I know that a budget for yet-another-management-product-from-vmware would probably not be there - it was up to me to trying cobble something together. Here’s the usage case. He wants his developers to get a desktop - install stuff and generally **** around with the desktop - but then give them an easy way to reset the desktop back to clean state. At the moment they have vCenter access to use snapshots/revert to snapshot - but they aren’t keen on giving them access to vCenter… They want to do it via View. Of course, non-persistent pools could help in this case - they have a feature which allows you to delete (and create a new) a virtual desktop at logoff. But both myself and this guy could see that rather than disconnecting one day a developer would logout - to find out their work was destroyed. I guess a bit of redirection and hardening could force them to store their stuff outside of the desktop was a possibility - but my guy was trying to aviod bolting them down…

So I hit upon this idea:

• Create a persistent pool of desktops
• Let them power up and sysprep themselves
• Use PowerCLI to shut them all down
• Change the Disk Mode on the OS drive to be independent mode with non-persistent
• Set the Desktop Pool to “Ensure VM is always powered on” and “Allow users to reset desktop”

This means if the developer in the virtual desktop hard shutdown their desktop OR use the Reset Desktop option in the  View menu. Their desktop would be reset to its previous state

This works fine as a concept but falters in two places. If the developer did a restart of Windows with the NT Security dialog box – they View Agent didn’t appear to restart properly (I figured I could write a powershell script to handle that which would run within the developers virtual desktop – the downside of which leaves me into giving them access to vCenter – which if you recall my guy was trying to aviod…)

The second place it falters in the use of non-persistent mode on a virtual disk. I was reading through the help file on the Set-HardDisk (which supports changing the disk mode of a VM) cmdlet when I came across this statement:

“Specifies the disk persistence mode. The valid values are: Persistent, NonPersistent, IndependentPersistent, IndependentNonPersistent, and Undoable. This parameter is supported only when the disk type is set to “rawVirtual” or “flat”. Note that the ‘NonPersistent’ and ‘Undoable’ persistence policies are deprecated and will be discontinued in future releases. Their usage is not recommended because they do not work with snapshots and are not supported on ESX 3.5 and higher.”

This was taken from a machine running the new PowerCLI 4.0 which is compatible with vSphere4…

The operative word is “deprecated”. It’s a special word used by VMware which you rarely hear from other vendors. I put up there with the usage of the word “experimental”. Occasionally, VMware deprecated a feature – it’s a rather artful way of saying “You know that feature you liked, understood and wrote scripts and procedures for… well, my friend – were removing it.” Just like that. No consultation.

It’s not first time I’ve come across with VMware this – for example in ESX3.x.x the old ESX2.x.x command vmkpcidivy got deprecated because it was no longer relevant. Similarly, the functionality of esxcfg-vmhbadevs in ESX3.x.x got deprecated in ESX4.xx. favour of another utility that provides much better functionality.

You see I don’t have problem with “ deprecated” especially when a new method is better or the old method is simply irrelevant. Beside which I think we can all agree we don’t want software bloated out with old procedures/utilities/code which is no longer needed. That would make you like other ISVs which will remain nameless!

But what irks me about it is the arbitrary nature of it. You never quite know when a feature might get deprecated on you (such as the shink feature in VMware Tools). Often the deprecated process seems quite arbitrary, especially when it happens within a product release – if it happened between two major product releases that could be understandable/excusable. But when it happens within a product release occasionally, it feels a bit odd. Can you imagine the manufacturer of your car deprecated the wing mirrors of car after you have bought it?

Clearly, vendors do reserve the right to discontinue models, but they don’t tend to remove features during the lifetime of a model. So model 3.0.2 of a car has wing mirrors, but in the 3.5 upgrade which they forced you to move up to keep your service plan they deprecated it.

Anyway, back to my powershell. I decide to ignore the advice. I used:

get-vc virtualcenter4.vi4book.com –user administrator –password vmware

stop-vm -vm (get-vm -name devdesktop*) -confirm:$false

get-vm -name devdesktop* | Get-HardDisk | Set-HardDisk -Persistence IndepedentNonPersistent

In short you can configure non-persistent mode on virtual disk in the vSphere4 client, and you can do it with the PowerCLI. But you run the risk if use this feature of being deprecated at some unspecified point in the future…

Anyway, what to say to my customer? Set non-persistent using PowerCLI, and but beware of upgrades could stop these scripts/function working in the future?  Offering him snapshots powersHell scripts instead? (This is what I’ve done)  Sell him a product (lab manager) he doesn’t desire or have a budget for?

Your deprecatedly
Mike Laverick….

Well, this particular configuration has been outstanding for me for more than month – and I’ve finally cracked it (albeit with a little help from my friends… beatles referrence geddit…?) Borrowing from Carter Shaklin’s example of enabling FT Logging – I found a method of doing this:

You have to be little bit careful when you run this script. You don’t need this script with ESX “Classic” which uses the Service Console. For that you can use the -consoleNIC parameter to make sure the new VMHostNetworkAdapter is a vswif interface rather than a vmkernel interface

$vs3 = vSwitch3
$HAheartbeat = New-VirtualPortGroup -VirtualSwitch $vs3 -Name HA-Heartbeat
New-VMHostNetworkAdapter -PortGroup HA-Heartbeat -VirtualSwitch $vs3 -IP $HAheartbeatIP -SubnetMask 255.255.255.0 -ConsoleNic

To do the same for ESXi you have dig into the SDK using the data object virtualNicManager held with configManager to set the “Management Traffic” attribute.

$hView = Get-VMHost esx4.vi4book.com | Get-View -Property configManager
$nicManager = Get-View $hView.configManager.virtualNicManager
$nicManager.SelectVnicForNicType("management", "vmk2")

The only slightly annoying thing about this PowersHell is don’t think I would have found these parameters without the help of the PowerCLI product manager – I’m trying to work out how he found these values – it could wind-up being an internal engineering thing, than something in the public domain. Well, it is public now

I suspect the that SelectVnicForNicType companion QueryNetConfig was used to find out the variables on an existing configured ESXi host to find out the values for ”faultToleranceLogging” and “management”. I wasn’t so clever, I worked out “management” by guessing!

Update:

Anyway, later after posting this the Product Manager for the PowerCLI ping’d me an email with URL showing where the values of “management”, “vmotion” and “faultToleranceLogging” were held on the

http://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/vim.host.VirtualNicManager.NicType.html

I had a post/comment on my blog this week about enabling FT logging on VMKernel Port. It wasn’t immediately apparent how to do this – so I ask Carter Shanklin who is Product Manager of PowerCLI for a “how to“. True to form he’s come up trumps.  This is what he’s sent me. Not had a chance to test it just yet. But will be post it here for the folks who asked me…

# Enable or disable FT logging.
$esxHost = "192.168.1.11"
$vmKernel = "vmk0" # You can get these out of Get-VMHostNetwork
$enable = $true
$hView = Get-VMHost $esxHost | Get-View -Property configManager
$nicManager = Get-View $hView.configManager.virtualNicManager
if ($enable -eq $true) {
	$nicManager.SelectVnicForNicType("faultToleranceLogging", $vmKernel)
} else {
	$nicManager.DeselectVnicForNicType("faultToleranceLogging", $vmKernel)
}

Update:

Anyway, the original poster of that comment David Gontie got back in touch with me – with away of doing the same thing from the kickstart install %post script. Personally, I’m weening myself off my beloved COS in favour of Powershell. But here’s David’s full blog post on how its done:

http://vmware-for-starters.blogspot.com/2009/09/kickstart-and-ft-logging.html

vmware-vim-cmd hostsvc/advopt/update FT.Vmknic string vmk1

Where vmk1 is the second vmkernel port. I found you had to restart the management services to make sure the vSphere Client reflected the changes (service mgmt-vmware restart)…

Well, actually its day 4 now so I’m a bit behind in the blogging. Don’t worry I’ve made copious notes of the various things I’ve done. So there will be blogfest offline on the plane if the in flight movie options don’t do it for me.

So you know powersHell and the PowerCLI right? No? OK, don’t worry about that – I’ve got something in the pipeline planed that will act as a door opener for all those who have yet to dip their toe into the powersHell waters. For those you have. The news is that were will be a new version of PowerCLI – 4.1 by the end of the year. Expect all so that then there will be ESX4.1/vCenter4.1 release. More or less the powerCLI development is dictated by the release strategy of the platform it manages.

I forget exactly the current number of PowerCLI command lets (150/160) but even more will be added into the PowerCLI at the 4.1 release. Including cmdlet to handle iSCIS (Yeah!!!) and to handle the NIC Teaming Policy Settings (Double-yeah) all of which require good knowledge of the SDK, a map and torch OR alternatively you download mine or any number of other bloggers PS sample and pretend your boss you did it all by yourself. WE KNOW WHO YOU ARE!

Also on show was a demo of Onxy, which has been put together by the Bulgian Dev team inside VMware [These guys are truely international!]. The demo wasn’t much more than what shown on the VMW site – which embedded into my blog a couple of days ago. In case you haven’t see it yet, Onxy is like a macro recorder which sits between the vSphere Client and vCenter “recording” all your interactions – leaving you with a cut and paste job on the PS code window.

http://www.rtfm-ed.co.uk/?p=1643

I made a point of attending the session so I could hand in my business card (actually tore strip of my paper keycard from the Marriot, and wrote my name on it) to be entered into a lotto to join the Alpha programme. Some of the PowerShell Gurus like LucD and Hal Rottenberg were a little word that exposing the SDK so easily might be a little “dangerous” in the wrong hands. But personally, the cmdlets can do as much (if not more) damage before you even get to the SDK. For instance I could write powersHell that shutdown all your VMs, deleted them and then your datastore. The only thing stopping that is a little old thing called a username and password.

Also on show was www.thevesi.org (free community supported product the brain child of VizionCore and Scott Herold – my co-author on the Vi3 book). Its much higher level version of the PowerGUI front end. Like Onyx, VESI gives you a graphic front-end (not the vSphere client) which carries many “bulk admin” tasks – and leaves you with a PS window ready to be cut & pasted into a PS1 file. I was quite empressed by the VESI. Especially the chart and VISO output features. It’s the kind of thing some folks wind-up paying for,  whilst the VESI is for free…

OK, well this example is a little obscure admittedly. During the course my travels in powersHell with VMware – I’ve begun to put together my own JACS (Just-Another-Configuration-Script). The idea is to take a clean-factory set ESXi build, and use purely powersHell to configure it. Of course you know when your writing scripts and TESTING them. You always need to reset your tests system against a new revision of the script.

Fortunately, ESXi makes this very easy to do by using the “Reset System Configuration” option

Prior to doing this – I have to drop the ESXi host into maintance mode, and remove it from the vCenter. Being the lazy git I am I thought I would investigate how to do this with powersHell. You see I only have 4-ESX hosts – and use them for all manner of VMware related projects. So in my lab environment I need to be able to wipe configurations to set them up for the rtfm-ed domain, the vi3book or vi4book.com domains – and then there’s the domain name of new SRM book which I start working after VMworld (corp.com). I should have been more smart about this configuration stuff – and just used something vanilla. Starting from the new SRM book everything is going to be corp.com from now on. In means I can work on different projects at the same time without worrying about the screen grabs having the wrong IDs. The other issue have with these ESX hosts – is often go from very simple vSwitch configurations, to very complicated ones. So the work I’ve been doing with powersHell and vSwitches – is going to come in very hand.

Anyway, below is the PS script I use to do a factory reset of my ESXi hosts. Once reset they get a client reservation from my DHCP server – and use this bit of PS at the beginning of my JACS before re-configuring them…

Connect-VIServer esx4.vi4book.com -username root
Set-VMHostAccount -UserAccount root -password P@ssw0rd!

I’m quite proud of the script below in a very geeky sad way. Not because it is clever. But because it is the FIRST piece of powersHell I have written on my own, that address the SDK directly that works! I got close with the DPM powersHell script – and it would have worked if I hadn’t been such a dumb ass about password. The same goes with the bulk reset of root passwords. The reason I’m pleased about it – is after 2-3 weeks of slogging away at the SDK, I think I have done enough examples that I now UNDERSTAND the damn SDK. And if I’m looking to PS the script I won’t have to resort to googlewacking and cutting & pasting other peoples work together – for a such crap scripting guy like me – that’s a real achievement!!!

$vmhost = "esx4.vi4book.com"
$vcname = "virtualcenter4.vi4book.com"

#Connect to vCenter & Enter Maintenance Mode
Connect-VIServer $vcname -username administrator -password vmware

$esxhost = Get-VMHost $vmhost
$hostview = $esxhost | Get-View

Set-VMHost $esxhost -State maintenance

# Remove ESX host from vCenter...
Remove-VMHost $vmhost -Confirm:$false

# Carry out factory reset...
Connect-VIServer $vmhost -username root -password password
$esxhost = Get-VMHost $vmhost
$hostview = $esxhost | Get-View
$ns = Get-View -Id $hostview.ConfigManager.firmwareSystem
$ns.ResetFirmwareToFactoryDefaults()

Some customers I know like to create on each ESX host what they call the uber-vSwitch or the Master-vSwitch. I sometime jokingly the “Lord of the Rings vSwitch” – One vSwitch to rule them all!

The concept is simple. Sometimes they have lack of vmnics (limited PCI bus) or a lack of physical switch ports – so their ESX host only has 4-nics. If you doing Management, VMotion, iSCSI/NAS, HA-Heartbeat and FT-Logging – its quite tricky to keep all of these separate (despite the use of VLANs) whilst offering redundency. So some of my customers opt for the UbervSwitch or MastervSwitch option. It looks like this:

As you can see fault-tolerence is offered by attaching all the NICs to the vSwitch. Each type of network activity resides on different VLAN (Production/10, VMotion&HA-Heartbeat, 11 and IP-Storage/12). Of course the worry here, is that the bandwidth intensive nature of VMotion or IP-Storage could affect your VMs and Management of the ESX host. So that leads people down the route in some cases of using Active/Passive on the Portgroup level to try and control the traffic a little bit more…

As you can see the prefer VMNIC for the “Production” portgroup is vmnic1, with the other nics being standby. This configuration could be repeated so the perferred VMNIC for VMotion/HA-Heartbeat could be vmnic2, with the remain NICs being standby. This way you can have the best of both worlds. Network separation (differnet traffic types prefers its particular VMNIC) but if you have a VMNIC failure there is still redundency through all the network dependent components.

So. I got think how this quite complicated configuration would take ages to do by hand, and quite a challenge to do using the esxcfg-commands or the RCLI/vMA. So I worked out how to do this using powersHell. Many thanks once again to Stuart Radnidge of vInternals which gave me a lot of pointers. Thank Stu, your fucking genius (by the way Stu enjoy gratious swearing in blogposts – sorry if your easily offended)

# Set Variables:
# This version just has all the variables at the top.
# These variables are HOST specific...
$vmhost = "esx4.vi4book.com"
$VMotionIP = "10.0.0.204"
$HAheartbeatIP = "10.0.0.104"
$IPstorageIP = "172.168.3.104"

# Adds vmnic1/2/3 to vSwitch0 and creates the portgroups of Production, VMotion, Ip-Storage, HA-Heartbeat

$vs0 = Get-VirtualSwitch -Name vSwitch0
Set-VirtualSwitch -VirtualSwitch $vs0 -Nic vmnic1, vmnic2, vmnic3

#Add the Production Port Group to vSwitch0

$Production =  New-VirtualPortGroup -VirtualSwitch $vs0 -Name Production

# Creates a portgroup for VMotion on vSwitch0

New-VMHostNetworkAdapter  -PortGroup VMotion -VirtualSwitch $vs0 -IP $VMotionIP -SubnetMask 255.255.255.0 -VMotionEnabled: $true

# This method will create a vswif interface. -ConsoleNIC ONLY works with ESX "Classic". There is currently no way to set "Management Traffic" on a VMKernel Port in ESXi
# PortGroups added to vSwitch0

$HAheartbeat = New-VirtualPortGroup -VirtualSwitch $vs0 -Name HA-Heartbeat
# New-VMHostNetworkAdapter -PortGroup HA-Heartbeat -VirtualSwitch $vs0 -IP $HAheartbeatIP -SubnetMask 255.255.255.0 -ConsoleNic
New-VMHostNetworkAdapter -PortGroup HA-Heartbeat -VirtualSwitch $vs0 -IP $HAheartbeatIP -SubnetMask 255.255.255.0

# This creates a VMKernel Port Group on vSwitch3 called IP-Storage
$IPstorage = New-VirtualPortGroup -VirtualSwitch $vs0 -Name IP-Storage
New-VMHostNetworkAdapter  -PortGroup IP-Storage -VirtualSwitch $vs0 -IP $IPstorageIP -SubnetMask 255.255.255.0

# By default all portgroups would default to originating port id, and the traffic could go through any nic.
# This could mean your VMotion traffic could go on the same NIC as your storage traffic
# Using active & standby on portgroups would allow us to stop this..
# Script assumes you have ESXi and using a management port group called "Management Network"
# Replace "Management Network" with Service Console if your using ESX "Classic"
# Set VLAND ID as you see appropriate

# Management Network (vmnic0 - Active, vmnic1,2,3 - standby)
$vSwitch = "vSwitch0"
$esxhost = Get-VMHost $vmhost
$hostview = $esxhost | Get-View
$ns = Get-View -Id $hostview.ConfigManager.NetworkSystem

$pgspec = New-Object VMware.Vim.HostPortGroupSpec
$pgspec.vswitchName = "vSwitch0"
$pgspec.Name = "Management Network"
$pgspec.vlanId = "0"
$pgspec.Policy = New-Object VMware.Vim.HostNetworkPolicy
$pgspec.Policy.NicTeaming = New-Object VMware.Vim.HostNicTeamingPolicy
$pgspec.Policy.NicTeaming.nicOrder = New-Object VMware.Vim.HostNicOrderPolicy
$pgspec.Policy.NicTeaming.nicOrder.activeNic = @("vmnic0")
$pgspec.Policy.NicTeaming.nicOrder.standbyNic = @("vmnic1","vmnic2","vmnic3")
$ns.UpdatePortGroup($pgspec.Name,$pgspec)

# Production (vmnic1 - Active, vmnic0,2,3 - standby)
$vSwitch = "vSwitch0"
$esxhost = Get-VMHost $vmhost
$hostview = $esxhost | Get-View
$ns = Get-View -Id $hostview.ConfigManager.NetworkSystem

$pgspec = New-Object VMware.Vim.HostPortGroupSpec
$pgspec.vswitchName = "vSwitch0"
$pgspec.Name = "Production"
$pgspec.vlanId = "10"
$pgspec.Policy = New-Object VMware.Vim.HostNetworkPolicy
$pgspec.Policy.NicTeaming = New-Object VMware.Vim.HostNicTeamingPolicy
$pgspec.Policy.NicTeaming.nicOrder = New-Object VMware.Vim.HostNicOrderPolicy
$pgspec.Policy.NicTeaming.nicOrder.activeNic = @("vmnic1")
$pgspec.Policy.NicTeaming.nicOrder.standbyNic = @("vmnic0","vmnic2","vmnic3")
$ns.UpdatePortGroup($pgspec.Name,$pgspec)

# VMotion (vmnic2 - Active, vmnic0,1,3 - standby)
$vSwitch = "vSwitch0"
$esxhost = Get-VMHost $vmhost
$hostview = $esxhost | Get-View
$ns = Get-View -Id $hostview.ConfigManager.NetworkSystem

$pgspec = New-Object VMware.Vim.HostPortGroupSpec
$pgspec.vswitchName = "vSwitch0"
$pgspec.Name = "VMotion"
$pgspec.vlanId = "11"
$pgspec.Policy = New-Object VMware.Vim.HostNetworkPolicy
$pgspec.Policy.NicTeaming = New-Object VMware.Vim.HostNicTeamingPolicy
$pgspec.Policy.NicTeaming.nicOrder = New-Object VMware.Vim.HostNicOrderPolicy
$pgspec.Policy.NicTeaming.nicOrder.activeNic = @("vmnic2")
$pgspec.Policy.NicTeaming.nicOrder.standbyNic = @("vmnic0","vmnic1","vmnic3")
$ns.UpdatePortGroup($pgspec.Name,$pgspec)

# VMotion (vmnic2 - Active, vmnic0,1,3 - standby)
$vSwitch = "vSwitch0"
$esxhost = Get-VMHost $vmhost
$hostview = $esxhost | Get-View
$ns = Get-View -Id $hostview.ConfigManager.NetworkSystem

# HA-Heartbeat same network as VMotion...
$pgspec = New-Object VMware.Vim.HostPortGroupSpec
$pgspec.vswitchName = "vSwitch0"
$pgspec.Name = "HA-Heartbeat"
$pgspec.vlanId = "11"
$pgspec.Policy = New-Object VMware.Vim.HostNetworkPolicy
$pgspec.Policy.NicTeaming = New-Object VMware.Vim.HostNicTeamingPolicy
$pgspec.Policy.NicTeaming.nicOrder = New-Object VMware.Vim.HostNicOrderPolicy
$pgspec.Policy.NicTeaming.nicOrder.activeNic = @("vmnic2")
$pgspec.Policy.NicTeaming.nicOrder.standbyNic = @("vmnic0","vmnic1","vmnic3")
$ns.UpdatePortGroup($pgspec.Name,$pgspec)

# IP Storage (vmnic3 - Active, vmnic0,1,2 - standby)
$pgspec = New-Object VMware.Vim.HostPortGroupSpec
$pgspec.vswitchName = "vSwitch0"
$pgspec.Name = "IP-Storage"
$pgspec.vlanId = "12"
$pgspec.Policy = New-Object VMware.Vim.HostNetworkPolicy
$pgspec.Policy.NicTeaming = New-Object VMware.Vim.HostNicTeamingPolicy
$pgspec.Policy.NicTeaming.nicOrder = New-Object VMware.Vim.HostNicOrderPolicy
$pgspec.Policy.NicTeaming.nicOrder.activeNic = @("vmnic3")
$pgspec.Policy.NicTeaming.nicOrder.standbyNic = @("vmnic0","vmnic1","vmnic2")
$ns.UpdatePortGroup($pgspec.Name,$pgspec)

# Removes "VM Network" from the vSwitch0

get-VirtualPortGroup  | where { $_.Name -like "VM Network"} |  Remove-VirtualPortGroup  -Confirm:$false

Over on youtube.com the Product Manager for VMware’s PowerCLU (aka PowerShell for VMware) has a interesting demo of beta product called “Onyx”. What does on Onyx do for you. Well, do you remember years ago that before VBA, applications like Word/Excel would have like “macro recorder”. You could carry out tasks and the macro recorder would create all that code for you without having to type it all in or learn complicated syntax.

Well, imagine that with the vSphere Client, and the output being raw powersHell that you could just cut and paste into a PS1 file and re-use… Pretty darn neat I can tell you, especially if like me you have been trying to navigate the complexities of the SDK with its Managed Object Types, Data Object Types, Enumerated Types, and Methods.

You can see a quick demo of Onyx in the youtube video below. A more extensive demo can be seen at VMworld which is on Tuesday of next week, between 12:00-5.30 (VM2241). If you bring your business card, you will put in the lottery to all you be part of the beta testing group.

Followers of this blog will know I’ve been trying to port all of post-configuration work from the older kickstart/%post method using esxcfg- commands to using PowerShell. The really agenda being behind this is that one day they will take my COS away (that’s the Service Console to you folks!) – because one day there will be only an ESXi version of ESX and nothing else. Rather than reacting to the loss of the COS in a toys in a pram way, I thought I better get working with this PowersHell thing. Why PowersHell, will I’m totally convinced that is infinitely more powerful than the RCLI or vMA appliance. You can just do soooooo much more with it them.

Anyway, last week I switched over to configuring the IP settings of my ESXi hosts with DHCP for the Management Network only (by only mean, that the vmkernel ports for VMotion/IP Storage and the HA Heartbeat are still be configured statically). So now I never have to interact with the console of the ESXi host at all. EXCEPT to set the password on the thing. You see a clean install of ESXi to a memory stick or factory reset – still leaves you with a passwordless ESX host. So I decided to look into how to do set the password of the root account.

First thing I learned was that connecting to vCenter, to then try do a bulk password reset is not allowed by PowersHell. You have connect directly to the ESX host, otherwise you get this error message

Set-VMHostAccount : 8/26/2009 3:52:13 PM    Set-VMHostAccount    8E894753-1749-413B-9B4B-E9BC5DF57FF3    The requested operation can only be perfonnected directly to an ESX server.

So the correct method is to use the set-VMhostAccount cmd-let to set the initial password like so:

Connect-VIServer esx4.vi4book.com -username root
Set-VMHostAccount -UserAccount root -password P@ssw0rd!

Notice how in the Connect-ViServer command, I’m not using the -password parameter because a newly installed ESXi doesn’t have a password.

Update:

Also notice how my password is complex one.

I learnt something new today. During the installation of ESX “Classic” a password of 6 characters or more is valid. Therefore if you set “vmware” as the root password (obiviously not a very good choice) it would work. BUT, if you later change the password after the installation, and try something like vmware it would fail due to lack of complexity. It seems like higher level of complexity is enforced after the install, than is imposed during. If you set a password that is not complex enough, and you are doing the password reset via powersHell you will get this message:

Set-VMHostAccount : 8/26/2009 7:41:42 PM    Set-VMHostAccount    52b28080-8b4f-2b1b-bbd3-400a5348a06b    A general system error occurred: passwd: Authentication token manipulation error

Anyway, all this came to light by comment left on this post by RTFM Reader, Rob Shaw-Fuller. Rob’s added a powersHell script that will go through and reset the password on all your ESX hosts (providing they have the identifical root passwords to begin with…) I want to reproduce here – because I’m interested in single host configuration with powersHell (as if you were deploying a new ESX host) and also so called “bulk administration” tasks that can be automated with powersHell. Here’s Rob’s script below:

# Connect to the VI Server
Write-Host "Connecting to vCenter"
Connect-VIServer "virtualcenter4.vi4book.com" -user administrator -password vmware
$VMHosts = Get-VMHost | Sort-Object Name
Disconnect-VIServer -Confirm:$False

ForEach ($VMHost in $VMHosts)
{
	$HostName = $VMHost.Name
	Connect-VIServer $HostName -User root -password P@ssw0rd
	Set-VMHostAccount -UserAccount root -password Password1
	Disconnect-VIServer -Confirm:$False
}

Thanks Rob… I would got there myself – if I hadn’t have been so stupid to test my bulk script with vmware as the darn password!!!

In vSphere4 there’s a new method enabling the “Distributed Power Management” options for a DPM enabled cluster. In the past you were dependent on the “wake-on-LAN” and so-called “magic packets” to suspend and resumme an ESX host. In ESX4, you able to configure a user on the iLO/IMPI/BMC/DRAC/RAC board and with the right settings get the ESX host to suspend and resumme itself via the ACPI functionality which has been around for some years.

You can configure it in the GUI like so:

That’s all well and good I guess. Follower of this blog will know I’ve recently been trying to port all my usually setup routines (commonly in my kickstart install scripts) to PowerShell. This is part of my preparation for getting ready for an ESXi only world where the days of esxcfg-commands will be long gone.

So how do you this in PowerShell. Well, I was stumped for days on this even though I was VERY close. In fact to this day, I really don’t see how my bad PS scripts didn’t work, and good one does work. I’ll just blame that on the ghost in my machine! In the end I was helped out by Stuart Radnidge of vInternals. I’m very grateful for Stu for sharing his PS script for DPM on the VMware Forums, after he responded to my forum post/question. That’s how first started delving into the more murker depths of the VMware SDK APIs. Stu has a very nice post explaining (for idiots/mere mortals like me) how deep into the SDK using PowerShell has your pick-axe. It’s called PowerShell Mastery - http://vinternals.com/powercli-mastery/.

Additionally, if you into DPM the other thing Stu has shown, is how to create DPM user account on a HP ILO using the HP ILO command-line utilities. That means the entire job (create DPM using in ILO and configure on ESX host) can be scripted. Of course the tricky thing to script I would imagine is getting hold of the MAC address of ILO. I imagine you can do that with the HP ILO CLI commands…

http://vinternals.com/2009/08/create-users-with-the-hp-ilo-cli/

Anyway, that’s the background. Here’s Stu’s DPM script. Stu wasn’t bothered about me giving him all credit –  but I think he deserves it. All he requested was some gratious swearing in this blog post. (Well, thank fuck for that, I thought he was gonna ask for book royalities!)

I’ve slight modified it (no major surgery) so it matches the conventions used in other samples on RTFM…

$vmhost = “esx4.vi4book.com”
$login = “vmware_dpm_user”
$password = “password”
$hostview = get-vmhost $vmhost | % {Get-View $_.Id}
$IpmiInfo = New-Object Vmware.Vim.HostIpmiInfo
$IpmiInfo.BmcIpAddress = “192.168.3.204″
$IpmiInfo.BmcMacAddress = “00:16:35:37:F8:02″
$IpmiInfo.Login = $login
$IpmiInfo.Password = $password
$hostview.UpdateIpmi($IpmiInfo)

Update:

Since writing this post I think I’ve figured out why Stu’s script worked and mine didn’t. He was including | % {Get-View $_.Id} and I wasn’t (not sure if that was significant). Additionally, it seems to be the case that the ESX host must added into vCenter first for the script to work. I found DPM didn’t have to be enabled on the cluster to allow the DPM configuration to go through.