zones p2v

About two years ago the zones team sat down and began to create the
solaris8 brand
for zones. This brand allows you to run your existing
Solaris 8 system images inside of a branded zone on Solaris 10. One
of the key goals for this project was to easily enable migration of Solaris 8
based systems into a zone on Solaris 10. To accomplish this, as part of the project we
built support for a “physical to virtual” capability, or p2v for short.
The idea with p2v is that you can create an image of an existing system
using a flash archive, cpio archive, a UFS dump, or even just a file system image
that is accessible over NFS, then install the zone using that image.
There is no explicit p2v tool you have to run; behind the scenes the zone installation process
does all of the work to make sure the Solaris 8 image runs correctly inside
of the zone.

Once we finished the solaris8 brand we followed that with the
solaris9 brand
which has this same p2v capability. Of course, while we were doing
this work, we understood that having a similar feature for native zones would
be useful as well. This would greatly simplify consolidation using zones,
since you could deploy onto bare metal, then later consolidate that application
stack into a zone with very little work.

The problem for p2v with native zones is that there is no brand module
that mediates between the user-level code running in the zone and the
kernel code, as we have with the solaris8 and solaris9 brands. Thus, the
native zones must be running user-level code that is in sync with the kernel.
This includes things like libc, which has a close relationship with the kernel.
Every time a patch is applied which impacts both kernel code and user-level
library code, all of the native zones must be kept in sync or unpredictable
bugs will occur.

Just doing native p2v, as we did for the solaris8 and solaris9 brands, doesn’t make
sense since the odds that the system image you want
to install in the zone will be exactly in sync with the kernel are pretty low.
Most deployed systems are at different patch levels or even running different minor releases (e.g.
Solaris 10 05/08 vs. 11/08), so there is no clean way to reliably p2v those images.

We really felt that native p2v was important, but we couldn’t make any progress
until we solved the problem of syncing up the system image to match the
global zone. Fortunately I was able to find some time to add this capability,
which we call
update on attach.
This was added into our zone migration
subcommands, ‘detach’ and ‘attach’, which can be used to move zones from
one system to another. Since zone migration has a similar problem as p2v,
where the source and target systems can be out of sync, we do a lot of
validation to make sure that the new host can properly run the zone. Of
course this validation made zone migration pretty restrictive. Now that we
have “update on attach”, we can automatically update the zone software when you
move it to the new host.

While “update on attach” is a valuable feature in its own right, we also built this
with an eye on p2v, since it is the enabling capability needed for p2v. In addition,
we leveraged all of the work
Dan Price
did on the installers for the solaris8 and solaris9 brands and were able to reuse much of that.
As with the solaris8 and solaris9 brands, the native brand installer accepts a variety of
image inputs; flar, cpio, compressed cpio, pax xustar,
UFS dump or a directly accessible root image (e.g. over NFS). It was also
enhanced to accept a pre-existing image in the zone root path. This is
useful if you use ZFS send and receive to set up the zone root and want
to then p2v that as a fully installed zone.

I integrated the
native p2v
feature into NV build 109 this morning. The
webrev
from the code review is still available if anyone is interested in seeing the scope of the
changes. At over 2000 lines of new code this is a pretty substantial addition
to zones which should greatly improve future zone consolidation projects.

Posted on February 11, 2009 at 9:01 am by jerry · Permalink
In: General

5 Responses

Subscribe to comments via RSS

  1. Written by Craig S. Bell
    on February 11, 2009 at 10:08 am
    Permalink

    Jerry, thank you for making native p2v possible — that’s very cool! I look forward to trying it.
    Are you also considering a non-native Solaris 10 brand? This would make it possible to (for example) patch a 5.10 full-root non-global zone independently from the global zone.
    I’ve heard that zone patch enhancements are coming (i.e. parallel patching of NGZ’s), but another idea was to de-couple a 5.10 zone with the use of a non-native solaris10 brand, as with S8 and S9.
    Now, if only certain app vendors would bother to support NGZ’s, we could use them more frequently. It’s all about supportability and licensing. Thanks for any info, and way to go on the native p2v.
    -cheers, CSB

  2. Written by Anil
    on February 23, 2009 at 10:59 pm
    Permalink

    Can we run the zones with zonepath on an NFS partition? (will OpenSolaris ever address that… through a good workaround or other?). I seem to recall there are some challenges for that… can you perhaps elaborate in another post?
    Thanks

  3. Written by eric
    on March 17, 2009 at 2:26 am
    Permalink

    I installed snv_109 on my new computer. How should i use the upgrade on attach fonctionality to import / attach a zone coming from snv_104 ?

  4. Written by Sriram Narayanan
    on May 2, 2009 at 10:23 pm
    Permalink

    An informative post. Thank you !

  5. Written by Murat Gokmen
    on April 11, 2010 at 5:36 am
    Permalink

    Thanks for the p2v support Solaris10 zone in SNV (or Solaris 11??) Will it be available in an Solaris 10 update in near future?
    Seemingly you have delivered a solution for S10 branded zone in SNV.

Subscribe to comments via RSS

Leave a Reply