Tag Archives: vSphere

Shortcut to testing VMware Auto-Deploy

It’s very useful to have a VMware lab environment particularly for training needs, and outside of larger enterprises this is generally difficult to achieve owing to the high time cost of setting one up. VMware Auto Deploy remedies this problem since it allows very rapid provisioning of ESXi hosts via PXE network boot.

I wrote these notes for myself since I’m getting some hands-on experience of it to upgrade my VCP4 qualification to VCP5. EDIT – I passed the exam :). I got the information about the Auto Deploy commands from this concise guide. My post here covers how to deploy this if you already use Windows DHCP and WDS, and in such a way that uses but does not impact your production VMware infrastructure. The key to this is using the vCenter Server Appliance to create (with just a few clicks) a separate vCenter on a different VLAN, hosted on your existing ESXi hosts. I think some of the required file downloads may need you to have a proper paid for vSphere licence.

  • Create a new VLAN, add it to your ESXi hosts’ VM Network trunk ports. Define a gateway for the new subnet on your router. In a Cisco environment you would also need to configure your DHCP server as an IP-helper. That’s beyond the scope of this document, and I assume that you probably already run a DHCP server that manages multiple subnets.
  • Obtain and install the VMware vCenter Server Appliance. Log in to the vmware.com site, go as if to download vCenter server, then after the EULA you’ll see multiple files offered (the .iso you would normally download, then further down the .ovf and .vmdk files for the appliance).
  • Install this appliance on your existing ESXi environment. Follow the instructions on screen and select Embedded Database. The default credentials are root and vmware. I reduced the VM’s RAM from 8GB down to 4GB. Ideally put this VM in the new VLAN you created.
  • This appliance already has the Auto Deploy option installed, but it’s disabled (in the Appliance WebUI go to Services > Auto Deploy). Impressively, the appliance also hosts the web services for the vSphere Webclient by default, which you can access from a browser on https://YourApplianceIP:9443/vsphere-client. Given the hassle-free setup for all this, I think it’s highly likely I will transition the production environment over to this instead of running vCenter on Windows.
  • If you’re already using WDS and Microsoft DHCP, make sure you’re defining options 66 and 67 (boot server & boot filename) on a per-scope basis (not in Server Options), that way we can configure different behaviour for the new subnet.
  • Launch vSphere Client and target it at your vCenter Server Appliance. From Home, select Auto Deploy. Select Download TFTP Boot Zip. Extract these files to the root level of your REMINST share on your WDS Server. These bootstrap files are designed to live at the TFTPRoot, not in the boot folder with the other WDS boot files (file paths that are loaded after the initial boot are hard-coded, not relative).
  • By default, the WDS TFTP server only allows read access to \tmp and \boot. You need to use Regedit to edit HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSTFTP\ReadFilter. Append “\*” to the existing value. Where I work the WDS server only serves boot images since I favour unattended install rather than image-based deployment, so I’m ok with this relaxing of the default security.
  • Create a DHCP scope for your new subnet (including a reservation for your vCenter Server Appliance). Define option 67 as undionly.kpxe.vmw-hardwired
  • Now you can connect some test physical machines with Intel VT support to the new VLAN you created and set them to boot to PXE first in the boot order. Test this – you should get a warning that there are no associated ESXi images for this machine. Note down the displayed model name (in my case OptiPlex 745).
  • Download an ESXi offline bundle (go as if to download ESXi from vmware.com, accept the EULA, and it’s further down on the download page).
  • Use a Windows 7 machine (which already has PowerShell 2.0) to install vSphere PowerCLI.
  • Connect the PowerCLI to the vCenter Server Appliance (help on the cmdlets is available here):
  • Add the offline bundle as a “depot”:
    Add-EsxSoftwareDepot C:\users\me\Downloads\ESXi500-201111001.zip
  • Within this depot there are several images, and we need their names:
    Get-EsxImageProfile | fl
  • Create a deployment rule:
    New-DeployRule -Name "FirstTimeBoot" -Item "ESXi-5.0.0-20111104001-standard" -Pattern "model=OptiPlex 745"
  • Activate it:
    Add-DeployRule -DeployRule FirstTimeBoot

Now your ESXi test machines can be woken with WOL, will boot ESXi and will automatically bind to vCenter Server Appliance, where they can be managed. Perfect for home study using a VPN connection. Here is the official VMware Auto Deploy Administrator’s Guide.

Optimizing virtual SQL Server performance

Some months ago I implemented these steps and saw a striking improvement in the performance of our applications (between 2x and 4x depending on the query):

  • Firstly, if you’re using iSCSI, make sure the network switches are ones which have been validated as ok by your storage vendor. I’ve run into poor performance using ones which ought to have worked and offered all the required features (Flow Control, Jumbo Frames), but which in reality were causing problems.
  • If you’re using iSCSI with a software initiator (be it at hypervisor or guest OS level), consider using Jumbo Frames to reduce I/O related CPU activity.
  • Move your VMDKs to a new SAN VMFS volume that is Thick-Provisioned. Although in my environment the EqualLogic array extends LUNs by 16MB at a time, over time this can fragment things appreciably. With a 1TB LUN this can get pretty bad.
  • Use Storage vMotion to make the VMDK files Thick Provisioned too. This eliminates fragmentation of the VMDK since it’s no longer growing in small increments. I think this made quite a big difference, despite a whitepaper from VMware denying a performance impact. The reasoning is that since the storage array has a big cache, having the data fragmented all over the disks shouldn’t really matter that much. I don’t really believe it, and my own results seemed to prove otherwise (what about a backup operation which will need to read your data sequentially in one long pass?). My SQL server vMotion operations were very slow compared to other servers, suggesting they were heavily fragmented in their old location.
  • Move all of your databases (including these system ones: msdb, model, master), their logs, and fulltext catalogs to a SAN LUN directly attached inside the Guest VM using Microsoft iSCSI initiator and your SAN vendor’s Integration Tools. If you use Vmxnet3 adapters then the TCP calculation overhead will be handled by the hypervisor which in turn can be passed to Broadcom bnx2 TOE NICs if you’re using vSphere 4.1. Having the databases on a separate LUN allows off-host backup of the databases using Backup Exec with your SAN vendors’ SQL-aware VSS Hardware Provider. Database backups can then occur at any time without any impact to the SQL server’s performance. I have written a dedicated post on this subject.
  • Create that SAN partition with its NTFS blocks aligned with the SAN’s own disk blocks to ensure no needless multiplication of I/O (64KB offset for EqualLogic – full explanation here).
  • Keep TempDB on the C: drive in its default location. That way I/O to that database is segregated and can be cached differently since it is using VMware’s iSCSI initiator and not the Microsoft initiator. Typically TempDB has high I/O, but it’s not a database that you need to back up so you don’t need to be able to snapshot it on the SAN.
  • Create an SQL management task to rebuild and defragment the database indexes and update their statistics every week (say, Sunday at 3:00am).
  • Change database file autogrow amounts from 1MB to 64MB to mitigate NTFS-level fragmentation of the database MDF files as they grow.

Upgrading vSphere ESXi 4.0 to 4.1 with Dell EqualLogic storage

There are several big motivators to moving over to vSphere 4.1 with respect to storage. Firstly, there’s support for vStorage APIs in new EqualLogic array firmwares (starting at v5.0.0 which sadly, together with 5.0.1 have been withdrawn pending some show-stopping bugs). VM snapshot and copy operations will be done by the SAN at no I/O cost to the hypervisor. Next there’s the support for vendor-specific Multipathing Extension Modules – EqualLogic’s one is available for download under the VMware Integration category. Finally, there’s the long overdue TCP Offload Engine (TOE) support for Broadcom bnx2 NICs. All of this means a healthy increase in storage efficiency.

If you’re upgrading to vSphere 4.1 and have everything set up as per Dell EqualLogic’s vSphere 4.0 best practice documents you’ll first need to:

  • Upgrade the hypervisors using vihostupdate.pl as per VMware’s upgrade guide, taking care to backup their configs first with esxcfg-cfgbackup.pl

Once that’s done choose an ESXi host to update, and put it in Maintenance Mode.

Make a note of your iSCSI VMkernel port IP addresses.

Make sure your ScratchConfig (Configuration -> Advanced Settings) is set to local storage. Reboot and check the change has persisted.

If the server has any Broadcom bnx2 family adapters they will now be treated as iSCSI HBAs so they will each have a vmhba designation. So, to unassign the previous explicit bindings to the Software iSCSI Initiator you need to check for its new name in the Storage Adapters configuration page.

You can’t unbind the VMkernel ports while there is an active iSCSI session using them so edit the properties of the Software iSCSI Initiator and remove the Dynamic and Static targets, then perform a rescan. Find your bound VMkernel ports using the vSphere CLI (replacing vmhba38 with the name of your software initiator):

bin\esxcli --server svr --username user --password pass swiscsi nic list -d vmhba38

Remove each bound VMkernel port like so (assuming vmk1-4 were listed as bound in the last step):

bin\esxcli --server svr --username user --password pass swiscsi nic remove -n vmk1 -d vmhba38
bin\esxcli --server svr --username user --password pass swiscsi nic remove -n vmk2 -d vmhba38
bin\esxcli --server svr --username user --password pass swiscsi nic remove -n vmk3 -d vmhba38
bin\esxcli --server svr --username user --password pass swiscsi nic remove -n vmk4 -d vmhba38

Now you can disable the Software iSCSI Initiator using the vSphere Client and then remove all the VMkernel ports and your iSCSI vSwitches.

Take note at this point that, according to the release notes PDF for the EqualLogic MEM driver, the Broadcom bnx2 TOE-enabled driver in vSphere 4.1 does not support jumbo frames. This information is further on in the document and unfortunately I only read it after I had already configured everything with jumbo frames so I had to start again. Any improvement they offer is kind of moot here since the Broadcom TOE will take over all the strenuous TCP calculation duties from the CPU, and is probably able to cope with traffic at line speed even at 1500 bytes per packet. I guess it could affect performance at the SAN end so perhaps they will work on supporting a 9000 byte MTU in forthcoming releases.

Make sure you set the MTU back to 1500 for any software initiators running in your VMs that used jumbo frames!

Re-patch your cables so you’re using your available TOE NICs for storage. On a server like the Dell PowerEdge R710 the four Broadcom TOE NICs are in fact two dual chips. So if you want to maximize your fault tolerance, be sure to use vmnic0 & vmnic2 as your iSCSI pair, or vmnic1 & vmnic3.

Log in to your EqualLogic Group Manager and delete the CHAP user you were using for the Software iSCSI Initiator for this ESXi host. Create new entries for each hardware HBA you will be using. Copy the intiator names from the vSphere GUI, and be sure to grant them access in the VDS/VSS pane too. Add these users to the volume permissions, and remove the old one.

Using vSphere CLI install the Mutipath Extension Module:

setup.pl --install --server svr --username root --password pass --bundle dell-eql-mem-

Reboot the ESXi host and run the setup script in interactive configuration mode. For multiple value answers, comma separate them:

setup.pl --server svr --username root --password pass --configure

If you have Broadcom TOE NICs say yes to hardware support. This script will set up the vSwitch and the VMkernel ports and take care of the bindings (thanks Dell!):

Configuring networking for iSCSI multipathing:
vswitch = vSwitchISCSI
mtu = 1500
nics = vmnic1 vmnic3
ips =
netmask =
vmkernel = iSCSI
EQL group IP =
Creating vSwitch vSwitchISCSI.
Setting vSwitch MTU to 1500.
Creating portgroup iSCSI0 on vSwitch vSwitchISCSI.
Assigning IP address to iSCSI0.
Creating portgroup iSCSI1 on vSwitch vSwitchISCSI.
Assigning IP address to iSCSI1.
Creating new bridge.
Adding uplink vmnic1 to vSwitchISCSI.
Adding uplink vmnic3 to vSwitchISCSI.
Setting new uplinks for vSwitchISCSI.
Setting uplink for iSCSI0 to vmnic1.
Setting uplink for iSCSI1 to vmnic3.
Bound vmk1 to vmhba34.
Bound vmk2 to vmhba36.
Refreshing host storage system.
Adding discovery address to storage adapter vmhba34.
Adding discovery address to storage adapter vmhba36.
Rescanning all HBAs.
Network configuration finished successfully.

Now go back to your active HBAs and enter the new CHAP credentials. Re-scan and you should see your SAN datastores.

Recreate a pair of iSCSI VM Port Groups for any VMs that may use their own software initiators (very convenient for off-host backup of Exchange or SQL), making sure to explicitly set only one network adapter active, and the other to unused. Reverse the order for the second VM port group. Notice that setup.pl has done this for the VMkernel ports which it created.

Reboot again for good measure since we’ve made big changes to the storage config. I noticed at this point that on my ESXi hosts the Path Selection Policy for my EqualLogic datastore reset itself to Round Robin (VMware). I had to manually set it back to DELL_PSP_EQL_ROUTED. Once I had done that it persisted after a reboot.

vSphere CLI libeay32.dll error on 64bit Windows 7

If you install the latest build of vSphere CLI 4.1 on Windows 7 x64 some of the commands will fail, with perl.exe throwing the following error:

The ordinal 3212 could not be located in the dynamic link library LIBEAY32.dll

There isn’t much to go on when you look up the error – just a lot of people saying you should delete all older copies of LIBEAY32.dll from your system.

Fortunately there is a neater solution, and I’m surprised VMware haven’t fixed this problem yet (4.0 also had the same issue).

  • Open your CLI command prompt as Administrator. Type ppm and hit enter (Perl Package Manager).
  • Now look for a module called Crypt-SSLeay. You’ll see that CLI’s bundled ActivePerl distribution includes version 0.53, but there is a newer version 0.57 available:ActiveState Perl PPM
  • Remove this as shown, then go to File -> Run Marked Actions
  • Click on the grey box icon on the left of the toolbar. These are available packages which are not currently installed. Search for Crypt-SSLeay once again, install, and Run Marked Actions. Exit.

Problem solved!

Upgrading to vCenter 4.1 with bundled SQL Express Edition – database migration fails

My infrastructure uses a bundled SQL Express Edition database because it isn’t hugely complex, and I didn’t want too much dependency on other servers (themselves VMs). I encountered problems upgrading the vCenter database while moving from Windows Server 2003 R2 SP2 x86 to Windows 2008 R2. I was migrating from vSphere 4.0U1 to 4.1. Perhaps this precise combination of versions was the problem, or perhaps it was that my database started life as VirtualCenter 3.5.

The process seems simple enough – unzip and run the Data Migration Tool from the installation media on the source vCenter server, move this folder (now with \data added) to the destination server and launch the install.bat script. However, there seem to be two major snags. The first is that the backup process will fail:

DB logs: HResult 0x2, Level 16, State 1 Named Pipes Provider: Could not open a connection to SQL Server

VMware has a knowledgbase article about this. They claim it’s caused by a misconfiguration of the SQL 2005 Express Edition instance which is pretty rich considering it was set up by their own installer. Make the named pipe change they suggest and it will work. Now unplug this machine from the LAN or disconnect its network adapter in vSphere if it’s a VM – remember you can connect the VI Client directly to the hypervisor which is hosting it.

The destination server needs to be configured with the same hostname as the source. I had then assumed that the restore tool would need to be run after a new install of vCenter 4.1 was placed on the destination server, so I installed vCenter. Then I discovered that the install.bat script in the datamigration folder refuses to run if it detects the product is already present. So naturally I uninstalled it and tried again. Perhaps this is what messed things up, or perhaps it’s because I’m using Windows 2008 R2.

Anyway, the datamigration\install.bat script kicks off the main product installer, supposedly importing all your backed up settings.

According to the vCenter 4.1 Upgrade Guide page 40 item 10 you are supposed to:

Select Install SQL Server 2005 Express instance (for small-scale deployments) and click Next.

Item 16 on the same page states that:

When the vCenter Server installation finishes, click Finish. The data migration tool restores the backed up configuration data.

If you do this you may, like me, discover that it actually doesn’t work and you end up with a completely blank database instance. Consulting datamigration\logs\restore.log I found no reference at all to any database restore.

My workaround

Go to your original vCenter server. Open the Data Sources MMC snap-in. In System DSN you should see an entry like so:

Note down the details, then create the same entry on your destination server (this will create a 64bit DSN). Notice how on page 38 of the Upgrade Guide it specifically states that:

If you use the data migration tool to migrate a SQL Server Express database located on the vCenter Server system to a new system, you do not need to create the 64-bit DSN. The data migration tool creates the DSN as part of the installation process

Apparently sometimes you do need to create the DSN.

On the destination server, copy the file \datamigration\data\vc\vc_upgraded_db and paste it in C:\temp. Rename it to vc_upgraded_db.bak.

Still on the destination server download, install and run the 64bit SQL Management Studio Express. Even if you’ve uninstalled vCenter, the SQL Express Edition instance will be left behind. If there’s not already one from a failed install, create a local database called VIM_VCDB. Restore the backup in C:\temp\vc_upgraded_db.bak over the top, paying attention to select Options -> Overwrite Existing Database and browsing to the target file locations of both the mdf and ldf files – the old database was found in C:\Program Files\Microsoft SQL Server\MSSQL.1\Data but on the 64bit system it’s C:\Program Files (x86)\…

Right-click your database, and select Properties. In Options, make sure your database recovery model is set to Simple. If you don’t do this your transaction log will fill up in a couple of days and the vCenter services will stop. In my case it seemed to have defaulted to Bulk-Logged.

Once that’s done you’ll need to update your newly created DSN to set the default database to VIM_VCDB. Now run datamigration\install.bat once again but this time opt to use an existing database as shown below:

Strangely, you will find that the you cannot use the SYSTEM account for the vCenter services however this can easily be changed in the Services MMC snap-in later.

And that’s it. You should end up with a working install with your data intact. One final tweak is to delay launch of the vCenter services so they don’t fail to start up at boot time.

UPDATE – after wasting a number of hours today with this, I’ve done some more searching and found this VMware KB article which basically just admits that the Data Migration Tool sometimes doesn’t work, and won’t even report errors in the log! When I download something as important as this, I sort of take it for granted that I won’t have to Google “vcenter data management tool does not migrate database” the moment I try using it (can’t believe I didn’t try that).