/etc/vx/reconfig.d/state.d/install-db

Exact Error Message
vxvm:vxconfigd: ERROR: enable failed: Error in disk group configuration copies
Rootdg disk group has no configuration copies; transactions are disabled.
vxvm:vxdctl: ERROR: enable failed: Error in disk group configuration copies

Details:

If the install-db file exists in the /etc/vx/reconfig.d/state.d directory, Volume Manager will be disabled during boot. Volume Manager can be re-enabled during boot by removing the install-db file in the /etc/vx/reconfig.d/state.d directory.

In Volume Manager 3.1.1 with patch02 or patch03, if /etc/vx/reconfig.d/state.d/install-db exists, the Volume Manager boot file, /etc/vx/volboot, will be re-initialized. If any simple disk is included in rootdg, Volume Manager can not be started properly even if the file install-db is removed. This problem only occurred in Volume Manager 3.1.1 with patch02 or patch03, and the Volume Manager 3.1.1 Japanese version.

NOTE: This problem does not occur in Volume Manager 3.1.1 without patches and Volume Manager 3.2.

After the /etc/vx/reconfig.d/state.d/install-db file is created, an error message will not be displayed during the boot process. But, after the machine boots up, running the vxdctl enable command to enable the vxconfigd daemon will generate an error message as shown below:

# vxdctl enable
vxvm:vxconfigd: ERROR: enable failed: Error in disk group configuration copies
Rootdg disk group has no configuration copies; transactions are disabled.
vxvm:vxdctl: ERROR: enable failed: Error in disk group configuration copies

If simple disks are used in Volume Manager, run the following command to re-add all simple disk entries to the volboot file in order to re-enable the vxconfigd daemon. If more than one simple disk is used in Volume Manager, repeat the command until all of the simple disk entries have been added.

# vxdctl add disk

If no simple disks are used in Volume Manager, then the above step is not necessary. If the prior Volume Manager host ID was different than the operating system host name, it must run the following command to change the Volume Manager host ID, which is saved in the volboot file, to get Volume Manager started properly.

# vxdctl hostid

Then vxconfigd can be re-enabled by executing the following commands:

# vxdctl -k stop
# vxconfigd -d
# vxdctl enable

To fix the problem permanently, apply the following solution after installing the patch, but before reboot, to avoid the problem. If the problem has already occurred, apply the solution after recovering the volboot file using the steps above.

Solution

1. Find the following lines in the startup script /etc/init.d/vxvm-reconfig in line 165 to 171:

165> if [ -f $mkdbfile ]; then
166> xcmd vxiod set 10
167> xcmd $VOLD -k -r reset -m disable
168> xcmd vxdctl init
169> xcmd vxdctl initdmp
170> xcmd vxdg init rootdg
171> fi

2. Find the following line in line 222:

222> [ -f $reconfigfile ] || exit 0

3. Move the lines in step 1 to appear below the line in step 2

4. The modified vxvm-reconfig file will appear as shown below:


214> [ -f $reconfigfile ] || exit 0
215>
216> if [ -f $mkdbfile ]; then
217> xcmd vxiod set 10
218> xcmd $VOLD -k -r reset -m disable
219> xcmd vxdctl init
220> xcmd vxdctl initdmp
221> xcmd vxdg init rootdg
222> fi


5. Reboot

Solaris Zone’s Resource capping – MEMORY-CPU

Resource Management, Solaris 10, Zones

Solaris Zone’s Resource capping:  Resource capping is nothing but Limiting the system resources like CPU,Memory,SWAP  to local zone.For an example, if you are running local zones without a resource capping,there may be high possibility that one zone will consume all the global zone resources and it will effect other local zones which are running the same global zone.We do not want to put the system in such a situation. It’s better to put resource  capping on  each local zones to avoid such a situation. 

What are the system resource can be capped in Solaris local zones ?
1.Physical Memory & SWAP capping
2.CPU capping

The resource capping daemon(rcapd) is responsible for the resource capping .See the Man page of rcapd.

Assumptions: The below mentioned local  zones are running without any resource capping.

#zoneadm list -cv
  ID NAME               STATUS     PATH                              BRAND    IP
   0 global             running    /                                native   shared
   1 uarena11103        running    /export/zones/uarena11103        native   shared
   2 uarena11105        running    /export/zones/uarena11105        native   shared
   3 uarena11106        running    /export/zones/uarena11106        native   shared
   4 uarena11107        running    /export/zones/uarena11107        native   shared
   5 uarena11108        running    /export/zones/uarena11108        native   shared
   6 uarena11109        running    /export/zones/uarena11109        native   shared

Verifying the capping on all the zones,

# cd /etc/zones
# grep -i mem *
# grep -i cpu *

As per above output, no capping has been made on the local zones.

Memory Capping:
To perform the memory capping,Login to global zone and perform the below. Here i am setting capping for physical memory ,SWAP.

MYGLOBAL#
zonecfg -z uarena11105
zonecfg:uarena11105> add capped-memory
zonecfg:uarena11105:capped-memory> set physical=24G
zonecfg:uarena11105:capped-memory> set swap=10G
zonecfg:uarena11105:capped-memory> set locked=1G
zonecfg:uarena11105:capped-memory> end
zonecfg:uarena11105>commit
zonecfg:uarena11105>exit
MYGLOBAL#

As per the above settings,local zone uarena11105 can use up to 24GB of physical memory from global and it can utilize swap up to 10GB. Locked memory is nothing but a physical memory which is dedicated physical memory to that localzone. 

CPU capping:
As like the memory capping ,we can cap the CPU’s to local zone. CPU is a key resource for applications and its needs to be divided across the local zone according to the requirement.To perform the CPU capping,login to global zone and perform the below.
To determine the no of physical CPU’s in your global zone,use “psrinfo -pv” command.

MYGLOBAL#zonecfg -z uarena11105
zonecfg:uarena11105>
zonecfg:uarena11105>add capped-cpu
zonecfg:uarena11105>capped-cpu> set ncpus=16
zonecfg:uarena11105>capped-cpu> end
zonecfg:uarena11105> commit
zonecfg:uarena11105> exit
MYGLOBAL#

As per the above command uarena11105 zone can use up to 16 CPU’s.

For CPU resource ,we have an option to assign dedicated CPU’s to the local zones.By doing that global & other local zones can’t use the those dedicated CPU’s which we have assigned to the zone.Here we will see how to perform that.

MYGLOBAL#zonecfg -z uarena11105
zonecfg:uarena11105>
zonecfg:uarena11105>add dedicated-cpu
zonecfg:uarena11105>dedicated-cpu> set ncpus=16
zonecfg:uarena11105>dedicated-cpu> end
zonecfg:uarena11105> commit
zonecfg:uarena11105> exit
MYGLOBAL#

The above command will set 16 dedicated CPU’s to zone uarena11105.If you want you can set importance to specific CPU by set property “set importance=2” in dedicated-cpu field. 

You can verify the setting using below command.

MYGLOBAL#zonecfg -z uarena11105 info