From: michael.christie@oracle.com
To: Dmitry Bogdanov <d.bogdanov@yadro.com>
Cc: Martin Petersen <martin.petersen@oracle.com>,
target-devel@vger.kernel.org,
Bart Van Assche <bvanassche@acm.org>,
linux-scsi@vger.kernel.org, linux@yadro.com
Subject: Re: [PATCH v2] scsi: target: alua: do not report emtpy port group
Date: Thu, 22 Sep 2022 11:26:29 -0500 [thread overview]
Message-ID: <e84419da-2950-3750-e6a1-af873c1253ac@oracle.com> (raw)
In-Reply-To: <20220915060840.GG9218@yadro.com>
On 9/15/22 1:08 AM, Dmitry Bogdanov wrote:
> On Wed, Sep 14, 2022 at 02:18:40PM -0500, Mike Christie wrote:
>>
>> On 9/12/22 4:45 PM, Dmitry Bogdanov wrote:
>>>> Remember how ESX used to send a RTPG to one port and expect that it got
>>>> every group and that the state info was all in sync (basically opposite
>>>> if what's in the spec now)?
>>>>
>>>> The spec and ESX were updated, but I don't know if other OSs did this and
>>>> if/when everyone was updated. Do you know this info? Are the old ESX versions
>>>> that worked like that end of life?
>>> ESXi is kinda a pain. But fortunately it has nothing to do with that
>>> patch 😄
>>
>> I didn't get why that is. How do you set up a distributed/cluster/HA target? I'm
>> probably missing that part.
>>
>> Software drivers like iscsi I get, but for HW drivers I didn't see how you do it.
>>
>> For example, if you have 2 systems/nodes running LIO which each export the same
>> device via 1 port each where one is active/optimized and the other is standby and you
>> are using qla2xxx, then on the local node would you create 2 groups:
>>
>> [root@ol8n4 alua]# pwd
>> /sys/kernel/config/target/core/iblock_0/device0/alua
>>
>> [root@ol8n4 alua]# ls
>> default_tg_pt_gp local remote
>>
>> Then under the mapped lun:
>>
>> [root@ol8n4 lun_0]# pwd
>> /sys/kernel/config/target/..../tpgt_1/lun/lun_0
>>
>> in the alua_tg_pt_gp file you set that to local. That would then have tg_pt_gp_members
>> set, but remote would not.
>>
>> Before your patch, windows and ESX could do a RTPG to just one port/path and we would
>> return the default, local and remote groups. We don't want the default group, but we
>> wanted the local and remote one returned. With your patch we only return the the local
>> one now. I wasn't sure how that works for drivers like qla2xxx.
>>
>> For iscsi, you could just mirror the remote node locally, so you would have a second
>> tpg:
>>
>> [root@ol8n4 lun_0]# pwd
>> /sys/kernel/config/target/..../tpgt_2/lun/lun_0
>>
>> and in there set alua_tg_pt_gp to remote. Your patch works fine for that because both
>> groups then have tg_pt_gp_members set so if the OS just does a RTPG to one path/port
>> you get all the groups.
>>
> I use a virtual remote fabric driver to configure wwn/iqn-tpg-lun of
> remote peers at each local node. In that way 'remote' alua port group
> will have ports(RTPI) too. That allows RTPG (and other discovery-like
> commands) report all ports in all port groups in the cluster.
> I sent it within the RFC patchset:
Ok shoot. I think this type of setup is not common, so the patch should be ok for most
users. However, I know people did do some complex setups and I'm worried those might
break.
I think the remote target patch is fine. Did that require any additional patches?
Maybe we could add that patch and your patch in this email at the same time and we
could migrate users.
What's your take?
next prev parent reply other threads:[~2022-09-22 16:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-12 12:54 [PATCH v2] scsi: target: alua: do not report emtpy port group Dmitry Bogdanov
2022-09-12 12:54 ` [PATCH v2] scsi: target: core: Set MULTIP bit for se_device with multiple ports Dmitry Bogdanov
2022-09-12 17:50 ` Mike Christie
2022-09-16 1:40 ` Martin K. Petersen
2022-09-12 17:49 ` [PATCH v2] scsi: target: alua: do not report emtpy port group Mike Christie
2022-09-12 21:45 ` Dmitry Bogdanov
2022-09-14 19:18 ` Mike Christie
2022-09-15 6:08 ` Dmitry Bogdanov
2022-09-22 16:26 ` michael.christie [this message]
2022-09-23 11:38 ` Dmitry Bogdanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e84419da-2950-3750-e6a1-af873c1253ac@oracle.com \
--to=michael.christie@oracle.com \
--cc=bvanassche@acm.org \
--cc=d.bogdanov@yadro.com \
--cc=linux-scsi@vger.kernel.org \
--cc=linux@yadro.com \
--cc=martin.petersen@oracle.com \
--cc=target-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox