New vinternals Site, Burning Feed...

I really need to bite the bullet on this one and move to my new wordpress based site. In the next few hours I will revert the current site to it's default vinternals.blogspot.com address, so the RSS feeds should still work. Then later this evening I'll point the vinternals.com domain at the new site. Finally, in the next day or 2 I'll burn the feeds from this site. If you haven't seen anything from me by next Sunday, either it's all gone horribly wrong or you need to update your RSS bookmark.

Hmmm, it seems putting the word burn all over the place has resulted in ads for "sexy singles" to temporarily appear on the site. Will have to use that word more often :D

Getting from Nice to Cannes / Cannes to Nice

VMworld Europe 2009 is only 1 week away, woohoo! I'm certainly getting pretty excited about it, so I thought I'd post up some info for anyone who is getting into Nice outside of the VMware provided bus times and travelling on their own dime or on restricted company dime (times are tough, I suspect most of us are lucky to be going at all).

The buses services around the Cote d'Azur are great - I've taken them a few times during various jaunts to the area and been amazed at what you get for a basic 1€ ticket. From Nice Airport, you have 2 options for buses - the 1€ Cannes RN7 (bus number 200, around 90mins journey time along the coast) or the ~15€ "Aeroport Express" (bus number 210, around 50mins journey time via the highway).

Here is a link to the timetable, route and departure location info for all buses departing from Nice Aeroport (might be worth saving the Bus 200 and Bus 210 pdf's to your phone / laptop / ipod). Below is a screeny from the Nice Aeroport website with some basic info on the Bus services to Cannes.



UPDATE Hit the comments for direct links to the Bus 200 timetable and route info PDF. Thanks Anonymous, and sorry to hear you won't be there.

VMworld Europe 2009 - "vinternals" Will _Not_ Be There...

... but Shyam and Stu from big-european-investment-bank-that-has-nothing-to-do-with-vinternals will be. Why am I saying this? Because it would be irresponsible of us not to have some dicussions with various vendors regarding their roadmaps and other potentially sensitive information during the course of the event. We completely understand that such discussions are not possible with media-blogger-types.

So to anyone out there who we do talk to, rest assured that the corporate non disclosure "cone of silence" will be in full effect, any information disclosed under NDA or the like will not make it's way into the public domain via us. We are _not_ attending VMworld as "vinternals", we are attending as responsible corporate citizens. At least while we're sober ;-)

ESXi Health Status Inequality - HP vs Dell

Ok, so I'm pretty sure most of you know I've been haxing around with ESXi for quite some time, but I only recently noticed the difference in what you see in vCenter Health Status depending on which hardware vendor you use. I'm sure you also all know that I'm a massive fan of HP, which is why I'm a so unimpressed with their integration with vCenter. For example, lets have a look at recent generation HP BL685c blade running the HP OEM version of ESXi 3.5 (installable), downloaded from the VMware website.


Notice anything strange? Or rather, notice the distinct _lack_ of anything out of the ordinary. That's right, when comparing this blade to a non-OEM ESXi installable, it looks exactly the same in vCenter! At first I thought there must have been a corruption in the CIM providers or something, but after investigating with my VMware SE, we could find nothing out of order.

Now compare the image above to what you see in vCenter on an old Dell rackmount (note the bios date - nearly 2 years old!).



Wow.

Now I can only hazard a guess that HP want you to use Insight Manager to perform health monitoring exclusively, but why force me to deploy more monitoring infrastructure than I need to? They could at least create a VI client plugin for Insight Manager so I can use a single pane of glass! But even with that, it doesn't seem like you get as much information as what you do with Dell - looking at Appendix B of this HP whitepaper, storage subsystem information is strangely absent.

If anyone else out there has seen this, seen different, or can compare with other hardware platforms like Sun or IBM, please share your experiences in the comments!

PowerCLI Mastery, Volume 3

Phew, Volume 1 and Volume 2 down, lets wrap this monster up. See, I told you I wasn't going to leave you hanging for weeks to nail through all this.

So, picking up right from where we left off. We need to perform a configuration operation on an ESX host. Of the available properties we're looking at now, which is most likely to tell us what we can configure? That's right, the configManager property! If you guessed "config", you were close - the config property tells us _what_ the current configuration values are. The configManager object tells _how_ we can do the configuring (is that even a word?). Lets click on that.


Now we're cookin! AS you can see at the top of the page, the configManager object is a Data Object of Type 'HostConfigManager', the properties of which contain a whole bunch of Managed Objects. The task at hand is to modify a portgroup configuration, so let’s check out the 'networkSystem' property.



Here we see all the available properties and methods available for the HostNetworkSystem Managed Object. And low and behold, down the bottom we see the method by which we can modify a portgroup, UpdatePortGroup. We can see that 'networkSystem' is actually a Managed object, but we have to traverse the configManager _Data_ object to get there (because we need to provide the correct context for the managed object reference). Recalling that Get-View can only return _Managed_ Object references, in order to get the HostNetworkSystem Managed Object reference for our particular host, we have to again use Get-View but this time passing it in the networkSystem property of the configManager Data object. Which is a lot easier in PowerShell than it is in English.

$esxNetSys = $esxMoRef.configManager.networkSystem
$esxNetSysMoRef = Get-View $esxNetSys

Finally click on the UpdatePortGroup method, and hopefully we're done


OK, finally we see that in order to use the UpdatePortGroup method of a HostNetworkSystem Managed Object, we need to pass in a portgroup name as a string, and a portgroup as a... HostPortGroupSpec object??? WTF!!! Stu, you lead us all this way to a dead fucking end!!! There won't be anything left for Boche to mash at VMworld Europe 2009 by the time I'm done with you!!!

Breathe. Stay Calm. Focus. I have only given you 2 of the 3 tools needed for PowerCLI mastery. Now, we turn to the dark side... err I mean we turn to the SDK documentation, version 2.5 of which is online here.

The online raw SDK documentation is the equivalent of that goo they eat for breakfast in The Matrix - it contains all the things a PowerCLI Master's body needs. You can have a read of the text in the main window there if you want to get a much better explanation of the different object types that what I've given, or you can just jump in, find what you need, then get the fuck out. Yes, while the raw SDK documentation contains everything the body needs, reading it is also a bit like staring at the Sun. Do it for too long, and you'll go insane like that guy in Sunshine.

Open up the online SDK documentation site. Recalling our conversation about the types of object in the VI API, you can reasonably deduce that a 'HostPortGroupSpec' object is likely a Data object. So click on the "Data Object Types" link in the top left hand corner, wait for the list underneath to update then scroll down to find "HostPortGroupSpec", and click on it. This is the equivalent of the part of our PowerShell code where we do:

$pgspec = New-Object VMware.Vim.HostPortGroupSpec

Now where did I pull that “VMware.Vim.” from? We are using a native .net assembly given to us by the VI Toolkit, Vmware.Vim.dll. You probably haven't realised this up until now, I certainly didn’t until about a year ago, but the VI Toolkit is not just PowerShell - it's actually also a native .net wrapper for the VI API, that you can use with C# instead of compiling your own proxy dll from the VI web service. But you don't need to know the nuts and bolts of that - this is something I'm going to ask you to take on faith. You will eat your greens, you will look both ways when crossing the road, and you will know that the VMware.Vim.dll contains a reference for _every_ object available in the underlying API and then some. And for those sceptics out there who don't believe me, execute the following in any old PowerShell window on a box that you have PowerCLI installed on (and make sure u have a large row buffer ;)

$vimDll = [Reflection.Assembly]::LoadWithPartialName("VMware.Vim")
foreach ($type in $vimDll.GetTypes()){write-host $type.name}

Back to the SDK documentation and the code. Now we see what the properties of a HostPortGroupSpec are. There are 4, and all are mandatory. But what’s this, one of those properties is _another_ object, a "HostNetworkPolicy". So what do we need to populate one of those? Click on it and we'll see!

$pgspec.vswitchName = vSwitch0
$pgspec.Name = "VM Network"
$pgspec.vlanId = "0"
$pgspec.Policy = New-Object VMware.Vim.HostNetworkPolicy

OMG!!! We just opened up a Pandora's box. HostNetworkPolicy has 4 properties, _all of them other objects_! But before you bury your head in your hands, check out those red asterisks - anything with one of those is an optional parameter, which is everything in our case!. Since we're only interested in changing the nic order, which has to do with nic teaming, we're going to leave all properties except the nicTeaming property as empty. Which basically means that this portgroup will inherit the offload policy, security policy and shaping policy of the virtual switch that it is created on. We can see that the nicTeaming property requires a "HostNicTeamingPolicy" object. Click through to that.

$pgspec.Policy.NicTeaming = New-Object VMware.Vim.HostNicTeamingPolicy

Once again we see a whole bunch of properties, all optional as denoted by the red asterisk. We are interested in changing what vmnics are active, standby and unavailable for this portgroup, so we'll need to populate the nicOrder property. Which as you can tell by now (see, you get the hang of this pretty fast), is another object named 'HostNicOrderPolicy'. So click on through...

$pgspec.Policy.NicTeaming.nicOrder = New-Object VMware.Vim.HostNicOrderPolicy

Finally! We're at the end of the line. No objects here, just data, and again all optional. As you can see, there are only 2 properties - activeNic and standbyNic. Any nics present on the parent vSwitch but not part of either of these properties is by definition "unused". So in our example, I'll tell you we have 4 vmnics on the parent virtual switch. On the parent virtual switch, all 4 are active (again, this is all in the imaginary pre-existing host this script will be run against). But in this portgroup, we only want vmnic1 and vmnic2 to be active, and vmnic0 and vmnic3 standby. We can see in the SDK documentation that activeNic and standbyNic need values of type 'string array', so we simply do the following to make a valid assignment:

$pgspec.Policy.NicTeaming.nicOrder.activeNic = @("vmnic1","vmnic2")
$pgspec.Policy.NicTeaming.nicOrder.standbyNic = @("vmnic0","vmnic3")

OK, now we've finally populated our HostPortGroupSpec object with all the required properties, objects, data types and data, it's time to finish off with a call to the UpdatePortGroup() method, via the HostNetworkSystem Managed Object reference we setup in the 3rd line of the script, with the required parameters we got from the MOB. Those being the name of portgroup we want to update, and a HostPortGroupSpec object containing the information we want to apply.

$esxNetSysMoRef.UpdatePortGroup($pgspec.Name, $pgspec)

Job done.

Now you understand why I'm such a huge fan of PowerCLI. I've had the displeasure of coding against the VI API directly in C#, and Shyam did most of the heavy lifting in Java when we developed statelesx. It often seems convoluted and contradictory, you often find that what you thought would be a simple operation based on another seemingly similar task, is actually anything but. As you've seen in this example, there are layers upon layers upon layers, you can get lost pretty easy. But thanks to the foresight of the VI Toolkit team to expose the underlying VI API via Get-View and provide us with VMware.Vim.dll assembly, anything is possible with the Power of Shanklin. Ooops I mean the Power of Shell ;-). But the Power of Shanklin does compel you.

Hopefully now you can not only do whatever you want to with PowerCLI, but also look at any script that the forum wizards may post, and understand exactly what they’ve done and how you might tweak them to your needs.

Now go forth and conquer. You are Jedi.

PowerCLI Mastery, Volume 2

Thought I was going to drag this out in some scandalous attempt to keep the viewers coming back week after week? Actually, wish I had thought of that before just now. Anyways, let's continue. If you haven't read Volume 1 in the series, go do so now. I'll wait for you.

So continuing on, let’s use the MOB to find a portgroup, and see if that helps us to know what we need to do. The MOB displays the internal object names for things rather than the display name you see in the VI client (the display name is still in there, but it’s usually a property of an object rather than the name of the object itself). If it makes navigation easier, open up the VI Client as well so you can see what internal object names map to which display names. To access the MOB:

1. Browse to https://vchostname/mob

2. Authenticate with whatever credentials you would use for vCenter

You are now for all intents and purposes at the landing page of where 'connect-viserver' takes you.


Click on the "Content" link in the value field of the content property. You can now see the top level of all the available managed objects of the vCenter box you connected to.


We know that networking is configured at the host level, so we need to find a host. The rootFolder property is the start of the inventory, let’s go there.


We are now effectively at the top level "Hosts & Clusters" folder in the VI Client Hosts and Clusters inventory view. As you can see here, in my case there is only 1 Datacenter defined, with an internal object name of 'datacenter-2'. Let’s see what’s in there.


OK, so by looking at the 'name' property, we can see that indeed we are looking at a Datacenter object (name removed to protect the innocent). Pretty easy to guess where we might find hosts... in the hostFolder object! Click through...


Because we have clusters defined in this Datacenter (in this case 2 clusters, 'domain-c28' and 'domain-c297' - again, internal object names), we are now actually looking at the cluster container. Clicking into one of the cluster objects will give us our host list.


OK, here's some useful info. We can see up the top of the screen that we are looking at a "Managed Object" Type. In the VI API there are Managed Objects (higher level objects), Data Objects (lower level objects), and then the data primitives like strings and integers. To illustrate, in this screen the host property contains an array of Managed Objects, the configurationEx property contains a single value that is a Data Object, and the name property contains a single value that is a data primitive. We can also see that the name of this Managed Object Type is ManagedObjectReference:ClusterComputeResource - logical for a cluster. Looking at the properties, we see one named 'host', which is also a Managed Object Type and named 'HostSystem'. Listed in the value field are our 2 host objects. Clicking on one of them, we come to the top level of a HostSystem Managed Object.


Cast your mind back to Volume 1, where I said that 'Get-View' was the window to the underlying objects of the VI API. Now that you know there are 2 different types of objects in the VI API, Managed Objects and Data Objects, I can be more specific and say that Get-View only returns _Managed_ objects. We used Get-View to get a Managed Object (hence why it's common to see variables of this nature have 'mor' or 'moref' in the name) to an ESX host. In order to do so, we had to pass the Get-View cmdlet the Id property of the object returned from Get-VMHost. The reason we had to use the Id property is just the way that the VI Toolkit team designed the Get-View cmdlet to work at this particular level.

$esxMoRef = Get-VMHost esxbox.corp.com | % {Get-View $_.Id}

What Managed Object Type did we get a reference to? The exact one we are looking at now - a ManagedObjectReference:HostSystem. And to prove I'm not lying, try this for yourself. Create an $esxHostMoRef variable by issuing the command above in your own environment, and then type $esxHostMoRef.overallStatus and hit enter - it will return whatever value is in the overallStatus row of the webpage in front of you.

And that's where we'll leave it for this installment, Padawans (cue Yoda laugh). In Volume 3 we'll start to disect the script from Volume 1, and follow the rabbit hole a bit deeper.

PowerCLI Mastery, Volume 1

OK, this one has been a looooooooooong time coming. I've been meaning to take a shot at conveying the advanced features of the VI SDK as applied to PowerShell for quite some time now. When Carter corrected me some months ago with regards to what is and isn't possible with PowerCLI (in the first statelesx video, about 1 minute in I mistakenly suggested there was something it _couldn't_ do :-), I've thought I really should get this info out there. Whether I will succeed in this post and the ones that follow is of course for you to decide (this is way to long for a single post), but I'm going to take you through what I think is the fastest way to get your head around the _entire_ SDK. That's right, the whole fucking thing. For as you will see, when you conquer a small piece of the SDK, the rest falls like dominoes.

Now the usual caveats. Yes there are other, possibly more efficient ways to find this info, or write the example code in this article. And some of the things I say will make people who work for Carter cringe. But I've done all this intentionally for the sake of simplicity. And about the the term 'PowerCLI' - Carter dropped it once on Twitter, and all bloggers being opportunists at heart, I'm going to seize on that one with both hands. Besides, it sounds a lot cooler than the VI Toolkit (or at least it more specifically refers to a part of the VI Toolkit). But to avoid any confusion, yes I am talking about this.

It's going to be difficult to go further without the help of an example, so let’s use an example of an operation that there is no native cmdlet for (yet) - modifying the nic order of a portgroup. I don't know how often other people do this, but every ESX blade built where I work gets this treatment. And there are hundreds of those.

Here's the code:

$esxMoRef = Get-VMHost esxbox.corp.com | % {Get-View $_.Id}
$esxNetSys = $esxMoRef.configManager.networkSystem
$esxNetSysMoRef = Get-View $esxNetSys

$pgspec = New-Object VMware.Vim.HostPortGroupSpec
$pgspec.vswitchName = "vSwitch0"
$pgspec.Name = "VM 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 = @("vmnic1","vmnic2")
$pgspec.Policy.NicTeaming.nicOrder.standbyNic = @("vmnic0","vmnic3")

$esxNetSysMoRef UpdatePortGroup($pgspec.Name,$pgspec)

But how did I know those methods and properties are available, what are required and optional values, and what type of values to use? It's not by remote chi, the force, and I didn't pull them out of my arse. I used a combination of Get-View, the MOB and the SDK documentation to do this. No it's not as scary as it sounds, anyone can be on their way to PowerCLI mastery with these tools.

The Get-View cmdlet is part of PowerCLI, and is the window to the underlying VI API. When you need to do something that isn't available via the usual PowerCLI cmdlets, you can use Get-View to acquire an object reference that the underlying API exposes. And of course with PowerShell natively supporting .net objects, you can then access all the associated methods and properties of those underlying objects. That's all well and good, but how do we know what underlying objects, methods and properties we need to use to get our desired result? Continue reading in our next exciting episode, when you will be introduced to the MOB. No, not the sleeps with the fishes type mob, the Managed Object Browser.

Interpol Release Travel Advisory for Cannes in Late Feb

That's right, in an uncanny (and unfortunate for VMware) coincidence, Interpol have issued a travel advisory for anyone in the Cote d'Azur region in late February. All travelers and residents are advised to be on the lookout for 2 males apparently involved in an ongoing London-based criminal enterprise. One male is described as 186cm, shaved head, blue eyes, dashing good looks and a strange accent. The other is described as even taller, of Indian descent, and speaking only in the near unintelligible Jafaican slang that is native to East London.

Well that's just bloody typical. Only yesterday did Shyam and I get our travel approval for VMworld Europe 2009, and this happens.

Only 1 Week Left for vIdiot Nominations!

The vExpert nomination process may be wrapping up in a few days, but you've still got a little over 1 week to get those vIdiot nominations in! We've had some good ones so far, this will be a difficult one to judge. Currently I'm leaning towards some cracking entries from the VMware forums submitted by Rodos (and no they're not innocent questions from newbies - they're ppl claiming to know better about things that they clearly do not), and someone else has put in a great entry from a Google Groups thread! Not to mention Chris Wolf's inadvertent nomination via an anonymous commenter on his blog for use of the word 'Irregardless'... that's not a word Chris, but oh too late, what a world, what a world!

So search high and low ppl, scan the corners of the interwebs for those vIdiots, and out them! Send entries to vinternals at gmail dot com.