work { solaris 10 + VCS 5.0 + solaris 9 branded zone, shared configuration

I had a problem where I needed to run a Solaris 9 image for an application group that required special permissions and a compiler. Since we have budget cuts and no where else to put them, I decided to use a Solaris 9 branded zone within our Solaris 10, shared zone (i.e. the zones failover from node to node) VCS cluster.

The installation and configuration of the zone worked, up to a point.
Switchover didn't work because branded zones, when migrated have to run a
physical:virtual mapping to be optimized for running on the node. I
tried various things to no avail, preonline triggers, custom scripts,
but none worked well or reliably or were just too unwieldy to implement, especially in the short deadline I had.

So I decided to modify the VCS Zone Agent.

NOTE: This probably invalidates your support with Symantec, so use at your own risk.

This procedure has to be done on all nodes. The agent is written in perl.

Steps:

1. make a backup of /opt/VRTSvcs/bin/Zone/online
2. Add following to /opt/VRTSvcs/bin/Zone/online

to the "# Zone specific commands" section:

my $SOL9P2V = "/usr/lib/brand/solaris9/s9_p2v";

change the following:

$cmd = "$ZONEADM -z $ZoneName boot";
`$cmd`;

to

# modified for use with Branded Solaris Zones - 1/29/2009
my $BrandedZone = `$ZONECFG -z $ZoneName info | $GREP brand`;
$cmd = "$ZONEADM -z $ZoneName boot";
if ($BrandedZone =~ m/brand: solaris9/i ) {
$cmd = "$SOL9P2V $ZoneName && $ZONEADM -z $ZoneName boot";
}
`$cmd`;

All the variables except for "$BrandedZone" and "SOL9P2V" are defined elsewhere within the agent.


What this little snippet does is check to see if the zone has a 'brand' defined, if it does it adds the part to run the P2V mapping command and boot the zone, otherwise it does what it would normally do (just boot the zone).

It does lengthen the boot time of the zone a little and the output of the command will look odd as the P2V command also tries to update any patches needed to run on the node (which is handled at branded zone creation time).

Running a shared zone is fairly easy to setup. You create the zone on one node, copy the appropriate .xml files from /etc/zones/ to the other nodes, add appropriate line to /etc/zones/index, make sure your mountpoints exist, define the resources into VCS and enjoy. This setup will let you have one zone that can float to multiple nodes.

Note the assumptions are that the networking and storage is setup properly.

Other things to note, Solaris branded zones cannot use the "inherit-pkg-dir" functionality. So this means you can't inherit /opt/VRTSvcs/bin, so some functionality will be different. However this did not seem to impact the running or viability of the zone for use.

tech/work { spoofing hostids in solaris 10 native zones

So at work we have an application suite that uses a licensing tool that is bound to specific hostids. This can pose a problem as in Solaris 10, the non-global zones inherit the hostid of the global (or source) zone, meaning you could only have one copy of this software running at a time, not cool if you want to leverage zones.

With the new Solaris 8 and 9 branded zones, you can embed a string in the XML config file like this:


add attr
set name=hostid
set type=string
set value=80001234
end


and it will reassign the hostid. This was put in place so you could pick up and move Solaris 8/9 install and move them to within a zone. Good idea, useful feature...only it doesn't work for native Solaris 10 zones. I didn't read the docs fully and was dismayed as I thought this was part of Solaris 10 Update 4. It isn't. I then went on a two day search for a solution. The first day was pursuing official SUN channels. This only resulted in a response that a RFE (request for enhancement) has been made and it will appear in an update of Solaris 10 in the future. Not good for my more immediate needs.

Day two was spent with the swiss army knife for sys admins, google. I really only spent two hours researching it but in that time I found a few things. One is that this is not a new need, people have been looking to do this since 2005 when Solaris 10 was released. Secondly there are some easy ways to do it and some less than ideal ways to do it. Eventually what helped me solved my problem was this post here (http://tinyurl.com/6fa63z). I tried the compile your own newhostid.so library and it worked, but I had problems with other shared libraries not working, mostly because of the LD_PRELOAD flag needs to have all your system libraries for proper functioning. That page also had a link to someone who put together a dtrace script that let you spoof host ids on the fly. He has a dtrace script called zhostid with the source found here (http://tinyurl.com/62wjq5). This was exactly what I was looking for as it let me add more zones to the list as I built more, could be start/stopped at anytime with seemingly minimal impact on the system. And it works fine in a clustered environment, which is where these zones are running. You just need to put this script into a start script for boot time in both nodes (or as many as you have). Now this is the part I don't like. I generally don't like using nohup for scripts, but for now it was the only way I can get this script to start and background and keep running. I'm researching putting this into SMF if I can.

For now I made a

/etc/init.d/zhostid

start script that just basically called this script and backgrounded via nohup. I then linked the script old school into rc3.d until (if I can) put it into SMF.


cd /etc/rc3.d ; ln -s /etc/init.d/zhostid S99zhostid


Some caveats.

First off this script isn't supported. Its meant for demonstration purposes and the author states this clearly in his comments in the script, and its released under GPL, so make sure to credit it properly if you make changes. SUN generally doesn't support host id spoofing, I guess with the exception of in branded zones, but they also at this time do not provide functionality to easily do this.

Secondly, you are modifying the running system and modifying a system call. Dangers are inherent with procedures like this. But I feel in this instance it is fairly safe and non-destructive. You just need to be aware this could cause some oddities if you're ever troubleshooting.

But it works. And seems to work well for the needs I had.

tech_support { Solaris 10 command to make managing HBAs easier

/usr/sbin/fcinfo hba-port

Fricking sweet! No more 'prtpicl' + 'grep' anymore. Thank you SUN.

Output looks like this:

# fcinfo hba-port
HBA Port WWN: 210000e08b1958a9
OS Device Name: /dev/cfg/c3
Manufacturer: QLogic Corp.
Model: 375-3102-xx
Firmware Version: 3.3.117
FCode/BIOS Version: ISP2300 Host Adapter Driver: 1.14.09 03/08/04
Type: N-port
State: online
Supported Speeds: 1Gb 2Gb
Current Speed: 2Gb
Node WWN: 200000e08b1958a9
HBA Port WWN: 210000e08b190fa9
OS Device Name: /dev/cfg/c2
Manufacturer: QLogic Corp.
Model: 375-3102-xx
Firmware Version: 3.3.117
FCode/BIOS Version: ISP2300 Host Adapter Driver: 1.14.09 03/08/04
Type: N-port
State: online
Supported Speeds: 1Gb 2Gb
Current Speed: 2Gb
Node WWN: 200000e08b190fa9