I was graciously given the opportunity to read and review vSphere High Performance Cookbook, written by Prasenjit Sarkar (@stretchcloud) and published by Packt Publishing, whose subtitle states it has Over 60 recipes to help you improve vSphere performance and solve problems before they arise. Gulping down its chapters was easy after seeing that Prasenjit’s recipes included fixes for such common, and some not so common, misconfigurations or lack thereof.
I’ve had occasion recently to implement many vSphere 4.1 environments for a customer. There’s a lot to learn during these deployments and many worthy blog posts are just waiting to be written. But one especially comes to mind mainly because of its temporal relation to a recent query I had regarding a BIOS setting for a Dell PowerEdge R710. The exact query doesn’t matter, but what’s important is that I ran across Marek.Z’s blog, Default Reasoning, and this post in search of an answer. His post regarding vSphere 4.x BIOS settings and best practices interested me in writing a BIOS best practices post for vSphere 5. This is going to be very similar to vSphere 4.x, but you’ll notice I’ve included explanations as to why these settings are best suited to vSphere 5 environments. Some of these settings may be obvious, while others, like NUMA, C1E, and Memory, may not be. Especially for these, I’ve included the results of my research.
Towards the end of a customer’s virtualization implementation we’re doing some clean-up of the environment. During the initial setup I was using my own local email address to test various alerting processes, of which there are several. For instance, every SQL Server maintenance task sends a success/failure e-mail alert, the NetApp Virtual Storage Console plug-in can be configured to e-mail an administrator after snapshots are taken, and the Dell iDRAC can send e-mails on hardware status changes. All those are fairly quick to configure or lack a way to script a quick solution. But with 40 default alarms in vSphere, three vCenters, and being lazy as I am, I knew there must be a better solution than right clicking 120 alarms and copying-and-pasting an email address. As the proverb goes, if you repeat it, script it. So I set out to find how PowerCLI could help me.
At a customer’s site towards the end of a deployment, we decided to see what this new fan-dangled vSphere Compliance Checker could do. We ran it against an ESXi 4.1U1 host and it spit out some nice colors and information. The quick and dirty of it is that it was easy to install, easy to use, and provided useful information. So I decided to run it against my ESXi 5 hosts in a test lab and write up a quickie post.
For my notes, I’m sharing what I’ve found searching the ‘net to bind VMkernel NICs to VMware’s built-in iSCSI software initiator in ESXi 4.1 I know ESXi 5.0 has changed this process to a nice GUI, but we’re stuck with the CLI in 4.1.
If you’re configuring jumbo frames as I’ve shown in a previous post, bind the VMkernel NICs after configuring jumbo frames.
Assuming you have two uplinks for iSCSI traffic, on the vSwitch of your iSCSI port group, set one uplink, temporarily, to unused. You’ll also want to note the vmhba# of the software iSCSI adapter. You can view this from the Configuration tab > Storage Adapters and viewing the iSCSI Software Adapter. You’ll also need to note the VMkernel NIC names of each iSCSI port group. You can view these from the Configuration tab > Networking and looking at the iSCSI port group. It will show the iSCSI port group name, the vmk#, IP address, and VLAN if you have one configured. Then from a CLI, either via the console or SSH, execute the following commands for each iSCSI port name:
Example: esxcli swiscsi nic add -n vmk# -d vmhba#