XO in-field upgrades

[Alexander Larsson]

On Mon, 2007-06-25 at 15:38 -0400, Noah Kantrowitz wrote:
> > Caveat: I'm not an expert here.  I haven't read the code, just the
> > documentation.  So we can all follow along, start here:
> >    http://linux-vserver.org/Paper#Unification
> >    http://linux-vserver.org/Frequently_Asked_Questions#What_is_vhashify.3F
> >
> > Basically, copy-on-write works by running a tool ('vhashify') which
> > looks for identical files in the different containers and hard links
> > them together, then marks them immutable.  The copy-on-write mechanism
> > works by intercepting writes to immutable files and cloning the file
> > before making it writable by the container.
> >   
> It is worth noting we are not using vhashify or any of the other util
> scripts. The rainbow daemon sets up the chroot for each activity itself.
> We are a bit non-standard in that we are doing process-level
> containerization, instead of a more guest-OS system like many vserver
> users (most?).

I still don't understand at all how vserver can be used to upgrade the
main image. Yes, one can clone the main image into a chroot, and use
vserver to boot into that. One can also enable some COW stuff so that we
can change that into the new version. 

But, how do we apply this new image (which is a copy of the root +
applied updates) to be the new master image the next time we boot? i.e.
when the kernel boots it will launch /bin/init,
not /vserver/updated_image/bin/init.

Nobody has explained this, yet everyone keeps talking about using
vserver and COW for the upgrades.

Btw. I don't see why we would have to use vserver and COW for doing
this, we just have to do the hardlink copy, and then apply the update on
that, carefully always changing files so that hardlinks are broken (i.e.
no in-place updates, just replace the files). However, that still gets
us into the same situation, with a copy of the new image in a
subdirectory that is not the main image.