On Mon, 2015-11-30 at 01:06 +0000, Sam McLeod wrote: > Hi Nicholas, > > Thank you for your reply. > Please don't top post. It's annoying. > It seems Xen uses the SCSIID rather than the iSCSI unit serial number > when repairing or mapping storage, if it changes the mapping will > fail. > I'm still not sure what you mean by 'SCSIID'. If Xen is querying the SCSI INQUIRY EVPD=0x80 UNIT_SERIAL, or SCSI INQUIRY EVPD=0x83 DEVICE IDENTIFIER, then you need to follow my original instructions below, and make sure whatever cluster software you're using is setting this up across device + export fail-over events. That is, you need to make sure that: /sys/kernel/config/target/core/$HBA/$DEV/wwn/vpd_unit_serial contains the same value across device + export fail-over. Have you confirmed that yet..? > On the initiator side, what Xen cares about below is > 36001405bff3f42a49d84cfcb64e2b933, which is used for attaching the > storage LUN, I believe on other target software you can set the SCSIID > that is used for each LUN but not on LIO and thus when failing LUNs > between redundant nodes the SCSIID may change: > > # xe sr-param-list uuid=31474fd8-7d7b-84cb-bc34-16e1105470bf > uuid ( RO) : 31474fd8-7d7b-84cb-bc34-16e1105470bf > name-label ( RW): s1-alpha-two > name-description ( RW): iSCSI SR [10.51.40.65 (iqn.2003-01.org.linux-iscsi.s1-san5.x8664:sn.cb568058d955; LUN 1: bff3f42a-49d8-4cfc-b64e-2b933e98141d: 1781.7 GB (LIO-ORG))] > host ( RO): <shared> > allowed-operations (SRO): VDI.create; VDI.snapshot; PBD.create; PBD.destroy; plug; update; VDI.destroy; scan; VDI.clone; VDI.resize; unplug > current-operations (SRO): > VDIs (SRO): f8f79b41-b0fa-4e2c-b208-6223da9facef; e6285c4a-f56a-472b-b4af-bb90dd6b94bd; e20706f4-a057-466e-9482-67c855c14eed; cc547a9e-cd10-41c5-bab7-2454b1c0498d; c062e1e0-91c8-41f3-ad8d-1611919717da; b8e2195d-58a0-49a3-8076-8ef14e2437d9; b5b98a9a-3910-4e50-adc7-b90f7804aa6a; ab0905a5-ebb1-42c0-8c8c-00448efe7cc6; a5e9a887-3932-4e5f-abe2-46e1669e11dd; 9c6933d8-cda4-4162-bc7d-e0a34c386c8a; 5235607e-da46-4bf4-9e79-40deeb6eb043; 4e76d1f6-85d8-40b0-b910-f1a0bb2bda37; 48c4fdf3-6061-4531-baf4-6516d474c7ac; 2fe1ec65-41c3-43ac-9fb9-83d54dbe2f4f; 1e31bc13-bb6a-4336-a642-b11d4a519778 > PBDs (SRO): b6953525-57a2-96a1-fafb-ca85575a7a18; e7fd1d8d-e8d6-25a1-83ba-b63dc9906129; 5f8c8d0f-07cc-ec62-4d10-33cfc33ac0ae; 24a06e7f-da11-d47c-6cc6-ec34d814272e; 3e8b32fb-5596-31df-f7b6-8e421a7f0be8; 7457b26d-426c-20c0-e177-8260962ace2b; b1a0aa1f-3f06-d96f-fd0e-bfedc2d92969; 3a68f510-af9f-7d6f-17f5-c5a144902a13 > virtual-allocation ( RO): 661836005376 > physical-utilisation ( RO): 677900189696 > physical-size ( RO): 1913080774656 > type ( RO): lvmoiscsi > content-type ( RO): > shared ( RW): true > introduced-by ( RO): <not in database> > other-config (MRW): > sm-config (MRO): allocation: thick; use_vhd: true; multipathable: true; devserial: scsi-36001405bff3f42a49d84cfcb64e2b933 > blobs ( RO): > local-cache-enabled ( RO): false > tags (SRW): > > > > # sg_inq -i /dev/disk/by-scsid/36001405bff3f42a49d84cfcb64e2b933/sdm > VPD INQUIRY: Device Identification page > Designation descriptor number 1, descriptor length: 20 > id_type: NAA, code_set: Binary > associated with the addressed logical unit > NAA 6, IEEE Company_id: 0x1405 > Vendor Specific Identifier: 0xbff3f42a4 > Vendor Specific Identifier Extension: 0x9d84cfcb64e2b933 > [0x6001405bff3f42a49d84cfcb64e2b933] > Designation descriptor number 2, descriptor length: 62 > id_type: T10 vendor identification, code_set: ASCII > associated with the addressed logical unit > vendor id: LIO-ORG > vendor specific: iscsi_lun_r1:bff3f42a-49d8-4cfc-b64e-2b933e98141d > Designation descriptor number 3, descriptor length: 8 > transport: Internet SCSI (iSCSI) > id_type: Relative target port, code_set: Binary > associated with the target port > Relative target port: 0x1 > Designation descriptor number 4, descriptor length: 8 > transport: Internet SCSI (iSCSI) > id_type: Target port group, code_set: Binary > associated with the target port > Target port group: 0x0 > Designation descriptor number 5, descriptor length: 8 > id_type: Logical unit group, code_set: Binary > associated with the addressed logical unit > Logical unit group: 0x0 > Designation descriptor number 6, descriptor length: 72 > transport: Internet SCSI (iSCSI) > id_type: SCSI name string, code_set: UTF-8 > associated with the target port > SCSI name string: > iqn.2003-01.org.linux-iscsi.s1-san5.x8664:sn.cb568058d955,t,0x0001 > Designation descriptor number 7, descriptor length: 64 > transport: Internet SCSI (iSCSI) > id_type: SCSI name string, code_set: UTF-8 > associated with the target device that contains addressed lu > SCSI name string: > iqn.2003-01.org.linux-iscsi.s1-san5.x8664:sn.cb568058d955 > > > > > -- > Sam McLeod > > > > From: "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx> > Date: Monday, 30 November 2015 at 10:13 AM > To: Sam McLeod <samm@xxxxxxxxxxxxxxx> > Cc: "target-devel@xxxxxxxxxxxxxxx" <target-devel@xxxxxxxxxxxxxxx> > Subject: Re: Setting iSCSI SCSI ID with LIO? > > > >Hi Sam, > > > >On Mon, 2015-11-23 at 20:59 +0000, Sam McLeod wrote: > >> Hello, > >> > >> As many before me I need to set the SCSI ID for iSCSI interfaces under LIO. > >> I can do this with tgt and other legacy iSCSI targets but it seems LIO > >> doesn't have the ability to manage this? > >> > >> Setting the SCSI ID is important for iSCSI failover and iSCSI clustering to > >> ensure that initatiors can continue to connect to the target across > >> different and new hosts. > >> > >> Some initators will just use the iSCSI WWN / serial but many also need the > >> SCSI ID to remain consistant such as Xen or in our case XenServer (Citrix's > >> open source Xen product). > >> > >> There is a complecated way of maintaining SCSI ID consistancy with LIO which > >> involved enabling and managed PR with APTPL but we've found that to be > >> complex and fraught with problems when all that is require is to be able to > >> set the SCSI ID when the target is created just the same as you do the WWN > >> etc... > >> > > > >By SCSI ID, I assume you mean the SCSI Unit Serial number, that is used > >as the basis for EVPD 0x83 device identifier. (See sg_inq -i output) > > > >As mentioned in the follow-up from one of your references: > > > >http://www.spinics.net/lists/target-devel/msg02128.html > > > >and also more recently here: > > > >http://www.spinics.net/lists/target-devel/msg10494.html > > > >this value is exposed as a per device configfs attribute: > > > > /sys/kernel/config/target/core/$HBA/$DEV/wwn/vpd_unit_serial > > > >and if your performing export failover between physical nodes, you'll > >need to ensure these remain consistent for backend devices floating > >between nodes. > > > >HTH. > > > >--nab > NrybXǧv^){.n+j ׯzXܨ}Ơz&j:+vzZ++zfh~iz w?&)ߢf -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
