X

News, tips, partners, and perspectives for the Oracle Solaris operating system

  • August 22, 2018

Recovering a Missing Zone After a Repeated Upgrade From Oracle Solaris 11.3 to 11.4

Jan Pechanec
Principal Software Engineer

Recap of the Problem

As I explained in my past Shared Zone State in Oracle Solaris 11.4 blog post, if you update to Oracle Solaris 11.4 from 11.3, boot the new 11.4 BE, create/install new zones there, then boot back to 11.3, update again to 11.4, and boot that second 11.4 BE, zones you created and installed in the first 11.4 BE will no longer be shown in the zoneadm list -c output when you booted up from the second 11.4 BE.

Those zones are missing as the 2nd update from 11.3 to 11.4 replaced the shared zones index file, storing the original one containing the zone entries to /var/share/zones/index.json.backup.<date>--<time> file. However, I did not explain how we can get such zones back and that is what I'm gonna show in this blog post.

There are two pieces missing. One is the zones are not in the shared index file, the other one is the zones do not have their zone configurations in the current BE.

The Recovery Solution

The fix is quite easy so let's show how to recover one zone. Either zoneadm -z <zonename> export > <exported-config> the zone config from the first 11.4 BE, and import it in the other 11.4 BE via zonecfg -z <zonename> -f <exported-config>, or just manually create the zone in the second 11.4 BE with the same configuration.

Example:

BE-AAA# zonecfg -z xxx export > xxx.conf
BE-BBB# zonecfg -z xxx -f xxx.conf

In this specific case of multiple updates to 11.4, you could also manually copy <mounted-1st-11.4-be>/etc/zones/<zonename>.xml from the first 11.4 BE (use beadm mount <1st-11.4-be-name> /a to mount it) but note that that's not a supported way do to things as in general configurations from different system versions may not be compatible. If that is the case, the configuration update is done during the import or on the first boot. However, in this blog entry, I will cheat and use a simple cp(1) since I know that the configuration file is compatible with the BE I'm copying it into.

The decribed recovery solution is brands(7) agnostic.

Example

An example that follows will recover a missing zone uar. Each color represents a different BE, denoted also by different shell prompts.


root@s11u4_3:~# zonecfg -z uar create
root@s11u4_3:~# zonecfg -z uar install

root@s11u4_3:~# zoneadm list -cv
  ID NAME     STATUS      PATH                  BRAND     IP
   0 global   running     /                     solaris   shared
   - tzone1   installed   /system/zones/tzone1  solaris   excl
   - uar      installed   /system/zones/uar     solaris   excl

root@s11u4_3:~# beadm activate sru35.0.3
root@s11u4_3:~# reboot -f  

root@S11-3-SRU:~# pkg update --be-name=s11u4_3-b -C0 --accept entire@11.4-11.4.0.0.1.3.0
...
root@S11-3-SRU:~# reboot -f

root@s11u4_3-b:~# svcs -xv
svc:/system/zones-upgrade:default (Zone config upgrade after first boot)
 State: degraded since Fri Aug 17 13:39:53 2018
Reason: Degraded by service method: "Unexpected situation during zone index conversion to JSON."
   See: http://support.oracle.com/msg/SMF-8000-VE
   See: /var/svc/log/system-zones-upgrade:default.log
Impact: Some functionality provided by the service may be unavailable.

root@s11u4_3-b:~# zoneadm list -cv
  ID NAME     STATUS      PATH                  BRAND     IP
   0 global   running     /                     solaris   shared
   - tzone1   installed   /system/zones/tzone1  solaris   excl

root@s11u4_3-b:~# beadm mount s11u4_3 /a
root@s11u4_3-b:~# cp /a/etc/zones/uar.xml /etc/zones/

root@s11u4_3-b:~# zonecfg -z uar create
Zone uar does not exist but its configuration file does.  To reuse it, use -r; create anyway to overwrite it (y/[n])? n
root@s11u4_3-b:~# zonecfg -z uar create -r
Zone uar does not exist but its configuration file does; do you want to reuse it (y/[n])? y

root@s11u4_3-b:~# zoneadm list -cv
  ID NAME     STATUS      PATH                  BRAND     IP
   0 global   running     /                     solaris   shared
   - tzone1   installed   /system/zones/tzone1  solaris   excl
   - uar      configured  /system/zones/uar     solaris   excl

root@s11u4_3-b:~# zoneadm -z uar attach -u
Progress being logged to /var/log/zones/zoneadm.20180817T134924Z.uar.attach
      Zone BE root dataset: rpool/VARSHARE/zones/uar/rpool/ROOT/solaris-0
Updating image format
Image format already current.
Updating non-global zone: Linking to image /.
Updating non-global zone: Syncing packages.
Packages to update: 527
Services to change:   2
...
...
Result: Attach Succeeded.
Log saved in non-global zone as /system/zones/uar/root/var/log/zones/zoneadm.20180817T134924Z.uar.attach

root@s11u4_3-b:~# zoneadm list -cv
  ID NAME     STATUS      PATH                  BRAND      IP
   0 global   running     /                     solaris   shared
   - tzone1   installed   /system/zones/tzone1  solaris   excl
   - uar      installed   /system/zones/uar     solaris   excl

Conclusion

This situation of missing zones on multiple updates from 11.3 to 11.4 is inherently part of the change from a BE specific zone indexes in 11.3 to a shared index in 11.4. You should only encounter it if you go back from 11.4 to 11.3 and update again to 11.4. We assume such situations will not happen often.

The final engineering consensus during the design was that while users mostly keep going forward, i.e. update to greater system versions and then go back not, if they happen to go back to 11.3 and update again to 11.4, they would expect the same list of zones as they had on the 11.3 BE they used last for the 11.4 update.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha

Recent Content

Oracle

Integrated Cloud Applications & Platform Services