Zone migration

[May 12, 2007] OpenSolaris Forums zone migration ...

Jan 20, 2006 | opensolaris.org

For those interested in zone migration, I have just submitted
a fast-track through our internal architectural review process.
The body of the proposal is enclosed.

Let me know if there are any questions.

Thanks,
Jerry

----

SUMMARY:

This fast-track enhances the Solaris Zones [1] subsystem
to address an existing RFE[2] requesting the ability to migrate
an installed non-global zone from one machine to another.

We will implement the concept of detaching and attaching a zone.
An installed non-global zone must be detached prior to moving it
from one system to another. The process of detaching the zone
will create the information necessary to attach the zone on a
different system. Attaching the zone will first validate that the
new machine is capable of properly hosting the zone.

Patch binding is requested for the new sub-commands and the stability
of these interfaces is "evolving".

DETAILS:

Overview

Migrating a zone from one system to another involves the following
steps:

1. Detaching the Zone. This leaves the zone on the originating
system in the "configured" state. Behind the scenes, the
system will generate a "manifest" of the information needed
to validate that the zone can be successfully attached to a new
host machine.

2. Data Migration. The system administrator moves the data which
represents the zone to a new host system (more details below).

3. Zone Configuration. The system administrator creates the zone
configuration on the new host using zonecfg(1m).

4. Attaching the zone. This will validate that the host is
capable of supporting the zone before the attach can succeed.
The zone is left in the "installed" state.

Validation

The validation will check that the exact version of the required
packages and patches are installed on the new host. The algorithm
to determine the packages and patches that must be validated is:

For each package installed in the global zone:
- ignore the package if SUNW_PKG_THISZONE is 'true'
otherwise,
- validate the package if
a) SUNW_PKG_ALLZONES is 'true',
or
b) any file delivered by the package is in a file system
that is inherited from the global zone.
If the zone does not inherit any file systems (whole root)
then (b) will be skipped.

For each of the packages that is being validated we will
also validate all of the associated patches.

In the future we plan to extend this so that we might upgrade
the zone or add patches to the zone when we attach, but initially
we will only validate the new host and inform the sys-admin if there
are packages or patches that are out of sync with what was installed
on the original host machine.

In order to validate the package and patch versions from the
original host and new host, we will read this information
from the pkginfo files in /var/sadm/pkg. We will also need to
read the /var/sadm/install/contents file to determine which packages
are within inherited-pkg-dirs. While some of this information
is public, the contents file format and the existence of the pkginfo
files within /var/sadm/pkg is not. These are contract private
interfaces and a contract with the Install group, to allow us to
access these files, is part of this case.

zoneadm Sub-Commands

We will add two new sub-commands to the zoneadm command and one
new option to the create subcommand within zonecfg.

The syntax for detaching a zone will be:

# zoneadm -z my-zone detach

The zone must be halted before being detached.

During detach we will generate metadata describing the versions of
the packages and patches installed on the host. This will be stored
in an XML file in the zonepath, alongside the root and dev
directories. This facilitates easy movement of the zonepath from one
system to another.

We will not implement any kind of archive for a detached zone.
We will document what the sys-admin must do to move the zone
bits around, but they can move this any way they choose.
In some cases, such as a SAN environment, the bits might not have
to move at all.

When we detach, we leave the zone in the configured state.
The sys-admin can then delete the configured zone or attach to
it later.

The syntax for attaching a zone will be:

# zoneadm -z my-zone attach [-F]

Attaching a zone is analogous to installing a zone. That is, you
first must configure the new zone using the zonecfg command. Once
you have the new zone in the configured state you can use attach to
set up the zone root instead of installing.

During attach we will perform the package and patch sanity checks
described above. This will validate that the attach can occur.
If the packages and patches don't match we will list which packages
and patches are out of sync and the zone will be left in the
configured state. The sys-admin can then apply any required
packages or patches to the host to enable the attach to succeed.
Or, they may not be able to attach to the specific host if the
installed software is sufficiently incompatible with the environment
on the original machine.

Once the attach has completed successfully, the XML file describing
the zone will be removed. If you try to install or clone to a
configured zone and there is an XML description for a detached zone
in the zonepath, we will give an error and won't proceed.

The -F option for attach allows the sys-admin to force the attach
with no validation. This is useful in certain cases such as
a clustered environment or for backup/restore, but it does require
that the sys-admin is certain that the system is properly configured
to host the zone or undefined behavior may later occur.

zonecfg create option

To facilitate configuring the detached zone on a new host we will
add a new '-a' option to the create subcommand within zonecfg.

The subcommand for creating a new zone from the detached XML data
will be:

zonecfg:my-zone> create -a path_to_zone_root

The -a option will used the XML description of the detached
zone to configure the new zone instance. It is not required to
to configure the new zone this way. That is, the new zone
can be configured using the traditional zonecfg operations and
then "zoneadm attach" can be used to attach the zone root.
All of the validation of the zone happens during attach, not
during configuration of the zone.

EXAMPLE

host1# zoneadm -z my-zone detach

- move the my-zone zonepath from host1 to host2

host2# zonecfg -z my-zone
my-zone: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:my-zone> create -a /export/zones/my-zone
zonecfg:my-zone> commit
zonecfg:my-zone> exit
host2# zoneadm -z my-zone attach

Here is an example where some packages and patches are out of sync
between the source host and the local host we are attempting to attach
to. The actual syntax of the error messages will be different in the
final implementation, this is just an example to give an idea of what
might happen.

host2# zoneadm -z my-zone attach
source host packages inconsistent with local host
SUNWgnome-libs (2.6.0,REV=101.0.3.2005.12.06.20.27) version mismatch
(2.6.0,REV=101.0.3.2005.12.19.21.22)
SUNWudaplr (11.11,REV=2005.12.13.01.06) version mismatch
(11.11,REV=2006.01.03.00.45)
SUNWradpu320 (11.10.0,REV=2005.01.21.16.34) is not installed
SUNWaudf (11.11,REV=2005.12.13.01.06) version mismatch
(11.11,REV=2006.01.03.00.45)
NCRos86r (11.10.0,REV=2005.01.17.23.31) is not installed
local host packages inconsistent with source host
SUNWukspfw (11.11,REV=2006.01.03.00.45) was not installed
SUNWsmcmd (1.0,REV=2005.12.14.01.53) was not installed
source host patches inconsistent with local host
120081 is not installed
118844 is not installed
118344 is not installed
local host patches inconsistent with source host
118669 was not installed
118668 was not installed
116299 was not installed

EXPORTED INTERFACES

zoneadm subcommands
detach EVOLVING
attach [-F] EVOLVING
zonecfg create subcommand option
-a path EVOLVING

IMPORTED INTERFACES

/var/sadm/install/contents Contracted Unstable
(LSARC/2004/464)
/var/sadm/pkg/*/pkginfo Contracted Unstable

A contract is part of this case.

pkginfo(4) public
VERSION keyword evolving (pkginfo(4))
PATCHLIST keyword public (psarc/1995/063)

REFERENCES

1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris
2. RFE: Ability to migrate zones across machines Bugid 5022513
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5022513
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org

p>Re: zone migration
Posted: Jan 20, 2006 8:45 PM in response to: gjelinek

Hi

sorry but i think there is a little more work to do,

>3. Zone Configuration. The system administrator creates the zone
> configuration on the new host using zonecfg(1m).

this should be automated and perhaps give the user a chance to edit
the resulting config on the target server. It really wouldn't be much
work, and it makes the whole process painless. Later someone else can
do a script that does zonemove zonename zonename@remotebox maybe
even load ballancing can be had for us poor folks that dont want the
time and expense of having identical hardware of a cluster.

James Dickens
uadmin.blogspot.com

On 1/20/06, Jerry Jelinek wrote:
> For those interested in zone migration, I have just submitted
> a fast-track through our internal architectural review process.
> The body of the proposal is enclosed.
>
> Let me know if there are any questions.
>
> Thanks,
> Jerry
>
> ----
>
> SUMMARY:
>
> This fast-track enhances the Solaris Zones [1] subsystem
> to address an existing RFE[2] requesting the ability to migrate
> an installed non-global zone from one machine to another.
>
> We will implement the concept of detaching and attaching a zone.
> An installed non-global zone must be detached prior to moving it
> from one system to another. The process of detaching the zone
> will create the information necessary to attach the zone on a
> different system. Attaching the zone will first validate that the
> new machine is capable of properly hosting the zone.
>
> Patch binding is requested for the new sub-commands and the stability
> of these interfaces is "evolving".
>
> DETAILS:
>
> Overview
>
> Migrating a zone from one system to another involves the following
> steps:
>
> 1. Detaching the Zone. This leaves the zone on the originating
> system in the "configured" state. Behind the scenes, the
> system will generate a "manifest" of the information needed
> to validate that the zone can be successfully attached to a new
> host machine.
>
> 2. Data Migration. The system administrator moves the data which
> represents the zone to a new host system (more details below).
>
> 3. Zone Configuration. The system administrator creates the zone
> configuration on the new host using zonecfg(1m).
>
> 4. Attaching the zone. This will validate that the host is
> capable of supporting the zone before the attach can succeed.
> The zone is left in the "installed" state.
>
> Validation
>
> The validation will check that the exact version of the required
> packages and patches are installed on the new host. The algorithm
> to determine the packages and patches that must be validated is:
>
> For each package installed in the global zone:
> - ignore the package if SUNW_PKG_THISZONE is 'true'
> otherwise,
> - validate the package if
> a) SUNW_PKG_ALLZONES is 'true',
> or
> b) any file delivered by the package is in a file system
> that is inherited from the global zone.
> If the zone does not inherit any file systems (whole root)
> then (b) will be skipped.
>
> For each of the packages that is being validated we will
> also validate all of the associated patches.
>
> In the future we plan to extend this so that we might upgrade
> the zone or add patches to the zone when we attach, but initially
> we will only validate the new host and inform the sys-admin if there
> are packages or patches that are out of sync with what was installed
> on the original host machine.
>
> In order to validate the package and patch versions from the
> original host and new host, we will read this information
> from the pkginfo files in /var/sadm/pkg. We will also need to
> read the /var/sadm/install/contents file to determine which packages
> are within inherited-pkg-dirs. While some of this information
> is public, the contents file format and the existence of the pkginfo
> files within /var/sadm/pkg is not. These are contract private
> interfaces and a contract with the Install group, to allow us to
> access these files, is part of this case.
>
> zoneadm Sub-Commands
>
> We will add two new sub-commands to the zoneadm command and one
> new option to the create subcommand within zonecfg.
>
> The syntax for detaching a zone will be:
>
> # zoneadm -z my-zone detach
>
> The zone must be halted before being detached.
>
> During detach we will generate metadata describing the versions of
> the packages and patches installed on the host. This will be stored
> in an XML file in the zonepath, alongside the root and dev
> directories. This facilitates easy movement of the zonepath from one
> system to another.
>
> We will not implement any kind of archive for a detached zone.
> We will document what the sys-admin must do to move the zone
> bits around, but they can move this any way they choose.
> In some cases, such as a SAN environment, the bits might not have
> to move at all.
>
> When we detach, we leave the zone in the configured state.
> The sys-admin can then delete the configured zone or attach to
> it later.
>
> The syntax for attaching a zone will be:
>
> # zoneadm -z my-zone attach [-F]
>
> Attaching a zone is analogous to installing a zone. That is, you
> first must configure the new zone using the zonecfg command. Once
> you have the new zone in the configured state you can use attach to
> set up the zone root instead of installing.
>
> During attach we will perform the package and patch sanity checks
> described above. This will validate that the attach can occur.
> If the packages and patches don't match we will list which packages
> and patches are out of sync and the zone will be left in the
> configured state. The sys-admin can then apply any required
> packages or patches to the host to enable the attach to succeed.
> Or, they may not be able to attach to the specific host if the
> installed software is sufficiently incompatible with the environment
> on the original machine.
>
> Once the attach has completed successfully, the XML file describing
> the zone will be removed. If you try to install or clone to a
> configured zone and there is an XML description for a detached zone
> in the zonepath, we will give an error and won't proceed.
>
> The -F option for attach allows the sys-admin to force the attach
> with no validation. This is useful in certain cases such as
> a clustered environment or for backup/restore, but it does require
> that the sys-admin is certain that the system is properly configured
> to host the zone or undefined behavior may later occur.
>
> zonecfg create option
>
> To facilitate configuring the detached zone on a new host we will
> add a new '-a' option to the create subcommand within zonecfg.
>
> The subcommand for creating a new zone from the detached XML data
> will be:
>
> zonecfg:my-zone> create -a path_to_zone_root
>
> The -a option will used the XML description of the detached
> zone to configure the new zone instance. It is not required to
> to configure the new zone this way. That is, the new zone
> can be configured using the traditional zonecfg operations and
> then "zoneadm attach" can be used to attach the zone root.
> All of the validation of the zone happens during attach, not
> during configuration of the zone.
>
> EXAMPLE
>
> host1# zoneadm -z my-zone detach
>
> - move the my-zone zonepath from host1 to host2
>
> host2# zonecfg -z my-zone
> my-zone: No such zone configured
> Use 'create' to begin configuring a new zone.
> zonecfg:my-zone> create -a /export/zones/my-zone
> zonecfg:my-zone> commit
> zonecfg:my-zone> exit
> host2# zoneadm -z my-zone attach
>
> Here is an example where some packages and patches are out of sync
> between the source host and the local host we are attempting to attach
> to. The actual syntax of the error messages will be different in the
> final implementation, this is just an example to give an idea of what
> might happen.
>
> host2# zoneadm -z my-zone attach
> source host packages inconsistent with local host
> SUNWgnome-libs (2.6.0,REV=101.0.3.2005.12.06.20.27) version mismatch
> (2.6.0,REV=101.0.3.2005.12.19.21.22)
> SUNWudaplr (11.11,REV=2005.12.13.01.06) version mismatch
> (11.11,REV=2006.01.03.00.45)
> SUNWradpu320 (11.10.0,REV=2005.01.21.16.34) is not installed
> SUNWaudf (11.11,REV=2005.12.13.01.06) version mismatch
> (11.11,REV=2006.01.03.00.45)
> NCRos86r (11.10.0,REV=2005.01.17.23.31) is not installed
> local host packages inconsistent with source host
> SUNWukspfw (11.11,REV=2006.01.03.00.45) was not installed
> SUNWsmcmd (1.0,REV=2005.12.14.01.53) was not installed
> source host patches inconsistent with local host
> 120081 is not installed
> 118844 is not installed
> 118344 is not installed
> local host patches inconsistent with source host
> 118669 was not installed
> 118668 was not installed
> 116299 was not installed
>
> EXPORTED INTERFACES
>
> zoneadm subcommands
> detach EVOLVING
> attach [-F] EVOLVING
> zonecfg create subcommand option
> -a path EVOLVING
>
> IMPORTED INTERFACES
>
> /var/sadm/install/contents Contracted Unstable
> (LSARC/2004/464)
> /var/sadm/pkg/*/pkginfo Contracted Unstable
>
> A contract is part of this case.
>
> pkginfo(4) public
> VERSION keyword evolving (pkginfo(4))
> PATCHLIST keyword public (psarc/1995/063)
>
> REFERENCES
>
> 1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris
> 2. RFE: Ability to migrate zones across machines Bugid 5022513
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5022513
> _______________________________________________
> zones-discuss mailing list
> zones-discuss at opensolaris dot org
>
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org

Posts: 531
From: Menlo Park, CA
Registered: 3/11/05

Re: zone migration
Posted: Jan 21, 2006 1:46 AM in response to: jamesd

On Fri 20 Jan 2006 at 10:45PM, James Dickens wrote:
> Hi
>
> sorry but i think there is a little more work to do,
>
> >3. Zone Configuration. The system administrator creates the zone
> > configuration on the new host using zonecfg(1m).
>
> this should be automated and perhaps give the user a chance to edit
> the resulting config on the target server. It really wouldn't be much
> work, and it makes the whole process painless. Later someone else can
> do a script that does zonemove zonename zonename@remotebox maybe
> even load ballancing can be had for us poor folks that dont want the
> time and expense of having identical hardware of a cluster.

James, doesn't the 'zonecfg create -a' subcommand which Jerry described
in the document do what you want? Could you be more specific about what
you'd like (i.e. a specific use case with a little more detail)?

To give an example, you will be able to trivially invoke it with:

# zonecfg -z newzone create -a path_to_zone_root
# zoneadm -z newzone boot

Or, you can invoke it interactively, and make edits:

# zonecfg -z newzone
zonecfg:newzone> create -a path_to_zone_root
zonecfg:newzone> add net
...

I'd like to better understand your concerns. Thanks,

-dp

--
Daniel Price - Solaris Kernel Engineering - dp at eng dot sun dot com - blogs.sun.com/dp

Jan 20, 2006  | opensolaris.org

For those interested in zone migration, I have just submitted
a fast-track through our internal architectural review process.
The body of the proposal is enclosed.

Let me know if there are any questions.

Thanks,
Jerry

----

SUMMARY:

This fast-track enhances the Solaris Zones [1] subsystem
to address an existing RFE[2] requesting the ability to migrate
an installed non-global zone from one machine to another.

We will implement the concept of detaching and attaching a zone.
An installed non-global zone must be detached prior to moving it
from one system to another. The process of detaching the zone
will create the information necessary to attach the zone on a
different system. Attaching the zone will first validate that the
new machine is capable of properly hosting the zone.

Patch binding is requested for the new sub-commands and the stability
of these interfaces is "evolving".

DETAILS:

Overview

Migrating a zone from one system to another involves the following
steps:

1. Detaching the Zone. This leaves the zone on the originating
system in the "configured" state. Behind the scenes, the
system will generate a "manifest" of the information needed
to validate that the zone can be successfully attached to a new
host machine.

2. Data Migration. The system administrator moves the data which
represents the zone to a new host system (more details below).

3. Zone Configuration. The system administrator creates the zone
configuration on the new host using zonecfg(1m).

4. Attaching the zone. This will validate that the host is
capable of supporting the zone before the attach can succeed.
The zone is left in the "installed" state.

Validation

The validation will check that the exact version of the required
packages and patches are installed on the new host. The algorithm
to determine the packages and patches that must be validated is:

For each package installed in the global zone:
- ignore the package if SUNW_PKG_THISZONE is 'true'
otherwise,
- validate the package if
a) SUNW_PKG_ALLZONES is 'true',
or
b) any file delivered by the package is in a file system
that is inherited from the global zone.
If the zone does not inherit any file systems (whole root)
then (b) will be skipped.

For each of the packages that is being validated we will
also validate all of the associated patches.

In the future we plan to extend this so that we might upgrade
the zone or add patches to the zone when we attach, but initially
we will only validate the new host and inform the sys-admin if there
are packages or patches that are out of sync with what was installed
on the original host machine.

In order to validate the package and patch versions from the
original host and new host, we will read this information
from the pkginfo files in /var/sadm/pkg. We will also need to
read the /var/sadm/install/contents file to determine which packages
are within inherited-pkg-dirs. While some of this information
is public, the contents file format and the existence of the pkginfo
files within /var/sadm/pkg is not. These are contract private
interfaces and a contract with the Install group, to allow us to
access these files, is part of this case.

zoneadm Sub-Commands

We will add two new sub-commands to the zoneadm command and one
new option to the create subcommand within zonecfg.

The syntax for detaching a zone will be:

# zoneadm -z my-zone detach

The zone must be halted before being detached.

During detach we will generate metadata describing the versions of
the packages and patches installed on the host. This will be stored
in an XML file in the zonepath, alongside the root and dev
directories. This facilitates easy movement of the zonepath from one
system to another.

We will not implement any kind of archive for a detached zone.
We will document what the sys-admin must do to move the zone
bits around, but they can move this any way they choose.
In some cases, such as a SAN environment, the bits might not have
to move at all.

When we detach, we leave the zone in the configured state.
The sys-admin can then delete the configured zone or attach to
it later.

The syntax for attaching a zone will be:

# zoneadm -z my-zone attach [-F]

Attaching a zone is analogous to installing a zone. That is, you
first must configure the new zone using the zonecfg command. Once
you have the new zone in the configured state you can use attach to
set up the zone root instead of installing.

During attach we will perform the package and patch sanity checks
described above. This will validate that the attach can occur.
If the packages and patches don't match we will list which packages
and patches are out of sync and the zone will be left in the
configured state. The sys-admin can then apply any required
packages or patches to the host to enable the attach to succeed.
Or, they may not be able to attach to the specific host if the
installed software is sufficiently incompatible with the environment
on the original machine.

Once the attach has completed successfully, the XML file describing
the zone will be removed. If you try to install or clone to a
configured zone and there is an XML description for a detached zone
in the zonepath, we will give an error and won't proceed.

The -F option for attach allows the sys-admin to force the attach
with no validation. This is useful in certain cases such as
a clustered environment or for backup/restore, but it does require
that the sys-admin is certain that the system is properly configured
to host the zone or undefined behavior may later occur.

zonecfg create option

To facilitate configuring the detached zone on a new host we will
add a new '-a' option to the create subcommand within zonecfg.

The subcommand for creating a new zone from the detached XML data
will be:

zonecfg:my-zone> create -a path_to_zone_root

The -a option will used the XML description of the detached
zone to configure the new zone instance. It is not required to
to configure the new zone this way. That is, the new zone
can be configured using the traditional zonecfg operations and
then "zoneadm attach" can be used to attach the zone root.
All of the validation of the zone happens during attach, not
during configuration of the zone.

EXAMPLE

host1# zoneadm -z my-zone detach

- move the my-zone zonepath from host1 to host2

host2# zonecfg -z my-zone
my-zone: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:my-zone> create -a /export/zones/my-zone
zonecfg:my-zone> commit
zonecfg:my-zone> exit
host2# zoneadm -z my-zone attach

Here is an example where some packages and patches are out of sync
between the source host and the local host we are attempting to attach
to. The actual syntax of the error messages will be different in the
final implementation, this is just an example to give an idea of what
might happen.

host2# zoneadm -z my-zone attach
source host packages inconsistent with local host
SUNWgnome-libs (2.6.0,REV=101.0.3.2005.12.06.20.27) version mismatch
(2.6.0,REV=101.0.3.2005.12.19.21.22)
SUNWudaplr (11.11,REV=2005.12.13.01.06) version mismatch
(11.11,REV=2006.01.03.00.45)
SUNWradpu320 (11.10.0,REV=2005.01.21.16.34) is not installed
SUNWaudf (11.11,REV=2005.12.13.01.06) version mismatch
(11.11,REV=2006.01.03.00.45)
NCRos86r (11.10.0,REV=2005.01.17.23.31) is not installed
local host packages inconsistent with source host
SUNWukspfw (11.11,REV=2006.01.03.00.45) was not installed
SUNWsmcmd (1.0,REV=2005.12.14.01.53) was not installed
source host patches inconsistent with local host
120081 is not installed
118844 is not installed
118344 is not installed
local host patches inconsistent with source host
118669 was not installed
118668 was not installed
116299 was not installed

EXPORTED INTERFACES

zoneadm subcommands
detach EVOLVING
attach [-F] EVOLVING
zonecfg create subcommand option
-a path EVOLVING

IMPORTED INTERFACES

/var/sadm/install/contents Contracted Unstable
(LSARC/2004/464)
/var/sadm/pkg/*/pkginfo Contracted Unstable

A contract is part of this case.

pkginfo(4) public
VERSION keyword evolving (pkginfo(4))
PATCHLIST keyword public (psarc/1995/063)

REFERENCES

1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris
2. RFE: Ability to migrate zones across machines Bugid 5022513
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5022513
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org

p>Re: zone migration
Posted: Jan 20, 2006 8:45 PM in response to: gjelinek

Hi

sorry but i think there is a little more work to do,

>3. Zone Configuration. The system administrator creates the zone
> configuration on the new host using zonecfg(1m).

this should be automated and perhaps give the user a chance to edit
the resulting config on the target server. It really wouldn't be much
work, and it makes the whole process painless. Later someone else can
do a script that does zonemove zonename zonename@remotebox maybe
even load ballancing can be had for us poor folks that dont want the
time and expense of having identical hardware of a cluster.

James Dickens
uadmin.blogspot.com

On 1/20/06, Jerry Jelinek wrote:
> For those interested in zone migration, I have just submitted
> a fast-track through our internal architectural review process.
> The body of the proposal is enclosed.
>
> Let me know if there are any questions.
>
> Thanks,
> Jerry
>
> ----
>
> SUMMARY:
>
> This fast-track enhances the Solaris Zones [1] subsystem
> to address an existing RFE[2] requesting the ability to migrate
> an installed non-global zone from one machine to another.
>
> We will implement the concept of detaching and attaching a zone.
> An installed non-global zone must be detached prior to moving it
> from one system to another. The process of detaching the zone
> will create the information necessary to attach the zone on a
> different system. Attaching the zone will first validate that the
> new machine is capable of properly hosting the zone.
>
> Patch binding is requested for the new sub-commands and the stability
> of these interfaces is "evolving".
>
> DETAILS:
>
> Overview
>
> Migrating a zone from one system to another involves the following
> steps:
>
> 1. Detaching the Zone. This leaves the zone on the originating
> system in the "configured" state. Behind the scenes, the
> system will generate a "manifest" of the information needed
> to validate that the zone can be successfully attached to a new
> host machine.
>
> 2. Data Migration. The system administrator moves the data which
> represents the zone to a new host system (more details below).
>
> 3. Zone Configuration. The system administrator creates the zone
> configuration on the new host using zonecfg(1m).
>
> 4. Attaching the zone. This will validate that the host is
> capable of supporting the zone before the attach can succeed.
> The zone is left in the "installed" state.
>
> Validation
>
> The validation will check that the exact version of the required
> packages and patches are installed on the new host. The algorithm
> to determine the packages and patches that must be validated is:
>
> For each package installed in the global zone:
> - ignore the package if SUNW_PKG_THISZONE is 'true'
> otherwise,
> - validate the package if
> a) SUNW_PKG_ALLZONES is 'true',
> or
> b) any file delivered by the package is in a file system
> that is inherited from the global zone.
> If the zone does not inherit any file systems (whole root)
> then (b) will be skipped.
>
> For each of the packages that is being validated we will
> also validate all of the associated patches.
>
> In the future we plan to extend this so that we might upgrade
> the zone or add patches to the zone when we attach, but initially
> we will only validate the new host and inform the sys-admin if there
> are packages or patches that are out of sync with what was installed
> on the original host machine.
>
> In order to validate the package and patch versions from the
> original host and new host, we will read this information
> from the pkginfo files in /var/sadm/pkg. We will also need to
> read the /var/sadm/install/contents file to determine which packages
> are within inherited-pkg-dirs. While some of this information
> is public, the contents file format and the existence of the pkginfo
> files within /var/sadm/pkg is not. These are contract private
> interfaces and a contract with the Install group, to allow us to
> access these files, is part of this case.
>
> zoneadm Sub-Commands
>
> We will add two new sub-commands to the zoneadm command and one
> new option to the create subcommand within zonecfg.
>
> The syntax for detaching a zone will be:
>
> # zoneadm -z my-zone detach
>
> The zone must be halted before being detached.
>
> During detach we will generate metadata describing the versions of
> the packages and patches installed on the host. This will be stored
> in an XML file in the zonepath, alongside the root and dev
> directories. This facilitates easy movement of the zonepath from one
> system to another.
>
> We will not implement any kind of archive for a detached zone.
> We will document what the sys-admin must do to move the zone
> bits around, but they can move this any way they choose.
> In some cases, such as a SAN environment, the bits might not have
> to move at all.
>
> When we detach, we leave the zone in the configured state.
> The sys-admin can then delete the configured zone or attach to
> it later.
>
> The syntax for attaching a zone will be:
>
> # zoneadm -z my-zone attach [-F]
>
> Attaching a zone is analogous to installing a zone. That is, you
> first must configure the new zone using the zonecfg command. Once
> you have the new zone in the configured state you can use attach to
> set up the zone root instead of installing.
>
> During attach we will perform the package and patch sanity checks
> described above. This will validate that the attach can occur.
> If the packages and patches don't match we will list which packages
> and patches are out of sync and the zone will be left in the
> configured state. The sys-admin can then apply any required
> packages or patches to the host to enable the attach to succeed.
> Or, they may not be able to attach to the specific host if the
> installed software is sufficiently incompatible with the environment
> on the original machine.
>
> Once the attach has completed successfully, the XML file describing
> the zone will be removed. If you try to install or clone to a
> configured zone and there is an XML description for a detached zone
> in the zonepath, we will give an error and won't proceed.
>
> The -F option for attach allows the sys-admin to force the attach
> with no validation. This is useful in certain cases such as
> a clustered environment or for backup/restore, but it does require
> that the sys-admin is certain that the system is properly configured
> to host the zone or undefined behavior may later occur.
>
> zonecfg create option
>
> To facilitate configuring the detached zone on a new host we will
> add a new '-a' option to the create subcommand within zonecfg.
>
> The subcommand for creating a new zone from the detached XML data
> will be:
>
> zonecfg:my-zone> create -a path_to_zone_root
>
> The -a option will used the XML description of the detached
> zone to configure the new zone instance. It is not required to
> to configure the new zone this way. That is, the new zone
> can be configured using the traditional zonecfg operations and
> then "zoneadm attach" can be used to attach the zone root.
> All of the validation of the zone happens during attach, not
> during configuration of the zone.
>
> EXAMPLE
>
> host1# zoneadm -z my-zone detach
>
> - move the my-zone zonepath from host1 to host2
>
> host2# zonecfg -z my-zone
> my-zone: No such zone configured
> Use 'create' to begin configuring a new zone.
> zonecfg:my-zone> create -a /export/zones/my-zone
> zonecfg:my-zone> commit
> zonecfg:my-zone> exit
> host2# zoneadm -z my-zone attach
>
> Here is an example where some packages and patches are out of sync
> between the source host and the local host we are attempting to attach
> to. The actual syntax of the error messages will be different in the
> final implementation, this is just an example to give an idea of what
> might happen.
>
> host2# zoneadm -z my-zone attach
> source host packages inconsistent with local host
> SUNWgnome-libs (2.6.0,REV=101.0.3.2005.12.06.20.27) version mismatch
> (2.6.0,REV=101.0.3.2005.12.19.21.22)
> SUNWudaplr (11.11,REV=2005.12.13.01.06) version mismatch
> (11.11,REV=2006.01.03.00.45)
> SUNWradpu320 (11.10.0,REV=2005.01.21.16.34) is not installed
> SUNWaudf (11.11,REV=2005.12.13.01.06) version mismatch
> (11.11,REV=2006.01.03.00.45)
> NCRos86r (11.10.0,REV=2005.01.17.23.31) is not installed
> local host packages inconsistent with source host
> SUNWukspfw (11.11,REV=2006.01.03.00.45) was not installed
> SUNWsmcmd (1.0,REV=2005.12.14.01.53) was not installed
> source host patches inconsistent with local host
> 120081 is not installed
> 118844 is not installed
> 118344 is not installed
> local host patches inconsistent with source host
> 118669 was not installed
> 118668 was not installed
> 116299 was not installed
>
> EXPORTED INTERFACES
>
> zoneadm subcommands
> detach EVOLVING
> attach [-F] EVOLVING
> zonecfg create subcommand option
> -a path EVOLVING
>
> IMPORTED INTERFACES
>
> /var/sadm/install/contents Contracted Unstable
> (LSARC/2004/464)
> /var/sadm/pkg/*/pkginfo Contracted Unstable
>
> A contract is part of this case.
>
> pkginfo(4) public
> VERSION keyword evolving (pkginfo(4))
> PATCHLIST keyword public (psarc/1995/063)
>
> REFERENCES
>
> 1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris
> 2. RFE: Ability to migrate zones across machines Bugid 5022513
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5022513
> _______________________________________________
> zones-discuss mailing list
> zones-discuss at opensolaris dot org
>
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org

Posts: 531
From: Menlo Park, CA
Registered: 3/11/05

Re: zone migration
Posted: Jan 21, 2006 1:46 AM in response to: jamesd

On Fri 20 Jan 2006 at 10:45PM, James Dickens wrote:
> Hi
>
> sorry but i think there is a little more work to do,
>
> >3. Zone Configuration. The system administrator creates the zone
> > configuration on the new host using zonecfg(1m).
>
> this should be automated and perhaps give the user a chance to edit
> the resulting config on the target server. It really wouldn't be much
> work, and it makes the whole process painless. Later someone else can
> do a script that does zonemove zonename zonename@remotebox maybe
> even load ballancing can be had for us poor folks that dont want the
> time and expense of having identical hardware of a cluster.

James, doesn't the 'zonecfg create -a' subcommand which Jerry described
in the document do what you want? Could you be more specific about what
you'd like (i.e. a specific use case with a little more detail)?

To give an example, you will be able to trivially invoke it with:

# zonecfg -z newzone create -a path_to_zone_root
# zoneadm -z newzone boot

Or, you can invoke it interactively, and make edits:

# zonecfg -z newzone
zonecfg:newzone> create -a path_to_zone_root
zonecfg:newzone> add net
...

I'd like to better understand your concerns. Thanks,

-dp

--
Daniel Price - Solaris Kernel Engineering - dp at eng dot sun dot com - blogs.sun.com/dp

[Nov 12, 2006] The Sun BluePrints Guide to Solaris Containers: Virtualization in the Solaris Operating System (pdf)

Find out how to create, use, and integrate Solaris Containers in a new "mini-book" with detailed examples...

1. Introduction to Solaris Zones
2. Non-Global Zone Configuration (Overview)
3. Planning and Configuring Non-Global Zones (Tasks)
4. About Installing, Halting, and Uninstalling Non-Global Zones (Overview)
5. Installing, Booting, Halting, and Uninstalling Non-Global Zones (Tasks)
6. Non-Global Zone Login (Overview)
7. Logging In to Non-Global Zones (Tasks)
8. Moving and Migrating Non-Global Zones (Tasks)
9. About Adding and Removing Packages and Patches on a Solaris System With Zones Installed (Overview)
10. Adding and Removing Packages and Patches on a Solaris System With Zones Installed (Tasks)
11. Solaris Zones Administration (Overview)
12. Solaris Zones Administration (Tasks)
13. Troubleshooting Miscellaneous Solaris Zones Problems

[Nov 10, 2006] Virtually Speaking Sun's Virtual Expansion

Solaris 10 11/06, the next build of the operating system, will be released at the end of November. The version will include new capabilities for Containers. Admins will be able to clone a Container as well as relocate it to another box, through a feature called Attach/Detach, Wake said.

[Nov 10, 2006] OpenSolaris Zones Presentation (pdf) by Narayana Janga and Shivani Khosa.

(BigAdmin) Presentation on Zones and OpenSolaris given at ApacheCon US 2006.

[Aug 24, 2006] BigAdmin - Submitted Tech Tip Zone Replication on the Solaris 10 OS in Five Easy Steps by David Steed

The following is coffeeware -- instructions rather than software. If you use this, you are obligated to buy me a coffee... at your convenience.

These instructions describe a very simple method of moving a local zone from one machine to another (using the Solaris 10 OS).

Given:

• Two physical machines, with no shared storage
• The same Solaris 10 version installed
• Machine Y with one fully populated local zone installed (and nothing inherited)
• Machine Z with no zones installed (Z can also be an additional zone on the same machine)

Here are the five easy steps:

1. Log in to the console of a zone running on machine Y and create a full flash (this does not work properly with an image created from a global zone!).

Example:

zonename # flarcreate -n "machineY" -S /machineY.flar (anywhere but /tmp)

2. Copy the following files from machine Y to machine Z:

• The newly created flash image
• /etc/zones/index  (merge it with the existing index file)
• /etc/zones/machineY.xml  (rename to machineZ.xml  and edit appropriately)

3. Create the following:

• /export/zones/machineX/root/  (machineX  directory with 700 perms)
• /export/zones/machineX/dev/

4. Split the flash image (flar split machineX.flar), then move the file "archive" to /export/zones/machineX/root/, and unpack it with cpio -i.

• Uncompress if necessary (mv archive archive.Z; uncompress archive.Z)
• cd  to the machineX/root directory: cpio -i < /export/archive

5. Boot the machine with zoneadm -z machineZ boot  and log in -- the devices will be built at that time. Sysid information is normally required at this point ...

Don't forget: send an invitation for coffee to [email protected] and I will accept!

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019