[Users] 3.4 iscsi multipath feature iface initiatorname

Hi All, I'm testing the 3.4 iscsi multipath feature and I think I have a problem with the way it is creating iscsi ifaces. The background: I've got an existing production 3.3 system that is iscsi, and it is multipath in the sense that there are mulitple networks configured on the hosts that are used to connect to my iscsi storage (a fujtisu eternus) and the storage domain is configured with multiple targets for each lun. This has worked for me but it's not the explicit managed multipath that the new feature provides. So in my test 3.4 all-in-one, i've tried to follow the steps at http://www.ovirt.org/Feature/iSCSI-Multipath. I got the iscsi domain up, but when I added the iscsi bonds, my storage domain went offline. After digging through it, the reason is that the iscsi bond creates iscsi ifaces, and those ifaces have an initiatorname that is the name of the network, not the iscsi initiatorname defined in /etc/iscsi/initiatorname.iscsi this is the part of vdsm log that shows the iscsi iface creation Thread-275963::DEBUG::2014-03-06 16:58:15,743::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) '/usr/bin/sudo -n /sbin/iscsiadm -m iface' (cwd None) Thread-275963::DEBUG::2014-03-06 16:58:15,786::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) SUCCESS: <err> = ''; <rc> = 0 Thread-275963::DEBUG::2014-03-06 16:58:15,787::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) '/usr/bin/sudo -n /sbin/iscsiadm -m iface -I em1.218 --op=new' (cwd None) Thread-275963::DEBUG::2014-03-06 16:58:15,827::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) SUCCESS: <err> = ''; <rc> = 0 Thread-275963::DEBUG::2014-03-06 16:58:15,828::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) '/usr/bin/sudo -n /sbin/iscsiadm -m iface -I em1.218 -n iface.initiatorname -v em1.218 --op=update' (cwd None) Thread-275963::DEBUG::2014-03-06 16:58:15,875::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) SUCCESS: <err> = ''; <rc> = 0 Thread-275963::DEBUG::2014-03-06 16:58:15,876::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) '/usr/bin/sudo -n /sbin/iscsiadm -m iface -I em1.218 -n iface.transport_name -v tcp --op=update' (cwd None) When those ifaces are used in the iscsiadm connections, I don't get the luns attached because they're not the correct initiatorname in the iscsi setup. I know Francesco wrote of success at http://lists.ovirt.org/pipermail/users/2014-January/020412.html Has anyone else seen this? Thanks, -John

John, I and several guys here tested it either and it worked for us, however in your case we definitely have a problem. Can we schedule a meeting in the ovirt channel so we can manage continues conversation and examine all facts? Regards, Sergey ----- Original Message -----
From: "John Taylor" <jtt77777@gmail.com> To: users@ovirt.org Sent: Sunday, March 9, 2014 3:29:09 AM Subject: [Users] 3.4 iscsi multipath feature iface initiatorname
Hi All, I'm testing the 3.4 iscsi multipath feature and I think I have a problem with the way it is creating iscsi ifaces.
The background: I've got an existing production 3.3 system that is iscsi, and it is multipath in the sense that there are mulitple networks configured on the hosts that are used to connect to my iscsi storage (a fujtisu eternus) and the storage domain is configured with multiple targets for each lun. This has worked for me but it's not the explicit managed multipath that the new feature provides.
So in my test 3.4 all-in-one, i've tried to follow the steps at http://www.ovirt.org/Feature/iSCSI-Multipath. I got the iscsi domain up, but when I added the iscsi bonds, my storage domain went offline. After digging through it, the reason is that the iscsi bond creates iscsi ifaces, and those ifaces have an initiatorname that is the name of the network, not the iscsi initiatorname defined in /etc/iscsi/initiatorname.iscsi
this is the part of vdsm log that shows the iscsi iface creation
Thread-275963::DEBUG::2014-03-06 16:58:15,743::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) '/usr/bin/sudo -n /sbin/iscsiadm -m iface' (cwd None) Thread-275963::DEBUG::2014-03-06 16:58:15,786::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) SUCCESS: <err> = ''; <rc> = 0 Thread-275963::DEBUG::2014-03-06 16:58:15,787::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) '/usr/bin/sudo -n /sbin/iscsiadm -m iface -I em1.218 --op=new' (cwd None) Thread-275963::DEBUG::2014-03-06 16:58:15,827::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) SUCCESS: <err> = ''; <rc> = 0 Thread-275963::DEBUG::2014-03-06 16:58:15,828::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) '/usr/bin/sudo -n /sbin/iscsiadm -m iface -I em1.218 -n iface.initiatorname -v em1.218 --op=update' (cwd None) Thread-275963::DEBUG::2014-03-06 16:58:15,875::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) SUCCESS: <err> = ''; <rc> = 0 Thread-275963::DEBUG::2014-03-06 16:58:15,876::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) '/usr/bin/sudo -n /sbin/iscsiadm -m iface -I em1.218 -n iface.transport_name -v tcp --op=update' (cwd None)
When those ifaces are used in the iscsiadm connections, I don't get the luns attached because they're not the correct initiatorname in the iscsi setup.
I know Francesco wrote of success at http://lists.ovirt.org/pipermail/users/2014-January/020412.html Has anyone else seen this?
Thanks, -John _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
participants (2)
-
John Taylor
-
Sergey Gotliv