[zones-discuss] need input for zone update on attach
During testing of the zone update on attach feature we have encountered a problem with IDRs on S10. If you are not familiar with an IDR, it is a temporary, one-time patch that is issued to try to solve a problem before an official patch is released. Because these are temporary, one-time patches, there is no metadata in official patches to tell us if the IDR is obsoleted or not. Because we don't know if the IDR is obsoleted by some other patch, update on attach will require that any IDRs installed on the source system must also be installed on the target system. If you have a zone that you are migrating because of a disaster recovery situation where the original system is no longer available, and the original system had an IDR installed that is not on the target (e.g. s10u4 with IDR to S10u6 where IDR is not needed), then there is no way to migrate the zone and update it to match the target if the IDR does not apply to the target system. If the original system is still available, you can work around this by removing the IDR before migrating the zone. I have a few different ideas for how to handle this. 1) change the meaning of attach -u -F Right now -F just forces the attach, changes the zone state to installed and we're done. No update occurs. We could change the interaction of these two options so that we still do the update but ignore any verification warnings. However this would allow a potentially major downgrade. 2) attach -u -p xxx -p yyy Add a new -p option which allows you to specify patches to ignore. We would use this to specify IDRs which don't exist on the target, although it could also be used for regular patches that might be broken. The user would have to understand this at a pretty good level to know when to use the option. We might want to extend this idea to specify pkgs as well, in case we have a broken pkg. This allows a potentially major downgrade if the user specifies a lot of patches. 3) attach -u -i Add a new -i option which means ignore all IDRs. This is pretty specific to the IDR issue, doesn't require a lot of thought for the user, but doesn't give much flexibility if we hit a different problem with bad patches or pkgs. This forces the user to think about the impact of ignoring the IDRs before an update is done. 4) attach -u No change to the CLI but change the implementation to always ignore all missing IDRs. This might still allow a pretty big downgrade with no user input if you had a lot of IDRs on the source system for some reason. This is pretty specific to the IDR issue, doesn't require any thought for the user, but doesn't give much flexibility if we hit a different problem with bad patches or pkgs. Let me know what you think about these choices or if there is another idea that seems better. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Will Zones Memory Caps let you specify more than physically installed system memory?
On Tue, Jun 17, 2008 at 8:07 PM, Jim Nissen [EMAIL PROTECTED] wrote: Hi all, Got a question from a customer, and can't seem to find an answer. Let's say they have multiple zones, and are specifying physical memory caps on all of them. If they have, say, 16GB of memory, is there anything that will prevent them from telling each zone to use physical memory caps over this amount? For instance, say they have five zones, and have 4GB phys memory caps on all of them. Will zonecfg check to see that they only have 16GB of memory installed, and prevent the last zonecfg from using 4GB? Doesn't that imply that all zones will be running at all times? I would imagine there are so many scenarios between DR, fault management automatically offlining DIMMs, etc. that would make such a thing more complicated than it might first appear (though this is just all speculation on my part). What I would expect is that if a zone has a cap more than what's available, that it would error out (i.e. in your scenario, the last zone to boot would fail). ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Will exclusive IP allow for TCP /etc/system settings?
Will Solaris 10 Zones, with exclusive IP, allow one to set NGZ TCP tunables, like tcp_conn_req_max_q? ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] need input for zone update on attach
On Tue, Jun 17, 2008 at 4:46 PM, Jerry Jelinek [EMAIL PROTECTED] wrote: If the original system is still available, you can work around this by removing the IDR before migrating the zone. Is it feasible to simply remove it as part of attaching? I don't think that it is possible to install an IDR with patchadd -d and a spot check of a zone that has an IDR (installed in global zone before non-global zone creation) shows that there is a package datastream file at /var/sadm/pkg/$pkg/save/$idr/undo in the non-global zone. I have a few different ideas for how to handle this. 1) change the meaning of attach -u -F Right now -F just forces the attach, changes the zone state to installed and we're done. No update occurs. We could change the interaction of these two options so that we still do the update but ignore any verification warnings. However this would allow a potentially major downgrade. This would be my third choice, but wouldn't be too excited about it. If this is done there needs to be clear warning or error messages in log files under the newly attached zone's /var/sadm directory. 2) attach -u -p xxx -p yyy Add a new -p option which allows you to specify patches to ignore. We would use this to specify IDRs which don't exist on the target, although it could also be used for regular patches that might be broken. The user would have to understand this at a pretty good level to know when to use the option. We might want to extend this idea to specify pkgs as well, in case we have a broken pkg. This allows a potentially major downgrade if the user specifies a lot of patches. If it is not possible to back out the missing IDR, then this would be my second choice. 3) attach -u -i Add a new -i option which means ignore all IDRs. This is pretty specific to the IDR issue, doesn't require a lot of thought for the user, but doesn't give much flexibility if we hit a different problem with bad patches or pkgs. This forces the user to think about the impact of ignoring the IDRs before an update is done. 4) attach -u No change to the CLI but change the implementation to always ignore all missing IDRs. This might still allow a pretty big downgrade with no user input if you had a lot of IDRs on the source system for some reason. This is pretty specific to the IDR issue, doesn't require any thought for the user, but doesn't give much flexibility if we hit a different problem with bad patches or pkgs. Let me know what you think about these choices or if there is another idea that seems better. I really hope it could just be backed out. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
