The latest information and perspectives on Oracle Enterprise Manager

Wednesday May 15, 2013

Many customers have large collections of physical Solaris 8,
9 and 10 servers in their datacenters and they are wondering how they are going
to virtualize them. This leads to a commonly asked question. Can Enterprise Manager
Ops Center 12C be used to P2V (Physical to Virtual) my
old servers? Ops Center does not
have a single button P2V capability, but it is possible for Ops Center to
deploy physical servers, LDOMs and branded zones based on flash archives(flars) that have been taken of your existing
physical servers. Ops Center achieves P2V by deploying flars
and leveraging its patching and automation capabilities, to make the P2V
process consistent, repeatable and as cost effective as possible.

As with any virtualization
project, there will be a number of things that will need to be updated as you
move from a physical to a virtual environment. It is a common misconception
that you can virtualize a system and change nothing about it. There are always
a few things that have to be changed on an OS or process level to make it
compatible with the virtualized environment. As a best practice, there are many
more things that should be updated, re-allocated and redesigned as part of a
virtualization project but that is a subject for another blog.

In this blog,
we will be covering migrating physical servers to Oracle Solaris Zones.

We will also review this in our community call on Monday , 05/20/2013. Here are web conference details.

Physical Server to Branded Zones

There are 4
basic steps involved in converting a physical server to a virtual server.

Capture

This is done by
creating a flash archive of the source system. If the source system is a
Solaris 10 environment with a ZFS root, it is possible to use a ZFS based flar, but for consistency and ease of coding in the
grooming scripts, I recommend that all flars be taken
as a cpio flash archive.

When capturing
the flar, we should include all the root files
systems that will be required for the new zone to boot. If the application data
is small, it can be included in the flar, but if it
is large, you should copy the application data after the P2V migration is
complete.

Example flar capture command line

# flarcreate -n [HostNameOfSourceSystem] -S -c -L cpio
\

-x /[Dir where archive will be stored] \

/[Dir where archive will be
stored]/[HostNameOfSourceSystem].flar

Note that we are using the –x flag to exclude the directory
where we are storing the archive. You can use multiple –x flags to
exclude any other directories you do not want to include as part of the
archive, such as large application data. Large archives just become difficult
to unpack/pack and upload. As you can imagine, if your source archive contained
100 GB of application data, you would need probably 300-400 GB of space just to
perform grooming, and that would make the process much slower.

Grooming

The first
question I often get is, “Why do I need to groom my flar?”
In an ideal world, you would not need to, but rarely do we live in an ideal
world:

1). If
your environments are like most customers', there are a wide variety of
configurations, patching levels and processes that have been applied to the
source system during its lifecycle. This level of entropy means that there may
well be things that must be fixed, like the following “real world” examples of
problems with source flars that I have observed:

A customer’s
patching methodology had disabled the startup scripts that are required for a
branded zone to boot.

Some
Solaris “df” command patches were missing that are mandatory for Solaris 8/9 branded zones (with a separate
/var) to work.

So formalized grooming is a chance to automate the fixing of these
anomalies and to help standardize your new environment.

2). A common
restriction that is placed on you, in a migration project, is that you cannot
alter/update/reconfigure the source machine to suit its target
virtualized environment. So you have to at least apply any mandatory fixes
needed to the archive file itself and preferably also remove
anything that may conflict with/fail in the new virtualized environment. So,
once again, a formalized grooming is an ideal way to address these
requirements.

You will often
come across the argument that everything must be identical on the new
virtualized environment, in an attempt to minimize change. Let’s be honest
here, while virtualization will aim to provide a functionally identical
environment, there is a massive amount of change that is happening under the
covers when you virtualize a machine and there are a few things that must be
changed to make it work. The history of virtualization projects has shown that
once the existing servers are virtualized, they are almost never revisited to
cleanup the idiosyncrasies of the source machines to bring them into a standard
format. Therefore, I am a supporter of more aggressive grooming and the
cleaning up of years of entropy as part of the P2V process.

The way to make
grooming consistent and less manual and tedious is to convert the steps into an
Operational Plan and use Ops Center to run them in a consistent manner.

Here are some
of the modules I usually include in my grooming plans:

Module

What It Does

Get_FLAR_info

Export flar info as shell variables to be used elsewhere in the
program.

Flar_Cpio_Fmt_Check

Check that
the flar is in cpio
format.

Unpack_Archive

Unpack the flar archive.

Min_OS_Release

Check that
the OS release meets the minimum for branded zones.

ServiceTag_Identity

Remove the service
tag identity file. Old service tags
and duplicate service tags can confuse Ops Center.

SoftPartition_Check

Check that no
soft partition data is included in the flar.

Clean_FMD

Remove any
outstanding FMD faults from source machine.

Clean_SVM

Disable any
references to disk suite (svm/sds/ods) from source machine.

Clean_NFS

Disable any
NFS mounts in vfstab from source machine as they
may not be available in the new virtualized environment and will stop the
zone from booting.

Add_Packages

Add missing
packages if required (the packages you want to add are laid out under a directory
structure).

Add_Patches

Add missing
patches if required (the patches you want to add are laid out under a
directory structure)

App_Disable

Disable application
startup in the flash archive. It is often advisable to disable automatic
application startup as part of the P2V process, so that it cannot
conflict/corrupt the production source machine.

Agent_Cleanup

Un-configure
OC agent and cleanup OC identity files in case the source system was already
under Ops Center control.

Pack_Archive

Repack the flar archive.

These are just
some of the common modules that I have used over the years on P2V projects. You
may not need any or all of these. You may need to create your own module if you
find something unique in your source machines. Grooming is an iterative process,
as your source machines can vary wildly from any machine I have ever come
across. This is not an Ops Center thing; this is just the nature of P2V on a
source pool of unknown quality. So if you hit an issue, troubleshoot it, add a
new module to the Operational Plan and try again. To help get you started, I
have included some sample code [Sample Grooming
script]. This script provides examples of what can be done and should be
considered an example of how you can build your own grooming script.

Loading the
script into an Operational Plan is as simple as:

Creating a new Operational Profile

Give the plan a name, and select Operating System as the target type.

Click browse to find the script and then load it. I have increased the profile time out to 180 minutes as grooming large flars can take a while.

Finally, specify any variables for which the script requires user
input. You can specify the variable as required or optional and provide a hint/description to help the user at run time.

So how do I
groom my flar?

Step 1) Copy the
flar taken from the source system onto any system
managed by Ops Center that has sufficient space.

Step 2) Launch
your grooming “Operational Plan” against the system to which you copied the flar.

To make these actions repeatable and consistent, I employ Operational Plans or Update Profiles.

Operational Plans – These are scripts that make actions
repeatable and can be modified by operator input (Operational Plan Variables)
at run time.

Update Profiles - These can contain patches, packages, scripts
and customized configuration files (based on the system you are deploying to).

Choose the
right method for what you are trying to do or combine both of them together in
a Software Deployment/Update Plan.

Congratulations
you have P2Ved your system.

Conclusion

It is fairly
straightforward to automate the migration of physical servers to Oracle Solaris
Zones using Enterprise Manager Ops Center. Operational Plans and Update Profiles are great tools to automate many of
those operational tasks and increase their reliability and repeatability.

Look out for a
future blog on “How to P2V to Oracle Virtual Machine for SPARC using
Enterprise Manager Ops Center“.

Tuesday Nov 27, 2012

Introduction:

This Oracle Enterprise Manager Ops Center blog entry provides tips for using Ops Center to update Solaris using Live Upgrade on Solaris 10 and Boot Environments on Solaris 11.

Why use Live Upgrade?

Live Upgrade (LU) can significantly reduce downtime associated with patching

Live Upgrade avoids dropping to single-user mode for long periods of time during patching

Live Upgrade relies on an Alternate Boot Environment (ABE)/(BE), which is patched while in multi-user mode; thereby allowing normal system operations to continue with the active BE, while the alternate BE is being patched

Activating a newly patched (A)BE is essentially a reboot; therefore the downtime is ~= reboot

Admins can easily revert to the prior Boot Environment (BE) as a safeguard / fallback.

All the benefits of Ops Center's extensive patch and package knowledge base can be leveraged on top of Live Upgrade

Ops Center can orchestrate patching based on Live Upgrade and Solaris 11 features, which all works together to minimize downtime

Ops Center's advanced inventory and reporting features assure that each OS is updated to a verifiable, consistent standard, rather than relying on ad-hoc (error prone) procedures and scripts

Ops Center gives admins control over the boot environment specifications or they can let Ops Center decide when a BE is necessary, thereby reducing complexity and lowering the opportunity for user error

Preparing to use Live Upgrade on Solaris 10

Requirements and information you should know:

Live Upgrade Pre-requisite patches must be applied before the first Live Upgrade Alternate Boot Environments are created (see "Pre-requisite Patches" section, below...)

Solaris 10 Update 6 or newer on ZFS root is the practical starting point for Live Upgrade

Live Upgrade with ZFS root is far more straight-forward than any scheme based on Alternative Boot Environments in slices or temporarily breaking mirrors

Use Solaris best practices to upgrade the OS to at least Solaris 10 Update 4 (outside of Ops Center)

UFS root can (technically) be used, but it is significantly more involved (e.g. discouraged) -- there are many reasons to move to ZFS while going through the process to update to Solaris 10 Update 6 or newer (out side of Ops Center)

Recommendation: Start with Solaris 10 Update 6 or newer on ZFS root

Recommendation: Start with Ops Center 12c or newer

Ops Center 12c can automatically create your ABE's for you, without the need for custom scripts

NOTE: There is no magic! If you have systems running Solaris 10 Update 5 or older on UFS root, and you don't know how to get them updated to Solaris 10 on ZFS root, then there are services available from Oracle Advanced Customer Support (ACS), which specialize in this area.

Live Upgrade Pre-requisite Patches (Solaris 10)

Certain Live Upgrade related patches must be present before the first Live Upgrade ABE's are created on Solaris 10.Use the following MOS Search String to find the “living document” that outlines the required patch minimums, which are necessary before using any Live Upgrade features:

Solaris 10 OS Update Plan (two-steps in this case)

Create a Solaris 11 OS Update Profile containing the packages that make up your standard build

ACTUALLY deploy the Solaris 11 OS Update Profile

BE will be created if needed (or you can stipulate no BE)

BE name will be auto-generated (if needed), or you may specify a BE name

Check the job status for each node, resolving any issues found

Check if a BE was created; if so, activate the new BE

Activate = Reboot to the BE, making the new BE the active BE

Ops Center does not separate BE activate from reboot

NOTE: Not every Solaris 11 OS Update will require a new BE, so a reboot may not be necessary.

Solaris 11: Auto BE Create (as Needed -- let Ops Center decide)

BE to be created as needed

BE to be named automatically

Reboot (if necessary) deferred to separate step

Solaris 11: OS Profile

Solaris 11 “entire” chosen for a particular SRU

Solaris 11: OS Update Plan (w/BE)

“Create a Boot Environment” + “Update OS” are chosen.

Summary:

Solaris 10 Live Upgrade, Alternate Boot Environments, and their equivalents on Solaris 11 can be very powerful tools to help minimize the downtime associated with updating your servers. For very old Solaris, there are some important prerequisites to adhere to, but once the initial preparation is complete, Live Upgrade can be used going forward. For Solaris 11, the built-in Boot Environment handling is leveraged directly by the Image Packaging System, and the result is a much more straight forward way to patch, and far fewer prerequisites to satisfy in getting there. Ops Center simplifies using either approach, and helps you improve consistency from system to system, which ultimately helps you improve the overall up-time across all the Solaris systems in your environment.

Monday May 21, 2012

One of the more significant new features in Oracle Enterprise Manager Ops Center 12c is the ability to install Ops Center on Oracle Solaris 11, and to deploy and manage systems running Solaris 11. The Solaris 11 capabilities are in addition to the analogous features for Solaris 10 and Linux, which can all be handled from the same Ops Center infrastructure.

When the Ops Center Enterprise Controller (EC) is installed on a system running Solaris 11, the EC can create a Solaris 11 Software Update Library containing Oracle Solaris Image Packaging System (IPS) content that is synchronized with the main Oracle repository at pkg.oracle.com. The Ops Center managed Solaris 11 repository becomes the package (pkg) publisher for downstream Solaris 11 deployments and updates on all Solaris 11 systems being managed by Ops Center.

Ops Center provides the ability to define Solaris 11 OS and Software Profiles comprised of Oracle Solaris 11 packages, user-supplied custom packages, scripts, and other files. Such Software Profiles profiles can then be used to install and update software on systems already running Solaris 11 in a structured and consistent way. Ops Center not only caches the main Oracle Solaris IPS repository, but more importantly it gives admins the ability to define their own preferred collection of packages so that systems can easily be kept in sync with each other, running a well-defined, life-cycle-managed Standard Operating Environment (SOE), instead of just whatever the latest content is at pkg.oracle.com.

Ops Center 12c also adds Solaris 11 features for bare-metal OS Provisioning, based on the Solaris 11 Auto Install (AI) facility. Ops Center configures the Solaris 11 AI in a way that shields admins from needing to write custom AI manifests or custom "first boot" packages. Solaris 11 deployments using Ops Center follow similar profile-based patterns as for Solaris 10 or Linux, all of which can all be deployed from the same Ops Center infrastructure running on Solaris 11. The gory details of all these different times of bare-metal OS Provisioning are handled automatically for the user so that he or she does not need to put time and resources into manually creating and maintaining infrastructure for deploying different OS's natively -- Solaris 11 with AI, Solaris 10 JumpStart with JET, or Linux with Kickstart or AutoYast. All of those OS's are handled by Ops Center under the covers, based on whatever network boot capability the OS requires (PXE/DHCP, WANBOOT, or AI), and all from the same Ops Center infrastructure running on Solaris 11.

Specific to Solaris 11 OS Provisioning (via AI), Ops Center provides its own "first-boot" package+scripts to customize the Solaris 11 deployment, and in particular this approach automatically installs the Ops Center agent. With the Ops Center Agent in place right from the start, it is easy to handle post-install steps using the Ops Center features for handling Solaris 11 OS and Software Profiles containing additional packages, scripts, and content from the Solaris 11 Software Library, described above.

Tying bare-metal Solaris 11 deployment and post-install customization together is a key way that Ops Center simplifies the overall life-cycle management for Solaris 11 (in addition to Solaris 10 and Linux). For example, a top-level plan based on "Configure and Install Logical Domains" can create numerous Logical Domains into an Oracle VM Server for SPARC "Server Pool" and provision Solaris 11 into each LDom Guest based on a powerful multi-step "Install Server" plan. Such a plan can cover the end-to-end steps for installing and updating the OS, running scripts and adjusting monitoring parameters, etc.

Here is an example of the kinds of activities that can be performed in conjunction an OS Deployment, or separately, depending on the need:

NOTE: In the above example, the last step "Create Guests" can be used to create one or more Solaris Containers within the LDom Guest, rounding out the end-to-end deployment all the way from LDom Guest to Solaris 11 Global Zone to multiple Solaris Containers, if so desired.

One of the nicest aspect of deploying and managing Solaris 11 using Ops Center Plans and Profiles is that the same content can be applied as updates to existing Solaris 11 systems, aligned to the same content as chained off a bare-metal OS Provisioning. It is up to the user which steps they want to include in a deployment plan -- whether they are updating Software Profiles on systems deployed 6 months ago to match the latest standard, or they are deploying new systems based on that same standard, Ops Center provides the means to insure that the outcome is consistent.

Here is an example of the kinds of activities that can be performed on an existing Solaris 11 OS -- either ad hoc, or immediately after a Solaris 11 OS Provisioning step, so that whether the life-cycle started with a new system, or the intent is to update a system deployed six months ago, the outcome can be the same:

In short, Ops Center running on Solaris 11 can manage Solaris 10 and Linux systems, all from a common infrastructure, and all based on a simplified, consistent, profile- and plan-based way to do the OS and Software deployments and updates. The net effect is an easy to use way to managing the life-cycle of heterogeneous systems, in a very consistent way through automation and re-use.

Tuesday Apr 24, 2012

Earlier this month, at Oracle Enterprise Manager Ops Center 12c launch, we published a series of demos of Oracle Enterprise Manager Ops Center 12c managing various Oracle solutions from applications to hardware . You could see all of those demos by clicking the graphic below. Following the graphics below, I have a brief overview of an enterprise customer scenario and various demos highlighting the management of various systems .

A Step-by-Step Journey to Enterprise Clouds

A large global financial company serving millions of customers worldwide has
decided to investigate a private cloud infrastructure. They have multiple
business units and are located in multiple regions worldwide.

Their enterprise applications include Oracle Siebel CRM, Oracle E-Business
Suite Financials, and PeopleSoft HCM. They have recently added several Oracle
Fusion Applications modules to enhance their CRM and HCM capabilities. Over
time, they have also deployed a number of Java and web-based applications. They
use Oracle Solaris/SPARC environments for their E-Business Suite applications.
Their web servers, some of their application servers, and a number of the home
grown applications run on Oracle Enterprise Linux and Oracle x86 servers. They
have deployed Oracle virtualization solutions for x86 servers and SPARC.

This company is transitioning their IT to a private cloud environment to
support the CEO’s new corporate strategy to increase operational efficiency by
10% while growing the top line by 30% in two years. The IT organization, led by
their CIO, considered various options and concluded that achieving the CEO’s
objectives would require them to transition their enterprise applications to
the cloud, thereby creating real differentiation in how they service their
customers. They reviewed several vendors and concluded that their private cloud
solutions were adequate for small applications but too risky for enterprise
applications. They decided to go with the an Oracle solution because only
Oracle was able to demonstrate a proven solution to power enterprise
applications while also leveraging SPARC and x86 virtualization for a complete
cloud management solution.

They have already started to deploy Database-as-a-Service and Fusion
Middleware-as-a-Service clouds using Oracle Enterprise Manger Self Service
Application Portal. They plan to deploy Infrastructure-as-Service cloud based
on both SPARC and x86 servers with Oracle virtualization solutions and manage
them through Oracle Enterprise Manager Ops Center. They have recently deployed
many ExaData systems. They are starting to deploy ExaLogic and Super Clusters
Engineered systems as well to accelerate performance and time to market.

Integrated Linux Management in the Cloud

Linux Management functionality is available as part of Oracle Enterprise
Manager 12c and is available to Oracle Linux Basic and Premier Support
customers at no cost. The solution provides an integrated and cost-effective
solution for complete Linux server lifecycle management and delivers
comprehensive provisioning, patching, monitoring, and administration
capabilities via a single, web-based user interface thus significantly reducing
the complexity and cost associated with managing Linux operating system
environments.

Using these rich Linux management features along with the complete Oracle
Enterprise Manager product solution, the global financial company takes
advantage of enterprise-scale service level management, automated change and
configuration management, and comprehensive system and application performance
management.

Integrated Lifecycle Management for Physical and Virtual Servers in the
Cloud

Oracle VM offers server virtualization for both x86 and SPARC architectures
that enable the deployment of agile cloud infrastructures. Virtualized server
environments integrated with Oracle Enterprise Manager Ops Center allow you to
easily create, deploy, clone virtual servers, and live migrate workloads while
dynamically controlingcompute resources. Integrated lifecycle management of both
physical & virtual servers with Ops Center simplifies the daily
workflowneeded to control cloud infrastructures. This is one of the key reasons
why this company decided power their private cloud with Oracle virtualization
technologies.

Oracle Solaris 11 – The First Cloud OS

With its new and improved features, Oracle Solaris brings mission-critical
enterprise class computing to cloud scale environments. These features include
extremely agile, no overhead virtualization, simplified software lifecycle
management, and built-in security across all layers. Oracle Enterprise Manager
Ops Center understands all these new technologies, and therefore is the perfect
tool to manage Oracle Solaris deployments at data center and cloud scales.

Manage Mission Critical Applications in the Cloud

Deploying and managing mission critical applications in cloud are one of the
key strategic interests of the enterprises. Oracle SPARC based
Infrastructure-as-a-Service ( IaaS ) offers the scale, reliability, and
performance needed for those mission critical applications. In this demo, you
will learn about how to manage SPARC server platforms, which is the foundation
of the enterprise cloud this global financial company wants to deploy The
Oracle SPARC technologies offers an extreme thread count and memory density in
a small and eco-friendly form factor. This company wanted to insure they could
leverage their existing SPARC population with not excluding new growth into the
T4 chassis models. They found Ops Center offered them complete coverage of
where they were the most invested.

Private PaaS and IaaS Cloud with Oracle Enterprise Manager

Oracle Enterprise Manager provides complete lifecycle management for cloud -
from automated cloud setup, to delivery, to cloud operations. Learn how Oracle
Enterprise Manager Cloud Control 12c and Oracle Enterprise Manager Ops Center
12c work together to provide an end-to-end solution to take you from zero to
cloud in a day, whether the goal of your private cloud is Infrastructure as a
Service (IaaS) or Platform as a Service (PaaS).

This demo showcases Engineered Systems Management capabilities of Oracle
Enterprise Manager Cloud Control and Ops Center 12c. You can now manage all
components of Oracle Exadata Database Machine, from databases to cell storage
to network swicthes, from a single console. Similarly, you can now manage all
aspects of Oracle Exalogic, including software and hardware, from a single
console. Learn how Oracle Enterprise Manager is engineered systems-aware and
provides insight into the performance, configuration and physical health of
these highly performance machines.

Simplify Your Data Center with Exalogic Elastic Cloud

Oracle Exalogic Elastic Cloud is the industry’s Best Foundation for Cloud. It
is hardware and software engineered together to provide extreme performance for
Java applications, Oracle Applications, and other enterprise applications.
Exalogic offers fully integrated compute nodes, storage and networking, fully
integrated ZFS network attached storage appliance with 40TB of SAS disk
storage, QDR InfiniBand IO Fabric, with 40 Gb/second throughput and microsecond
latencies, Data center service network integration with 10 GbE, Scalable, open
standard grid architecture. That means less effort spent by you on putting the
pieces together and more time spend on extending the business value of your
applications.

Check out this demonstration to learn more about Exalogic and the right
configuration that meets your needs.

Oracle Software Runs
Best on Oracle Hardware

Oracle Enterprise Manager offers the right amount of information across the
stack, breaking down isolated IT organizations and helps make a stronger
connection between the business services and the server assets they utilize.

Tuesday Apr 10, 2012

In February, we posted a blog of Oracle Enterprise Manager Ops Center Doctor aka OCDoctor Utility. This utility assists in various stages of the Ops Center deployment and can be a real life saver. It is updated on a regular basis with additional knowledge (similar to an antivirus subscription) to help you identify and resolve known issues or suggest ways to improve performance.A new version ( Version 4.03 ) of the OCDoctor is now available . This new version adds full support for recently announced Oracle Enterprise Manager Ops Center 12c including prerequisites checks, troubleshoot tests, log collection, tuning and product metadata updates. In addition, it adds several bug fixes and enhancements to OCDoctor Utility.

Join Oracle Launch Webcast : Total Cloud Control for Systems
on April 12th at 9 AM PST to learn more about Oracle Enterprise
Manager Ops Center 12c from Oracle Senior Vice President John Fowler,
Oracle Vice President of Systems Management Steve Wilson and a panel of
Oracle executive.

Thursday Mar 08, 2012

IT professionals are excited by the technical advantages of cloud computing, and Line of Business managers look to the cloud as a driver of business growth, efficiency, and productivity. By transforming IT into a business-centric provider of services that users can access from anywhere, Oracle Enterprise Manager 12c helps you build a more agile, efficient, and innovative enterprise.

If you have to apply a list of patches to multiple systems every now and then, creating an Update Profile would be the best method, as once you have created the Profile it can be used many times ensuring the exact same patches in the list are applied each and every time.

Update Profiles are located in the 'Plan Management' section. Update Profiles can be used in two ways: either you select a single or a group of OS assets and pick the action 'New Update OS Job'. Or, you pick the Update Profile in the Plan Management section and select 'New Update OS Job'. The wizard will allow you to select one or more target assets or groups.

For regular Baseline Patching 'Update Profiles' can be based on given patchsets which are made available by the Ops Center Knowledge Base (KB).

The KB offers two different patchsets, the monthly released Solaris Baselines (based on Oracle's internal EIS-DVD) and the current or archived versions of the "Recommended Patchset for Solaris". These are updated whenever a new critical patch gets released. Every quarter, one of these Recommended Patchsets for Solaris will be renamed as the 'Critical Patch Update' in line with standard Oracle practice. It's up to the Customer's patching policy and strategy to determine which patchsets should be used and how often they should be applied.

Scenario 4 - Latest & Greatest patchset

Finally, if required, Customers can select what is called "Latest & Greatest" patchset. These are all the latest available patches for all installed packages. To perform this task, use the 'Host Compliance Report' and tick the Security & Bug Fixes check box.

So far, we have talked about various scenarios around applying a single patch or multiple patches. These patches can be applied on a running system or by using LiveUpgrade (LU). LU allows creating Alternate Boot Environment (ABE), Synchronizing boot environments, Patching the ABE and then Activating the ABE.For detailed examples and howto examples:

Tuesday Feb 07, 2012

This blog provides a short history of how Oracle technology in the Solaris and SPARC world has progressed to where we are with the SPARC-T4 Server family and Oracle VM Server for SPARC (formerly Logical Domains). The entry continues with observations of why these technologies are relevant to business and IT stakeholders, today. And finally, how Oracle Enterprise Manager Ops Center is piquing customer interest in moving forward with Logical Domains, followed by a short demonstration of LDom Migration in action.[Read More]