[从Windows 8和Windows Server 2012开始，虚拟磁盘服务 COM 接口将被 Windows 存储管理 API 取代。

设置发起方 CHAP 共享机密，当发起方对目标进行身份验证时，用于相互 CHAP 身份验证。

包含共享机密的 VDS_ISCSI_SHARED_SECRET 结构的地址。 如果 pSharedSecret 成员为 NULL ， ulSharedSecretSize 为零， 则 SetInitiatorSharedSecret 方法清除任何现有机密。 如果此参数为 NULL 且 targetId 参数未 GUID_NULL， 则 SetInitiatorSharedSecret 将清除发起程序与目标之间的关联。

目标的 VDS_OBJECT_ID 。 如果共享机密不是特定于目标，则此参数设置为 GUID_NULL 。

此方法可以返回标准 HRESULT 值，例如E_INVALIDARG或E_OUTOFMEMORY，以及 特定于 VDS 的返回值。 它还可以使用HRESULT_FROM_WIN32宏返回转换的系统错误代码。 错误可能源自 VDS 本身或正在使用的基础 VDS 提供程序 。 可能的返回值包括以下内容。

返回代码/值	说明
S_OK	已成功设置共享机密。
VDS_E_INITIALIZED_FAILED 0x80042401L	VDS 无法初始化。 如果应用程序在服务完成初始化之前调用此方法，则会阻止该方法，直到初始化完成。 如果初始化失败，则返回此错误。
VDS_E_TARGET_SPECIFIC_NOT_SUPPORTED 0x80042706L	发起程序服务不支持设置特定于目标的共享机密。

发起程序可能支持为每个目标设置不同的 CHAP 共享机密。

无法以编程方式确定发起程序是否支持特定于目标的机密。 如果 对 SetInitiatorSharedSecret 的调用返回VDS_E_TARGET_SPECIFIC_NOT_SUPPORTED，请再次调用该方法，并将 targetId 参数设置为GUID_NULL。

Microsoft iSCSI 软件发起程序不支持设置特定于目标的机密。

?	?
最低受支持的客户端	Windows Vista [仅限桌面应用]
最低受支持的服务器	Windows Server 2003 R2 [仅限桌面应用]
目标平台	Windows
标头	vds.h
Library	Uuid.lib
可再发行组件	VDS 1.1

IVdsIscsiTarget：：RememberInitiatorSharedSecret

IVdsIscsiTarget：：SetSharedSecret

IVdsServiceIscsi

IVdsServiceIscsi：：RememberTargetSharedSecret

VDS_ISCSI_SHARED_SECRET

---

linux怎么发起iscsi连接 windows和linux的iscsi配置有什么不同

linux怎么起进程,linux是怎么开发出来的,linux怎么发消息,linux怎么开

本文详细介绍iSCSI相关的内容，以及在Linux上如何实现iSCSI。

传统的SCSI技术是存储设备最基本的标准协议，但通常需要设备互相靠近并用SCSI总线连接，因此受到物理环境的限制。

iSCSI(Internet Small Computer System Interface)，顾名思义，iSCSI是网络上的SCSI，也就是通过网络连接的SCSI。它是由IBM公司研究开发用于实现在IP网络上运行SCSI协议的存储技术，能够让SCSI接口与以太网技术相结合，使用iSCSI协议基于以太网传送SCSI命令与数据，克服了SCSI需要直接连接存储设备的局限性，使得可以跨越不同的服务器共享存储设备，并可以做到不停机状态下扩展存储容量。

iSCSI实现的是IP SAN，数据传输基于以太网。

initiator向target发起scsi命令后，在数据报文从里向外逐层封装SCSI协议报文、iSCSI协议报文、tcp头、ip头。

封装是需要消耗CPU资源的，如果完全以软件方式来实现iscsi，那么所有的封装过程都由操作系统来完成。在很繁忙的服务器上，这样的资源消耗可能不太能接受，但好在它是完全免费的，对于不是非常繁忙的服务器采用它可以节省一大笔资金。

除了软件方式实现，还有硬件方式的initiator(TOE卡和HBA卡)，通过硬件方式实现iSCSI。由于它们有控制芯片，可以帮助或者完全替代操作系统对协议报文的封装。

• TOE卡，操作系统首先封装SCSI和iSCSI协议报文，而TCP/IP头则交由TOE内的芯片来封装，这样就能减少一部分系统资源消耗。
• HBA卡，操作系统只需封装SCSI，剩余的iSCSI协议报文还有TCP/IP头由HBA芯片负责封装。

显然，HBA卡实现iSCSI是最好的方案，但是它要花钱，还不便宜。

1.说明

• (1).iscsi在target端是工作在套接字上的，监听端口默认是3260，且使用的是tcp连接。因为要保证数据安全性，使用udp可能会导致丢包。
• (2).iscsi对客户端有身份认证的需要，有两种认证方式：基于IP认证，基于CHAP认证(双方都进行验证，即双向认证)。

2.需求描述

找一台服务器A作为iscsi的target，将其中的一块磁盘或分区/dev/sdb当作要共享的存储设备共享出去。再找两台服务器B和C当作iscsi initiator连接到target的共享存储上。

大致拓扑图如下：

请确保服务器A上已经关闭了防火墙或者允许了3260端口。

下图描述了使用iSCSI的大致过程，后文内容虽然因为介绍各种用法而显得比较杂，但根据这张图的流程，阅读时很容易搞清楚相关内容。

在服务器A上：

查看该工具包生成了哪些文件。

其中和的都是管理和配置target的工具，它们作用是一样的，只不过tgtadm是命令行下的工具，而tgt-admin是根据配置文件调用tgtadm来实现。另外是服务启动脚本。

这个时候已经可以启动target服务了。

加入开机自启动。

tgtadm是一个高度模式化的命令，他们的模式很相近。有三个模式:target、logicalunit、account。指定模式时使用--mode选项。再使用--op来指定对应模式下的选项。另外，使用-lld指定driver，有两种driver：iscsi和iser，基本都会使用iscsi。

看上去很复杂。不过可以将上面的语法抛去driver部分，target、logicalunit和account这3种模式下的操作方式简化后如下：

这样就简单的多了。

上表中的选项都是长格式的，但他们都有对应的短格式选项。

target和logicalunit两个模式随后就会有示例，而account是和CHAP认证有关的，将在后文和配置文件放在一块解释。

• 是iscsi qualified name的缩写，就像fqdn一样。
• 描述的是此target是何年何月创建的，如2016-06。
• 是域名的反写，起到了唯一性的作用，如longshuai.com写为com.longshuai。
• 是可选的，是为了知道此target相关信息而设的描述性选项，如指明此target用到了哪些硬盘。

示例：

需要说明的是，下面的实验全是使用命令行工具tgtadm来实现的。但是修改配置文件然后使用tgt-admin也是一样可以的，且target数量多的时候，更建议使用配置为文件加载的方式。最重要的一点是，使用命令行方式创建的target及lu等是临时生效的，在target服务重启后就失效了，再手动建立它们是一件相当麻烦的事情。

如下，分别使用了长格式选项和短格式选项分别创建和显示target。注意：创建target时，tid不能是0，因为0是被系统保留的。

以上是第一个target的信息。从信息中可以看到：

• 创建完第一个target后自动就创建了一个LUN为0的logicalunit(以后简称lu)，这是固定给每个target都使用的LUN。
• 此lu的类型是controller。
• "backing store type"为null，即此lu没有向下扩展逻辑设备，因为它是lun控制器。也就是说这个LUN是保留作为lu控制器用的。
• "I_T nexus information"记录的是initiator与此target的联结关系，nexus的意思就是联结、关联，在后文介绍initiator的时候会展示此处信息。

现在向此target添加一个lu，使用的是新插入的磁盘/dev/sdc(全新，未进行分区)。当然，使用新建立的分区或者已经格式化后的分区做实验也可以。

然后再来查看target的信息。

从LUN 1信息中可以看出，lu type已经是disk而非controller，且显示了此lu的容量大小是42950M。另外还显示了使用的逻辑设备是/dev/sdc，且是可读可写的(rdwr)。

但到目前为止，该target都没有定义共享给谁，这从target信息的最后两行Account/ACL information中可以看出。

现在将此target绑定一个共享IP，即说明此IP可以连接该target。这是iSCSI的一种认证方式：IP认证。除此之外，还有基于account的CHAP认证，详细内容见后文。IP认证的作用是允许Initiator发现该target，并允许做进一步的基account的CHAP认证。

再添加一个10G分区/dev/sdb1为逻辑存储单元，lun=2。

由于该lu是在target id=1下的，所以192.168.100.0这个网段的机器也能访问此设备。也就是说，共享出去的是target级别而不是lu级别的。

然后在iscsi的"客户端"initiator安装iscsi-initiator-utils看看是否能看见这两个设备。如果想急着看结果，请跳到安装initiator的章节中。

tgt-admin是读取配置文件的选项然后调用tgtadm来执行的工具。它的选项很多可以简化tgtadm命令的书写，毕竟tgtadm的选项太长太多余了，除此之外也有一些其他的作用用于更细致的配(tgtadm配置的太粗糙了)。用法如下：

tgt的配置文件为，该配置文件的格式很容易读懂，能实现的target和lun的配置方式多种多样。它的配制方法在后文会和iscsi initiator的配置文件/etc/iscsi/iscsid.conf放在一起介绍。

下面就使用tgt-admin为当前的target生成对应的配置文件来稍作分析。

首先列出当前target的信息。

使用选项输出为配置文件的格式，并将其重定向到/tmp/tgt.conf中。

由此可以看出，全局使用的driver是iscsi，名称为的target有两个backing-store，即逻辑设备，分别是/dev/sdb1和/dev/sdc。但是要注意，这样导出的配置文件指定的LUN号码可能会在tgt-admin读取并执行的时候更换位置，但这并不会有任何影响。

现在将已有的target全部删除，再去查看信息就已经没有了。

再从刚才生成的配置文件中读取并启动。然后查看信息，发现已经有了target。

关于tgt-admin其他选项也都很简单，都是从字面意思就能看出来用法的。所以就不多说明了。

另外需要说明的是在tgt的配置文件中有一行：

将此行注释后，以后可以导出配置文件到/etc/tgt/temp目录下并以.conf作为后缀，重启tgtd服务即可重新加载，而不需要在手动加载了。不过有个问题，使用dump出来的配置文件会有default-driver指令行，而这一行在主配置文件中也有，且他们是不能出现多次的，否则将会报错，所以需要将主配置文件中的default-driver指令注释掉。

安装Initiator的机器成为iscsi的发起者，initiator本身的意思就是"发起者"，在这里即iscsi的"客户端"程序的意思。

此处先在B服务器(192.168.100.5)上安装iscsi-initiator-utils。另一台C服务器后面再做测试。

下面是此安装包生成的一些重要文件和目录(只列出了必要的部分)。

其中:

• ：是iscsi发起者的配置文件。
• ：服务启动脚本，只需要启动iscsi即可，因为它会自动调用iscsid脚本。
• ：为initiator命名的工具。就像target有自己独特的iqn名称，initiator也有独特的名称标识自己。
• ：initiator的管理工具，在initiator上的绝大部分的命令都是通过它来执行的。
• ：指定使用哪个网卡接口和target通信。
• ：该目录中保存了发现的target，分别是以target_name命名的目录，在target_name目录下又保存了以"target_ip,port"(如192.168.100.151,3260)的配置文件，这个配置文件是本initiator向对应的target 发起连接时的参数，这些参数继承于。
• ：该目录中也存储了一个或多个以"target_IP,port"命名的目录，记录的是discovery的历史记录，对于discovery成功的则在对应的目录会有文件，否则是空目录。

其中的记录方式称为protal，是入口、入门的意思。

需要注意的是，建议不要把iscsi和iscsid设置为开机自启动，因为开机时如果它找不到target的时候会一直卡在那里等待。可以将其放在rc.local文件中来启动。

和target一样，initiator也需要一个独特的名称来标识自己让target识别。initiator在连接target的时候，会读取/etc/iscsi/initiatorname.iscsi中的内容作为自己的iname。

初始状态的iname如下：

其中后缀"ceb390801983"是一个随机串。

也可以为iname生成一个别名，只需在此文件中另起一行写入以下内容：

如:

若要自指定iname，可以手动修改该文件。也可以使用iscsi-iname工具来生成iname并保存到该文件。

可以看出iscsi-iname生成的iname前缀都是一样的，修改的只是后缀部分的随机串。如果要指定前缀，则使用-p选项。

所以，通过iscsi-iname向/etc/iscsi/initiatorname.iscsi中写入一个iname。

然后重启下iscsi服务。

iscsiadm也是一个模式化的命令，使用-m指定mode。mode有:discovery、node、session、iface。一般就用前两个mode。

• ：发现某服务器是否有target输出，以及输出了哪些target。发现target后会生成target数据库discoverydb。
• ：管理跟某target的关联关系。在discovery发现了target后，是否要跟target建立关系，是否要删除已有的关系或者解除已有的关系等。删除关联关系不仅会解除关联，还会删除发现target后生成的discoverydb。
• ：会话管理。
• ：接口管理。

即使用discovery模式。

现在可以进行discovery了。这里发起两次，第一次是正确的，第二次是错误的(该IP上没有target或主机未启动)。

如果出现以上错误，检查下是不是防火墙阻挡了，是不是IP地址写错了。

在发现了target后，在中的nodes和send_targets目录中就有了文件。

可以看到，对于discovery失败的在send_targets目录中也会记录，只不过是空目录。在nodes目录和正确discovery到的send_targets子目录中都有几个配置文件，都是些参数信息。而且可以看到，send_targets中的目录是nodes目录的软链接。

如果想重新发现已存在的target时，可以清空nodes目录中对应的项，然后再discovery。

使用可以查看到相关信息项。

关联target的作用是initiator和target建立session，建立session后，initiator上就可以查看、访问、操作target上的scsi设备。

有两种关联方法，一是关联所有，一是指定单个target进行关联。

例如，使用单个的关联方式关联target。其中target_name可以通过命令查看。

实际上，在执行discovery的时候很可能就已经自动执行了关联，所以再次关联很可能什么消息也看不到。如果是这样的话，需要先退出session，再进行关联。当然也可能是直接显示successful，这样就说明原来discovery的时候是没有主动关联的。

此时fdisk -l看看是否已经多出了两块硬盘出来。

现在就可以对这两块逻辑盘进行分区格式化(创建文件系统)，并投入使用。

此时先看下target端的target信息。

其中I_T nexus表示initiator到target的关联信息，nexus的值是该initiator关联到target的次数。多个initiator会显示多个I_T nexus信息。这里可以看到只有一个I_T nexus，说明只有一个initiator进行了关联。

现在在initiator上将/dev/sdb进行格式化，并向其中写入一个文件。

然后配置服务器C(192.168.100.6)，让其作为另一台initiator。

不出所料，C服务器也能挂载/dev/sdb1，且在B服务器写入的test.txt文件也已经同步过来了。

再看看此时target的target信息。

现在在C服务器上，向/dev/sdb1挂载的目录/mnt下写入一个文件，看看是否会同步到B服务器上。

在192.168.100.5上执行：

显然，test1.txt并没有同步到B服务器上。同理，此时B中再写入文件也不会同步到C上。

那么在C上卸载/mnt，然后再次挂载会有什么情况呢？

没看错，test1.txt确实没了。这就是使用iscsi出现的问题，多个主机同时使用逻辑存储，数据会冲突并且不能及时同步而导致数据丢失。

所以，iscsi一定要配合集群文件系统或者分布式文件系统来使用以防止上述问题。

该问题在前文描述过。

出现

---

Migrating Microsoft iSCSI Software Target

migratory,migrating,migrate和immigrate的区别,migrate英文翻译

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:

• Migrating Microsoft iSCSI Software Target in a standalone configuration

• Migrating Microsoft iSCSI Software Target in a failover cluster

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.

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 ().

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:

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:

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

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

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.

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:

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

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

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:

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:

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.

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:

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:

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:

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.

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 m