Eric Schrock wrote:
On Mon, Sep 18, 2006 at 10:06:21PM +0200, Joerg Haederli wrote:
It looks as this has not been implemented yet nor even tested.
What hasn't been implemented? As far as I can tell, this is a request
for the previously mentioned RFE (ability to change GUIDs on import).
I'm not sure what you mean by an unimplemented RFE being "nor even
tested".
From a previous email to the list ...
ShadowImage takes a snapshot of the LUN, and copies all the blocks to a
new LUN (physical copy). In our case the new LUN is then made available
on the same host as the original LUN.
After the ShadowImage is taken, we can see the snapshop using the
format(1M) command as an additional disk. But when running "zpool
import" , it only says: "no pools available to import".
I think this is a bug. At least it should say something like "pool with
the same name already imported". I have only tested this on 10 06/06,
but I haven't found anything similar in the bug database, so it has to
be in OpenSolaris as well.
Its not the transport layer. It works fine as the LUN IDs are different
and the devices will come up with different /dev/dsk entries. (And if
not then you can fix that on the array in most cases.) The problem is
that devices are present with the same GUID and the behavior of ZFS is
unknown.
Here's an example: I've three LUNs in a ZFS pool offered from my HW raid
array. I take a snapshot onto three other LUNs. A day later I turn the
host off. I go to the array and offer all six LUNs, the pool that was in
use as well as the snapshot that I took a day previously, and offer all
three LUNs to the host. The host comes up and automagically adds all the
LUNs to the host with correct /dev/dsk entries.
What happens?
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
