Last week I LU’d from snv_60 to snv_62. The LU stuff doesn’t seem to cope with zones that have their zoneroot on zfs. Still …..
One day it’s got to be fixed, surely.
Anyway…. I’ve got the global zone, my webzone and a punchin zone since I have two nge interfaces and can take advantage of the separate IP stack per zone feature which was integrated in build 57. All was working fine until I did the LU + rebuild-zone-from-scratch dance and tried to login to the non-global zones.
The automounter wasn’t mounting my home directory. Or my web directory. Or my sources ….. what the heck?!?!?
I was sharing the relevant directories from the global zone, and (for homedir and sources, ie /ws) using a bog-standard automount map to make them visible in the client zone. For my /ws/onnv-* directories, they were actually statically mounted under /opt/gate and /opt/hometools, then automounted via localhost:….. to the /ws path.
Prior to snv_62, this worked just fine. With 62, no dice. When I bleated about this in an internal irc channel, Dave Comay was kind enough to mention that (a) I shouldn’t be using my global zone as an nfs server for client zones (due to nfs, zfs and vm subsystems potentially kicking each other to the curb via 5065254 NFS/UFS deadlock when system is both NFS server and client), and (b) that I should be using lofs mounts in my zone config instead, then automounting those. By that time I’d logged 6547732 automountd zones out, and Dave pointed me to`6542696 automounter has problem accessing entries with indirect map in non-global zone`_.
This does work for me, though I still have an issue with being unable to bringover from my /ws source trees… need to gather a few spare cycles to figure out enough to log a bug on it…. just… too … busy!
So here’s what I was seeing:
On the zone console I logged in as root. After setting up the appropriate automount map entry for my homedir, I then tried to su - jmcp. What I saw was that the directory was mounted, but the automounter refused me permission to enter it or read any of its contents. If I manually/statically mounted that directory elsewhere (eg under /mnt), then I could cd into it, look at files etc etc and all was good.
The other behaviour that I saw was static mounts (ie, in /etc/vfstab) were not being mounted on boot as directed. However if I logged in on the zone console and ran mountall the directories mounted ok.
So, after shutting down my zones and a quick rtfm, I came up with the following sorts of additions to my zone config files:
<filesystem special="/scratch/zones/pieces_scratch" directory="/scratch" type="lofs">
<fsoption name="rw"/>
which you get like this:
# zonecfg -z pieces
zonecfg:pieces:fs> set special="/scratch/zones/pieces_scratch"
zonecfg:pieces:fs> set options="rw"
zonecfg:pieces:fs> set type="lofs"
zonecfg:pieces:fs> set dir="/scratch"
zonecfg:pieces:fs> end
zonecfg:pieces:fs> info
....
fs:
dir: /scratch
special: /scratch/zones/pieces_scratch
raw not specified
type: lofs
options: [rw]
Then a quick commit, end and zoneadm -z pieces reboot and you’re all set.
Incidentally, the feature which I think is the cause of my problem is the In-kernel sharetab integration …. which was backed out.
Technorati tags: topic:{Technorati}[Solaris Containers], topic:{Technorati}[NFSv4], topic:{Technorati}[automounter], topic:{Technorati}[Solaris], topic:{Technorati}[OpenSolaris], topic:{Technorati}[loopback mount, topic:{Technorati}[lofs]
