|
Replies:
2
-
Last Post:
Dec 8, 2005 10:49 AM
by: jlarke
|
|
|
Posts:
470
From:
US
Registered:
3/9/05
|
|
|
|
moving and cloning a zone
Posted:
Nov 29, 2005 1:31 PM
|
|
For those interested in these features, 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 two existing RFEs. The first [2] enables non-global
zones to be relocated from one point on the filesystem to another;
this may involve actually moving the bits and requires changing the
associated metadata (the "zonepath"). The second [3] enables
administrators to rapidly provision new non-global zones, once
one has been set up, by allowing installation via copying from
another (non-global) zone.
Patch binding is requested for these sub-commands and the stability
of the interfaces is "evolving".
DETAILS:
We will add two new sub-commands to the zoneadm command.
The syntax for moving a zone will be:
# zoneadm -z my-zone move /newpath
where /newpath specifies the new zonepath for the zone. This will
be implemented so that it works both within and across filesystems,
subject to the existing rules for zonepath (e.g. it cannot be on an
NFS mounted filesystem). When crossing filesystem boundaries the
data will be copied and the original directory will be removed.
Internally the copy will be implemented using cpio with the proper
options to preserve all of the data (ACLs, etc.). The zone must be
halted while being moved.
The syntax for cloning a zone will be:
# zoneadm -z new-zone clone [-m method] method_params
Cloning 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 clone to
set up the zone root instead of installing. This allows all
customizations (configuration, pkgs, etc.) from the source zone to
be directly instantiated in the new zone. The new zone will be left
in the sys-unconfigured state even though the source zone is likely
to be fully configured. The source zone must be halted while the
clone is running.
The zoneadm command will be enhanced to perform additional
verification when cloning. Appropriate warnings and errors will
be printed if the new zone and source zone are configured
inappropriately.
The -m option specifies the method used to clone the source. The
default and initial -m method will be "copy". This will copy the
data from the source zone (specified as the method_param) zonepath
to the new-zone zonepath (implemented using cpio as with the move
sub-command).
In the future we anticipate supporting other cloning methods, such
as ZFS clones, where we would specify a ZFS snapshot in the method
parameter. However, use of ZFS clones is not part of the current
proposal. We currently lack upgrade support for zones on ZFS
filesystems so use of a ZFS filesystem for the zonepath is not
recommended [4]. Once this issue is addressed we expect to
submit a fast-track to enhance clone support by using ZFS snapshots
and clones.
REFERENCES
1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris
2. RFE: zoneadm move command. Bugid 4963361
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4963361
3. RFE: provide faster zone provisioning. Bugid 6292928
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6292928
4. 6356600 - zfs datasets can't be used to provide space for zone roots
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6356600
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
Posts:
20
From:
CH
Registered:
10/20/05
|
|
|
|
Re: moving and cloning a zone
Posted:
Nov 30, 2005 10:00 AM
in response to: gjelinek
|
|
This is interesting. I appreciate this feature.
I have already cloned zones by hand doing the following steps:
1) Backup old zone with my backup script: http://www.opensolaris.org/jive/thread.jspa?threadID=3498&tstart=0
2) Create new directory <zonedirectory> for new zone
3) Copy backup <zonename>.tar.gz into the new directory and extract it.
4) Update new nodename for the new zone in the files
<zonedirectory>/root/etc/nodename
<zonedirectory>/root/etc/hosts
<zonedirectory>/root/etc/inet/ipnodes
5) Remove the <zonedirectory>/root/etc/sysidcfg file if present.
6) Modify in the /etc/zones/index file: add the new zone to the list of zones
7) Create a new /etc/zones/<newzone>.xml file according to the requirenments
8) The new zone is now ready to boot. For some reasons, I don't know why, the SMF is counting up each service. Therefore the first boot of the zone takes a while.
9) May be it is necessary to create a new SSH keypair for the new zone as well as delete sytstem logfiles ...
I know this is not the 'official' way to create zones, but I did this for at least 10 zones on several servers so far and all of them are working since a few weeks without any problems.
BR Marcel
|
|
|
|
|
Posts:
1
From:
Registered:
12/8/05
|
|
|
|
Re: moving and cloning a zone
Posted:
Dec 8, 2005 10:49 AM
in response to: gjelinek
|
|
I can think of lots of situations where upgrade functionality would not be required and using zfs clones to easily clone zones would be very, very handy. I'd like to see some support for such a feature even if there are caveats.
|
|
|
|
|
