Great ! Thanks Mike. It seems this was the reason.
Short summary of what I did: 1) Enabled Comstar on the target node 2) Disabled legacy iscsi on the target node 3) Backed up the STMF config on source node (pre 116) svccfg export -a stmf > /tmp/stmf.cfg 4) Copied over the file to the other node scp /tmp/stmf.cfg target:/tmp/stmf.cfg 5) Cleared the Comstar Configuration on the target node svcadm disable stmf svccfg delete xtmf cd /var/svc/manifest svccfg import system/stmf.xml svcadm disable stmf 6) Imported the Configuration on the target node svccfg import /tmp/stmf.cfg 7) Export the pool on the primary side zpool export mypool 8) Import the pool on the secondary side zpool import mypool 9) Imported the lu stmfadm import-lu /dev/zvol/rdsk/mypool/vzol1 10) Verified mappings stmfadm list-lu stmfadm list-view -l LU 11) DONE Everything was taken over. Mappings available and the GUID did not change, which is importand for linux device mapper multipath clients woth persistent mappings. Also the content stayed the same (verified with md5sum). Alignment is also correct (verified with md5sum on the device). All mappings are there also. I even tried this with Linux devicemapper client with "queue_if_no_path" and switched a virtual IP between the nodes. During the operations above the path fails (because of queue_if_no_path this is not critical), but after the IP is up (as a last action), paths are online again - 100% transparently. Thanks again for the Tipp Mike. Regards, Robert -- This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
