Yellow Bricks

by Duncan Epping

update

Patching your Image Profile (stateless ESXi)

· ·

The first patch for ESXi has been released so I figured this was a great time to create and article around how to patch your Image Profile with a new update. The process is fairly straight forward as in this case you will need to create a new image-profile (described here) and link it to a new rule (New-DeployRule and make that rule active (Add-DeployRule). That is what I like about Stateless. You can just prepare a new Image Profile, create a new rule and you are good to go. A reboot of your ESXi host will load up the latest Image Profile. I did this within a couple of minutes and I’m now running build 474610 of ESXi.

While I was playing around I decided to do things in an incorrect order to see if I could break it, and of course I did manage to break it… I managed to fix all of it though. The first thing I did was testing the rule set and repairing it as documented below.

Now if you run into any issues you can repair the ruleset by using the following command:

Get-VMHost <esxi host> | Test-DeployRuleSetCompliance | Repair-DeployRuleSetCompliance

Now if your host boots and mentions that there’s no rule associated you might want to try the following:

Get-DeployRule

If your newly created rule is returned you will want to make sure it is active:

Get-DeployRuleSet

If there’s nothing listed it means no rules are currently active (active ruleset is what the documentation will refer to). You you can set the rule as active as follows:

Set-DeployRuleSet -DeployRule <name of rule>

Everyone who is considering using Auto-Deploy I would most definitely recommend to explore these commands and to try to break things and fix it. Document your steps along the way, I am certain it will be valuable at some point!

Migrating your 32-bit vCenter Server to 64-bit

· ·

I am working on a whitepaper about vCenter Server migrations and stumbled upon this great tool which is hidden away on the vCenter install media called “datamigration”. The data migration tool allows you to backup a vCenter Server configuration which is hosted by the MS SQL Express databases that is packaged with vCenter. Now this might seem like a limited scenario but I bet many people start out using the Express database that comes with vCenter using a 32-bit OS and found themselves more or less locked in. If you are still using 4.0 with a 32-bit platform, this is your way out. It is fairly straight forward if I may say so. The beauty of it all is that you can keep your current vCenter config, be it disabled… but you always have a roll back option might it be needed.

  • Build a new 64-bit vCenter Server
  • Download the vCenter zip or ISO
  • Go to the “datamigration” folder and copy/extract the datamigration.zip.
  • Copy the extracted content to your “source” vCenter Server
  • Stop the vCenter Service, Update Management Service and the vCenter Web Service
  • Run  “backup.bat” under the datamigration folder from a Command Prompt
    • One decision that you need to make is if you want to backup all Host patches as well, I prefer to just download them again
  • When the process has completed copy the full “datamigration” folder to your new vCenter server
  • Run  “install.bat” under the datamigration folder from a Command Prompt
    • It will display the name of the vCenter Server you are about to “restore”, validate it and type Y
    • Provide the path to the vCenter install files
    • Provide the path to the VUM install files (probably same as previous step)
    • Now just follow the normal installation process
    • You will see an installer popping up, note that in the Command Prompt window the databases will be restored etc.
    • Takes roughly 15 minutes depending on the amount of data
  • Start the vSphere Client… done,

Is that simple or what? I was kind of amazed by this to be honest, very simple and effective tool to migrate to a new 64-bit vCenter Server while keeping your Events, Tasks, Resource Pools etc… it is all there. Use it to your advantage,

32-bit ODBC DSN for VUM 4.1

· ·

My VMware Cloud Team colleague Max Daneri of VMTS fame was building a vSphere 4.1 environment this week. During the installation of VUM(VMware Update Manager) he ran into an issue with the database connection which I thought would be useful to share with you. After some playing around he found out that apparently VUM requires a 32-bit ODBC DSN. Which was a surprise as VUM requires a 64-bit OS.

Of course we should have read the documentation first as it is stated on page 27 of the VUM Install Guide…

IMPORTANT: Although you can install the Update Manager server only on 64-bit machines, Update Manager is a 32-bit application and requires a 32-bit DSN.

VMware vCenter SRM 4.0.1 released

· ·

VMware just released VMware vCenter SRM 4.0.1.

Site Recovery Manager 4.0.1
File size: 104 MB

You can find the download here. This patch fixes the following issues:

  • Test recovery times have been improved for ESX 4.0.1 hosts that use iSCSI arrays.
  • a problem that could cause a recovery plan to hang while powering-off virtual machines at the protected site if the virtual machine’s storage goes offline while the plan is running
  • Customization is now supported for virtual machines running Windows 7 and Windows 2008 R2.
  • a problem that could prevent IP customization from updating the /etc/hosts file on a protected virtual machine running Linux
  • a problem that could cause intermittent site disconnections when there was a firewall between the sites that was configured to close connections due to inactivity
  • a problem that could cause test and recovery networks to be swapped in a recovery plan after the SRM service was restarted
  • a problem that could cause datastore group calculation to fail with a “Not initialized” exception when encountering a virtual machine with an RDM device for which the lunUuid is not set
  • a problem that could cause a recovered virtual machine to be deleted if an administrator manually removed it from a protection group while a recovery plan was being run
  • a problem that could cause the SRM Installer to fail to update vCenter credentials when running in Repair mode
  • a problem that caused the Perl installation created by SRM to be incompatible with some Perl packages. This fix eliminates the need to create the temporary Perl installation mentioned in VMware Knowledge Base article 1014232.
  • a problem that could cause the SRM Service to hang when a Configure All operation configured more than 300 virtual machines
  • a problem that could cause recovery plan failures with hardware iSCSI HBAs connected to Clarriion arrays

VMware vCenter Update Manager 4.0 Update 1 Patch 1

· ·

VMware just released VMware vCenter Update Manager 4.0 Update 1 Patch 1.

This patch resolves the following issues :

  • After upgrading Cisco Nexus 1000V VSM to the latest version, you might not be able to patch the kernel of ESX hosts attached to the vDS (KB 1015717)Upgrading Cisco Nexus 1000V VSM to the latest version upgrades the Cisco Virtual Ethernet Module (VEM) on ESX hosts attached to the vDS. Subsequently, from the same vSphere Client instance, you might not be able to use a host patch baseline to apply patches to the ESX vmkernel64 or ESXi firmware of hosts attached to the vDS. Applying patches to ESX vmkernel64 or ESXi firmware requires that you include the compatible Cisco Nexus 1000V VEM patch in the baseline. However, this patch might not be available for selection in the Update Manager New Baseline wizard or in the Update Manager patch repository.
  • Upgrade of Cisco Nexus 1000V version 4.0(4)SV1(1) to version 4.0(4)SV1(2) with Update Manager might fail for hosts with certain patch levels (KB 1017069)If you are using Cisco Nexus 1000V version 4.0(4)SV1(1), and the ESX patch bulletins ESX400-200912401-BG or ESXi400-200912401-BG are installed on the host, you might not be able to upgrade to Cisco Nexus 1000V version 4.0(4)SV1(2).
  • Scanning of hosts in a cluster and staging of patches to hosts in a cluster might take a long time to finishThe scanning and staging operations of hosts in a cluster run sequentially. If a cluster contains a lot of hosts, scanning and staging patches might take a long time to be completed. Scanning and staging of hosts in a cluster run concurrently on all of the selected hosts in the cluster.

For details regarding these new fixes, please refer to the release notes.

VMware vCenter Update Manager 4.0 Update 1 Patch 1 is available for download.

VMware vCenter Update Manager 4.0 Update 1 is required for installation of this patch.