[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
