Mark Huff wrote:
IHAC who is pretty excited about the clone option in Solaris 10 11/06
(U3), however they're running into problems in the execution of the
clone option for zoneadm. Here are the step-by-step procedures they are
following
For example they have a zone called bluto-zone1 installed already and
they want to clone it. The bluto-zone1 currently has a loopback mounted
filesystem called localcw, as shown below in the generated master config
file
Steps:
1). zonecfg -z bluto-zone1 export -f /var/tmp/master ( Completes OK)
2). vi /var/tmp/master
[EMAIL PROTECTED] # vi master
"master" 24 lines, 368 characters
1 create -b
2 set zonepath=/zones/roots/bluto-zone2
3 set autoboot=true
4 add inherit-pkg-dir
5 set dir=/lib
6 end
7 add inherit-pkg-dir
8 set dir=/platform
9 end
10 add inherit-pkg-dir
11 set dir=/sbin
12 end
13 add inherit-pkg-dir
14 set dir=/usr
15 end
16 add fs
17 set dir=/usr/localcw
18 set special=/zones/roots/bluto-zone2/localcw
19 set type=lofs
20 end
21 add net
22 set address=129.153.180.21
23 set physical=hme0
We changed the ZONEPATH to reflect the new zonename and the IP as shown
above in the file. Then saved the file.
3). zonecfg -z bluto-zone2 -f /var/tmp/master ( This completed OK)
4). zoneadm -z bluto-zone2 clone bluto-clone1 (This fails as shown below)
Here is the ERROR they get: could not verify fs /usr/localcw: could not
access /zones/roots/bluto-zone2/localcw: No such file or directory
zoneadm: zone bluto-zone2 failed to verify
Now, I understand adding this step (mkdir -p
/zones/roots/bluto-zone2/localcw), before running the zoneadm -z
bluto-zone2 clone bluto-clone1) will allow the clone to work, but it
kind of defeats the purpose of the word CLONE. Clone to me for example
means whatever I have in this zone clone it, and I should have a
identical new zone with the same stuff just a new hostname and IP. I
shouldn't have to make the directory first in the ZONEPATH for it to
work. I would think the /zoneadm/ with the /clone/ option should be
smart enough to see that the directory /zones/roots/bluto-zone2/localcw
doesn't existed and create it since I'm telling it to create the zone
with theses identical attributes from the bluto-zone1.
If a customer has 50 lofs filesystems in the origainal zone, do we mean
they would need to run the mkdir command 50 times. That's just silly.
Am I missing something!! Or is this the way it's supposed to work for
now and it will be future releases
If I understand what your customer did, then I think you left out
a step above. You said they changed their zonepath and IP address for
the new host. However, based on the names above, it also looks like
they changed the lofs mounted filesystem configuration for the new zone.
This is reflected on line 18 of the configuration listing above. If
this is the case, then the two zones do not have the same filesystem layout.
The purpose of the zoneadm clone command is to use the original zone's
installation as the basis for the new zone. With cloning, the new zone will
have the exact same filesystem contents as are on the original zone. If you
change the filesystem configuration for the second zone, then that concept
basically no longer makes sense. All that the clone command does is replicate
the original zones contents within the new zone. It does not attempt to figure
out that you made changes to the configuration and that it should somehow merge
those changes with what was in the original zone.
There is a fundamental misunderstanding in your explanation above. The zoneadm
clone command *does not* create the zone. You have already created the
zone using the zonecfg command. The zoneadm clone command is an alternative
way to install the zone using the bits from another zone as the basis for the
installation. If the two zones are not configured the same, then a clone
installation generally cannot work.
Now, as you noted above, you can workaround this for this specific case
by creating the new filesystem that needs to be lofs mounted. This works
since the lofs mounted data is not actually cloned during the installation.
The point here is that the clone command does not create any filesystems
that are needed for your zone configuration. It simply replicates the
data from the first zone into the second zone. So, the bottom line is
yes, you must manually create any filesystems that you need to have lofs
mounted into the zone. There is no zone commands that will do that for you.
In fact, you will have the same problem if you tried to just install the
zone (as opposed to cloning) since the filesystems needed for the zone
lofs mounts don't exist until you create them.
Jerry
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
