Three questions - migrating to branded zone

  1. i read that VxFS (3.x) installed on a solaris 8 will not work on a branded zone. fair enough, but what is the impact of having the packages installed when the flarcreate is done? will the container fail to boot with those packages installed?

  2. NTP client and server doesnt work on branded zone - does the container still get its time from the system clock?

1: Kernel modules are ignored in a non global zone.
2: It is possible to grant the right for a non global zone to handle NTP. There is no point in having more than one zone managing it as there is a single system clock shared by all zones.
3: Where is the third question ?

thanks for getting back to me, but i fear you missed my point. i am concerned about what will happen if i leave the packages installed after i migrate to the branded zone.

will the container work? will the fact that vfstab be looking for VxFS filesystems cause the container NOT to boot?

Before booting a Solaris 8 zone, you need to make sure all the mounts using vxfs (or ufs for that matter) are commented out in the zone /etc/vfstab.

do i have to do that before the flarcreate?

How would you ? Before running flarcreate, there is no zone to boot and no /etc/vfstab to check.

i have no idea what the process is yet. so i assume that i would change it via the global zone then?

Hi

Nothing will happen. You will get a few VX errors at boot, but that's all. I did the same as you, I made a flar dump of a solaris 8 server, using VxVm and put it into a zone. I have to give the install option of requiring a system id / ip change, but when it booted up, I noticed a few vxvm errors, regarding dump areas, etc etc, and the zone came online.

Or, one thing you could do, is once the dump has been put into the zone, via the global zone, cd down to the directories and remove the traces of vxvm. If you follow the steps you would do when you unencapsulate a root drive, i.e. remove the kernel /system options, alter the vfstab, and remove the database file, then this will stop more inital start up errors.

Ive created a number of branded zones, with flar archives, and its cool

SBK

didnt happen to document it did you? pm it to me? i'm doing the same thing, it'd be good to see if there was anything i missed.

the worst part of my migration is the fact that the solaris8 domains are clustered. i dont exactly know yet how i'm going that part is going to work.

Hi there.

I followed these steps ( ive just cut / pasted from my notes ). These are just a guide, so see them as a help, not an exect step by step senario.

Creating Branded Zones / containers in Solaris 10

 1. Download the Solaris 8 Containers software bundle from the Sun
           Download Center:
           http://www.sun.com/software/solaris/containers/getit.jsp

 2. Verify the software bundle checksum:
           # digest -a md5 s8containers-bundle-solaris10-sparc.tar.gz

           Compare this checksum to the checksum file on the product
           download webpage.

3. Unarchive and install 1.0.1 software package:
           # gunzip s8containers-bundle-solaris10-sparc.tar.gz
           # tar xf s8containers-bundle-solaris10-sparc.tar
           # cd s8containers-bundle/1.0.1/Product
           # pkgadd -d `pwd` SUNWs8brandk



4) Create Zone

# zonecfg -z svx-dwhousedb-1 -f  svx-dwhousedb-1.zonecfg           # create zone using stated conf file
# zonecfg -z svx-dwhousedb-1 verify                                # verify elements in conf file are create
# zoneadm list -icv                                                # list zones



# zoneadm -z zonename install -u -a /path/to/flash archive.flar

  -a   Location of archive from which to copy system image. Full flash archive and cpio, gzip compressed cpio, bzip compressed cpio, and level 0 ufsdump are supported. Refer to the gzip man page available in the SUNWsfman package.
  -d   Location of directory from which to copy system image. 
  -p   Preserve system identity. 
  -s   Install silently. 
  -u   sys-unconfig the zone.
  -v   Verbose output. 


N.b   Creating a flar dump command

# flarcreate -S -n nemesis-data -x /u03/oracle -x /u04/oracle -x /u06 -x /SBK/m5000 -c /SBK/m5000/nemesis-data.flar


# zoneadm -z svx-dwhousedb-1 ready                                  # Clears up temp files, prepares zone


5. Remove vertias startup database

# touch /location to zone within global zone/etc/vx/reconfig.d/state.d/install-db
# rm   /location to zone within global zone/etc/vx/reconfig.d/state.d/root-done

6. Remove /etc/system stuff - Ok I know that solaris 10 doesnt use it.

vi /location to zone within global zone/etc/system
# Only comment out the following entries
rootdev:/pseudo/vxio@0:0
set vxio:vol_rootdev_is_volume=1

7) Start Zone
																																																																																																																																																																																																																																																															
# zoneadm -z svx-dwhousedb-1 boot                                   # boots zone																																																																																																																																																																																																																									
# zlogin -C svx-dwhousedb-1                                         # console login to zone

SBK

that's good stuff there thanks!

Question though: the zoneadm "ready"; does it really clean up the archive?

also:

  1. Remove vertias startup database - is this effectively unencapsulating the old veritas managed root drive?

EDIT: it's part of it. the other two parts include:
i) remove the kernal/system options - any ideas on what they might be in this case?
ii) alter the vfstab - to remove veritas devices.

Hi there

Yes, you are basically removing all the traces of the veritas boot / root encapsulation. Im not sure the /etc/system file is really used in a zone, infact most of it will be ignored. When you install the flar copy, on boot it will mention that certain paramters in the system file are ignored, so you might find that most of the veritas components are already ignored, so these steps are for completeness.

Removing the veritas db and checking the vfstab is more to stop errors coming on script, via boot up.

When you've made the flar dump, you've obviously told it what mounts to included, e.g. u01 / u02 /u03, when constructing the zone, you made new mounts, named the same, but using storage allocated to it via the global zone, or directly mounted into the zone.

The underlying type of the source f/s is irelevant, so once the dump is extracted back into the zone, your away.

The errors at boot up are regarding vxdmps, databases, and vfstab rubbish, so by removing all these before you boot, will make a clearer startup.

I will test it out, created a test zone, pour the dump into it, and see. Good thing about zones, is that once you shut them down, you can alter them via the global zone, aka, just cd down to the area where the install is, and amend files.

SBK