Patching zones when they are attached to hosts


I 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

This is pretty sweet, and I can see myself using this functionality (along with live upgrade) in the future!

This article was posted by Matty on 2009-04-09 11:14:00 -0400 -0400