|
Replies:
28
-
Last Post:
Jun 20, 2006 4:57 AM
by: gjelinek
|
|
|
Posts:
470
From:
US
Registered:
3/9/05
|
|
|
|
zone migration
Posted:
Jan 20, 2006 2:34 PM
|
|
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
|
|
|
Posts:
316
From:
Milwaukee WI
Registered:
4/27/05
|
|
|
|
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 <Gerald dot Jelinek at sun dot com> 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:
807
From:
US
Registered:
3/9/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
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
316
From:
Milwaukee WI
Registered:
4/27/05
|
|
|
|
Re: zone migration
Posted:
Jan 21, 2006 8:24 AM
in response to: dp
|
|
On 1/21/06, Dan Price <dp at eng dot sun dot com> wrote:
> 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,
>
I guess automate was the wrong word, I want the step to disapear, when
moving a zone, I would like just to say move zone x to machine b.
and have it all done automaticly no creating a new zone config on the
remote machine, have it export the current config, then import the
config and transfer all the files necessary then start the new zone.
James Dickens
uadmin.blogspot.com
> -dp
>
> --
> Daniel Price - Solaris Kernel Engineering - dp at eng dot sun dot com - blogs.sun.com/dp
>
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
470
From:
US
Registered:
3/9/05
|
|
|
|
Re: zone migration
Posted:
Jan 23, 2006 6:31 AM
in response to: jamesd
|
|
James Dickens wrote:
> I guess automate was the wrong word, I want the step to disapear, when
> moving a zone, I would like just to say move zone x to machine b.
> and have it all done automaticly no creating a new zone config on the
> remote machine, have it export the current config, then import the
> config and transfer all the files necessary then start the new zone.
That is not the problem we are trying to solve with this proposal but
it would be very easy for you to use this new feature to make this
work in your environment. For example, if your environment was setup
to allow root access across machines, then it would be trivial to write
a small shell script to detach the zone, copy the bits to the new host,
and re-attach it. Since there are a lot of assumptions that have to
be made to make this work, it is easy for you to do this in your
environment, but it is hard to do this in a general way. But, as
I said, this proposal enables you to do this, if that is what you
need and you are set up appropriately.
Jerry
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
807
From:
US
Registered:
3/9/05
|
|
|
|
Re: zone migration
Posted:
Jan 23, 2006 12:17 PM
in response to: jamesd
|
|
On Sat 21 Jan 2006 at 10:24AM, James Dickens wrote:
> > I'd like to better understand your concerns. Thanks,
> >
> I guess automate was the wrong word, I want the step to disapear, when
> moving a zone, I would like just to say move zone x to machine b.
> and have it all done automaticly no creating a new zone config on the
> remote machine, have it export the current config, then import the
> config and transfer all the files necessary then start the new zone.
I know Jerry already replied but I just wanted to add a few more
thoughts.
I think about attach and detach as primitives we need to cleanly do a
whole bunch of things--
- Restore from tape
- Maintain zones on multiple cluster nodes
- Move zones from box to box
- Over Networks
- Over SANs
- Over NFS
- Over Sneakernet
In terms of having a magic "move it" command, as Jerry noted, there are
some difficulties-- selecting the right copy/move method is the first
serious one I see. The copy/move could be as complex as a LUN remapping
on your SAN to another host, or not involve any copying at all in the
case that you were attaching a zone on a node which was a zfs remote
replication client. Or it could be as simple as scp. Or rcp. Or ftp.
Or ... Which set of these methods would we need to implement to satisfy
90% of our user base? I'm not sure. Let us know if you have opinions.
I think you have a good point that higher automation levels for the
common cases would be good. But I don't think that obviates the strong
need for attach and detach (to do some of the things I highlight above).
That is to say-- does this work pass the usefulness test and stand
alone? I believe it does.
So further automating the "move" case could be follow on work. I am a
little wary of inventing it before we understand how folks will do
migration in practice. I'll think on it some more this week.
-dp
--
Daniel Price - Solaris Kernel Engineering - dp at eng dot sun dot com - blogs.sun.com/dp
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
29
From:
Virginia, US
Registered:
7/19/05
|
|
|
|
Re: zone migration
Posted:
Jan 23, 2006 1:19 PM
in response to: dp
|
|
On Mon, 23 Jan 2006, Dan Price wrote:
> In terms of having a magic "move it" command, as Jerry noted, there are
> some difficulties-- selecting the right copy/move method is the first
> serious one I see. The copy/move could be as complex as a LUN remapping
> on your SAN to another host, or not involve any copying at all in the
> case that you were attaching a zone on a node which was a zfs remote
> replication client. Or it could be as simple as scp. Or rcp. Or ftp.
> Or ... Which set of these methods would we need to implement to satisfy
> 90% of our user base? I'm not sure. Let us know if you have opinions.
With zones, I think that aslong as zonecfg and/or zoneadm have the implement
the necessary calls to export/import all the requirements of a zone, including
some method of interactive import so that zone configs can be modified on
import, then it becomes easy for people to implement their own tools to
migrate zones. If the Sun/OpenSolaris communities want to release our own
branded tool to migrate zones, that's great, but it would also be nice to
have the option of using whatever tool I choose to handle the migration,
whether it's a shell script, a tape-restore, a zfs snapshot/export-import, or
whatever.
Like Oracle. How many ways are there to create replicated databases? How
many tools does Oracle supply to do it? There are a number of equally
viable alternatives for database replication, all based around the same
set of requirements. Take RMAN, DataGuard, tar, Netbackup, fs migration,
etc, etc.
-Tim
--
______
/_____/\ Timothy Kennedy
/_____\\ \ IT Technologist
/_____\ \\ / Sun Microsystems, Inc.
/_____/ \/ / / Sun Management Connection (SMC)
/_____/ / \//\ Infrastructure OS Team
\_____\//\ / / Email: Timothy dot Kennedy at Sun dot COM
\_____/ / /\ / Phone: 703-636-0531
\_____/ \\ \ Ext: 53151
\_____\ \\ http://www.sun.com
\_____\/ http://blogs.sun.com/tkblog
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
326
From:
DE
Registered:
4/28/05
|
|
|
|
Re: zone migration
Posted:
Jan 25, 2006 4:15 AM
in response to: dp
|
|
Dan Price <dp at eng dot sun dot com> writes:
> I think about attach and detach as primitives we need to cleanly do a
> whole bunch of things--
[...]
> - Move zones from box to box
[...]
> - Over NFS
Speaking of this: what's the status/current plan for allowing zone roots on
NFS filesystems? I'd like to run zones on diskless clients, which didn't
work at least back in S10 Plat Beta.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
962
From:
US
Registered:
3/9/05
|
|
|
|
Re: zone migration
Posted:
Jan 25, 2006 9:54 AM
in response to: rorth
|
|
Rainer,
> Speaking of this: what's the status/current plan for allowing zone roots on
> NFS filesystems? I'd like to run zones on diskless clients, which didn't
> work at least back in S10 Plat Beta.
This still isn't currently supported. There are some folks now looking
into it and we'll try to get back with updated status in the not too
distant future.
dsc
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
807
From:
US
Registered:
3/9/05
|
|
|
|
Re: zone migration
Posted:
Jan 25, 2006 10:12 AM
in response to: comay
|
|
On Wed 25 Jan 2006 at 09:54AM, David dot Comay at Sun dot COM wrote:
> Rainer,
>
> >Speaking of this: what's the status/current plan for allowing zone roots on
> >NFS filesystems? I'd like to run zones on diskless clients, which didn't
> >work at least back in S10 Plat Beta.
>
> This still isn't currently supported. There are some folks now looking
> into it and we'll try to get back with updated status in the not too
> distant future.
Well, there's also no guarantee in the current plans that zone-roots-on-
NFS will also yield support for zones on diskless clients-- the
principal reason is zlogin (or anything which must do a zone_enter(),
really), which needs to cross over from global to non-global zone. If
zlogin is backed by NFS pages (for example if it is in your home
directory on NFS), we don't allow it to work, since you wind up with NFS
pages from one network identity in a zone with a different network
identity.
-dp
--
Daniel Price - Solaris Kernel Engineering - dp at eng dot sun dot com - blogs.sun.com/dp
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
12
From:
Registered:
4/14/06
|
|
|
|
Re: zone migration
Posted:
Apr 14, 2006 1:37 PM
in response to: dp
|
|
Zone configuration on the other node can not be made completely transparent to the user, IMO. This is because the network interfaces on the new node may be different from the ones on the source node. Also, the FS special may be different. Zone configuration should be a required step on the target.
|
|
|
|
|
Posts:
12
From:
Registered:
4/14/06
|
|
|
|
Re: zone migration
Posted:
Apr 14, 2006 1:40 PM
in response to: gjelinek
|
|
What happens if the node hosting the zone crashes and the maintenance window is such that we need to migrate (attach) the zone to other machine? Zone on the other machine is not installed, but sits in the configured state. Assuming that the storage is accessible from the other node, is it possible to attach the zone on the other machine? The reason I ask this is because the XML file was not created as there was no prior detach.
|
|
|
|
|
Posts:
470
From:
US
Registered:
3/9/05
|
|
|
|
Re: zone migration
Posted:
Apr 14, 2006 1:53 PM
in response to: van30
|
|
This is an issue we have discussed and we have talked about
the idea of "predetaching" a zone so that you could set it
up ahead of time on another machine but it would be left
in the installed state on the original system.
In the meantime, it is easy to work around this by detaching
the zone, tar-ring up the zonepath as if you were going to
migrate the zone, then reattaching the zone back onto
the same machine. You now have a tar file you can take
to another machine and be ready to attach at any time.
I am also working on a proposal to support dry-runs of
zone migration so that you can check the target ahead of
time to determine if the migration will suceed.
Jerry
|
|
|
|
|
Posts:
12
From:
Registered:
4/14/06
|
|
|
|
Re: zone migration
Posted:
Apr 14, 2006 2:28 PM
in response to: gjelinek
|
|
Tar-ring up the entire zonepath may not be feasible because during the lifetime of the zone while source node was up, there will be tons of changes to the data on the disk. If the tar was to be attached on the target node, we may be losing the changes which took place from the tar to the point when the source crashed.
Dry run of zone migration is a cool idea.
|
|
|
|
|
Posts:
12
From:
Registered:
4/14/06
|
|
|
|
Re: zone migration
Posted:
Apr 25, 2006 10:53 AM
in response to: gjelinek
|
|
One question.
If the zone was created on a system with Sol 10 update n (or for that matter, solaris 11, in future), can it be attached to a machine running Sol 10 update < n? And vice versa? Bottomline, do the OSes have to be at the same level?
Thanks!
|
|
|
|
|
Posts:
470
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: zone migration
Posted:
Apr 25, 2006 11:17 AM
in response to: van30
|
|
Anish Vaidya wrote:
> One question.
>
> If the zone was created on a system with Sol 10 update n (or for that matter, solaris 11, in future), can it be attached to a machine running Sol 10 update < n? And vice versa? Bottomline, do the OSes have to be at the same level?
Anish,
The systems have to have the exact same versions of the pkgs, and
their associated patches, for the pkgs that the zone depends on.
This means that you can't move a zone to a new host running
an earlier (or later) release of Solaris. In the future we
have some ideas about upgrading the zone when we move to a host
running a newer release of Solaris. However, we have no plans
to be able to downgrade a zone like you are describing. To
do that, we would first need support from the install tools and
that is not on their roadmap.
Jerry
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
95
From:
Registered:
2/27/06
|
|
|
|
Re: Re: zone migration
Posted:
Apr 26, 2006 8:27 AM
in response to: gjelinek
|
|
another question to migration,
this week i have seen a demo of the feature "zero-downtime migration" from a competitor, really impressive. they started a large ftp-download from the apache on the virtual server and then migrate the virtual server to a other physical server.
i think there first step was a rsync session while the vserver is running to copy the data to the second server. then all processes of the vserver became offline and a memory dump like "suspendtodisk" was taken.
this is the hot phase like the "dynamic reconfiugre of the kernel board in the 15k" where the ftp-client obtains no data from the vserver.
the second rsync session was running and after three minutes the vserver is up on the second machine and the ftp-client to continue withe the download.
i dont know if this is practicable with other applications like big databases.
is a similar technical solution with solaris zones thinkable?
|
|
|
|
|
Posts:
470
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Re: zone migration
Posted:
Apr 26, 2006 8:40 AM
in response to: mario2
|
|
mario heimel wrote:
> another question to migration,
>
> this week i have seen a demo of the feature "zero-downtime migration" from a competitor, really impressive. they started a large ftp-download from the apache on the virtual server and then migrate the virtual server to a other physical server.
>
> i think there first step was a rsync session while the vserver is running to copy the data to the second server. then all processes of the vserver became offline and a memory dump like "suspendtodisk" was taken.
> this is the hot phase like the "dynamic reconfiugre of the kernel board in the 15k" where the ftp-client obtains no data from the vserver.
> the second rsync session was running and after three minutes the vserver is up on the second machine and the ftp-client to continue withe the download.
>
> i dont know if this is practicable with other applications like big databases.
> is a similar technical solution with solaris zones thinkable?
Mario,
This would be very difficult to do with zones since you need a way
to checkpoint the entire software stack including the
kernel state. Since zones are a lightweight virtualization where
the kernel is shared by all running zones, including the global
zone, it is not very likely that we could do this. If you want
a feature like this, xen has this capability, but it is much
more heavyweight than zones.
Jerry
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
409
From:
Registered:
6/16/05
|
|
|
|
Re: Re: Re: zone migration
Posted:
Apr 26, 2006 9:08 AM
in response to: mario2
|
|
Although this is a dramatic demonstration, in practice there are several factors
which decrease the value of this feature:
* What is the business requirement that makes such a feature valuable?
(I'm not stating that there is no value. For example, this feature
simplifies system administration. There are others. I just want
to learn what business requirements make this valuable to *you*.)
* If zero-downtime is a priority, the application should already be either:
A) in a load-balanced configuration
B) in a high-availability configuration
In either of those situations, planned downtime of one node, whether
it's a server, zone, or virtual machine, is generally accepted.
However, to address your question: a similar solution with zones would need to
overcome this basic challenge: a zone, unlike a VM, does not have its own kernel.
It's (relatively) easy to copy the entire address space of an entire VM to a
different system, checkpoint the original VM, and start the next instruction on
the new system. Moving a live zone would require replicating each element of the
kernel's data structures that are related to that particular zone in the kernel of
the target system, and removing them from the original system. Doing this
without causing problems (functionality or performance, in any reasonable set of
configurations) would require careful design, implementation and testing, and
might be impractical.
Additionally, there is the problem of verifying sufficient OS patch consistency,
etc. This might decrease the value of the solution enough to make it
uninteresting to users.
I'm not saying that it's impossible (I wouldn't know, I'm not a kernel engineer),
only that it's a different, and more difficult, problem to solve.
Finally, there is the possibility of an interesting advantage to migrating zones
(with short downtime) compared to virtual machine migration: it's theoretically
possible to migrate a (sparse-root) zone from one hardware architecture to
another. I've actually done this in a lab environment (SPARC --> x86). It works
because there are (almost) no hardware dependent files in a sparse-root zone.
Of course there are issues that would need to be resolved, e.g. configuration of
filesystems so that the correct application binaries are available, etc. And we
(Sun) wouldn't be able to support this type of migration without significant work.
But it does make for interesting possibilities, e.g. "upgrading" an x86 system
to a SPARC system with minimal effort... ;-)
mario heimel wrote:
> another question to migration,
>
> this week i have seen a demo of the feature "zero-downtime migration" from a
> competitor, really impressive. they started a large ftp-download from the
> apache on the virtual server and then migrate the virtual server to a other
> physical server.
>
> i think there first step was a rsync session while the vserver is running to
> copy the data to the second server. then all processes of the vserver became
> offline and a memory dump like "suspendtodisk" was taken. this is the hot phase
> like the "dynamic reconfiugre of the kernel board in the 15k" where the
> ftp-client obtains no data from the vserver. the second rsync session was
> running and after three minutes the vserver is up on the second machine and the
> ftp-client to continue withe the download.
>
> i dont know if this is practicable with other applications like big databases.
> is a similar technical solution with solaris zones thinkable?
>
>
> This message posted from opensolaris.org
> _______________________________________________ zones-discuss mailing list
> zones-discuss at opensolaris dot org
--
--------------------------------------------------------------------------
Jeff VICTOR Sun Microsystems jeff.victor @ sun.com
OS Ambassador Sr. Technical Specialist
Solaris 10 Zones FAQ: http://www.opensolaris.org/os/community/zones/faq
--------------------------------------------------------------------------
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
95
From:
Registered:
2/27/06
|
|
|
|
Re: Re: Re: zone migration
Posted:
Apr 28, 2006 9:03 AM
in response to: jeffv
|
|
i think with xen you c'ant move virtual server between physical machines or am i wrong here ?
it seems that the technical implementation of virtual private servers are very similar to zones, because they also share only one kernel in the system.
what is the business requirement?
a) not all applications are behind load-balancers (maybe 20% of our servers) and this is sadly true not all customers use the redundancy
b) clusters are expensive and don´t simplify administration ( 2% of our systems are clusters)
c) 78% of the servers are not in category a or b, but are also very important for our customers; even if it is only a development environment, we don´t get a planned downtime to acceptable hours.
our downtimes take place at sunday 2 - 5 am and every possibility to move this to normal working time is a gleam of hope.
the main reason is not the high-availability of the application (e.g. development environment) relating to hardware failure, but with live-zone-migration the sysadmin can maintan the server at a human friendly hour and the developer is happy, because he can do their work.
we have planned to work with sol10/liveupgrade to shorten the downtimes to a reboot - with zones this is actually not possible.
|
|
|
|
|
Posts:
95
From:
Registered:
2/27/06
|
|
|
|
Re: Re: Re: zone migration
Posted:
Apr 28, 2006 11:54 AM
in response to: mario2
|
|
i have found more about the checkpointing/migration feature, here is the link to the full technical article.
http://lwn.net/Articles/180775/
a quote:
As might be expected, the checkpointing code is on the long and complicated side. The checkpoint process starts by putting the target process(es) on hold, in a manner similar to what the software suspend code does. Then it comes down to a long series of routines which serialize and write out every data structure and bit of memory associated with a virtual environment. The obvious things are saved: process memory, open files, etc. But the code must also save the full state of each TCP socket (including the backlog of sk_buff structures waiting to be processed), connection tracking information, signal handling status, SYSV IPC information, file descriptors obtained via Unix-domain sockets, asynchronous I/O operations, memory mappings, filesystem namespaces, data in tmpfs files, tty settings, file locks, epoll() file descriptors, accounting information, and more.
|
|
|
|
|
Posts:
1,264
From:
US
Registered:
8/5/05
|
|
|
|
Re: Re: Re: Re: zone migration
Posted:
Apr 28, 2006 7:35 PM
in response to: mario2
|
|
On 4/28/06, mario heimel <mheimel at web dot de> wrote:
> i think with xen you c'ant move virtual server between physical machines or am i wrong here ?
http://blogs.sun.com/roller/page/tpm?entry=opening_day_for_opensolaris_on
While we were in our final approach to this release,
we got live migration to work too, which is one of
the key features we've been working on.
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
201
From:
AU
Registered:
6/14/05
|
|
|
|
Re: Re: Re: Re: zone migration
Posted:
Apr 29, 2006 4:22 PM
in response to: mgerdts
|
|
On 29/04/2006, at 12:35 PM, Mike Gerdts wrote:
> On 4/28/06, mario heimel <mheimel at web dot de> wrote:
>> i think with xen you c'ant move virtual server between physical
>> machines or am i wrong here ?
>
> http://blogs.sun.com/roller/page/tpm?
> entry=opening_day_for_opensolaris_on
>
> While we were in our final approach to this release,
> we got live migration to work too, which is one of
> the key features we've been working on.
More information at:
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/architecture.html
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,264
From:
US
Registered:
8/5/05
|
|
|
|
Re: Re: Re: zone migration
Posted:
Apr 28, 2006 7:30 PM
in response to: jeffv
|
|
On 4/26/06, Jeff Victor <Jeff dot Victor at sun dot com> wrote:
> Although this is a dramatic demonstration, in practice there are several factors
> which decrease the value of this feature:
>
> * What is the business requirement that makes such a feature valuable?
> (I'm not stating that there is no value. For example, this feature
> simplifies system administration. There are others. I just want
> to learn what business requirements make this valuable to *you*.)
For me...
1) If a server requires maintenance (DIMM errors, etc.) I can migrate
the workload to another physical machine without taking an outage.
Depending on the circumstances and how routine this operation is, this
may not even involve notifying the application owner.
2) If a server is becoming overloaded I can rebalance at will.
> * If zero-downtime is a priority, the application should already be either:
>
> A) in a load-balanced configuration
> B) in a high-availability configuration
>
> In either of those situations, planned downtime of one node, whether
> it's a server, zone, or virtual machine, is generally accepted.
In the case of VMware, the sweet spot is a bunch of legacy OS's that
had previously been running on less powerful hardware. That hardware
is being replaced because it is cheaper to run current generation
hardware that is under warranty than four year old hardware that you
can't find parts for. Re-architecting this legacy OS with the legacy
app is not going to happen.
I would love for Solaris to have a VMware-like P2V (physical to
virtual) tool to encapsulate the contents of my once beefy E450 and
slap it onto a small slice of a T2000. You may argue that if the
E450/E420/220R is doing something and doing it well, leave it be.
However, the Sun maintenance cost of previous generation hardware is
often slightly greater than the lease/depreciation cost + maintenance
cost of current generation hardware when doing a one for one
replacement. If you can squeeze in some consolidation at the same
time, you are cutting real dollars.
So far, there is no interest from the Sun side of things to make this
work: apparently Solaris 8/9 BrandZ is more work than it is worth.
Perhaps it would be less work to make these older OS's run under Xen?
I know that Sun beleives very strongly in its ABI compatibility
guarantees. I appreciate this, really! However, if I am need to
replace a server that was installed x years ago and everyone that has
any technical knowledge of the application has moved on, the
application vendor is out of business, etc. upgrading to a newer OS to
get it onto newer hardware is a one-way conversion. Now multiply that
problem times a few hundred - it turns into an ugly problem really
quickly. (Arguably, it is just a delay - eventually the thing that is
being encapsulated becomes unsupported too.)
VMware has sold a lot of licenses to P2V to migrate NT4 servers
installed five years ago to Opteron servers. Apparently there is a
V2P procedure available upon request to P2V customers.
> Finally, there is the possibility of an interesting advantage to migrating zones
> (with short downtime) compared to virtual machine migration: it's theoretically
> possible to migrate a (sparse-root) zone from one hardware architecture to
> another. I've actually done this in a lab environment (SPARC --> x86). It works
> because there are (almost) no hardware dependent files in a sparse-root zone.
Very interesting. This had not even crossed my mind. Not sure where
I would use it, but it makes my propeller hat spin.
As for short downtime migration, I have automated procedures that can
"migrate" a suitable zone between machines in less than a minute
("zlogin -z zone init 0" until first web page load on new server).
The procedure really involves pre-staging the zone at the target
server, performing a shutdown on the original server and a boot on the
new server. The key to this is having dataless or near dataless
zones. This is a huge step forward over traditional UNIX
environments.
Mike
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
33
From:
Registered:
6/19/06
|
|
|
|
Re: zone migration
Posted:
Jun 19, 2006 5:48 PM
in response to: gjelinek
|
|
What is the official release date of solaris10 for customers that will support Detach and Attach operations on a Zone ?
cheers
Ihsan
|
|
|
|
|
Posts:
470
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: zone migration
Posted:
Jun 19, 2006 5:56 PM
in response to: zaghmoui
|
|
Ihsan Zaghmouth wrote:
> What is the official release date of solaris10 for customers that will support Detach and Attach operations on a Zone ?
Ihsan,
Attach and detach is planned to be part of S10u3. The schedule for
that release is currently showing November but that could change.
Jerry
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
39
From:
Germany
Registered:
5/23/06
|
|
|
|
Re: zone migration
Posted:
Jun 20, 2006 3:43 AM
in response to: gjelinek
|
|
Hi Jerry,
> 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.
> ation
>
> 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:
It would be nice to check the ability for attachment without errors prior to moving the zone to the new machine. To minimize downtime for the application inside the zone proper configuration of the target host prior zone migration is necessary. Referring to the different possibilities of moving a zone there might not always be connections to the same storage or a common network at all. Summing up everything needed for comparison of the zone in an XML file seems like a good idea to me. Usage would look like something like
srchost# zonecfg -z myzone dumpstate > myzone.state
srchost# scp myzone.state targethost:
targethost# zonecfg create --verify myzone.state
As an automated process this would act as a safety net to ensure proper migration with the current zone running and without too much data copying.
As a more lightweight implementation the check could be done on a remote (NFS) filesystem from where the zone root is mounted from the active server. This should be easy with a "don't do just check" -n Option:
targethost# zonecfg create -n -a /exported/zone/root
Best regards
-- Dagobert
|
|
|
|
|
Posts:
39
From:
Germany
Registered:
5/23/06
|
|
|
|
Re: zone migration
Posted:
Jun 20, 2006 4:57 AM
in response to: dago
|
|
Hi Jerry,
> It would be nice to check the ability for attachment
> without errors prior to moving the zone to the new
> machine.
I hate replying to my own post. However, I just found out that this has already been discussed at http://www.opensolaris.org/jive/thread.jspa?threadID=8745 and that there is even an RFE for that.
Sorry for the inconvenience
-- Dago
|
|
|
|
|
Posts:
470
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: zone migration
Posted:
Jun 20, 2006 5:33 AM
in response to: dago
|
|
Dagobert Michelsen wrote:
> I hate replying to my own post. However, I just found out that this has already been discussed at http://www.opensolaris.org/jive/thread.jspa?threadID=8745 and that there is even an RFE for that.
Dagobert,
Yes, that is the correct description for this feature.
The code changes are also already available within the
opensolaris source.
Jerry
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
