February 8th, 2010 |
No Comments
A couple of weeks ago I blogged about the vSphere Security Hardening Guide. Just a couple of days later William “the king of Perl” Lam already produced a script that checks the Hardening Guide best practices against your environment. It produces a great html based report.
Source
While going through the COS/HOST and VM documentation, I noticed there were quite a few checks that might benefit from having a script to validate the guidelines and that was the motivation for this script. Not all sections can be validated using the vSphere APIs and will require some manual validation and I’ve seperated the types of passes whether it’s a fail, pass or manual (which requires user intervention).
The script allows you to run the current existing guides as of (01/29/2010) against vCenter 4.0 hosting ESX(i) 4.0 hosts/virtual machines OR run it against an individual ESX(i) 4.0 host. The script allows you to run a subset of the checks and against different type of validation (ENTERPRISE,DMZ or SSLF). Upon completion, a report is generated including a grade for your environment.
A couple of details on the features:
- Email report
- Ability to execute subset of the checks (COS,HOST,VCENTER,VNETWORK,VM)
- Ability execute specific test suite (ENTERPRISE,DMZ,SSLF)
- Detail HTML summary report with letter grade
You can find an example report here. Great work again William, keep it up!
February 5th, 2010 |
10 Comments
I received a bunch of questions around storage masking over the last couple of weeks. One of them was around VMware’s best practice to mask LUNs on a per cluster basis. The best practice has been around for years and basically is there to reduce conflicts. More hosts accessing the same LUNs means more overhead, just to give you an example every 5 minutes a rescan of both HBAs takes place automatically to check for dead storage paths. You can imagine that there’s a difference between 32+ hosts accessing your storage or limiting it to for instance 16 hosts.
The obvious next question is, won’t I lose a lot of flexibility? Well in a way you do as a simple VMotion to another cluster will not work anymore. But of course there’s always a way to move a host to a different cluster. In my design I usually propose a so called “Transfer Volume”. This Volume(NFS or VMFS) can be used to transfer VMs to a different cluster. Yes there’s a slight operational overhead here, but is also reduces overhead in terms of traffic to a LUN and decreases the chance of scsi reservation conflicts etc.
Here’s the process:
- Storage VMotion the VM from LUN on Array 1 to Transfer LUN
- VMotion VM from Cluster A to Cluster B
- Storage VMotion the VM from Transfer LUN to LUN on Array 2
Of course these don’t necessarily need to be two separate arrays, it could just as easily be a single array with a group of LUNs masked to a particular cluster. For the people who have a hard time visualizing it:
Close
transfer lun concept
February 3rd, 2010 |
No Comments
This is just a reminder. The ESXi scripting contest is still running. Make sure you enter the competition. So far not many people have so chances of winning are pretty big!
VMware challenges you to build the best, most creative ESXi management scripts possible. The goal of the ScriptoMania contest is to help our wider community adopt ESXi by providing useful, fun and powerful scripts to manage the ESXi platform. The best part is that we give our winners bragging rights and we put some hard cold cash in your pockets. Are you up to the challenge?
Contest Overview:
February 2nd, 2010 |
5 Comments
At a customer site we received several notifications of performance issues with a VMware VI3 environment. After having checked the configuration of the VMs and the Hosts we decided to dive into esxtop. At first sight we did not see any abnormalities. Low %RDY, which is usually the first thing I check, some swapping but not enough to cause any major delays. The weird thing about this one is that it seemed that only when IP was sent/received the VM felt sluggish. As we could not reproduce the issue we decided to start esxtop in batchmode and use esxplot and perfmon to get to the bottom of it. Soon we found what the issue was, receive packets were being dropped at the vSwitch level.
The following screenshot depicts the symptoms.
In other words, at times an enormous amount of received packets were dropped. After some research I found an article which actually describes this behavior. (http://kb.vmware.com/kb/1010071) We tried increasing the buffer size for the E1000 virtual network adapter this VM was configured with but it did not resolve the issue. As there were other drivers mentioned in the post we decided to “upgrade” the NIC to a “vmxnet” NIC and this actually resolved the issue. Although performance is not where we expected it would be yet we are not seeing any dropped packets anymore and can focus on the next possible cause.
January 31st, 2010 |
1 Comment
Rob de Veij just released a brand new version of RVTools. Download it while it is still hot! Please note that this application supports ESX(i) Server 3.5 and vCenter 2.5. vSphere 4 is in experimental support.
Latest Version: 2.8 | January 31, 2010
Download | Documentation
- On vHost tab field “# VMs” now only powered on VMs are counted.
- On vHost tab field “VMs per core” now only powered on VMs are counted.
- On vHost tab field “vCPUs per core” now only powered on VMs are counted.
- On vDatastore tab field “# VMs” now only calculated for VM’s which are powered on.
- Health check “Number of running virtual CPUs per core” now only powered on VMs are counted.
- Health check “Number of running VMs per datastore” now only powered on VMs are counted.
- During Installation there will be an application event source created for RVTools. This to fix some security related problems.
- Some users run into a timeout exception from the SDK Web server. The default web service timeout value is now changed to a higher value.
- New fields on vHost tab: NTP Server(s), time zone information, Hyper Threading information (available and active), Boot time, DNS Servers, DHCP flag, Domain name and DNS Search order
- New Health Check: Inconsistent folder names.
- Improved exception handling on vDisk, vSwitch and vPort tab pages.
January 29th, 2010 |
3 Comments
VMware has just released LCM 1.1.
What’s new?
VMware vCenter Lifecycle Manager (LCM) 1.1 release enhances the performance, robustness, and scalability of LCM and resolves a number of known issues.
The LCM 1.1 release runs on VMware vCenter Orchestrator 4.0.1. To run LCM 1.1, you must install the version of Orchestrator (4.0.1 Build 4502) that accompanies the LCM 1.1 download. See the vCenter Lifecycle Manager 1.1 Installation and Configuration Guide for installation instructions.
Download now.
http://www.vmware.com/support/pubs/lcm_pubs.html
VMware vCenter Lifecycle Manager Release Notes
VMware vCenter Lifecycle Manager Installation and Configuration Guide
VMware vCenter Lifecycle Manager Administration Guide
VMware vCenter Lifecycle Manager User’s Guide
January 28th, 2010 |
9 Comments
I received a question from a customer who wanted, for security reasons, to remove the ESXi web welcome screen. This is the screen that enables you to download the vSphere Client and RCLI and even browse datastores.
I’ve tested it and removing (or renaming) the following file will lead to a blank page when the ESXi host is accessed via http(s):
/usr/lib/vmware/hostd/docroot/index.html
<edit>
William Lam created another work around which is definitely a more elegant solution: Remove the ESXi web welcome screen.
</edit>
vSphere 4.0 Quick Start Guide