SPARC: Lift & Shift Solaris 10 ZFS RPool

SPARC: Lift & Shift Solaris 10 ZFS RPool

Abstract:

Since the adoption of SMP (Symmetric Multi Processing) by Sun Microsystems, there has been a shift in consolidation on chassis: co-hosting applications on a common OS instance, applications leveraging limited protections with "chroot", hosting multiple OS's on the same chassis through PDoms (Physical Domains), hosting multiple OS's via LDoms (Logical Domains), hosting applications in Solaris Containers (Zones). Sun had created techniques to lift-and-shift UFS based Solaris instances to LDoms, but had not provided a way forward for virtualization of ZFS bsed Solaris 10 systems... until days ago.

Solaris 10 P2V With ZFS Root

With Solaris 10 coming "end of life" and the push to Solaris 11 going strong, there is still a need to consolidate older model chassis. There is a guide called "Lift and Shift". Sekhar Lakkapragada, Senior Principal Software Engineer at Oracle, wrote an article on  how to accomplish this very task:

"Migrate Oracle Solaris 10 Physical Systems with ZFS root to Guest Domains in 3 Easy Steps" 

ldmp2vz

Sekhar posted a tool to accomplish this very activity, to the Oracle Solaris Blog. A short synopsis:

We are happy to announce that we now offer a new tool called ldmp2vz(1M) that can migrate Oracle Solaris 10 source systems with ZFS root. This tool has two commands; ldmp2vz_collect(1M) and ldmp2vz_convert(1M). These two commands enable migration of a sun4u or a sun4v Oracle Solaris 10 physical machine to an Oracle Solaris 10 guest domain on a system running Oracle Solaris 11 in the control domain as shown in this diagram.

In short, it is a 3 step process, not dissimilar from the ldmp2v tool:

1. Collection: Run ldmp2vz_collect(1M) on the source for system image and configuration
2. Preparation:  Create a new Oracle Solaris 10 SPARC guest domain using ovmtdeploy(8), Jumpstart, or DVD.
3.  Conversion: Run ldmp2vz_convert(1M) from prepared Solaris 10 guest domain using Live Upgrade technology.

Sekhar 

Conclusions:

This has been a long time coming, but it is welcome, none the less.

Virtualizing Solaris

Abstract:
The movement from physical to virtual servers has been happening for decades. First, the use of Physical Domains under SPARC "big-iron" became possible when Sun purchased Cray SPARC assets in 1996 while SGI purchased the remaining. The Sun Enterprise 10000 was introduced in 1997 with Physical Domains. With the release of Solaris 10 almost a decade ago, physical systems could be moved to logical Zones under a single kernel in 2004. With the line of T processors, the ability to load multiple OS's on the same platform at the firmware layer became possible in 2006. This article discusses LDom's.

P2V:
Physical to Virtual Migration or P2V is possible to consolidate physical Solaris platforms onto various virtualized Solaris platform destinations - such as Zones, Branded Zones, or LDom's. The P2V process uses an archive called a FLAR.

P2V and Branded Zone:
An Oracle Enterprise Manager blog was published recently, explaining how to move a physical server to a Branded Zone. The May 15th blog was titled: "How to go Physical to Virtual with Oracle Solaris Zones using Enterprise Manager Ops Center."

Logical Domains:
The documentation describing the deployment of the Logical Domains for Oracle Enterprise Manager is available under Oracle's web site. Each Logical Domain, sits on top of the firmware of T-Class processors, and can host Solaris 11, Solaris 10, and Solaris 10 can host older Solaris 8 & 9 Operating System under Branded Zones.

Network Management Implications:
Network Management platforms can very easily be consolidated onto newer platforms, with very little effort, using free drag-and-drop tools such as Oracle Enterprise Manager. If a network management center is still running under multiple older Physical platforms, one should consider Zones or LDom's, which offer virtually no overhead (in comparison to systems such as VMWare or HyperV which require a foreign software layer between their domains and the hardware, introducing problematic latency under heavy loads.)