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.
Topic: How to P2V to
Oracle Solaris Zones using Enterprise Manager Ops Center
Date: Monday, May 20, 2013
Time: 5:00 pm, Eastern Daylight Time (New York, GMT-04:00)
Meeting Number: 594 835 639
Meeting Password: oracle123
To join the online meeting (Now from mobile devices!)
1. Go to https://oracleconferencing.webex.com/oracleconferencing/j.php?ED=236653047&UID=1653030737&PW=NNzUxYjUwOWY5&RT=MiMxMQ%3D%3D
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: oracle123
4. Click "Join".
To view in other time zones or languages, please click the link:
To join the teleconference only
Call-in toll-free number: 1-866-682-4770 (US/Canada)
Conference Code: 7629343#
Security code: 7777#
Ops Center does
not do anything differently to what you could do by hand,
it just automates the process and, by the use of templates and wizards, drives
consistency and repeatable results.
Physical Server to Branded Zones
look at converting existing Solaris 8, 9 and 10 physical servers into Solaris
8/9 branded zones (on Solaris 10) and Solaris 10 branded zones (on Solaris 11).
There are 4
basic steps involved in converting a physical server to a virtual server.
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.
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
Example flar capture command line
# flarcreate -n [HostNameOfSourceSystem] -S -c -L cpio
-x /[Dir where archive will be stored] \
/[Dir where archive will be
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.
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
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.
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
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:
| What It Does
Export flar info as shell variables to be used elsewhere in the
the flar is in cpio
Unpack the flar archive.
the OS release meets the minimum for branded zones.
Remove the service
tag identity file. Old service tags
and duplicate service tags can confuse Ops Center.
Check that no
soft partition data is included in the flar.
outstanding FMD faults from source machine.
references to disk suite (svm/sds/ods) from source machine.
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.
packages if required (the packages you want to add are laid out under a directory
patches if required (the patches you want to add are laid out under a
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.
OC agent and cleanup OC identity files in case the source system was already
under Ops Center control.
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.
script into an Operational Plan is as simple as:
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.
Step 3) Have a
cup of coffee... then check the logs
Step 4) You now have a flar ready for
uploading into Ops Center.
where this process comes under full Ops Center control.
Step 1) Load
your groomed flar into the EC library.
Step 2) Create
a profile for the zone you want to deploy.
Step 3) Deploy
When the job
completes, you have your source system as a zone.
What are the
sorts of actions you can do here?
Add additional networks if you only deployed with a single network.
- Update the application configuration.
- Update secondary apps like backup software, application monitoring, etc.
- Re-enable application startup scripts and remote file systems in vfstab.
- Do any updates to patches/packages/applications.
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).
right method for what you are trying to do or combine both of them together in
a Software Deployment/Update Plan.
you have P2Ved your system.
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“.