cancel
Showing results for 
Search instead for 
Did you mean: 

Patching of Solaris-Whole-Root-Zones in a VCS-Environment

bsobek
Level 5
Hi,
 
we have a 2-node-VCS with one whole-root-zone installed. Now we have to path this environment. Does anybody have experiences with doing this? For starting the whole-root-zone on both nodes, all (the nodes and the zone) must have the same kernel version. Actually, we have no really working method for patching all.
 
Thanks.
 
regards
Björn
4 REPLIES 4

Eric_Hennessey1
Level 5
Employee Certified
Patching gets a bit tricky for zones in a cluster environment, whether it's VCS or Brand X.

The normal approach to applying patches in a VCS environment is to patch the idle node, then switch the service group(s) to that node at some convenient time, then patch the other node.  When local zones are in the picture, however, there are other things to consider.

When you run the Solaris patchadd utility, patchadd will examine the node for any configured local zones.  If any are found, patchadd will attempt to boot the local zone(s).  If the zone fails to boot, patchadd exits with an error.  If your zone root file system is on shared storage, patching the idle node will error out, because the local zone can't boot without access to the zone root file system.  But if the zone root file system is on local storage, you won't have the problem.  While we support zone root on either local or shared storage, it's for this reason that we recommend zone root on local storage.

The next piece of this is the network configuration.  When clustering local zones, we recommend leaving the IP information out of the zone configuration and let the VCS IP agents manage it.  This is so that when patchadd boots a local zone on the idle node, you don't encounter an IP address conflict.

Hope this helps!

dahlborg
Not applicable
Hi,
 
What would be the best approach patching Solaris with zones in a VCS environment with the zone root on a shared storage? Im about to take this configuration in production shortly and a patch procedure is the only missing part to get this working.
 
BR
 
Robert

Ramesh_Pareet
Level 3
Employee
 I guess I do not fully understand what Veritas means by having the zone root on local storage. Could it be interpreted to mean the following? 

STEP A
Configure a zone named  zoneA  on server A to reside on local storage.
Naturally this file system cannot be relocated onto any other host in the cluster. So,
this specific Local Zone cannot be failed to another host in the cluster at this point.


STEP B

Now configure a zone named zoneA on server B to reside on server B local
storage. So when the Zone named zoneA is given to VCS to manage as a zone resource it
will find a zone root for zoneA on local storage on each host and be able to start the Local
Zone?

 

Now for the issue of the IP address.  The White Paper says  dated
July, 2006 states That IP configuration MUST be removed from the zone configuration file
and managed by VCS. However, "Veritas Cluster Server" 4.1 User Guide states that the IP must
be contained in the Global Zone's configuration file for the local zone and CANNOT be managed by
VCS.  This comes from  Page 611 in the User Guide.


Please assist me as i am working with BCS customer on this.

Regards
Ramesh

buckwheat
Not applicable


@E. Hennessey wrote:
If your zone root file system is on shared storage, patching the idle node will error out, because the local zone can't boot without access to the zone root file system.  But if the zone root file system is on local storage, you won't have the problem.  While we support zone root on either local or shared storage, it's for this reason that we recommend zone root on local storage.

T

Hope this helps!



You're way off on this. If the zone ROOTS use common storage, then it only gets patched in one spot. Don't know what you're talking about with "it errors out" and takes longer. With common storage, the zones go down, one spot is patched, and it's back up. If you've elected to use whole root zones, then your patching will take MUCH longer. If you use local, separate storage for your local zones instead of common storage, and your system has actually continued to run and not crashed due to synchronization issues, then you'll still have to patch two systems. Not only is this not recommended by Sun, it'll take forever. I think the issue here is really whole root zones - or the magical zone for the ignorant