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.
if I have more time, I will try does REST request work.
Created attachment 1419370 [details] loggedToPortal
Created attachment 1419371 [details] portalTargetNotAvailable
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 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.
(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.
Hi, can we test this on environment with continuous IO as Yaniv suggested? Thanks in advance
Kevin, please take a look
(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.
(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 .
(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?
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
Created attachment 1422989 [details] odd
Created attachment 1422990 [details] HypervisorLoggedProperly
Created attachment 1422991 [details] newPortalNotOnTheList
This discussion was taken offline
*** This bug has been marked as a duplicate of bug 1566415 ***