One of the exciting new dvSwitch features in vSphere 5.1 is the ability to export and restore a dvSwitch configuration. This new feature is only available through the vSphere Web Client.
On Hypervisor.fr, a blog you should have in your RSS reader, there were already posts on how to configure the dvSwitch healthcheck and how to do a dvSwitch configuration rollback from PowerCLI. But till now, as far as I know, there were no functions to provide the dvSwitch export/restore functionality.
Time to make this useful functionality available for the “PowerCLI automation crowd”
Now that Windows 8 and Windows Server 2012 are readily available , we all want to do some exploring. But if you want to automate the creation of some test VMs for this, you are in for a surprise.
The current PowerCLI 5.1 Release 1 doesn’t accept the E1000E NIC as a Type on the New-NetworkAdapter cmdlet. Users start hitting this limitation, as can be seen on this PowerCLI Community thread. You can go for the E1000, but why settle for less if you can easily script the use of the E1000E NIC from PowerCLI?
So even though Eric “the Scoop Meister” Sloof debunked the myth that the E1000/E1000E is faster than the VmxNet3, the E1000E is the default NIC type that vSphere gives you when you create a VM for a Windows Server 2012 or Windows 8 VM. Note that the E1000 apparently uses slightly more CPU resources than the E1000E. With the function in this post you can now automate this behavior.
Update November 17th 2012: In KB2006859 it seems to say that the VMXNET3 NIC doesn’t work with Windows Server 2012 or Windows 8. And there have been several blogs (including mine) that picked up this info. But after you apply the September 2012 patch to your ESXi servers, you can also use a VMXNET3 NIC for both Windows OS. See here and here for more info.
Thanks to reader alcapapower for drawing my attention to this (see his remark in the comments below).
Categories: dvSwitch, E1000E, Guest OS, PowerShell, vSphere, Windows 8, Windows Server 2012 dvSwitch, E1000E, NIC, PowerCLI, vSphere, Windows 8, Windows Server 2012
Another post coming from our Dutch VMUG Event 2011 presentation. On position number 10, we find the vMotion Enhancements that were introduced with vSphere 5.
A single vMotion can now scale over multiple NICs. This feature can use a regular vSwitch or distributed vSwitch.On YouTube there are 2 videos, uploaded by VMwareKB, that show how to configure such a vMotion enabled multi-NIC vSwitch, regular and distributed.
Very useful videos, but as you can imagine, I wanted to automate this. No GUI clicking for me
Categories: 2011, Dutch, multi-nic, PowerShell, vMotion, VMUG, vSphere multi-nic, PowerCLI, PowerShell, vMotion, vSphere
During our presentation at the Dutch VMUG Event 2011, Alan and myself showed how several entries of the Top 10 vSphere 5 Features session could be automated with the help of PowerCLI. In the session we showed several demos.
This post is the first in a series, that will publish and document most of the scripts we used for the demos.
On the first position in the Top 10 we have Storage DRS. This feature brings intelligent placement of VMs and storage load balancing based on space usage and IO metrics. See part 4, part 5 and part 6 in Cormac‘s excellent series on vSphere 5 Storage Features.
Categories: 2011, Dutch, SDRS, VMUG, vSphere 2011, Dutch, event, SDRS, Top-10, VMUG, vSphere
Buried in the massive amount of new features introduced with vSphere 5 there are several new API methods on the HostStorageSystem managed object.
Two of these API methods will allow you to automate the new Attach/Detach LUN feature from the vSphere Client. It concerns the AttachScsiLun and DetachScsiLun methods. Until this new feature is available natively in PowerCLI, you can use the following functions.
After the Cloud Infrastructure Launch Forum event from July 12th 2011, it seemed that the new licensing model attracted more blog posts and tweets than the 140 new features in vSphere 5.
As one could imagine, one of the most heard questions was, what will I need to pay in the new licensing model. As a pro-active measure, I decided to write a short script that would tell me what vRAM entitlement my current vSphere 4 licenses would offer me.
Update August 4th 2011 08:30: VMware updated the vRAM calculation specifications. See the VMware vSphere™ 5.0 Licensing, Pricing and Packaging White Paper.
Update July 13th 2011 14:45: Apparently you have a vRAM pool per license type. I updated the script.
It happens quite often that you launch a PowerCLI cmdlet or a call to a SDK method or a script and that you get a rather cryptic message that something went wrong. One source of information to find out what went wrong are the vCenter’s vpxd log or the ESX(i) server’s hostd log.
But these logs are flooded with messages and it’s often quite hard to find the messages that relate to your task.
When running against a vCenter Server you can set the vCenter’s Logging Options to “Verbose” or “Trivia“. That produces more information in the logs but that often also makes it harder to find/extract the information that belongs to your task. And who has never forgotten to set the the Logging Options back to their original state when done with debugging ?
To make life a bit easier, I wrote a function that automates the above steps. I expanded on a function that I was using privately, and made it more general. This function allows you to retrieve the log entries for one specific or all recent task. The function also allows you to pass a cmdlet, or even a complete script, run the script in an elevated Logging Options mode and returns the task-related log entries.
A useful property that is obviously missing from the Get-Folder cmdlet, is the path of the folder. In the PowerCLI Community there are regularly threads that ask for this kind of information. Most of the time it concerns scripts to export/import folder structures or scripts to migrate vCenters.
Another property that is obviously missing, is the indication if a specific folder is a so-called “blue” or “yellow” folder.
To solve this problem once and for all, I wrote this short function, called Get-FolderPath, that will return you both of these properties.
The VMTN Communities have always been a useful source of inspiration for writing scripts. This week, for example, there was an intriguing question raised in the Onyx Community. The user wanted to know if it was possible to monitor changes in the vSphere environment in real time.
As far as I know there is no API in the vSphere SDK to do real time monitoring. But the EventHistoryCollector can deliver something that I prefer to call nearly real time monitoring. The following script is a very basic function, written primarily to show that this principle of nearly real time monitoring works. The function displays some selected properties of each event it sees.
One of the announcements during VMworld 2010 in San Francisco that perhaps got a bit obscured by the other “big” announcements, was the release of Onyx 2.0. For those of you that hadn’t heard of Project Onyx before, this nifty little tool captures all SOAP traffic that is passed between your vSphere client or PowerCLI session and the vCenter or ESX(i) server to which you are connected.
And that’s not all, the Onyx program will translate the captured SOAP traffic into PowerShell code. This allows you to see which vSphere APIs are used and how parameter objects for these methods are constructed.
Update September 16th 2010: the Onyx Development Team has just released a new build (2.0.3910.32223) that fixes some issues when using Onyx with the PowerCLI client. Congratulations to the Onyx Development Team for this quick resolution of the problem !