Steps for Installing Solaris patch cluster

1. Check all mirrors for "needs maintenance", and if there are any, "metasync" those.

2. "metadetach" the mirror

3. "init 0"

4. "OK> boot -s"

5. If necessary, "zfs mount -a" to get everything mounted in single-user

6. "install_cluster"

7. "init 0"

8. "boot -r"
9. "metattach" the mirror that was broken

Some ZPOOL commands

bash-3.00# /usr/sbin/zpool history
History for 'pool_name':
2009-05-01.15:14:12 zpool create pool_name c2t50060482D52D2E56d10 c2t50060482D52D2E56d11
2009-05-01.15:16:29 zfs create pool_name /u001
2009-05-01.15:16:33 zfs create pool_name /u003
2009-05-01.15:20:33 zfs set mountpoint=/u001 pool_name/u001
2009-05-01.15:24:21 zfs set compression=on pool_name/u001
2009-05-01.15:24:24 zfs set compression=on pool_name/u003
2009-05-01.15:25:11 zfs set mountpoint=/u003 pool_name/u003
2009-05-01.15:31:43 zfs set mountpoint=/u003 pool_name/u003
2009-05-01.15:32:06 zfs set mountpoint=/u003 pool_name/u003
2009-05-01.15:33:36 zfs set mountpoint=/mnt pool_name/u001
2009-05-01.15:33:42 zfs set mountpoint=/u001 pool_name/u001
2009-05-01.15:37:56 zfs set compression=off pool_name/u001
2009-05-01.15:37:57 zfs set compression=off pool_name/u003

No quotas, no compression

Log in to the zone to be shut down

global# zlogin my-zone shutdown -i 0

shutdown -y -g0 -i6

Core-Dump

"savecore -L" which produces a live core dump on the running system
reboot -d to reboot the box and get a core.

some zoneadm commands

zoneadm list -cv
zoneadm list -iv
zoneadm list
zoneadm list -p
zoneadm -z myzone boot -- -m verbose
zoneadm -z myzone reboot -- -m verbose

Exporting Solaris zone configurations

(Got it from other site for my information)


I have been using Solaris 10 zone technology for the past 4 - 5 months, and just recently came across the zonecfg(am) “export” option. This option allows you to export the configuration from a specific zone, which can be used to recreate zones, or as a template when adding additional zones (with some adjustments of course). The following example prints the zone configuration for a domain called “irc”:
$ zonecfg -z irc exportcreate -b
set zonepath=/export/home/zone_irc
set autoboot=false
add net
set address=192.168.1.4
set physical=hme0
end
This is super useful, and can make creating 1000s of zones a snap!

Patching zones when they are attached to hosts

(Got this information from different post for my reference)

recently patched one of my Solaris 10 hosts, and decided to test out the zone update on attach functionality that is now part of Solaris 10 update 6. The update on attach feature allows detached zones to get patched when they are attached to a host, which can be rather handy if you are moving zones around your infrastructure. To test this functionality, I first detached a zone from the host I was going to patch:
$ zoneadm -z zone detach
$ zoneadm list -vc
ID NAME STATUS PATH BRAND IP
0 global running / native shared
- zone1 configured /zones/zone1 native shared
Once the zone was detached, I applied the latest Solaris patch bundle and rebooted the server. When the system came back up, I tried to attach the zone:
$ zoneadm -z zone1 attach
These patches installed on the source system are inconsistent with this system:
118668: version mismatch
(17) (19)
118669: version mismatch
(17) (19)
119060: version mismatch
(44) (45)
119091: version mismatch
(31) (32)
119214: version mismatch
(17) (18)
119247: version mismatch
(34) (35)
119253: version mismatch
(29) (31)
119255: version mismatch
(59) (65)
119314: version mismatch
(24) (26)
119758: version mismatch
(12) (14)
119784: version mismatch
(07) (10)
120095: version mismatch
(21) (22)
120200: version mismatch
(14) (15)
120223: version mismatch
(29) (31)
120273: version mismatch
(23) (25)
120411: version mismatch
(29) (30)
120544: version mismatch
(11) (14)
120740: version mismatch
(04) (05)
121119: version mismatch
(13) (15)
121309: version mismatch
(14) (16)
121395: version mismatch
(01) (03)
122213: version mismatch
(28) (32)
122912: version mismatch
(13) (15)
123896: version mismatch
(05) (10)
124394: version mismatch
(08) (09)
124629: version mismatch
(09) (10)
124631: version mismatch
(19) (24)
125165: version mismatch
(12) (13)
125185: version mismatch
(08) (11)
125333: version mismatch
(03) (05)
125540: version mismatch
(04) (06)
125720: version mismatch
(24) (28)
125732: version mismatch
(02) (04)
125953: version mismatch
(17) (18)
126364: version mismatch
(06) (07)
126366: version mismatch
(12) (14)
126420: version mismatch
(01) (02)
126539: version mismatch
(01) (02)
126869: version mismatch
(02) (03)
136883: version mismatch
(01) (02)
137122: version mismatch
(03) (06)
137128: version mismatch
(02) (05)
138224: version mismatch
(02) (03)
138242: version mismatch
(01) (05)
138254: version mismatch
(01) (02)
138264: version mismatch
(02) (03)
138286: version mismatch
(01) (02)
138372: version mismatch
(02) (06)
138628: version mismatch
(02) (07)
138857: version mismatch
(01) (02)
138867: version mismatch
(01) (02)
138882: version mismatch
(01) (02)
These patches installed on this system were not installed on the source system:
125556-02
138889-08
139100-01
139463-02
139482-01
139484-05
139499-04
139501-02
139561-02
139580-02
140145-01
140384-01
140456-01
140775-03
141009-01
141015-01
As you can see in the above output, the zone refused to attach because the zone patch database differed from the global zone patch database. To synchronize the two, I added the “-u” option (update the zone when it is attached to a host) to the zoneadm command line:
$ zoneadm -z zone1 attach -u

Getting the list of files to remove
Removing 1209 files
Remove 197 of 197 packages
Installing 1315 files
Add 197 of 197 packages
Updating editable files
The file within the zone contains a log of the zone update.
Once the zone was updated, I was able to boot the zone without issue:
$ zoneadm -z zone1 boot
$ zoneadm list -vc ID NAME STATUS PATH BRAND IP
0 global running / native shared
4 zone1 running /zones/zone1 native shared