Targetcliconfiguration在服务器重新启动后丢失了,我试图从备份文件中恢复configuration,使用targetcli restoreconfig <backupFile>configuration未恢复命令storageobjects or targets present, not restoring输出消息storageobjects or targets present, not restoring 。 下面是targetcli ls和systemctl status -l target
targetcli ls o- / ................................................................................................ [...] o- backstores ..................................................................................... [...] | o- block ......................................................................... [Storage Objects: 0] | o- fileio ........................................................................ [Storage Objects: 0] | o- pscsi ......................................................................... [Storage Objects: 0] | o- ramdisk ....................................................................... [Storage Objects: 0] o- iscsi ................................................................................... [Targets: 1] | o- iqn.2017-01.com.urgroup-tz:target ........................................................ [TPGs: 1] | o- tpg1 ...................................................................... [no-gen-acls, no-auth] | o- acls ................................................................................. [ACLs: 1] | | o- iqn.2017-01.com.urgroup-tz:initiator ........................................ [Mapped LUNs: 0] | o- luns ................................................................................. [LUNs: 0] | o- portals ........................................................................... [Portals: 1] | o- 0.0.0.0:3260 ............................................................................ [OK] o- loopback ................................................................................ [Targets: 0] # systemctl status -l target ● target.service - Restore LIO kernel target configuration Loaded: loaded (/usr/lib/systemd/system/target.service; enabled; vendor preset: disabled) Active: active (exited) since Ij 2017-03-10 17:18:43 EST; 1 day 18h ago Main PID: 1342 (code=exited, status=0/SUCCESS) CGroup: /system.slice/target.service Mac 10 17:18:43 server1 target[1342]: Could not create StorageObject tools_disk: Cannot configure StorageObject because device /dev/cl/tools_lv is already in use, skipped Mac 10 17:18:43 server1 target[1342]: Could not create StorageObject bamboo_disk: Cannot configure StorageObject because device /dev/cl/bamboo_lv is already in use, skipped Mac 10 17:18:43 server1 target[1342]: Could not create StorageObject metadata_disk: Cannot configure StorageObject because device /dev/cl/ovirt_domain_metadata is already in use, skipped Mac 10 17:18:43 server1 target[1342]: Could not find matching StorageObject for LUN 2, skipped Mac 10 17:18:43 server1 target[1342]: Could not find matching StorageObject for LUN 1, skipped Mac 10 17:18:43 server1 target[1342]: Could not find matching StorageObject for LUN 0, skipped Mac 10 17:18:43 server1 target[1342]: Could not find matching TPG LUN 0 for MappedLUN 0, skipped Mac 10 17:18:43 server1 target[1342]: Could not find matching TPG LUN 1 for MappedLUN 1, skipped Mac 10 17:18:43 server1 target[1342]: Could not find matching TPG LUN 2 for MappedLUN 2, skipped Mac 10 17:18:43 server1 systemd[1]: Started Restore LIO kernel target configuration.
重新启动之前确保已启用该服务:
systemctl启用目标
帮助这里。
mistige
您应该在引导时运行target.service以恢复LIOconfiguration,并确保iscsid.service正在运行以导出您的LIO设备,并且tgtd未运行,因为它将与其他LIO守护程序冲突。
应该看起来像这样,
root@centos7host# systemctl | grep "target.service\|iscsi" iscsi-shutdown.service loaded active exited Logout off all iSCSI sessions on shutdown iscsi.service loaded active exited Login and scanning of iSCSI devices iscsid.service loaded active running Open-iSCSI iscsiuio.service loaded active running iSCSI UserSpace I/O driver target.service loaded active exited Restore LIO kernel target configuration iscsid.socket loaded active running Open-iSCSI iscsid Socket iscsiuio.socket loaded active running Open-iSCSI iscsiuio Socket
你之前也想清理你之前做的任何事情,因为这会让你感到困惑。 你有可能在LIO之外创build的卷,所以当你用targetcli来pipe理它们时,会有一些东西没有被正确地导出,而且会变得混乱。
如果有可能的话,我build议擦拭系统,如果你有这个选项干净的开始。 从一开始就正确地获得iscsi子系统的设置是非常重要的,因为在运行之后处理它是危险的,因为你可能会对用户数据做很多潜在的破坏性操作。
如果您将LVMpipe理的存储池用于后端存储设备,则应该确保LVM /设备映射程序丢弃第二层VG / LV。
我的意思是第二层VGs / LV; 例如:
假设下面的LV(DISK_1)有另一个由iSCSI客户端初始化的VG,并用于客户端的服务。 一个磁盘将有两个不同的VG层,一个VG在另一个磁盘内。
如果LVM子系统在第一层LV内扫描VG,则新发现的第二层VG和LV将映射到目标服务器。 由于LV被映射到目标服务器(通过devicemapper),lio_target模块将无法加载它们作为后端存储。
[root@target ~]# pvs PV VG Fmt Attr PSize PFree /dev/mapper/mpatha STORAGE_POOL lvm2 a-- 12.00t 2.50t [root@target ~]# lvs LV VG Attr LSize DISK_1 STORAGE_POOL -wi-ao---- 5.00t DISK_2 STORAGE_POOL -wi-ao---- 1.00t DISK_3 STORAGE_POOL -wi-ao---- 2.50t DISK_4 STORAGE_POOL -wi-ao---- 1.00t [root@target ~]#
LVM在引导OS期间searchVG和LV。 这就是为什么你没有意识到这个问题的原因。
您应该设置一个LVMfilter来扫描磁盘中的新VG。 请参阅global_filter的lvm.conf手册。 使用此configuration,您将能够放弃第二层VG。 以下是上述存储架构的示例,仅用于扫描PV中的VG,并丢弃所有块设备的其余部分。
[root@target ~]# diff /etc/lvm/lvm.conf{,.orginal} 152d151 < global_filter = [ "a|/dev/mapper/mpath.|", "r|.*/|" ] [root@target ~]#
您可以简单地使用脚本在启动后运行“vgchange -an 2nd_layer_VG”并恢复LIO目标configuration。 不过,我build议使用LVM的“global_filter”function。
注意:在CentOS 7 / Red Hat 7之前,在启动第二层LV时没有任何问题,目标仍然可以将它们加载为LUN。 然而,在这种情况下,新的linux-iscsi(LIO)failt。 我没有进一步研究这个问题。
问候…