There's a few things I can think of:

1) If your SAN supports copying disks, you can clone/copy the existing iSCSI disk/LUN/volume and then offline the cluster resource of the EXISTING item and possibly online the new one (you'll have to change some IP stuff I imagine). OR possibly be able to re-use the old IP of the old iSCSI LUN and assign that to the copied one.

2) You can probably use miggui to migrate the data from one to another, although I imagine this will require changing the cluster resource names/volume in the process which may be undesireable (ie, if the volume hosts HOME directories, for example, or if you have items that utilize the UNC path)

3) Some combination of DST setup. You shadow the current iSCSI disk and basically use the "2nd" scenario described in the cluster docs where you create a secondary volume and basically shadow all the data over to the 2nd shadow volume which exists on the new SAN/whatever. Then offline the resource/break the shadow and then create the new primary on the new iSCSI node and re-link the shadow/DST volume to that. You can keep the same volume name of the primary in that case (I've done that before--just not with iSCSI).

On 03.11.2011 20:26, kjhurni wrote:
>
> There's a few things I can think of:
>
> 1) If your SAN supports copying disks, you can clone/copy the existing
> iSCSI disk/LUN/volume and then offline the cluster resource of the
> EXISTING item and possibly online the new one (you'll have to change
> some IP stuff I imagine). OR possibly be able to re-use the old IP of
> the old iSCSI LUN and assign that to the copied one.
>
> 2) You can probably use miggui to migrate the data from one to
> another, although I imagine this will require changing the cluster
> resource names/volume in the process which may be undesireable (ie, if
> the volume hosts HOME directories, for example, or if you have items
> that utilize the UNC path)
>
> 3) Some combination of DST setup. You shadow the current iSCSI disk
> and basically use the "2nd" scenario described in the cluster docs where
> you create a secondary volume and basically shadow all the data over to
> the 2nd shadow volume which exists on the new SAN/whatever. Then
> offline the resource/break the shadow and then create the new primary on
> the new iSCSI node and re-link the shadow/DST volume to that. You can
> keep the same volume name of the primary in that case (I've done that
> before--just not with iSCSI).
>
>
4. Not to forget the good old mirroring trick.. ;)

CU,
--
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de

Thanks Massimo!

I've not worked with iSCSI at all so I wasn't sure if there was different "magic" that could be used.

Hudo, Massimo is referring to (I believe) the NSS mirroring feature where you mirror at a partition level. Then you can break the mirror and use the new one. THAT is documented in the OES2 docs somewhere and they even cover a scenario for data migration.

Personally I'd go with your SAN route if you can (ie, if your SAN supports cloning/copying iSCSI disks), but I'm not knowledgeable enough to know how/what you have to change the iSCSI settings

Thanks Massimo!

I've not worked with iSCSI at all so I wasn't sure if there was different "magic" that could be used.

Hudo, Massimo is referring to (I believe) the NSS mirroring feature where you mirror at a partition level. Then you can break the mirror and use the new one. THAT is documented in the OES2 docs somewhere and they even cover a scenario for data migration.

Personally I'd go with your SAN route if you can (ie, if your SAN supports cloning/copying iSCSI disks), but I'm not knowledgeable enough to know how/what you have to change the iSCSI settings

thx for the info,

what about this approach:

1. Connect to new iscsi target
2. Create new pool volume on this new device
3. Migrate all data from oldvol to newvol (with miggui)
4. deactivate old resource
5. rename newpool and newvol to old names
6. configure to old ip and old virt. server name

Any problems with this?