Re: [zones-discuss] Zone Cloning issues
Mark Huff wrote: 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 only thing changed in line 18 from the zone that I want to clone is the zonename as shown bluto-zone2. The bluto-zone1 zone has the same lofs filesystem as shown above in line 18 just its zonename is bluto-zone1 instead. Thats right. You are changing the lofs mount entry so that the new zone mounts a different directory into the zone compared to what is being mounted in the original zone. Since the directory you want to mount into the new zone doesn't exist, you need to create that directory so that the lofs mount can succeed. The two zones do have the same configuration. The same lofs filesystem. That is my point. unless I physically make the directory structure as shown with mkdir -p /zones/roots/bluto-zone2/localcw the clone fails. Personally I think that's not right. Personally cloning to me, means whatever I have in X, I want th same in Y. As I mention if I have 50 zones identical configurations and before I can clone the 50 zones I need to do a mkdir, to create those filesystems, then cloning, in my opinion doesn't work. No they don't. I don't understand how you can think this since your previous comment makes it is clear that that they are not mounting the same directory in each case. This has nothing to do with cloning. What is happening here is that the zone code is verifying the zone configuration and it is telling you that the source directory for the lofs mount just doesn't exist. Once you create the directory that you want to lofs mount into the zone, then the verification succeeds. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Zone Cloning issues
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 Cheers Mark -- -- -- http://www.sun.com/images/l1/l1_solaris_logo.jpg Solutions Architect / OS Ambassador Solaris Adoption Systems Practice Sun Microsystems, Inc. » Source Browser http://cvs.opensolaris.org/source/ » Get Solaris Now http://www.sun.com/software/solaris/get.jsp Solaris Technology Get it Now at sun.com 400 Atrium Dr. 2nd Floor Somerset, NJ 08873 (973) 582-3740 Accessline (973) 223-3519 Mobile [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http://www.sun.com http://www.opensolaris.org/os/ NOTICE: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zone Cloning issues
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
Re: [zones-discuss] Zone Cloning issues
-- http://www.sun.com/images/l1/l1_solaris_logo.jpg Solutions Architect / OS Ambassador Solaris Adoption Systems Practice Sun Microsystems, Inc. » Source Browser http://cvs.opensolaris.org/source/ » Get Solaris Now http://www.sun.com/software/solaris/get.jsp Solaris Technology Get it Now at sun.com 400 Atrium Dr. 2nd Floor Somerset, NJ 08873 (973) 582-3740 Accessline (973) 223-3519 Mobile [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http://www.sun.com http://www.opensolaris.org/os/ NOTICE: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Jerry Jelinek wrote: 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 only thing changed in line 18 from the zone that I want to clone is the zonename as shown bluto-zone2. The bluto-zone1 zone has the same lofs filesystem as shown above in line 18 just its zonename is bluto-zone1 instead. 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
