On 10/25/07, Jerry Jelinek <[EMAIL PROTECTED]> wrote:
> Mario,
> While it would be possible to do this, it is in some sense
> harder than it was for S8.  S10 is still a very dynamic
> release so the interpositioning layer would need constant
> work to cope with the on-going changes in the
> kernel/user-land boundary.

I've been thinking that I would like this capability as well, but as I
tried to articulate why I found very few arguments that I could stand
behind long-term.  The key thing that this would address for me is
being able to move a zone between sun4u and sun4v, which already seems
to be on the radar, as mentioned in Jerry's initial message at

        One additional comment. I believe this proposal should also
        address the recurring question about being able to migrate a
        zone from sun4u to sun4v (and back).

> As far as easily moving a zone around, take a look at
> 6480464 RFE: zoneadm attach should patch/update the zone to
>          the new hosts level

I would also be quite interested in having a mechanism to live upgrade
a single zone.  This way I could do the following to maximize
flexibility in scheduling for consolidated servers while minimizing
down time for patching.  That is, the process would look like:

host1# lucreate -Z <zonename> ...
host1# luupgrade -Z <zonename> ...
host1# luactivate -Z <zonename> ...
host1# zlogin <zonename> init 0
host1# zoneadm -z <zonename> detach
host2# zoneadm -z <zonename> attach
host2# zoneadm -z <zonename> boot

> Now that the S8MA project is done I am planning to get back
> to this RFE.  This is a much more straightforward solution
> to the problem than a new brand.

I suspect that the update on attach process may be substantially
faster than patching, so maybe the method I mention above isn't
terribly important.  I think with update on attach, I may be able to
accomplish the same with:

host1# zlogin <zonename> init 0
host1# zoneadm -z <zonename> detach
host1# zonecfg -z <zonename> export -f /zones/<zonename>/zone.cfg
host1# zfs snapshot <zonename>@host1-detach-<timestamp>
host1# zonecfg -z <zonename> delete
host1# zpool export <zonename>
host2# zpool import <zonename>
host2# zonecfg -z <zonename> -f /zones/<zonename>/zone.cfg
host2# zoneadm -z <zonename> attach -u

If things went badly with "attach -u":

host2# zoneadm -z <zonename> detach
host2# zpool export <zonename>
host1# zpool import <zonename>
host1# zfs rollback <zonename>@host1-detach-<timestamp>
host1# zonecfg -z <zonename> -f /zones/<zonename>/zone.cfg
host1# zoneadm -z <zonemame> attach

My use case is based upon the notion that I want each zone to be able
to move independently, and as such a zpool is created per-zone.
Certainly there are other strategies that could be applied (move many
zones at once, use zfs send | something | zfs receive, AVS, etc.).

Mike Gerdts
zones-discuss mailing list

Reply via email to