Export (0) Print
Expand All

Migrating Microsoft iSCSI Software Target

This topic discusses the actual migration steps for Microsoft iSCSI Software Target 3.2 or iSCSI Software Target 3.3. Depending on your setup, use the instructions in the following sections for your migration:

noteNote
The two migration processes are very similar. The failover cluster section presents the differences for you to follow if you are migrating a failover cluster.

Migrating Microsoft iSCSI Software Target in a standalone configuration

The migration of Microsoft iSCSI Software Target 3.2 or iSCSI Software Target 3.3 has equivalent steps, whether you are migrating from Windows Storage Server 2008 to Windows Storage Server 2008 R2, from Windows Storage Server 2008 R2 to Windows Storage Server 2008 R2, or from Windows Server 2008 R2 to Windows Server 2008 R2.

Establish network identity of the iSCSI Software Target server

As part of the planning process, a strategy should have been devised regarding how iSCSI Software Target will be accessed from the network, including but not limited to:

  1. Which computer name will be used?

  2. Which IP addresses on which subnet or set of network interfaces will be used?

  3. What relationship should be maintained between the IP addresses and computer name of the source server and the destination server—will you keep the same addresses and names or create new ones?

Based on the desired final configuration, configuration changes are potentially needed in the following areas:

  1. The DHCP Server that might assign IP addresses to the destination iSCSI Software Target servers

  2. The DHCP Server that might assign IP addresses to the iSCSI initiators

  3. The DNS Server or Active Directory domain controller that might perform naming resolution services for the computers in the enterprise

For further information, see the IP Configuration Migration Guide (http://go.microsoft.com/fwlink/?LinkID=128513).

Configure the iSCSI Software Target portal

After you have configured IP addresses for the network interfaces of the iSCSI Software Target server, it is possible to verify the existing configuration by using the following Windows PowerShell command:

PS > $Portals = Get-WmiObject -Namespace root\wmi -Class WT_Portal | Where-Object { $_.Listen }
PS > $Portals

The configuration of the access surface for iSCSI Software Target from the network can be restricted by disabling certain portals. For example, you can disable the fourth portal in the array returned in the previous step by using the following Windows PowerShell commands:

PS > $Portals[3].Listen = 0
PS > $Portals[3].Put()

The default port can also be changed from 3260 to any available TCP port on the destination server.

Configure iSNS settings

The iSNS servers that were configured for the source server can be configured for the destination server by using the following Windows PowerShell commands:

PS > $WT_ISnsServerClass =  Get-WmiObject -namespace root\wmi -class meta_class -filter "__CLASS = 'WT_ISnsServer'"
PS > $WtiSNSInstanace = $WT_ISnsServerClass.CreateInstance()
PS > $WtiSNSInstanace.ServerName = "<iSNS computer name or IP>"
PS > $WtIsnsInstanace.Put()

noteNote
The set of iSNS servers that are configured for the iSCSI Software Target server was obtained during the preparation of the source server.

Configure storage

The destination server is expected to have sufficient storage space to host all of the virtual disks that are present on the source server.

The space does not need to be contiguous or in a single volume, and it does not need to replicate the same file system structure or volume mount point structure of the source server.

The storage that is prepared to host the virtual disks must not be a nested volume, and it must be formatted with the NTFS file system.

Configure the Volume Shadow Copy Service

For the storage that was prepared in the previous step, it is appropriate to configure the Volume Shadow Copy Service, in case the default per-volume settings are not adequate.

To inspect that current configuration, use the following Windows PowerShell command:

PS > & vssadmin.exe list shadowstorage

To modify the current configuration, use the following Windows PowerShell commands:

PS > & vssadmin.exe add ShadowStorage
PS > & vssadmin.exe delete ShadowStorage
PS > & vssadmin.exe resize ShadowStorage

Transfer the virtual disk

For all the files in the list of files that was captured in the source server preparation step, copy the files from the source server to the destination server. For more information, see Capture the existing settings.

You will need the destination paths in the following steps. So if the absolute file path is different between the source server and the destination server, create a table with the mapping, for example:

 

Source path

Destination path

G:\WS08R2_OpsMgr2007_R2.vhd

H:\VHDS\WS08R2_OpsMgr2007_R2.vhd

F:\Dynamic_Spanned_GPT_2.vhd

D:\DYNVHDS\Dynamic_Spanned_GPT_2.vhd

Import the iSCSI Software Target settings in a standalone configuration

To import the iSCSI Software Target settings in a standalone configuration, you need the .xml file that you previously created. For more information, see Capture the existing settings.

If there is no change in the absolute path of the virtual disk files, the import process can be performed by using the following Windows PowerShell commands:

PS > cd “$ENV:Programfiles\Microsoft iSCSI Software Target”
PS> .\ iSCSITargetSettings.PS1 –Import –FileName <settings XML file>

If the absolute path is different between the source server and the destination server, before you import the settings, the settings .xml file needs to be altered to reflect the new path.

Locate the records for the virtual disk, and alter the path in the <MigrationDevicePath> tag to reflect the absolute file path in the destination server, for example:

    <iSCSIVirtualDisk>
       …
      <DevicePath>F:\Dynamic_Spanned_GPT_2.vhd</DevicePath>
      …
      <MigrationDevicePath>D:\DYNVHDS\Dynamic_Spanned_GPT_2.vhd</MigrationDevicePath>
      …
    </iSCSIVirtualDisk>

After the XML has been altered to reflect the path in the destination server, you can import the settings by using the Windows PowerShell commands previously presented.

Configure locally surfaced virtual disks

The virtual disks that were surfaced as a local disk on the source server can be surfaced locally on the destination server, if desired, by using the following Windows PowerShell commands:

PS > $VirtualDisk = Get-WmiObject -Namespace root\wmi -Class WT_Disk | Where-Object { $_.DevicePath -eq '<Virtual Disk path>' }
PS > $VirtualDisk.DvMount()

Configure shadow storage for the virtual disks

If certain virtual disks have shadow storage requirements that are different than the ones configured in the section Configure Volume Shadow Copy Service, it is possible to alter the default or previously configured settings by using the following Windows PowerShell commands:

PS > $VirtDisk = Get-WmiObject -Namespace root\wmi -Class WT_Disk | Where-Object { $_.DevicePath -eq '<full path of virtual disk>' }
PS > $VirtDisk.SnapshotStorageSizeInMB = <new size>
PS > $VirtDisk.Put()

Configure CHAP and Reverse CHAP

The authentication settings for iSCSI Software Target that are configured with CHAP and Reverse CHAP need to be manually configured. The list of targets that require CHAP and Reverse CHAP configuration is listed at the end of the import script, as described in the section Import the iSCSI Software Target settings.

To configure the CHAP and Reverse CHAP settings, use the following Windows PowerShell commands:

PS > $Target = Get-WmiObject -Namespace root\wmi -Class WT_Host | Where-Object { $_.HostName -eq '<name of the target>' }
PS > $Target.EnableCHAP = 1
PS > $Target.CHAPUserName = "<user name>"
PS > $Target.CHAPSecret = "<CHAP Secret>"
PS  $Target.Put()

Migrating iSCSI Software Target in a failover cluster

The migration process for the failover cluster configuration is largely identical to migrating a standalone configuration, with the following differences:

  • You will migrate resource groups instead of merely establishing the network identity of the server.

  • You will use different Windows PowerShell commands to import the resource groups.

Migrate resource groups

This steps replaces the “Establishing the network identity of the iSCSI Software Target Server” step when you migrate a standalone configuration. The reason is that the network identity of an iSCSI Software Target server in a cluster is given by the union of the client access point. (A client access point in the cluster is the logical union of a network name resource and one or more IP addresses that are assigned to the network name resource.)

Assuming the initial cluster resource groups and network names were configured in the default state, those can be recreated by using the following Windows PowerShell command:

PS > Add-ClusterServerRole – Name <resource group name>

Use this command for each of the resource groups that were in the original configuration.

If the default client access point configuration does not match the initial configuration (for example, because the network name is bound to the incorrect cluster network, or the configuration required statically assigned IP addresses), modifications can be made by following instructions in the IP Configuration Migration Guide. For more information, see IP Configuration Migration Guide (http://go.microsoft.com/fwlink/?LinkID=128513).

After the resource groups have been created, clustered disks must be assigned to the network resources to match the configuration that you captured. For more information, see the Cluster resource group configuration section.

Import the iSCSI Software Target settings in a failover cluster

Follow these instructions to import settings in a failover cluster configuration. (This information differs from the how you would import settings in a standalone configuration.)

A prerequisite for the import phase is to have all of the resource groups that will host iSCSI Software Target server resources owned by the same cluster node. Use the following Windows PowerShell command to validate the current ownership:

PS > Get-ClusterGroup

If there is no change in the absolute path of the virtual disk files, the import process can be performed by using the following commands:

PS > cd “$ENV:Programfiles\Microsoft iSCSI Software Target”
PS> .\iSCSITargetSettings.PS1 –Import –FileName <settings XML file>

If the absolute path is different between the source server and the destination server, before you import the settings, the settings .xml file needs to be altered to reflect the new path.

Locate the records for the virtual disk, and alter the path in the <MigrationDevicePath> tag to reflect the absolute file path in the destination server, for example:

<iSCSIVirtualDisk>
       …
      <DevicePath>F:\Dynamic_Spanned_GPT_2.vhd</DevicePath>
      …
      <MigrationDevicePath>D:\DYNVHDS\Dynamic_Spanned_GPT_2.vhd</MigrationDevicePath>
      …
    </iSCSIVirtualDisk>

After the XML has been altered to reflect the path in the destination server, you can import the settings by using the Windows PowerShell commands previously presented.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft