[CentOS] Anything Like Solaris' Live Upgrade?

Mon Jan 28 19:27:57 UTC 2013
xrx <xrx-centos at xrx.me>

On 01/28/13 22:54, Tim Evans wrote:
> On 01/28/2013 01:20 PM, xrx wrote:
>> On 01/28/13 22:14, Tim Evans wrote:
>>> On 01/28/2013 01:05 PM, xrx wrote:
>>>> On 01/28/13 21:27, James A. Peltier wrote:
>>>>> ----- Original Message -----
>>>>> | Does anyone know of any sort of Linux utility that does something
>>>>> | like
>>>>> | what Solaris' Live Upgrade
>>>>> | (http://docs.oracle.com/cd/E19455-01/806-7933/index.html) does?
>>>>> |
>>>>> | In my past life as a Solaris sys-admin, I found this an extremely
>>>>> | useful
>>>>> | tool for upgrading and patching running systems, as well as for
>>>>> | maintaining redundant boot environments on separate system disks for
>>>>> | disaster situations.
>>>>> Nothing really until BTRFS comes of age.  I suppose you could snapshot your LVM volumes before performing the upgrade but to my knowledge there is nothing similar to Live Upgrade for CentOS
>>>> It does sound like you can do the roughly the same with LVM snapshots.
>>>> Reading the introduction of the solaris document you linked; it seems as
>>>> if the solaris upgrade is applied on say a snapshot; and then the system
>>>> is rebooted into the upgraded environment; and if it works, great, if
>>>> not you need a reboot back into the original state.
>>>> Wheras with CentOS 6; you take a snapshot of the root partition (easy as
>>>> "lvcreate --snapshot --name RootSnapshot --size 2G /dev/VolGroup/Root"),
>>>> and then do an upgrade with a reboot. If it works; you're set, if not,
>>>> just revert back to the snapshot (lvconvert --merge
>>>> VolGroup/RootSnapshot) and reboot; you'd be back to the state before the
>>>> upgrade.
>>> Thanks. You also need to manage the grub and fstab configurations to
>>> allow the second boot environment to be visible, bootable, and mountable.
>> Are you talking about CentOS? There is no need to change the fstab or
>> grub; the upgrade gets applied on the main volume (where the OS can be
>> upgraded on the fly without a reboot if it works out; or optionally with
>> a reboot if you want to be extra sure). The snapshot is only there if
>> the update goes bad; in which case you'd run the merge command to revert
>> back to the original state.
> Thanks, again.  What you've described is sort of the bass-ackward to
> what LU does.
> It creates one or more "alternate boot environment(s)," then newfs's it,
> mounts it, copies the running system to it, then applies
> upgrades/patches to it.  It does not touch the running environment
> (except to create a housekeeping database for the multiple boot
> environments).  The target boot environment is made bootable, and the
> grub configuration is updated to include the second bootable
> environment, and the /etc/fstab file on the second environment is
> modified to reflect the disks/LV's it uses.
> The whole idea is not to touch the running system, apply changes to the
> alternate system, then boot to the alternate when change is done. Once
> the reboot to the new environment is done, you can further use LU to
> replace the un-upgraded/un-patched original environment with a copy of
> the new one.
Right, but if the end result is being able to recover from a bad 
upgrade; they both do the job. In fact, I'd argue that what you 
described sounds a lot worse (in being complicated, & always requiring a 
reboot) than what CentOS 6 does for the same use case. If you're going 
to have downtime in the time required to reboot solaris, try out the 
upgrade, and reboot again if the upgrade was borked; then not touching 
the running environment isn't a huge advantage since you'd need to 
arrange a lot of downtime anyway. With CentOS, instead of the downtime 
being on a reboot; it will (or rather may) be during/after the update 
(yum does not take very long). If the update goes bad; then you can go 
back to the untouched environment with a merge & reboot. So the CentOS 
method could be a lot faster & easier overall.

Is there any particular reason you prefer LU over snapshots if both can 
give you the non-updated environment, if required, at the end?