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 http://www.opensolaris.org/jive/thread.jspa?messageID=127152 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 http://mgerdts.blogspot.com/ _______________________________________________ zones-discuss mailing list email@example.com