On Mon, Dec 8, 2008 at 9:43 AM, Jerry Jelinek <[EMAIL PROTECTED]> wrote: > SUMMARY: > > This fast-track enhances the Solaris Zones [1] subsystem to address an > existing RFE [2] requesting a "physical to virtual" (or p2v) capability > for installing native-branded zones based on an existing system image. > > This capability is very similar to what already exists for solaris8 and > solaris9 branded zones [3,4], which are installed using an archive of an > existing system image, but in this case there is no brand module and the > zone brand is 'native'. > > Patch binding is requested for this native p2v capability. The > stability of these interfaces is documented in the interface table below. > > DETAILS: > > This new feature is primarily an extension to the native-brand zone > installation code so that the zone can be installed using an archive of a > system, as is already done with the solaris8 and solaris9 brands. > However, because there is no brand module, part of the installation > process > uses the zone "update on attach" [5] feature to sync the zone image up > so that it is usable on the system. Because "update on attach" does not > allow zone downgrades, the system image being installed and p2v-ed must > not > be newer than the host OS release or the installation will fail with an > error. > > In addition to the "update on attach" during zone installation, there are > a variety of other modifications which must be applied to the image so > that > it is usable within a zone. Again, this is very similar to what happens > today with the solaris8 and solaris9 brands during installation. > > The image modifications fall into the following areas: > 1) SMF services that are not usable within a zone should be deleted or > disabled as necessary (for S8 and S9 we dealt with rc scripts instead).
This implies that the source system can be S8, S9, or S10. I don't see anywhere else in the proposal that explicitly states that S8 and S9 can be attached and upgraded, so I suspect I am reading my wishes into your words. Assuming the S8 and S9 are supported source systems, is there any real difference in the resulting zone if the following paths are taken: src-s9# lucreate -c s9 -n s10 ... src-s9# luupgrade -s /mnt/s10media -n s10 ... src-s9# luactivate s10 src-s10# flarcreate ... /net/server/src-10.flar dst-s10# zoneadm install -a /net/server/src-10.flar ... vs. (upgrade on attach - not branded) src-s9# flarcreate ... /net/server/src-9.flar dst-s10# zoneadm install -a /net/server/src-9.flar > 2) Network configuration must be adjusted depending on if the zone is > shared-stack or exclusive. > 3) NFS serving must be disabled [6]. > 4) The vfstab must be adjusted so that local file systems from the > original > system are disabled. > 5) Any zones installed on the original system will be uninstalled and > deleted from the image (zones do not nest). > > All of these modifications happen transparently as part of the zone > installation, as is the case with the solaris8 and solaris9 brands. Will config files be removed or will services just be disabled (and hollow packages removed)? That is, will "destructive" things be done that prevent the implementation of some future v2p (e.g. zone to ldom or xen) transition? Or is it believed that the typical packages that are not appropriate for non-global zones lack configuration that would be interesting in a p2v -> v2p world? -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
