I do not understand this as well the only possibilty is that the stop_timeout is excceded, but then the status of the sczbt resource must be stop_failed.
So we have to solve two questions: what is blocking the zfs umount? is the stop_timoutn exceeded? This must be reflected in /var/adm/messages of the node something like: "Function: stop_sczbt - Manual intervention needed for non-global zone". If the stop_timout is exceeded, I would try to raise it, just a try, but question one needs to be resolved first. Detlef Tundra Slosek wrote: >> Hi Tundra, >> >> The reasoning behind is that the root directory is a >> property of >> Solaris, and placing something in her might have some >> impact. It could >> have been, that the zoneadm halt tried to unmount the >> root fs without >> success, because the gds is sitting on it. >> > > As a recap - sometimes stop (no matter the source) works correctly, sometimes > it doesn't. When it doesn't, it is because zoneadm issues a zfs umount > against the root directory and that is still lingering when the underlying > zpool's hastorageplus tries to export the zpool. What I have noticed is that > when the timing is right (i.e. zfs umount completes first), then the zpool > export happens without the 'FORCE' flag set, but when the timing is wrong > (and zfs umount has not yet completed), then the 'FORCE' flag is set on the > zpool export (and it fails because the device is in use, and then immediately > after, the zfs umount completes). > > I do not understand why the hastorageplus begins it's 'stop' before the zone > is completely stopped - what seems to happen is that the zone stops, and then > issues zoneadm request to unmount the zonepath; however the gds returns to > the rgm with success before zoneadm is actually finished. > > >> Anyway silly question. you do have adependency >> between the sczbt >> resource and the HAStoragePlus resource? >> > > No question is silly. If I undestand the output of clrs here, then the > dependency is set. > > root at mltstore1:~# clrs show -v smb1_zone | grep smb1 > Resource: smb1_zone > Group: smb1_rg > Resource_dependencies: smb1_lhname smb1_zpool > Start_command: > /opt/SUNWsczone/sczbt/bin/start_sczbt -R smb1_zone -G smb1_rg -P > /smb1_pool0/parameters > Stop_command: > /opt/SUNWsczone/sczbt/bin/stop_sczbt -R smb1_zone -G smb1_rg -P > /smb1_pool0/parameters > Probe_command: > /opt/SUNWsczone/sczbt/bin/probe_sczbt -R smb1_zone -G smb1_rg -P > /smb1_pool0/parameters > Network_resources_used: smb1_lhname > > > >> Detlef >> >> Tundra Slosek wrote: >> >>>> Hi Tundra, >>>> >>>> One thing which you should never do is move the >>>> parameter directory into >>>> the root file system for the zone. this is what >>>> >> might >> >>>> cause the >>>> headache, because the sczbt resource accesses the >>>> parameter directory >>>> and calling zoneadm halt which tries to remove >>>> >> the >> >>> mount and this might >>> >>>> not work. >>>> >>>> I would suggest to move the parameters directory >>>> >> to: >> >>>> /smb1_pool0/parameters >>>> >>>> >>> I'm not sure I understand why a file open in >>> >> /smb1_pool0/smb1_zone/parameters/ would prevent zfs >> unmounting of /smb1_pool0/smb1_zone/root, however >> it's easy enough to test, I don't see any harm in the >> suggested change and I remain open to the possibility >> that there is something fundamental I'm >> misunderstanding. >> >>> Done, (created the directory above, copied the >>> >> existing contents of parameters and changed the clrs >> Start_command, Stop_command and Probe_command to >> point at /smb1_pool0/parameters instead of >> /smb1_pool0/smb1_zone/parameters) however the exact >> same behavior exists - i.e. overlap between zfs >> unmount of /smb1_pool0/smb1_zone/root and >> hastorageplus attempting to export the smb1_pool0 >> zpool. DTrace log available as per prior efforts, if >> anyone thinks it will be helpful, however it doesn't >> seem different to me. >> >>> >>> >> -- >> >> ****************************************************** >> *********************** >> Detlef Ulherr >> Staff Engineer Tel: (++49 6103) >> 752-248 >> Availability Engineering Fax: (++49 6103) 752-167 >> Sun Microsystems GmbH >> Amperestr. 6 >> mailto:detlef.ulherr at sun.com >> http://www.sun.de/ >> ****************************************************** >> ****** >> >> Sitz der Gesellschaft: >> Sun Microsystems GmbH, Sonnenallee 1, D-85551 >> Kirchheim-Heimstetten >> Amtsgericht M?nchen: HRB 161028 >> Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, >> Wolf Frenkel >> Vorsitzender des Aufsichtsrates: Martin H?ring >> >> ****************************************************** >> *********************** >> >> >> _______________________________________________ >> ha-clusters-discuss mailing list >> ha-clusters-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/ha-cluste >> rs-discuss >> -- ***************************************************************************** Detlef Ulherr Staff Engineer Tel: (++49 6103) 752-248 Availability Engineering Fax: (++49 6103) 752-167 Sun Microsystems GmbH Amperestr. 6 mailto:detlef.ulherr at sun.com 63225 Langen http://www.sun.de/ ***************************************************************************** Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin H?ring *****************************************************************************
