I tried for over an hour to use the Set-VMHostNetworkAdapter for the life of me I can’t get it to work. Fortunately the SDK is both well documented and wide open thanks to the get-view cmdlet!

PS >  (Get-View (Get-Host 'ESX1' | get-view).ConfigManager.VmotionSystem).SelectVnic('vmk0')

that’s it… Now the cool thing here is that let’s say vnic vmk1 is currently selected. The SelectVnic method will unselected vmk1, and select vmk0. As with everything in the VI toolkit once you figure out how to do one, scale is suddenly a trivial task.

PS >Get-VMHost |Foreach-Object {
    (Get-View ($_|get-view).ConfigManager.VmotionSystem).SelectVnic('vmk0')
}

Personally, I always test automation task like this on a ‘test cluster’.

PS >Get-Cluster "Test" | Get-VMHost | Foreach-Object {
    (Get-View ($_|get-view).ConfigManager.VmotionSystem).SelectVnic('vmk0')
}

If you haven’t figured it out yet… We’re making a concerted effort to solve any issue we find. From both the view point of a Windows (PowerShell) and a *nix(perl) administrator’s point of view. All of this stuff is really just a stop gap until the RCLI has matured. We’ll at least the perl is (have you seen how long that stuff is )

One of the things that I do when configuring my hosts after kickstart is setup a kernel interface and enable vMotion for that port group. This isn’t too difficult, but takes a little bit of futzing with some vmware-vim-cmd results to get the data we need.

Since I’m on the subject, I figured I may as well do the same thing using the SDK, which eliminates one more thing that the rCLI can’t do in order for me to configure a new ESX host completely.

Continue Reading »

After hearing about the bug with ESX 3.5 Update 3 where a vMotion would cause a tools upgrade, and consequentially a VM reboot, I wanted to check and verify that my VMs would not exhibit this behavior. Apparently the bug is present when the tools update policy is set to “Update at Power On”. (Yes, I admit this bug has been known for a while, I just kept forgetting to post this script.)

There are a multitude of other scripts (including the powershell cmdlet “update-tools”) out there to kickoff a tools update task, so I wasn’t interested in that, all I wanted was to know the update policy and be able to change it.

This perl is the result of that…

Continue Reading »

The last few posts I’ve been mentioning how much of the configuration for my ESX hosts is automated. This post I’m going to talk a little more about how that automation is done, and provide an example kickstart script. I have been holding off on this post for a while now, as I have been planning on rebuilding my PXE server, at which point I will document each step and be able to provide a much more detailed post. However, things keep getting in the way and I haven’t had time to rebuild the server yet, so this is a slightly less detailed post, but should still be enough to get you on your way And I have no doubt that you, dear reader, are not afraid of asking questions in the comments…

This automation is currently handled (I say “currently” because I’m working to move the majority of it to a remote host and use the SDK) by kickstart when the system is loaded. Well, to be totally honest, kickstart only plays a partial role in the process…during the %post section of kickstart I copy a series of scripts from an NFS mount point into the startup process (/etc/init.d/rc3.d), which are executed at first boot and, like good one-time-only scripts, remove themselves.

This setup allows me to pxe boot a host, give it the boot command which has the host ID appended, and that’s it. I can then walk away and wait for the host to add itself to vCenter, indicating that it’s finished. Kickstart and the post install scripts then configure the hostname, ip, virtual network configuration, security policy, ntp, base user set, install any custom RPMs, etc. This makes it extremely easy for me to keep all of our hosts at the same configuration level.

In order to keep all the hosts the same I simply have to update the relevant post install script when we decide to make a global change and it will configure the host correctly the next time it is loaded/reloaded. For updating hosts that can’t be reloaded (I try to reload the hosts periodically with the newest binaries from VMware…every 4-6 months…so that the software is not a huge conglomeration of patches…I know, it’s unnecessary, but it gives me peace of mind) we use a combination of Glenn’s POSH prowess and the perl toolkit scripts I’ve created to remediate hosts en masse to our baseline configuration.

Continue Reading »

You know after Andrew does all the hard work in perl… Converting this stuff to powershell is like shooting fish in a barrel.

Get the current COS Ram configuration:

(Get-View (get-view -VIObject (get-vmhost ESX1)).ConfigManager.MemoryManager).ConsoleReservationInfo

Change the ammount of RAM dedicated to the COS to 512MB:

(Get-View (get-view -VIObject (get-vmhost ESX1)).ConfigManager.MemoryManager).ReconfigureServiceConsoleReservation(512mb)

~Glenn

I couldn’t let a perl post go unanswered… Update the security policy of a vSwitch via Powershell.

~Glenn

Continue Reading »

In order to facilitate my ability to configure all aspects of an ESX host automatically, I wanted to adjust the amount of memory that is assigned to the COS without having to use VI Client. The perl below is the result of that effort.

As always, I am not responsible for any damage caused to your infrastructure, I recommend you put your host in maintenance mode and move all VMs off of it before attempting any significant action upon it (there should be little risk involved with this script though…). The change will not take effect until you reboot the host (which can be accomplished with the hostops.pl sample script provided as a part of the Perl Toolkit).

Continue Reading »

Update 2009-2-22: Yet again, I updated the script, this time just to simplify and shorten the code using the “normal” method of updating values in objects retrieved from the SDK (rather than creating a whole new object and copying values, the script now updates the object retrieved, then uses that to update).

Update 2009-01-02: I have updated the script again, this time using the standard “vihost” so that you can connect to vCenter and change a host’s switches, as opposed to just connecting to the ESX host directly. I have also started using the _default_ parameter, which means that it is no longer necessary to specify the “–vswitch” option, but rather it is the last option on the line (just like all the other VMware provided scripts).

Update 2008-12-30: I have updated the script so that it defaults to turning all options off without having to specify them. This makes it easier to use (thanks to Glenn for this idea…).

I haven’t posted in a while, but it’s not because I haven’t been busy. The bulk of my recent work has been in automating the droll configuration items for an ESX server. With the exception of hardening the COS, pretty much everything can be setup/configured remotely via the SDK or rCLI. If you can change or set something via the Virtual Infrastructure Client, then you can set it via the SDK.

I am no POSH coder (just ask Glenn…), but I do know some perl, so using the VI Perl Toolkit, I’ve been able to script most of the configuration items that I need to do for an ESX server. This post is the first in what I hope will be a line that will hopefully contain scripts on configuring most aspects of an ESX host remotely.

I set all of our vSwitches to have Promiscuous Mode, Forged Transmits and MAC changes disabled, and so far there are no port groups that override this setting, thus giving me at least a little sense of security for certain aspects of my virtual networking.

Continue Reading »

Normally I hate repeating what others have posted many MANY times (why has everyone and their grandmother blogged about Veeam’s “Christmas Present” 17 times in the last 2 days?), however Eric Sloof, of www.ntpro.nl, posted an excellent method of reestablishing your authority over vCenter Server should you accidentally lock yourself out.

Thanks Eric!!

Blue_fish posted a question over on powershellcommunity.org. The source of the question was a mysterious blank entry. This anomaly appeared when he tried to convert a string into an array of individual words. Without his actual code on hand I tried to guess what could cause that. Along the way I typed up the following… thinking out loud with my fingers. Afterwards I realized that this was the kind of information I was looking for when I started out. With that in mind enjoy…

Convert ” abcd efg hi j ” into an array…

(” abcd efg hi j “).split(” “) #done… now remove the blank entries…

(” abcd efg hi j “).split(” “) | where-object {$_ -ne ” “}

Why did that work?  Powershells access to the .net framework doesn’t require one to be a .net dev.  Far from it instead it brings an incredible amount of power to a usable surface. So how did .split() come to be and why does where work. I think I can explain it… let’s see…

In PowerShell “” refers to a string, obviously, but it’s more than that.  A string in PowerShell is a .net object with a type of string,  99.99% of the time that doesn’t matter, but in this case it’s quite pertinent.  As a first class object string carries with it many powerful methods free of charge

Parenthesis () have several responsibilities within POSH, but mainly it’s just execution order i.e. (THIRD((FIRST)SECOND(FIRST))).  Part of that execution is PowerShell normalizing your data. For example 15 will be cast as an int, asdf as a string, and @(1,2,3,4,5) is an array or integers. As that cast is of objects, this is where all the free posh goodness comes from.  Therefore we need to enclose our string in () to perform that cast and have those methods available. 

Believe it or not that’s the hard part…

.split(” “) = splits our string into an array of strings using one whitespace as the delimiter.

And that’s how:

” abcd efg hI j “ 

Transforms into:
@”

abcd

efg



hI


j
“@

Now that you have an array of words all that is left is to remove the false positives.  Enter Where-Object, think of where-object (aka where, and ?) as an extremely streamlined if then else filter.  {} in PowerShell represent a script block. 

A script block is a chunk of code that is executed to its completion before the engine moves on.  In other words {} will overrule ().  where-object is a bool operator, if the script block evaluates to true then pass the object down the pipeline, else drop the object. 

Before where {}

[0] ” ” = False
[1] “abcd” = True
[2] ” “     = False
[3] “efg” = True
[4] ” “     = False
[5] ” “     = False
[6] ” “     = False
[7] “hi”     = True
[8] ” “     = False
[9] ” “     = False
[10] “j”     = True

After where {}

[0] “abcd”
[2] “efg”
[3] “hi”
[4] “j”

*Only objects that evaluate to $TRUE in the where-object script block are passed down the pipeline. As you can see their really aren’t any “smoke and mirrors” in PowerShell. Instead the team provided a kick ass engine that does 90% of the work for us in a predictable and comprehendible fashion!

~Glenn

I started to post all of this in my response to blue_fish’s post over on powershellcommunity.org, but it occurred to me that I went way to in depth.  Sometimes I like to talk myself through the nth degree to prove I know it

Don’t be shy if I screwed something up please let me know.  That’s the other part of laying it out to the nth degree if I’m mistaken, you’ll correct me, and we all improve from that exercise!