zfs discuss - Dec 2008 - automatic forced zpool import with unmatched hostid

Hi,

since hostid is stored in the label, "zpool import" failed if the
hostid dind''t match. Under certain circonstances (ldom failover) it
means you have to manually force the zpool import while booting. With more than
80 LDOMs on a single host it will be great if  we could configure the machine
back to the old behavior where it didn''t failed, maybe with a
/etc/sytem option.

any idea will be greatly appreciate. 

For more inofrmation see
http://blogs.sun.com/erickustarz/en_US/entry/poor_man_s_cluster_end

bbr
-- 
This message posted from opensolaris.org

Hi,

some more details to the question above.

We are using ldom in a cluster environment, which means the ldom is relocatable
between two execution hosts. The ldom owns one zpool named local and this zpool
can be in use only from this domain. This zpool provides some zfs for an
application and should be imported at boot automatically.
After a ldom changeover the ldom inherits the hostid from new execution host and
after reboot ''zpool import'' fails with hostid mismatch.

I know, zpool behavior (avoid ''hostid mismatch'' import) and
ldom behavior (hostid change) are correct on its own.

Unlike ''bbr'' I advocate for a zpool property to supress hostid
check, provided that there are some more people who agree that this could be
expedient.

Some opinions?  

thanks,
torsten
-- 
This message posted from opensolaris.org

Torsten Weigel wrote:
> Hi,
>
> some more details to the question above.
>
> We are using ldom in a cluster environment, which means the ldom is
relocatable between two execution hosts. The ldom owns one zpool named local and
this zpool can be in use only from this domain. This zpool provides some zfs for
an application and should be imported at boot automatically.
>   
There are times when a cluster might try a simple import, and there
are times when a cluster will force the import.  We do know that if
two nodes have simultaneously imported the pool then chances are
very good that the pool will be corrupted.  So it seems prudent for
the cluster to make the decision to force the import (as Solaris Cluster
and Clustron do).  For humans, the -f flag seems to help keep them
out of trouble.
 -- richard

> There are times when a cluster might try a simple
> import, and there
> are times when a cluster will force the import.  We
> do know that if
> two nodes have simultaneously imported the pool then
> chances are
> very good that the pool will be corrupted.  So it
> seems prudent for
> the cluster to make the decision to force the import
> (as Solaris Cluster
> and Clustron do).  For humans, the -f flag seems to
> help keep them
> out of trouble.
>  -- richard

Sun cluster does not provide any help in this case. The problem is located
inside the logical domain.
SUN cluster supports the changeover of ldom between execution hosts and works
fine at all. But after changeover a ldom inherits the hostid of the current
execution host.
After binding and rebooting the automated ''zpool import''
inside this ldom fails based on the fact that the same virtual server has a new
hostid. The zpool which can not be imported is never out in the open and can be
in use from this virtual server only.

In future, if ldoms can use zfs/zpool as boot disk our problem can turn nasty.
http://www.opensolaris.org/jive/thread.jspa?messageID=311019&#311019


torsten
-- 
This message posted from opensolaris.org