One thing we’ve been trying to do in Oracle Solaris over the last few years is make it easier for our customer to engage with support should a problem occur. And make that engagement easier for all involved. Getting the right information about the system that the problem occurred on to support earlier really helps our support team to give you the right assistance. There’s no point in sending you information on how to solve an IPS problem if the problem occurs on Solaris 10 for example.

We are also keen to automate resolution of common problems, and again, having the right information about the system where the problem occurred is vital. 

Automatic Service Requests are a key component of this. Historically these have been triggered by FMA (Fault Management Architecture) events for hardware faults. But as of Solaris 11 we started raising FMA Defects for certain software problems (Panics for example). Later we added Alerts for conditions which might be interesting to know about, but may not represent a software bug. These also trigger ASR events which are monitored by the automation team at Oracle.

We’ve made some changes recently to make these software events more useful, but it may mean you notice some changes.

  1. The biggest thing you’ll notice is FMA will now proxy software alerts and defects from a guest LDom to the Control Domain. If you have ASR enabled in the Control Domain it will now raise ASR events for software faults and defects in all guest LDoms. Even one which don’t own any I/O resources. This is available as of the following versions.
    1. 11.4 SRU 26
    2. 11.3 SRU 36 LSU 23
    3. Solaris 10 with either patch 153078-01 or 153079-01.
  2. If you have ILOM configured to do ASR, then as of Firmware 9.10.1.a ILOM will also raise ASR for software defects and alerts. Don’t worry, the ASR back-end will recognise duplicates.
  3. FMA events and ASR events contain more information about the system where the problem occured. eg
    1. Solaris version information (eg. Patch or SRU level)
    2. What type of virtualization is in place (eg zones or ldoms)
    3. Hardware architecture.

Now when you run fmadm list on the Control Domain, you can see if a fault is proxied from another host (ie the LDom) and the additional information about the OS version. See the screen shot at the start of the article, even though I’ve had to remove the host names.