If you’ve already read my previous post on checking the NIC bind order on all your servers, please read it again.
I have corrected the script after discovering the previous version was not finding all misconfigurations in our environment. Now it return a collection containing both the IP-addresses of the first and second NIC in the bind order instead of just the first one. This allows for better checking for misconfigurations. It also uses the Tcpip bind order instead of the lanmanworkstation bind order for more consistent results.
Any questions? Please leave a comment.
Want to quickly check your scripts for deprecated cmdlets? Try this:
Today I’ve started to disect the new v1.0 official release of the VI Toolkit (for Windows), THE tool to script VMware tasks using Windows Powershell.
To get you started, here’s an overview of added and removed cmdlets:
I’m seeing a lot of posts on different forums about VMware HA.
Some people, including myself, have been receiving error messages when trying to power on a vm in a HA cluster like this one:
“Insufficient resources to satisfy HA failover level on cluster x in y”
Some fellow bloggers have preceeded me in providing clear explanations on how HA actually calculates this sort of thing. For instance:
Now, I still see a lot of replies from people that are having difficulties calculating exactly what happens in their situation. For those people, I have created a Powershell / VI Toolkit (beta) script that does the math and shows you exactly what is going on in your cluster.
So, download it, try it, and please send me some feedback if you have questions, remarks or problems.
Hope this helps.
To all you SysAdmins: a very happy System Administrator Appreciation Day (of SysAdminDay for short)!
I hope you’ll finally get the appreciation you deserve.
Check this out:
“VMware is challenging the world’s VI administrators to a contest of skill, creativity and raw scripting talent. If you think you have what it takes to be the best and an all expenses paid trip to VMworld Las Vegas is your cup of tea – this is for you.”
“When you add a host to a cluster, all virtual machines in the cluster default to the cluster’s default restart priority (Medium, if unspecified) and default isolation response (Power off, if unspecified).”
Resource Management Guide, page 116.
So avoid using per-vm settings for HA, because those are lost when adding a host to your cluster.
“As a result, if the network connection is restored in this window between 12 and 14 seconds after the host has lost connectivity, the virtual machines are powered off but not failed over.”
Resource Management Guide, page 80.
So it is theoretically possible that, in the case of an intermittent network problem, some of your virtual machines will be powered off but not restarted (not on the original server nor on any other server).
“In a cluster using DRS and HA with HA admission control turned on, virtual machines might not be evacuated from hosts entering maintenance mode. This is because of the resources reserved to maintain the failover level. In this case, you must manually migrate the virtual machines off the hosts using VMotion.”
Resource Management Guide, page 80
What will happen, is that the host will not enter maintenance mode until you have manually powered off or VMotioned the vm’s. Note that this will probably be an issue when trying to schedule ESX updates, as Update Manager will try to enter each ESX server into maintenance mode before installing the updates.
If you’re into automating (scripting) VMware tasks, as of today you might run into the term VIX. What is is and – more importantly – what it can do for you, is described in the first post of the VIX API blog over at VMware:
Too bad it doesn’t have a Powershell binding (yet)!
Today’s Powershell Oneliner is one to make your manager happy:
Get-QADComputer -sizeLimit 0 |
Group-Object -Property OSName,OSServicePack -noelement |
Sort-Object -Property Count -Descending |
Format-Table -Property Count,Name
All this simple oneliner does, is query Active Directory for computer objects and group them by OS Name and Service Pack. The output looks something like this:
1111 Windows XP Professional, Service Pack 2
197 Windows Server 2003, Service Pack 2
136 Windows Server 2003, Service Pack 1
117 Windows 2000 Server, Service Pack 4
15 Windows XP Professional, Service Pack 1
6 Windows 2000 Server, Service Pack 3
1 Windows Server® 2008 Standard, Service Pack 1
Don’t you just love the ease with which you can create such a handy little overview? I know you manager will!