Details of latest test (mltstore0 and mltproc1 are both nodes in the cluster -
you can see by the fact that the resource group is on mltstore0, that switching
works sometimes!):
--- START of SESSION COPY ---
root at mltstore0:~# /usr/cluster/bin/clresourcegroup status common_shares
=== Cluster Resource Groups ===
Group Name Node Name Suspended Status
---------- --------- --------- ------
common_shares mltproc0 No Offline
mltproc1 No Offline
mltstore1 No Offline
mltstore0 No Online
root at mltstore0:~# /usr/cluster/bin/clrg switch -n mltstore1 common_shares
clrg: (C969069) Request failed because resource group common_shares is in
ERROR_STOP_FAILED state and requires operator attention
root at mltstore0:~# /usr/cluster/bin/clresourcegroup status common_shares
=== Cluster Resource Groups ===
Group Name Node Name Suspended Status
---------- --------- --------- ------
common_shares mltproc0 No Offline
mltproc1 No Offline
mltstore1 No Offline
mltstore0 No Error--stop failed
root at mltstore0:~# /usr/cluster/bin/clresource status common_zpool
=== Cluster Resources ===
Resource Name Node Name State Status Message
------------- --------- ----- --------------
common_zpool mltproc0 Offline Offline
mltproc1 Offline Offline
mltstore1 Offline Offline
mltstore0 Stop failed Faulted
root at mltstore0:~# zpool export common_pool0
root at mltstore0:~# zpool list common_pool0
cannot open 'common_pool0': no such pool
--- END of SESSION COPY ---
The log /var/adm/messages shows materially the same entries. So after failing
to switch via clrg, I did just a regular zpool export, not a forced export, and
had no errors. Having exported common_pool0 manually, I was then able to to
'clrg switch -n mltstore1 common_shares' without incident, and in fact could
switch back to mltstore0 w/o a problem. Is there something I can add to a
script somewhere to detail what files are open on the pool just prior to the
hastorageplus_postnet_stop trying to do the 'umount
/common_pool0/common_zone/root'?
Also, when switched back to mltstore0... I did the following to confirm that
the exact path /common_pool0/common_zone/root' was actually a mount point - is
there some issue around the fact that zfs list shows the mountpoint as
'legacy', not the actual path?:
root at mltstore0:~# zfs list | grep common_zone
common_pool0/common_zone 1.24G 725M 27.5K
/common_pool0/common_zone
common_pool0/common_zone/ROOT 1.24G 725M 19K legacy
common_pool0/common_zone/ROOT/zbe 1.24G 725M 1.24G legacy
root at mltstore0:~# df /common_pool0/common_zone/root
Filesystem 1K-blocks Used Available Use% Mounted on
common_pool0/common_zone/ROOT/zbe
2047217 1305119 742099 64%
/common_pool0/common_zone/root
--
This message posted from opensolaris.org
