Re: [zones-discuss] S10 brand spec.
As I've mentioned in the past to Dan, it's worth noting that Crossbow is not the only project that has significant impact here -- e.g., Clearview UV and Clearview IPMP (among other projects) also made significant changes to both kernel and userland that are presumed to be in lockstep. I suspect you will be safe with shared-stack, but exclusive stack will pose some significant challenges, and in some cases you may find the path of least resistance is to use the S11 userland binaries inside the S10 zone. Using the S11 binaries might be what we wind up doing for this. We haven't started to investigate the exclusive stack yet, so we don't know all of the issues. We do already have a mechanism for running binaries from the global zone and we do use that in some other cases already. One concern might be around 3rd party S10 apps that want to do networking stuff directly. I'm not sure how common that would be or what, if anything, would not work. That should be pretty uncommon as the affected interfaces are unstable, undocumented, and undergoing fairly regular change. -- meem ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10 brand spec.
Part 2: solaris10 Brand The solaris10 brand is conceptually similar to the existing solaris8 and solaris9 brands and builds directly on the BrandZ infrastructure that was created to support the lx brand. Familiarity with BrandZ and the solaris8 and solaris9 brands is assumed. At this time the design and development of the brand is only supporting the shared stack [6] networking model in which the zone's network is managed by the global zone. The exclusive stack model is anticipated to require more complex solutions or emulation due to the introduction of Crossbow [7] into S.next. The exclusive stack issues will be resolved before commitment review. Jerry, As I've mentioned in the past to Dan, it's worth noting that Crossbow is not the only project that has significant impact here -- e.g., Clearview UV and Clearview IPMP (among other projects) also made significant changes to both kernel and userland that are presumed to be in lockstep. I suspect you will be safe with shared-stack, but exclusive stack will pose some significant challenges, and in some cases you may find the path of least resistance is to use the S11 userland binaries inside the S10 zone. -- meem ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10 brand spec.
Hi Jerry, This document provides a lot of useful information. The section solaris10 Brand: What's Not Emulated you repeat some old information that is no longer correct. One point to note is that TX will continue to be incompatible with branded zones. That statement probably dates to the time when the lx brand was the only branded zone other than native. Solaris Trusted Extensions (TX) does not support lx and so it was correct at that time to state that TX does not support branded zones. The BrandZ framework now supports multiple kinds of zones, including the native brand zone. The BrandZ framework provides a powerful mechanism for tailoring the behavior of a zone. The Sun Cluster organization has taken the native brand zone and used the BrandZ framework to add callbacks for notifying Sun Cluster software about various zone changes. This cluster brand zone is a branded zone, but is really a native zone with cluster hooks. Our goal is make this cluster brand zone behave as much as possible just like the native brand zone. We have recently been successful in getting Sun Cluster to work with TX using the cluster brand zone. The Zone Cluster provides a cluster-wide security container. :) So please revise your statement about TX not being able to work with zones other than the native zone. Please note that this is a very recent development. The Sun Cluster organization has not announced support for this as a product offering. Here is the usual disclaimer that an engineering milestone is not the same as a product announcement. In the past, there have been bugs where code was written that assumed that only a native zone supported various options. Please assume that both native and cluster brand zones need the same support. The Sun Cluster organization is considering supporting Zone Clusters composed of non-global zones based upon the solaris10 container for Solaris.Next. This will probably require a cluster+solaris10 composite brand zone. We recognize that the Sun Cluster organization would have to create this composite zone. However, we do request that the design for the solaris10 zone make it possible for the Sun Cluster organization to create such a composite zone by reusing all or almost all solaris10 brand features. We would also be interested in reusing the p2v and v2v features. TX on Solaris.Next will use a branded zone (according to the latest information that I have heard). The Sun Cluster organization will be interested in supporting a composite cluster+TX brand zone. The net result is that we recommend that the Solaris Zones team consider how zone features would be reused by the previously mentioned composite branded zones. Regards, Ellard On 05/12/09 04:28, Jerry Jelinek wrote: Enclosed is a first draft of a spec. for the S10 brand which we plan to submit for a PSARC inception review. Please send us any comments or questions. Thanks, Jerry --- S10C: A Solaris 10 Branded Zone for Solaris.Next Gerald Jelinek, Jordan Vaughan Solaris Virtualization Technologies [A note on terminology: This document uses the terms Solaris 10 and Solaris.Next very frequently. As such, the abbreviations S10 and S.next respectively are used interchangeably with the longer forms. The term virtualization is abbreviated as V12N.] Part 1: Introduction Each new minor release of Solaris brings with it the well known problems of slow user adoption, slow ISV support and concerns about compatibility. The compatibility concerns will be more pronounced with the release of S.next since it's anticipated that there will be greater than normal user-visible changes (e.g. the packaging system, etc.). Fortunately, since the last minor release of Solaris (Solaris 10), V12N techniques have become widespread and V12N can be used as a solution to ease the transition to the new version of Solaris. Zones[1] combined with a brand[2] are particularly well suited for this task since the host system is actually running S.next, whereas this is not necessarily the case with other V12N solutions. In addition, zones are usable on any system which runs S.next, which is also not the case with other V12N alternatives. We already have a proven track record delivering this sort of zones/brand based solution to enable running earlier versions of Solaris on S10 [3, 4], so in one sense this case breaks little new ground. However, the earlier 'solaris8' and 'solaris9' brands were used to host releases that are very static as compared to hosting a zone running S10. In addition, S.next can be expected to continue to change rapidly for the forseeable future. Given this, a 'solaris10' brand for S.next poses additional challenges for projects on both the S10 and S.next sides of the system. Many of these challenges are outside of the scope of an architectural review and include developer education, testing and
Re: [zones-discuss] S10 brand spec.
Ellard Roush wrote: Hi Jerry, This document provides a lot of useful information. The section solaris10 Brand: What's Not Emulated you repeat some old information that is no longer correct. One point to note is that TX will continue to be incompatible with branded zones. That statement probably dates to the time when the lx brand was the only branded zone other than native. Solaris Trusted Extensions (TX) does not support lx and so it was correct at that time to state that TX does not support branded zones. The BrandZ framework now supports multiple kinds of zones, including the native brand zone. The BrandZ framework provides a powerful mechanism for tailoring the behavior of a zone. The Sun Cluster organization has taken the native brand zone and used the BrandZ framework to add callbacks for notifying Sun Cluster software about various zone changes. This cluster brand zone is a branded zone, but is really a native zone with cluster hooks. Our goal is make this cluster brand zone behave as much as possible just like the native brand zone. We have recently been successful in getting Sun Cluster to work with TX using the cluster brand zone. The Zone Cluster provides a cluster-wide security container. :) So please revise your statement about TX not being able to work with zones other than the native zone. Ellard, TX is incompatible with branded zones which actually implement emulation with a brand module. The cluster brand and the labeled brand do not do this, so since those brands only use the simple user-level hooks, they can co-exist. Brands such as lx, solaris8, solaris9 or solaris10 which need emulation support within the kernel cannot co-exist with TX. See the brand_register_zone() function in usr/src/uts/common/os/brand.c. I'll add some text to clarify this. Thanks for looking it over, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] S10 brand spec.
Enclosed is a first draft of a spec. for the S10 brand which we plan to submit for a PSARC inception review. Please send us any comments or questions. Thanks, Jerry --- S10C: A Solaris 10 Branded Zone for Solaris.Next Gerald Jelinek, Jordan Vaughan Solaris Virtualization Technologies [A note on terminology: This document uses the terms Solaris 10 and Solaris.Next very frequently. As such, the abbreviations S10 and S.next respectively are used interchangeably with the longer forms. The term virtualization is abbreviated as V12N.] Part 1: Introduction Each new minor release of Solaris brings with it the well known problems of slow user adoption, slow ISV support and concerns about compatibility. The compatibility concerns will be more pronounced with the release of S.next since it's anticipated that there will be greater than normal user-visible changes (e.g. the packaging system, etc.). Fortunately, since the last minor release of Solaris (Solaris 10), V12N techniques have become widespread and V12N can be used as a solution to ease the transition to the new version of Solaris. Zones[1] combined with a brand[2] are particularly well suited for this task since the host system is actually running S.next, whereas this is not necessarily the case with other V12N solutions. In addition, zones are usable on any system which runs S.next, which is also not the case with other V12N alternatives. We already have a proven track record delivering this sort of zones/brand based solution to enable running earlier versions of Solaris on S10 [3, 4], so in one sense this case breaks little new ground. However, the earlier 'solaris8' and 'solaris9' brands were used to host releases that are very static as compared to hosting a zone running S10. In addition, S.next can be expected to continue to change rapidly for the forseeable future. Given this, a 'solaris10' brand for S.next poses additional challenges for projects on both the S10 and S.next sides of the system. Many of these challenges are outside of the scope of an architectural review and include developer education, testing and procedural changes. However, the existence of this brand could potentially impact future projects in various ways and at a minimum will require ARC consideration for future reviews. The existence of this brand can be seen as a potential tax on all projects which work on both sides of the user/kernel boundary for both S10 and S.next. The benefits of the brand are as follows: For customers: - Provides a solution to cope with compatibility differences between S10 and S.next - Protects investment in S10 infrastructure, training, and internal support - Minimize the cost of consolidating Solaris 10 systems - Enables deployment of new technologies in S.next (e.g., crossbow) while still running applications on S10, thereby limiting risk to production environment - Avoids or delays required application recertification For Sun: - S.next is adopted sooner - Provide a Solaris compatibility environment for S.next - Sun is a solution provider easing the burden of getting to S.next - Provide cross-platform virtualization solution for S.next across all hardware (it is the only V12N solution on M-Series) This has been identified as a required feature for S.next. === Project Overview === As with the earlier 'solaris8' and 'solaris9' brands, this project delivers the following: - A Branded Container which emulates Solaris 10's user environment, based on the BrandZ infrastructure provided with zones. This brand is called 'solaris10'. Only Solaris 10u8 and beyond will be supported and tested in the zone. - A mechanism for archiving existing Solaris 10 systems and for redeploying those archives into the branded zone. This process is referred to as p2v and uses the same techniques as the 'solaris8' and 'solaris9' brands. In addition, the following additional capabilities will be provided as compared to the 'solaris8' and 'solaris9' brands. - This brand will be supported on all hardware architectures that run S.next (sun4v, sun4u and x86). The specific platforms, particularly sun4u, will be the same as are certified for S.next. - A virtual to virtual or v2v mechanism for archiving existing Solaris 10 native zones and for redeploying those archives into the branded zone on S.next will be provided. The process will be very similar to the existing zone migration [5] feature except that the zone's brand will be changed as part of the process. In addition, if the zone is sparse on S10 it must be converted to a whole-root zone during the migration. Part 2: solaris10 Brand The solaris10 brand is conceptually similar to the existing solaris8 and solaris9 brands and builds
Re: [zones-discuss] S10 brand spec.
On 05/12/09 13:28, Jerry Jelinek wrote: Enclosed is a first draft of a spec. for the S10 brand which we plan to submit for a PSARC inception review. Please send us any comments or questions. Thanks, Jerry Hi Jerry, Cool stuff! A couple of questions: - it is stated that the minimum supported S10 release in a branded container is S10U8. What is the plan for migrating from S10 releases below U8? Will the update on attach feature be able to update pre-U8 systems and/or zones? Or should the source system/zones be upgraded to U8 first? - can multiple versions of the Solaris 10 brand coexist? I.e if a future Solaris 10 version requires a newer version of the brand to run, will existing zones running an earlier Solaris version still run with their current required version of the brand? Or must they be upgraded in some way? Cheers, Menno -- Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10 brand spec.
Hi! Will there be an adoption toolkit, to let the people use the S10 brand while testing it, and starting the migration process? Thanks a lot, and best regards, HeCSa. On Tue, May 12, 2009 at 8:28 AM, Jerry Jelinek gerald.jeli...@sun.comwrote: Enclosed is a first draft of a spec. for the S10 brand which we plan to submit for a PSARC inception review. Please send us any comments or questions. Thanks, Jerry --- S10C: A Solaris 10 Branded Zone for Solaris.Next Gerald Jelinek, Jordan Vaughan Solaris Virtualization Technologies [A note on terminology: This document uses the terms Solaris 10 and Solaris.Next very frequently. As such, the abbreviations S10 and S.next respectively are used interchangeably with the longer forms. The term virtualization is abbreviated as V12N.] Part 1: Introduction Each new minor release of Solaris brings with it the well known problems of slow user adoption, slow ISV support and concerns about compatibility. The compatibility concerns will be more pronounced with the release of S.next since it's anticipated that there will be greater than normal user-visible changes (e.g. the packaging system, etc.). Fortunately, since the last minor release of Solaris (Solaris 10), V12N techniques have become widespread and V12N can be used as a solution to ease the transition to the new version of Solaris. Zones[1] combined with a brand[2] are particularly well suited for this task since the host system is actually running S.next, whereas this is not necessarily the case with other V12N solutions. In addition, zones are usable on any system which runs S.next, which is also not the case with other V12N alternatives. We already have a proven track record delivering this sort of zones/brand based solution to enable running earlier versions of Solaris on S10 [3, 4], so in one sense this case breaks little new ground. However, the earlier 'solaris8' and 'solaris9' brands were used to host releases that are very static as compared to hosting a zone running S10. In addition, S.next can be expected to continue to change rapidly for the forseeable future. Given this, a 'solaris10' brand for S.next poses additional challenges for projects on both the S10 and S.next sides of the system. Many of these challenges are outside of the scope of an architectural review and include developer education, testing and procedural changes. However, the existence of this brand could potentially impact future projects in various ways and at a minimum will require ARC consideration for future reviews. The existence of this brand can be seen as a potential tax on all projects which work on both sides of the user/kernel boundary for both S10 and S.next. The benefits of the brand are as follows: For customers: - Provides a solution to cope with compatibility differences between S10 and S.next - Protects investment in S10 infrastructure, training, and internal support - Minimize the cost of consolidating Solaris 10 systems - Enables deployment of new technologies in S.next (e.g., crossbow) while still running applications on S10, thereby limiting risk to production environment - Avoids or delays required application recertification For Sun: - S.next is adopted sooner - Provide a Solaris compatibility environment for S.next - Sun is a solution provider easing the burden of getting to S.next - Provide cross-platform virtualization solution for S.next across all hardware (it is the only V12N solution on M-Series) This has been identified as a required feature for S.next. === Project Overview === As with the earlier 'solaris8' and 'solaris9' brands, this project delivers the following: - A Branded Container which emulates Solaris 10's user environment, based on the BrandZ infrastructure provided with zones. This brand is called 'solaris10'. Only Solaris 10u8 and beyond will be supported and tested in the zone. - A mechanism for archiving existing Solaris 10 systems and for redeploying those archives into the branded zone. This process is referred to as p2v and uses the same techniques as the 'solaris8' and 'solaris9' brands. In addition, the following additional capabilities will be provided as compared to the 'solaris8' and 'solaris9' brands. - This brand will be supported on all hardware architectures that run S.next (sun4v, sun4u and x86). The specific platforms, particularly sun4u, will be the same as are certified for S.next. - A virtual to virtual or v2v mechanism for archiving existing Solaris 10 native zones and for redeploying those archives into the branded zone on S.next will be provided. The process will be very similar to the existing zone migration [5] feature except that the zone's brand will be changed as part
Re: [zones-discuss] S10 brand spec.
Hernan Saltiel wrote: Hi! Will there be an adoption toolkit, to let the people use the S10 brand while testing it, and starting the migration process? I'm not sure I understand the question. Are you asking if the source code will be available before S.next is released? If so, then yes, we're running this as an open project and our plan is to get the current code that is under development posted on the project page within the next month or so. We have to finish an internal process review first, before we can open the code we've already written. After the code is posted, we'll be keeping it updated as we work on it. Once the code is available, you'll be able to build it and use the brand on OpenSolaris to try it out. If I misunderstood your question, please let me know. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10 brand spec.
No, I'm talking about the Solaris migration toolkit, available in the past to certify pre-Solaris 10 binaries against the new versions. They were a couple of Perl scripts (solcat, for example). They were a binary interface certification set of scripts. They were a good point to start thinking in a migration. Best regards, HeCSa. On Tue, May 12, 2009 at 9:26 AM, Jerry Jelinek gerald.jeli...@sun.comwrote: Hernan Saltiel wrote: Hi! Will there be an adoption toolkit, to let the people use the S10 brand while testing it, and starting the migration process? I'm not sure I understand the question. Are you asking if the source code will be available before S.next is released? If so, then yes, we're running this as an open project and our plan is to get the current code that is under development posted on the project page within the next month or so. We have to finish an internal process review first, before we can open the code we've already written. After the code is posted, we'll be keeping it updated as we work on it. Once the code is available, you'll be able to build it and use the brand on OpenSolaris to try it out. If I misunderstood your question, please let me know. Thanks, Jerry -- HeCSa ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10 brand spec.
On 05/12/09 14:20, Jerry Jelinek wrote: It wouldn't really be multiple versions of the brand. The idea is that any enhancements to the brand module will need to continue to support all versions of S10 that are supported in the zone (i.e. S10u8 and beyond). So, there may be conditional code in the brand module to determine which KU is installed in a specific zone so that the emulation would behave differently based on that. Thats what we're trying to describe in the 'versioning' section of the spec. If that seems confusing we can try to clarify it. Thanks, that clears it up. Adding some text at the start of the Versioning section that newer versions of the brand will provide compatibility for older versions of the brand would help I think. Menno -- Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10 brand spec.
Hernan Saltiel wrote: No, I'm talking about the Solaris migration toolkit, available in the past to certify pre-Solaris 10 binaries against the new versions. They were a couple of Perl scripts (solcat, for example). They were a binary interface certification set of scripts. They were a good point to start thinking in a migration. Thanks for the clarification. We are planning to build a tool which we're calling the 'preflight checker'. The idea is that you could use the tool on your S10 system and it would evaluate things to tell you what issues it sees that might have an impact on moving that system image into a solaris10 branded zone on S.next. The preflight checker isn't part of this initial project proposal but would be a small add-on project coming later. The tool might do some level of binary analysis but it would also look at other aspects of the system configuration as a whole. For example, it would check if you have zones, add-on kernel modules, etc. We haven't started to scope this tool out yet. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10 brand spec.
Menno Lageman wrote: Thanks, that clears it up. Adding some text at the start of the Versioning section that newer versions of the brand will provide compatibility for older versions of the brand would help I think. Thanks, I'll add that clarification. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10 brand spec.
On Tue, May 12, 2009 at 6:28 AM, Jerry Jelinek gerald.jeli...@sun.com wrote: [snip] Zones have been part of S10 since its FCS, so in general S10 is already zone-aware and does the right thing in most cases. Commands that are zone-aware will continue to work as they do today in S10 native zones. One set of commands which does require emulation are the S10 SVr4 packaging and patch commands. Those commands are zone-aware and in some cases will check if they are running in the global zone and refuse to function if not. If running in the global zone they will also attempt to look for other zones to operate on. Any thoughts on supporting live upgrade? That is, I would like live upgrade within the branded zone to work as it does for a S10 global zone. I don't care about it from the upgrade standpoint, but it is a very helpful tool for patching. Having a zfs zonepath is an acceptable prerequisite. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10 brand spec.
Jerry, I am not sure if that was described in the proposal. Would it be possible to run s10 brands ontop of future s10 global zones ? -Ursprüngliche Nachricht- Von: Jerry Jelinek gerald.jeli...@sun.com Gesendet: 12.5.'09, 13:28 Enclosed is a first draft of a spec. for the S10 brand which we plan to submit for a PSARC inception review. Please send us any comments or questions. Thanks, Jerry --- S10C: A Solaris 10 Branded Zone for Solaris.Next Gerald Jelinek, Jordan Vaughan Solaris Virtualization Technologies [A note on terminology: This document uses the terms Solaris 10 and Solaris.Next very frequently. As such, the abbreviations S10 and S.next respectively are used interchangeably with the longer forms. The term virtualization is abbreviated as V12N.] Part 1: Introduction Each new minor release of Solaris brings with it the well known problems of slow user adoption, slow ISV support and concerns about compatibility. The compatibility concerns will be more pronounced with the release of S.next since it's anticipated that there will be greater than normal user-visible changes (e.g. the packaging system, etc.). Fortunately, since the last minor release of Solaris (Solaris 10), V12N techniques have become widespread and V12N can be used as a solution to ease the transition to the new version of Solaris. Zones[1] combined with a brand[2] are particularly well suited for this task since the host system is actually running S.next, whereas this is not necessarily the case with other V12N solutions. In addition, zones are usable on any system which runs S.next, which is also not the case with other V12N alternatives. We already have a proven track record delivering this sort of zones/brand based solution to enable running earlier versions of Solaris on S10 [3, 4], so in one sense this case breaks little new ground. However, the earlier 'solaris8' and 'solaris9' brands were used to host releases that are very static as compared to hosting a zone running S10. In addition, S.next can be expected to continue to change rapidly for the forseeable future. Given this, a 'solaris10' brand for S.next poses additional challenges for projects on both the S10 and S.next sides of the system. Many of these challenges are outside of the scope of an architectural review and include developer education, testing and procedural changes. However, the existence of this brand could potentially impact future projects in various ways and at a minimum will require ARC consideration for future reviews. The existence of this brand can be seen as a potential tax on all projects which work on both sides of the user/kernel boundary for both S10 and S.next. The benefits of the brand are as follows: For customers: - Provides a solution to cope with compatibility differences between S10 and S.next - Protects investment in S10 infrastructure, training, and internal support - Minimize the cost of consolidating Solaris 10 systems - Enables deployment of new technologies in S.next (e.g., crossbow) while still running applications on S10, thereby limiting risk to production environment - Avoids or delays required application recertification For Sun: - S.next is adopted sooner - Provide a Solaris compatibility environment for S.next - Sun is a solution provider easing the burden of getting to S.next - Provide cross-platform virtualization solution for S.next across all hardware (it is the only V12N solution on M-Series) This has been identified as a required feature for S.next. === Project Overview === As with the earlier 'solaris8' and 'solaris9' brands, this project delivers the following: - A Branded Container which emulates Solaris 10's user environment, based on the BrandZ infrastructure provided with zones. This brand is called 'solaris10'. Only Solaris 10u8 and beyond will be supported and tested in the zone. - A mechanism for archiving existing Solaris 10 systems and for redeploying those archives into the branded zone. This process is referred to as p2v and uses the same techniques as the 'solaris8' and 'solaris9' brands. In addition, the following additional capabilities will be provided as compared to the 'solaris8' and 'solaris9' brands. - This brand will be supported on all hardware architectures that run S.next (sun4v, sun4u and x86). The specific platforms, particularly sun4u, will be the same as are certified for S.next. - A virtual to virtual or v2v mechanism for archiving existing Solaris 10 native zones and for redeploying those archives into the branded zone on S.next will be provided. The process will be very similar to the existing zone migration [5]
Re: [zones-discuss] S10 brand spec.
Mike Gerdts wrote: Any thoughts on supporting live upgrade? That is, I would like live upgrade within the branded zone to work as it does for a S10 global zone. I don't care about it from the upgrade standpoint, but it is a very helpful tool for patching. Having a zfs zonepath is an acceptable prerequisite. Mike, We know that we need to come up with some sort of solution for being able to upgrade a solaris10-branded zone. We have this on our list of things to look at but we haven't started on that yet. I don't know if we'll try to make live-upgrade work inside a branded zone or if we'll try something else. Making live-upgrade work would probably be hard but until we get into it, we don't know how hard. It might be that we do something else since its already easy to clone a zone. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10 brand spec.
On Tue, May 12, 2009 at 8:02 AM, Jerry Jelinek gerald.jeli...@sun.com wrote: Mike Gerdts wrote: Any thoughts on supporting live upgrade? That is, I would like live upgrade within the branded zone to work as it does for a S10 global zone. I don't care about it from the upgrade standpoint, but it is a very helpful tool for patching. Having a zfs zonepath is an acceptable prerequisite. Mike, We know that we need to come up with some sort of solution for being able to upgrade a solaris10-branded zone. We have this on our list of things to look at but we haven't started on that yet. I don't know if we'll try to make live-upgrade work inside a branded zone or if we'll try something else. Making live-upgrade work would probably be hard but until we get into it, we don't know how hard. It might be that we do something else since its already easy to clone a zone. I suspect that making live upgrade work within a zone would be significantly easier if ZFS was a prerequisite. It looks as though the ipkg brand already has support for mounting the appropriate dataset on boot and attach. Delegated datasets can be snapshotted and cloned within the non-global zone. It seems as though the only missing bits (without having read the LU code) are: - Live Upgrade shouldn't try to read or update OBP through PICL or otherwise - The brand needs to trick live upgrade into thinking that it is in the global zone I don't care so much if Live Upgrade or something else is chosen, I just see the lack of a live upgrade work-alike as a potential blocker to adoption. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10 brand spec.
Mike Gerdts wrote: I suspect that making live upgrade work within a zone would be significantly easier if ZFS was a prerequisite. It looks as though the ipkg brand already has support for mounting the appropriate dataset on boot and attach. Delegated datasets can be snapshotted and cloned within the non-global zone. It seems as though the only missing bits (without having read the LU code) are: - Live Upgrade shouldn't try to read or update OBP through PICL or otherwise - The brand needs to trick live upgrade into thinking that it is in the global zone I don't care so much if Live Upgrade or something else is chosen, I just see the lack of a live upgrade work-alike as a potential blocker to adoption. Mike, Yes, we agree that some sort of upgrade solution is a requirement. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
