Re: [zones-discuss] Fwd: Live Upgrade and sparse root zones with their own /usr?
Thank you, I will try detaching and upgrading, that seems like a very useful feature. I'm going from u3 to u6 here. (although I guess I could go to u7 - I don't usually like to be an early adopter and u7 wasn't out when I started this process) . I've looked at the release notes, is there a more detailed list of bug fixes and changes in u7 available? ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Fwd: Live Upgrade and sparse root zones with their own /usr?
Hi I'm a bit late getting in on this thread, so basically each zone in /space will get duplicated, and the new zone will get upgraded, then in luactivate will get renamed, so say you have /space/zone1 lucreate will create a new zone /space/lu-zone1 ( can't remember what the exact name it uses is ) then luactivate of the new BE will rename lu-zone1 to zone1. I guess if space is a consideration? then assuming the upgrade was to u6 ( or better still u7 ), once could detach the zone prior to upgrade, then upgrade just the global zone, and do an zoneadm update on attach of the zones once the global zone has upgraded. NOTE: There are differences between standard upgrade and zone update on attach. Enda On 05/10/09 02:08, Elizabeth Schwartz wrote: Thanks! I still feel like I'm missing two vital pieces of the puzzle. First, for better or worse, the sparse zones were created with separate /usr dirs, using the command: zonecfg:zone_1> remove inherit-pkg-dir dir=/usr Also, I have four zones on one machine (and ten on another!) The four zones are sharing one physical partition, named /space. I don't have enough free partitions to make one for each zone, and Solaris 10 u3 doesn't allow for ZFS roots so I can't use my ZFS SAN partition (another reason to upgrade!) So do I understand correctly that if all my zones live on /space, If I do: lucreate -n newbe -m /space:/dev/dsk/whatver:/ufs liveupgrade will duplicate /space in the new BE and use it for all of the zones that live on /space? And just to complicate matters, on the test server, /space is a heck of a lot bigger than any other free partition. Would this work if I lived dangerously, allow my alternate boot environment to mount /space, and let it update the zones? Recognizing that if the ugrade fails, my zones are toast and I have no rollback (on this particular server, rebuilding the zones would be relatively easy) (I'm obviously going to learn a lot that I can use to redesign my next generation of servers, but meanwhile I'm trying to drag this group into this decade. And the irony is that, when this is all done, I'll have a server I can use as a *proper* test server. And double irony, I'll be at an OS release that'll let me use ZFS root file systems, but I'm not there yet...) thanks for your patience, this is all sort of an emergency because I've got a production server crashing and Sun is insisting that it needs an upgrade or bust - my original plan to do this over a 2-month period and spend lots of time with a test server, is toast. ___ zones-discuss mailing list zones-discuss@opensolaris.org -- Enda O'Connor x19781 Software Product Engineering Patch System Test : Ireland : x19781/353-1-8199718 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Fwd: Live Upgrade and sparse root zones with their own /usr?
Thanks! I still feel like I'm missing two vital pieces of the puzzle. First, for better or worse, the sparse zones were created with separate /usr dirs, using the command: zonecfg:zone_1> remove inherit-pkg-dir dir=/usr Also, I have four zones on one machine (and ten on another!) The four zones are sharing one physical partition, named /space. I don't have enough free partitions to make one for each zone, and Solaris 10 u3 doesn't allow for ZFS roots so I can't use my ZFS SAN partition (another reason to upgrade!) So do I understand correctly that if all my zones live on /space, If I do: lucreate -n newbe -m /space:/dev/dsk/whatver:/ufs liveupgrade will duplicate /space in the new BE and use it for all of the zones that live on /space? And just to complicate matters, on the test server, /space is a heck of a lot bigger than any other free partition. Would this work if I lived dangerously, allow my alternate boot environment to mount /space, and let it update the zones? Recognizing that if the ugrade fails, my zones are toast and I have no rollback (on this particular server, rebuilding the zones would be relatively easy) (I'm obviously going to learn a lot that I can use to redesign my next generation of servers, but meanwhile I'm trying to drag this group into this decade. And the irony is that, when this is all done, I'll have a server I can use as a *proper* test server. And double irony, I'll be at an OS release that'll let me use ZFS root file systems, but I'm not there yet...) thanks for your patience, this is all sort of an emergency because I've got a production server crashing and Sun is insisting that it needs an upgrade or bust - my original plan to do this over a 2-month period and spend lots of time with a test server, is toast. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Fwd: Live Upgrade and sparse root zones with their own /usr?
I have read that document but I do not see any discussion of how to handle sparse zones ; I am particularly concerned about the zones which have their own /usr . Will their /usr partitions be kept in sync and if so *HOW*? There are 2 parts to this question: sparse vs whole root and how live upgrade does it's thing. For inherit-pkg-dirs the packaging system knows that the directories are readonly. As such the actual update to those directories doesn't happen, but the packaging metadata in /var/sadm is properly updated. The inherit-pkg-dirs are actually updated when the patch/update is applied to the global zone, but the pkg metadata in each zone needs to be updated to reflect the new contents as well as any changes not in an inherit-pkg-dir (such as package scripts, local data, etc). This is the exact same thing that happens when zones are installed. The mechanism for whole root zones is very similar, which is why much of the documentation doesn't draw the distinction.For whole root zones the changes are actually made when the patch/update is applied to the zone. Live upgrade will mount the zones in the alternate boot environment when it needs to make changes (patchadd or pkgadd/pkgrm). What you will see it do is mount the alternate boot environment and make all of the updates to it. Then it will mount each non-global zone from the alternate boot environment and update each one individually. It really does work. Although to be honest I am chasing my tail on some ZFS zoneroots, but it's very likely that it is my fault. But if not, a bug report will be entered :-) Bob ___ zones-discuss mailing list zones-discuss@opensolaris.org
