[OpenIndiana-discuss] "shareiscsi" and COMSTAR

[Mike La Spina]

2012-06-27 4:51, Mike La Spina wrote:
>> Hi Jim,
>>
>>> 1) Is COMSTAR still not-integrated with shareiscsi ZFS attributes?
>>>     Or can the pool use the attribute, and the correct (new COMSTAR)
>>>     iSCSI target daemon will fire up?
>>
>> COMSTAR is not integrated with ZFS and it will ignore the ZFS props.
>
>Well, that was the case a couple of years ago when we played with the
newly released COMSTAR. We did not know whether the progress marched on
(to integrate ZFS >with COMSTAR) - hence the questions ;)
>
>> What is the release of the old host OS?
>
>
>SXCE snv_117... Well, it may be more than a couple of years :)

Yes very early COMSTAR code :)

>>
>> I strongly suggest you record the old iqn target names and the LU's 
>> they are mapped to, as well the LU GUID is helpful.
>
>Probably so, if only to check that the SMF/file-based config migration
attempt went well.
>
>> Snapshots on zvols are your friends!
>
>Unfortunately, they are not. The OS upgrade is part of the box's
migration to larger new drives, and so far it is very restrained on free
disk space in the pool. >ZVOL snapshots reserve the zvol size so as to
guarantee the ability to rewrite the whole zvol contents safely, and the
box can not afford that much wasted space. >Ability to do these
snapshots is indeed one of the many reasons for the overall upgrade
(HW+SW).

Then I would at minimum suggest a VM VMFS file level backup outside the
storage host scope.

Other option is to thin it out and free up that unused space then
snapshot it.
zfs set refreservation=none pool/esx/vol0
 
>>
>>
>>> 2) What would be the best way to migrate iSCSI server configuration
>>>     (LUs, views, allowed client lists, etc.) - is it sufficient to
>>>     just export the SMF config of "stmf" service, or do I also need
>>>     some other services and/or files (/etc/iscsi, something else?)
>>
>> This really depends on your current configuration .. can you provide 
>> some specifics of the existing targets/initiators?
>
>The targets are now a few zvols on the snv_117 box, served by COMSTAR
(svc:/system/stmf:default, svc:/network/iscsi/target:default).
>The service svc:/network/iscsi/initiator:default is also online, but it
was AFAIK used for testing and does not normally attach remote LUNs.
>
>Initiators that I know of are from free ESXi hosts, I'm uncertain about
the version.

It's fairly strait forward. You have two possible options.

1) Backup the manifest method.
"It will migrate every property and attribute, be it good or bad for the
new COMSTAR code"
"Suggest you look at and keep a diff on the manifest files"
"I have used this successfully from snv_134 to snv_148""

On the old host:
svccfg export -a stmf > stmf.cfg

note the -a parm "It will include the LU info and other elements."

if your moving the pool vdevs or creating a clean OS image with
importing (otherwise in-place = done)

On the new host:
svccfg export -a stmf > original-stmf.cfg 
svcadm disable stmf
svccfg delete stmf
svccfg import stmf.cfg
svcadm refresh stmf
svcadm enable stmf

2) Recreate the stmf properties method.
"Need to ensure your LU numbers are correct before the ESX host scans
them or you may have serious VMFS problems" 
"Ensures a healthy clean stmf manifest"  
"If you have more than one interface with an IP bound you should define
which IP(s) should be associated to the target using a portal group."

itadm create-tpg tpg1 ip? (assign the appropriate interfaces)
itadm create-target previous.target.iqn.name -t tpg1
itadm create-initatitor esx.iqn.initiator.name
stmfadm create-hg esx1
stmfadm add-hg-member -g esx1 esx.iqn.initiator.name

stmfadm import-lu /dev/zvol/rdsk/sp/store0/vol0
stmfadm add-view -n lu# lu-naa

...

Regards,
Mike