A Solaris flar won’t install on it’s own architecture

A few weeks ago, I created a Sun flar (flash archive) of one T-2000 system, to install on another identical T-2000 system. For more info on creating flars, check out the flarcreate(1M) manual page.

The installation of the flar failed with an error I had never seen:

Processing profile
        - Opening Flash archive
        - Validating Flash archive
ERROR: Archive does not support this architecture (sun4v)
ERROR: Flash installation failed
Solaris installation program exited.

Really? These are both T-2000 machines – uname -a output says so. I recreated the flar, and tried the install – with the same result – flash installation failed.

Thanks to this mailing list thread, I found out that this is bug 6523030, and only impacts sun4v architecture. The work-around is to delete the /var/sadm/system/admin/.platform file on the system to be imaged, then recreate the flar. Without the .platform file, the flarcreate command will properly determine the architecture.
If you can not or do not want to recreate the flar from scratch, you can also split the original flar, edit the identification file, then combine the components into a new flar:

  • Create a temporary directory, where the flar’s components will be broken out into files. This makes cleanup easier later.
  • Split the flar’s components into separate files, with flar split oldfile.flar
  • Edit the identification file, and change the “content_architectures” line so that it includes sun4v.
  • Create a new flar by combining the components, with flar combine new.file.flar

Looking at the old and new flars. . .

Getting info about my old flar:

root@t-2000 # flar -i *.flar
archive_id=4ceac667ee15dc27283b2654a045a1b3
files_archived_method=cpio
creation_date=20110118230559
creation_master=t-2000
content_name=t-2000 Sol10 09/2010 Recommended 12/2010 with cluster
creation_node=t-2000
creation_hardware_class=sun4v
creation_platform=SUNW,Sun-Fire-T200
creation_processor=sparc
creation_release=5.10
creation_os_name=SunOS
creation_os_version=Generic_142909-17
files_compressed_method=compress
content_architectures=sun4c,sun4d,sun4m,sun4u,sun4us,sun4s
type=FULL

Notice that content_architectures does not list the architecture of the T-2000 (sun4v), but creation_hardware_class does show sun4v.

Getting info about my new flar:

root@T-2000 # flar -i *.flar
archive_id=d2fe659ace201ecc9f07d1ee3fb69cc2
files_archived_method=cpio
creation_date=20110119002244
creation_master= t-2000
content_name=t-2000 Sol10 9/2010, cluster 3.2, Recommended 12/2010
creation_node=t-2000
creation_hardware_class=sun4v
creation_platform=SUNW,Sun-Fire-T200
creation_processor=sparc
creation_release=5.10
creation_os_name=SunOS
creation_os_version=Generic_142909-17
files_compressed_method=compress
content_author=ifetch
content_architectures=sun4v
type=FULL

Now, the flar installs properly!

Posted in Solaris | Tagged , | Leave a comment

vCenter upgrade changes DB recovery mode

At work, the vCenter service crashed this morning, because the database log had filled up it’s disk. We were confused about this, because we previously set the MS SQL recovery mode to simple. Now, the recovery mode is set to bulk recovery – how did that happen?

IT turns out the recovery mode is changed incorrectly during the vCenter upgrade to version 4.1 RE: KB 1026430 (Transaction log for vCenter Server database grows large after upgrading to vCenter
Server 4.1)
.

After setting the recovery mode back to simple, the log file which filled up the disk still needs to be shrank. The dbcc shrinkfile command ran for a couple of hours, and appeared to do nothing. Following the instructions in KB 1003980 (Troubleshooting transaction logs on a Microsoft SQL database server) ended up shrinking the 43Gb log file in about a minute.

Note to self: Check the recovery model of the vCenter database after every upgrade!

Posted in VMware vSphere | Tagged , | Leave a comment

Using VMware Update Manager with PowerCLI

While this isn’t anything exciting which I have accomplished (I am just using the tools which others have done a great job of creating), this is exciting because it provides other options – even if they involve a little more work initially. Granted, I don’t want to end up re-creating the entire VMware Infrastructure Client through PowerCLI, but it is a very nice tool, to help me function more quickly.

Tired of the VUM add-on user interface, and the clumsiness which often ensues when navigating the VIC in general (focus changes when arrowing through tree views, sub-sections of the display are unable to be maximized without dragging them using a mouse), I turned to VMware PowerCLI to help me use VUM to remediate ESX hosts.

Besides PowerShell (which comes with Windows 7 and Server 2008) and VMware vSphereâ„¢ PowerCLI, you also need the vCenter Update Manager PowerCLI. Make sure you get VUM PowerCLI version 4.1.

I had planned on pasting a complete session with commands and output, but my history turned out to only include the last 4th of my work. SO instead, I’ll just show commands, including some comments.

This is not a PowerCLI script, but a set of commands which I used interactively – similarly to what you would do in the VIC. This is also my first real use of Powershell, so likely there are other smarter ways to do some of the pipelining – suggestions are welcome!

# Connect to a vCenter server.
# Instead of using a Powershell authentication object, or specifying user / password, we will get prompted with a GUI.
connect-viserver -server vcenter.company.local
# We will use the critical and noncritical host patches baselines.
# Put both of those in a single variable, which we can then attach to ESX hosts.
# Baselines only need to be attached to a host once.
$baselines = Get-Baseline '*critical host patches'
# Verify which baselines we have chosen, by printing the variable:
# This will show the two baselines and their description.
$baselines
# Create a variable which represents the host we want to patch.
$h = get-vmhost -name esx1.company.local
# Attach the two baselines to the ESX host.
attach-baseline -baseline $baselines -entity $h
# Show the baselines atached to this ESX host, just to verify.
# This is also useful when baselines are already attached from an earlier use of VUM.
$h | get-baseline
# Scan the host.
# You can also add the -async option to the scan-inventory call, to not wait for the task to complete.
$h | scan-inventory
# See if the host is compliant.
$h | get-compliance
# Show compliance, with more info (number of patches in each baseline).
$h | get-compliance -detailed
# For interest, see which VMs are running on this host.
$h | get-vm | foreach-object {(Get-View $_.ID).name } | sort
# Put the host in maintenance mode before remediating it.
# The remediation action puts the host into maintenance mode too,
# but doing it by hand lets us deal with any issues along the way, without risking the remediation task timing out.
# The -evacuate parameter registers powered off VMs on other hosts.
# The -runasync parameter does not wait for the task to complete, so you can do other things, like look at the task list.
$h | set-vmhost -state maintenance -evacuate -runasync
Get-task
# Now remediate this host.
# The -runasync parameter does not wait for the task to complete.
$h | remediate-inventory -baseline $baselines -runasync
# Watch tasks with:
get-task -status running
# Get the host's status after reboot, wait for the host to come back in VC:
# I am not sure of a way to do this with our $h variable.
# This will show a status of not responding while the host reboots.
# Once it shows a status of maintenance mode, continue...
get-vmhost -name esx1.company.local
# Now that the host has rebooted, and is connected in vCenter:
# Rescan the host, then check compliance again.
# I believe the remediate process does an automatic rescan itself, but we'll do it again just to be sure...
$h | scan-inventory
$h | get-compliance -detailed
# Now exit maintenance mode.
$h | set-vmhost -state connected
Posted in VMware vSphere | Tagged , , , | Leave a comment