Tuesday May 26, 2015

Data to collect when logging a Service Request on Enterprise Manager Ops Center

If you ever have to log a Service Request (SR) on your Enterprise Manager Ops Center instance, the question often arises as to what data you should include with the SR. Including the right information when you log the SR will greatly reduce your Time To Resolution (TTR).

So, what data should you add to the SR? That will depend on what type of issue you are experiencing.

Basic Information for All SR's

While the My Oracle Support (MOS) portal will help by asking you relevent questions, here is a list of things to think about while answering them:

  1. A clear problem description - Tell us about what you were attempting to do when you encountered the issue, what host(s) were involved and what error message you saw. You would be surprised how many SR's get logged with "It didn't work" or just the error message as the problem description without telling us what you were actually trying to do. 
  2. Time and date - Tell us the time and date you saw the issue. The log files are time stamped, so knowing the time the issue occurred (at least approximately) will reduce the extent of searching of the log files that will need to be done.
  3. Software Version - Always tell us what version of Enterprise Manager Ops Center you are using. To find out your version, look on your Ops Center BUI under [Administration] ==> [Enterprise Controller] and at the top of the middle panel (Summary Tab) will be listed the Enterprise Controller Version. Don't forget to include if there are any IDR's (Patches) that have been applied to your Enterprise Manager Ops Center instance.

Additional Data to include with your SR

The most common thing to include with your SR is an OCDoctor --collectlogs output (# /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs), but it will often depend on which part of the process Ops Center was at when the issue occurred. If your issue falls under multiple sections below, please supply the data from all relevant sections.

It should be noted that all of the Ops Center logs will rollover over time and on a busy environment that may not be a long time. So, it is important to collect any log files as soon as possible after you have seen your issue or you should reproduce the issue just before collecting the logs.

Browser User Interface (BUI) issues

  • Collect screen shots of what you are seeing in the browser
  • Run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on your Enterprise Controller and collect the output file

Job related issues (Job fails)

  • Provide the job number
  • Provide the full job logs
    • In the BUI, click through to the failed task on the job and then export the logs
    • Select the radio button for "Full Job Log" and save the job log
  • Run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on your Enterprise Controller and collect the output file

OS provisioning issues

  • Capture the full job log (as described above)
  • Run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on the relevant Proxy Controller and collect the output file
  • Capture any console logs of either the physical server or, if deploying to LDOMs, capture /var/log/vtnds/[LDOM name]/console.log
  • If deploying to an LDOM, run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on the relevant CDOM and collect the output file

Patching issues

  • Capture the full job log (as described above)
  • Run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on the system being patched and collect the output file
  • Run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on your Enterprise Controller and collect the output file

Discovery issues

  • Capture the full job log (as described above)
  • Run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on your Enterprise Controller and collect the output file
  • Run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on the relevant Proxy Controller and collect the output file

Agent deployment issues

  • Capture the agent install output and logfile (/var/tmp/agent_install, /var/scn/install/log)
  • Capture the agent configuration output and logfile (/var/tmp/agentadm.log)
  • If the agent has actually been installed, run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on the system you are installing the agent on and collect the output file
  • Run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on the relevant Proxy Controller and collect the output file

Domain Model issues

  • Run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs -u [EC Master Admin User] on your Enterprise Controller and collect the output file
    • This will collect the domain model information as well as the normal output from OCDoctor log collect. Note:  this can take a long time to run
    • The [EC Master Admin User] is the user that you specified as part of the initial install. On some customer systems, this will be root but it does not have to be.

Collecting the right information and providing it as part of the initial logging of the SR will make it easier for the engineer to analyze your issue and avoid a lot of unnecessary back and forth. Overall, it will get your issue resolved quicker. I hope this information will help you if you ever have to log a SR on Enterprise Manager Ops Center.


Rodney Lindner

Thursday Jun 26, 2014

Creating A Secondary I/O domain with Ops Center 12.2

Contributed by Juergen Fleischer and Mahesh Sharma.

The purpose of this blog is to show you how to create a Secondary I/O domain. The First I/O domain is commonly known as Control Domain (CDOM). There are various terms that are used for a Secondary domain, like alternative I/O domain or redundant I/O domain.

The secondary I/O domain will have been assigned some physical I/O devices, which may be a PCIe bus root complex, a PCI device, or a SR-IOV (Single Root I/O Virtualization) virtual function.

Within Ops Center when creating a Secondary Domain we also use the terms Physical I/O Domain and Root Domain. The Physical I/O Domain maps PCI device end points, and the Root Domain maps PCIe buses, which also has an option to create SR-IOV functions.

In this blog we will show you how to create a Root Domain by assigning PCIe buses, so that we have a redundant I/O domain which will enable us to shutdown the CDOM without affecting any of our guests.

Our host a T5-2 (we’re using the same host as in the previous blogs) has two free PCIe buses that have not been assigned to domains (pci_2 and pci_3). So let’s create a Secondary I/O domain (Root Domain) with these buses and give the domain two whole cores with 4 GB of Memory.

We’ll start by creating a Logical Domain Profile. This is created from:

Navigation -> Plan Management -> Profiles and Polices, then click on Logical Domain. On the right under Actions select Create Profiles

From the Identify Profile screen, give the Profile a name (Secondary-I/O in our case) and select Root Domain in the Sub-type, as shown above. Click Next.

Step 2: is where we provide a name for our Secondary I/O domain, we called ours secondary and click Next to continue.

The next screen, show below, we entered the amount of cores and memory.

 Step 4: is where we specify how many PCIe buses we will assign to this secondary domain. In our cases we have specified two for  pci_2 and pci_3.

The next few steps are optional and are not required for this example.

Step 7: Is the Summary, if everything looks correct click Finish.

Note: The Metadata is on the local disk (file://guest). This is fine for the Secondary Domain as it will not be migrated. It’s just the Logical domains and their Guests that will get migrated, therefore making it mandatory to have the metadata on shared storage for these – if you want migration to succeed!

Now that we have created the Profile, we will create our Secondary domain (Root domain).

This is done from Navigation -> Plan Management -> Deployment Plans – Create Logical Domain and select the plan we have just created. From the Actions panel on the right select "Apply Deployment Plan".

From the Select Target Asset pop-up, select the CDOM and move it to the Target list. Select Next.

Complete Step 1, by specifying the secondary name.

Step 2, we pick the PCIe Buses that will be assigned to the secondary domain.

In step 3: we kept the default Virtual Disk Sever (vds) name.

The next few screens are not required in this example.

From the Summary screen click Finish. This will create the Secondary Domain.

Once the Secondary Domain has been created we can check if it’s built as we specified. We can check via the Ops Center BUI and also command line.

Let’s do both:

And from the command line

While on the command line we can also check if the buses have been assigned correctly.