Bug 1565198 - iSCSI bond setup doesn't show additional portal
Summary: iSCSI bond setup doesn't show additional portal
Keywords:
Status: CLOSED DUPLICATE of bug 1566415
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.1.9
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ovirt-4.3.0
: ---
Assignee: Maor
QA Contact: Elad
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-09 15:15 UTC by Olimp Bockowski
Modified: 2019-04-28 09:13 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-08-13 08:54:32 UTC
oVirt Team: Storage
Target Upstream Version:


Attachments (Terms of Use)
loggedToPortal (87.89 KB, image/png)
2018-04-09 15:26 UTC, Olimp Bockowski
no flags Details
portalTargetNotAvailable (54.43 KB, image/png)
2018-04-09 15:27 UTC, Olimp Bockowski
no flags Details
odd (51.24 KB, image/png)
2018-04-17 10:18 UTC, Olimp Bockowski
no flags Details
HypervisorLoggedProperly (71.57 KB, image/png)
2018-04-17 10:19 UTC, Olimp Bockowski
no flags Details
newPortalNotOnTheList (78.72 KB, image/png)
2018-04-17 10:20 UTC, Olimp Bockowski
no flags Details

Description Olimp Bockowski 2018-04-09 15:15:04 UTC
Description of problem:

When we want to create iSCSI bond using a new iSCSI Portal, then it is not visible in "Add iSCSI Bond" dialog window. A hypervisor is able to log into a new portal, connect to the existing Target, on hypervisor we can see iSCSI session, but it is volatile and storage_server_connections table doesn't have a nice combination portal/target.
   
Version-Release number of selected component (if applicable):

4.x


How reproducible:

Always


Steps to Reproduce:

I am going to describe the problem giving an example from my test environment:
so I have host having 1 default ovirtmgmt and 1 iSCSI Storage Domain. The hypervisor has 172.31.16.25/27 and iSCSI Storage has IP 172.31.16.19/27. Everything is working properly. Now, let's say I want to move it to the other network, 192.168.100.0/24. A hypervisor has 2 NICs with 192.168.100.15 and 192.168.100.16, Storage has 192.168.100.10. Going into GUI, I manage existing Storage Domain, edit, discover, put a new Portal (192.168.100.10:3260) and 
everything is ok:

[root@rhv-h3 ~]# iscsiadm -m session -P 1
Target: iqn.2003-01.org.linux-iscsi.storage.x8664:sn.c09e9c3328dd (non-flash)
	Current Portal: 192.168.100.10:3260,1
...
	Current Portal: 172.31.16.19:3260,1
	Persistent Portal: 172.31.16.19:3260,1

[root@rhv-h3 ~]# iscsiadm -m node  
172.31.16.19:3260,1 iqn.2003-01.org.linux-iscsi.storage.x8664:sn.c09e9c3328dd
192.168.100.10:3260,1 iqn.2003-01.org.linux-iscsi.storage.x8664:sn.c09e9c3328dd

in GUI not possible to pick up Logical Networks from 192.168.100.0/24 and target, there is only target with an old subnet

on Manager
engine=# select id,connection,iqn from storage_server_connections;
                  id                  |  connection  |                            iqn                            
--------------------------------------+--------------+-----------------------------------------------------------
 49e1bc60-3821-456f-b7ec-e77df60f267d | 172.31.16.19 | iqn.2003-01.org.linux-iscsi.storage.x8664:sn.c09e9c3328dd


Actual results:
can't use a combination of a new portal / target

Expected results:

Can we use a new combination of portal / target and then get rid of old one?

Additional info:


RHV Administration GUIDE and section "Configuring iSCSI Multipathing" is very spare

https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/administration_guide/sect-preparing_and_adding_block_storage#Configuring_iSCSI_Multipathing

I believe we should create a new section regarding migration existing iSCSI into a bonded network. Most of the customers build their environment in a simple way and then, after some time, they want to change. We have nothing about it in our official documentation. We should introduce some tested way to do that.

Comment 1 Olimp Bockowski 2018-04-09 15:19:11 UTC
if I have more time, I will try does REST request work.

Comment 2 Olimp Bockowski 2018-04-09 15:26:15 UTC
Created attachment 1419370 [details]
loggedToPortal

Comment 3 Olimp Bockowski 2018-04-09 15:27:20 UTC
Created attachment 1419371 [details]
portalTargetNotAvailable

Comment 4 Yaniv Kaul 2018-04-10 10:55:59 UTC
IIUC, you are trying to edit the current domain? Use the new addresses?
This is indeed not possible, I believe. You should remove the old one and create new one.

Comment 5 Olimp Bockowski 2018-04-10 14:44:47 UTC
@Yaniv 
yes, you have understood correctly. So at the moment, if it is not possible what are we going to do with it: either: 
1. leave as it is, 
2. try to change the current behavior? I could be wrong, but if on hypervisor part it is working properly, aren't we close enough to make it possible improving ovirt-engine?

And second matter: what about migration to iSCSI bond and official documentation? Do you agree with me we can test it and create doc BZ?
My current customer has a bond (from 2 NICs), on top of it Logical Network (responsible for storage connection). Now he wants to move it (without downtime) to iSCSI bond using the same subnet. I have tested such scenario, it is working properly: I broke the bond, prepared Logical Networks (not-required), attached to NICs, created iSCSI Bond, everything on a running hypervisor. It seems to be ok, but I afraid to give recommendations for production environments.

Comment 6 Yaniv Kaul 2018-04-10 16:20:35 UTC
(In reply to Olimp Bockowski from comment #5)
> @Yaniv 
> yes, you have understood correctly. So at the moment, if it is not possible
> what are we going to do with it: either: 
> 1. leave as it is, 
> 2. try to change the current behavior? I could be wrong, but if on
> hypervisor part it is working properly, aren't we close enough to make it
> possible improving ovirt-engine?

Perhaps. This is what this bug is about, right? I'm quite certain it's not that easy.

> 
> And second matter: what about migration to iSCSI bond and official
> documentation? Do you agree with me we can test it and create doc BZ?

Sure, but this is a separate item.

> My current customer has a bond (from 2 NICs), on top of it Logical Network
> (responsible for storage connection). Now he wants to move it (without
> downtime) to iSCSI bond using the same subnet. I have tested such scenario,
> it is working properly: I broke the bond, prepared Logical Networks
> (not-required), attached to NICs, created iSCSI Bond, everything on a
> running hypervisor. It seems to be ok, but I afraid to give recommendations
> for production environments.

Correct, it needs to be thoroughly tested with continuous IO.

Comment 7 Marian Jankular 2018-04-11 08:59:10 UTC
Hi,

can we test this on environment with continuous IO as Yaniv suggested?

Thanks in advance

Comment 8 Elad 2018-04-11 09:13:30 UTC
Kevin, please take a look

Comment 9 Kevin Alon Goldblatt 2018-04-15 11:58:51 UTC
(In reply to Yaniv Kaul from comment #4)
> IIUC, you are trying to edit the current domain? Use the new addresses?
> This is indeed not possible, I believe. You should remove the old one and
> create new one.

Yaniv, editing the domain address could be achieved by manage storage connection for iSCSI:

https://www.ovirt.org/develop/release-management/features/storage/manage-storage-connections/ 

However, this requires downtime as manage storage connections is possible only when the domain is in maintenance.

Comment 10 Yaniv Kaul 2018-04-15 12:06:33 UTC
(In reply to Kevin Alon Goldblatt from comment #9)
> (In reply to Yaniv Kaul from comment #4)
> > IIUC, you are trying to edit the current domain? Use the new addresses?
> > This is indeed not possible, I believe. You should remove the old one and
> > create new one.
> 
> Yaniv, editing the domain address could be achieved by manage storage
> connection for iSCSI:
> 
> https://www.ovirt.org/develop/release-management/features/storage/manage-
> storage-connections/ 
> 
> However, this requires downtime as manage storage connections is possible
> only when the domain is in maintenance.

Please read and respond to comment 5 .

Comment 11 Kevin Alon Goldblatt 2018-04-15 12:19:36 UTC
(In reply to Olimp Bockowski from comment #5)
> @Yaniv 
> yes, you have understood correctly. So at the moment, if it is not possible
> what are we going to do with it: either: 
> 1. leave as it is, 
> 2. try to change the current behavior? I could be wrong, but if on
> hypervisor part it is working properly, aren't we close enough to make it
> possible improving ovirt-engine?
> 
> And second matter: what about migration to iSCSI bond and official
> documentation? Do you agree with me we can test it and create doc BZ?
> My current customer has a bond (from 2 NICs), on top of it Logical Network
> (responsible for storage connection). Now he wants to move it (without
> downtime) to iSCSI bond using the same subnet. I have tested such scenario,
> it is working properly: I broke the bond, prepared Logical Networks
> (not-required), attached to NICs, created iSCSI Bond, everything on a
> running hypervisor. It seems to be ok, but I afraid to give recommendations
> for production environments.
After modifying an existing iSCSI bond with new connection details, an iSCSI sessions refresh is needed (by hosts/domain maintenance and re-activate), which requires downtime.
Have you done this?

Comment 12 Olimp Bockowski 2018-04-17 10:18:13 UTC
Ok, I tried it once again to take screenshots. The problem is that you are able to log into the same target using different portals, but "iSCSI Multipathing" doesn't allow you to use other portals (even if they are reported). Nothing changes this situation, neither SD maintenance nor hypervisor maintenance.  
But the most confusing is that you are able to create iSCSI bond using different subnets, e.g. I add target using portal 172.31.16.0/27 and Logical Network with NICs using 192.168.100.0/24
I am attaching 3 screenshots:
1. loggedProperly.png - you see that hypervisor/SPM is logged properly
2. noOptionToUseOtherPortal.png - create iSCSI bond without new portal
3. odd.png - mix of different subnets

Comment 13 Olimp Bockowski 2018-04-17 10:18:56 UTC
Created attachment 1422989 [details]
odd

Comment 14 Olimp Bockowski 2018-04-17 10:19:34 UTC
Created attachment 1422990 [details]
HypervisorLoggedProperly

Comment 15 Olimp Bockowski 2018-04-17 10:20:07 UTC
Created attachment 1422991 [details]
newPortalNotOnTheList

Comment 16 Kevin Alon Goldblatt 2018-06-19 17:31:06 UTC
This discussion was taken offline

Comment 17 Yaniv Lavi 2018-08-13 08:54:32 UTC

*** This bug has been marked as a duplicate of bug 1566415 ***


Note You need to log in before you can comment on or make changes to this bug.