I am considering options for Live Upgrading a Solaris 10 9/10 machine with a ZFS root pool (actually will be deploying a flash archive if that is of any interest).

The docs mentions several options. One is to create a new boot environment in a new root pool. The other option is to create new boot environment in an existing root pool. I am tending towards the latter, however this is just gut feeling and I am a bit lost regarding the pros and cons of each option. So if someone could list pros and cons of each option I might be able to do a more informed decision.


It's pretty simple, actually.

If you make the new boot environment in the same ZFS root pool as the one you're copying from, it's just a ZFS snapshot and clone of the original pool.

So creating/destroying such boot environments is relatively quick.

That seems better at first. But it leaves the new boot environment tied to the one it was copied from.

On a long-lived server that gets regular updates, each time to a new boot environment, creating new boot environments in the same pool as the source boot environment builds up a nasty tangle of ZFS snapshots and clones that's extremely difficult if not impossible to manage. And because the snapshots/clones "pin" old copies of files, it also creates space problems over time.

Conversely, if you create the new boot environment in a different pool, it's a completely separate copy - files are literally copied from the source boot environment to the new one. It takes longer, and initially takes more space, but it's clean and totally separate.

In my experience, long-lived Solaris organizations tend to use the latter, often having Solaris servers with four boot drives - two hardware RAID-1 mirrors for two root pools. (Yes, HARDWARE mirrors. Replacing a disk in a ZFS mirror takes coordinated actions between the disk replacement tech and sysadmin. That coordination is hard to do when remotely managing hundreds if not thousands of servers in multiple locations. And as the replacement tech is from the hardware vendor doing warranty disk replacement, if the sysadmin isn't ready when the replacement tech shows up, he's likely to walk out. Replacing a disk in a hardware mirror is a simple "pull the disk with the orange light, pop in a replacement" action for just the tech doing the replacement. The admin gets to read the logs later, and there's no chance for fat-fingering a command.)

Just be careful when creating boot environments that you don't include users' home directories in the boot environment. Users tend not to like having their files rolled back to something they were at the moment you created the boot environment, and then rolled over to something else entirely when you have to switch to another boot environment for some reason.

  • @Isaac - The clone used for the new boot environment's file system depends on the snapshot. You'd have to promote the clone first. See docs.oracle.com/cd/E19253-01/819-5461/gavvx/index.html Now, imaging a chain of 3-4 boot environments built on top of that chain of snapshots and clones, each one dependent on the previous one. Cleaning up a clone of a snapshot of a clone of a snapshot of a clone of a snapshot is a mess when the names are all intertwined with the names of the boot environments built on top. Botch it and the root pool and all the boot environments in it are trashed. – Andrew Henle Sep 20 '16 at 12:01
  • I see. In my particular scenario I might end up with just one clone ever (if at all) - so I am still tending towards the clone because of speed and ease. But now I understand the implications better. – Isaac Sep 20 '16 at 13:00
  • Even with hardware raid used inside the server, there is still coordination needed between the SA(s) and the person with the replacement drive. Even in large enterprise arrays, I've had a tech pull the wrong drive. Also note, that in the case of internal drives, using RAID1 zpool gives you more functionality at putting the drive in a different or new system to boot. Although possible, internal hw raid is a more complex procedure. btw, I love SAN booting. – sleepyweasel Feb 2 '17 at 22:45
  • And to help with space for a single rpool, you can turn on compression on. However, note that I think only the default lz4 is currently supported in the rpool for v10 & v11--but still gives a respectable compression ratio, esp. for log files in /var. – sleepyweasel Feb 2 '17 at 22:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.