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.

Post a Comment:
  • HTML Syntax: NOT allowed



Top Tags
« June 2016