zones p2v
About two years ago the zones team sat down and began to create the
solaris8 brand
for zones. This brand allows you to run your existing
Solaris 8 system images inside of a branded zone on Solaris 10. One
of the key goals for this project was to easily enable migration of Solaris 8
based systems into a zone on Solaris 10. To accomplish this, as part of the project we
built support for a "physical to virtual" capability, or p2v for short.
The idea with p2v is that you can create an image of an existing system
using a flash archive, cpio archive, a UFS dump, or even just a file system image
that is accessible over NFS, then install the zone using that image.
There is no explicit p2v tool you have to run; behind the scenes the zone installation process
does all of the work to make sure the Solaris 8 image runs correctly inside
of the zone.
Once we finished the solaris8 brand we followed that with the solaris9 brand which has this same p2v capability. Of course, while we were doing this work, we understood that having a similar feature for native zones would be useful as well. This would greatly simplify consolidation using zones, since you could deploy onto bare metal, then later consolidate that application stack into a zone with very little work.
The problem for p2v with native zones is that there is no brand module that mediates between the user-level code running in the zone and the kernel code, as we have with the solaris8 and solaris9 brands. Thus, the native zones must be running user-level code that is in sync with the kernel. This includes things like libc, which has a close relationship with the kernel. Every time a patch is applied which impacts both kernel code and user-level library code, all of the native zones must be kept in sync or unpredictable bugs will occur.
Just doing native p2v, as we did for the solaris8 and solaris9 brands, doesn't make sense since the odds that the system image you want to install in the zone will be exactly in sync with the kernel are pretty low. Most deployed systems are at different patch levels or even running different minor releases (e.g. Solaris 10 05/08 vs. 11/08), so there is no clean way to reliably p2v those images.
We really felt that native p2v was important, but we couldn't make any progress until we solved the problem of syncing up the system image to match the global zone. Fortunately I was able to find some time to add this capability, which we call update on attach. This was added into our zone migration subcommands, 'detach' and 'attach', which can be used to move zones from one system to another. Since zone migration has a similar problem as p2v, where the source and target systems can be out of sync, we do a lot of validation to make sure that the new host can properly run the zone. Of course this validation made zone migration pretty restrictive. Now that we have "update on attach", we can automatically update the zone software when you move it to the new host.
While "update on attach" is a valuable feature in its own right, we also built this with an eye on p2v, since it is the enabling capability needed for p2v. In addition, we leveraged all of the work Dan Price did on the installers for the solaris8 and solaris9 brands and were able to reuse much of that. As with the solaris8 and solaris9 brands, the native brand installer accepts a variety of image inputs; flar, cpio, compressed cpio, pax xustar, UFS dump or a directly accessible root image (e.g. over NFS). It was also enhanced to accept a pre-existing image in the zone root path. This is useful if you use ZFS send and receive to set up the zone root and want to then p2v that as a fully installed zone.
I integrated the native p2v feature into NV build 109 this morning. The webrev from the code review is still available if anyone is interested in seeing the scope of the changes. At over 2000 lines of new code this is a pretty substantial addition to zones which should greatly improve future zone consolidation projects.
Once we finished the solaris8 brand we followed that with the solaris9 brand which has this same p2v capability. Of course, while we were doing this work, we understood that having a similar feature for native zones would be useful as well. This would greatly simplify consolidation using zones, since you could deploy onto bare metal, then later consolidate that application stack into a zone with very little work.
The problem for p2v with native zones is that there is no brand module that mediates between the user-level code running in the zone and the kernel code, as we have with the solaris8 and solaris9 brands. Thus, the native zones must be running user-level code that is in sync with the kernel. This includes things like libc, which has a close relationship with the kernel. Every time a patch is applied which impacts both kernel code and user-level library code, all of the native zones must be kept in sync or unpredictable bugs will occur.
Just doing native p2v, as we did for the solaris8 and solaris9 brands, doesn't make sense since the odds that the system image you want to install in the zone will be exactly in sync with the kernel are pretty low. Most deployed systems are at different patch levels or even running different minor releases (e.g. Solaris 10 05/08 vs. 11/08), so there is no clean way to reliably p2v those images.
We really felt that native p2v was important, but we couldn't make any progress until we solved the problem of syncing up the system image to match the global zone. Fortunately I was able to find some time to add this capability, which we call update on attach. This was added into our zone migration subcommands, 'detach' and 'attach', which can be used to move zones from one system to another. Since zone migration has a similar problem as p2v, where the source and target systems can be out of sync, we do a lot of validation to make sure that the new host can properly run the zone. Of course this validation made zone migration pretty restrictive. Now that we have "update on attach", we can automatically update the zone software when you move it to the new host.
While "update on attach" is a valuable feature in its own right, we also built this with an eye on p2v, since it is the enabling capability needed for p2v. In addition, we leveraged all of the work Dan Price did on the installers for the solaris8 and solaris9 brands and were able to reuse much of that. As with the solaris8 and solaris9 brands, the native brand installer accepts a variety of image inputs; flar, cpio, compressed cpio, pax xustar, UFS dump or a directly accessible root image (e.g. over NFS). It was also enhanced to accept a pre-existing image in the zone root path. This is useful if you use ZFS send and receive to set up the zone root and want to then p2v that as a fully installed zone.
I integrated the native p2v feature into NV build 109 this morning. The webrev from the code review is still available if anyone is interested in seeing the scope of the changes. At over 2000 lines of new code this is a pretty substantial addition to zones which should greatly improve future zone consolidation projects.
Jerry, thank you for making native p2v possible -- that's very cool! I look forward to trying it.
Are you also considering a non-native Solaris 10 brand? This would make it possible to (for example) patch a 5.10 full-root non-global zone independently from the global zone.
I've heard that zone patch enhancements are coming (i.e. parallel patching of NGZ's), but another idea was to de-couple a 5.10 zone with the use of a non-native solaris10 brand, as with S8 and S9.
Now, if only certain app vendors would bother to support NGZ's, we could use them more frequently. It's all about supportability and licensing. Thanks for any info, and way to go on the native p2v.
-cheers, CSB
Posted by Craig S. Bell on February 11, 2009 at 10:08 AM PST #
Can we run the zones with zonepath on an NFS partition? (will OpenSolaris ever address that... through a good workaround or other?). I seem to recall there are some challenges for that... can you perhaps elaborate in another post?
Thanks
Posted by Anil on February 23, 2009 at 10:59 PM PST #
I installed snv_109 on my new computer. How should i use the upgrade on attach fonctionality to import / attach a zone coming from snv_104 ?
Posted by eric on March 17, 2009 at 02:26 AM PDT #
An informative post. Thank you !
Posted by Sriram Narayanan on May 02, 2009 at 10:23 PM PDT #