Comment 5 for bug 1671397

​Thanks KC,
that makes it interesting.

On a restart it stops the service and starts it again - so there is nothing
the running program could take over other than what is in config files.
Yet on a reboot just the same happens, the difference is that the kernel
might have lost some context on the reboot.

While I still can't reproduce in my SAN env which doesn't have a concept
like the LUNZ->VRAID transition I wonder if we could somehow force your
environment to pick up the new data other than rebooting.

rescan-scsi-bus.sh has various options which might help here, please try
them one by one (ordered by increased potential impact to your system)
--forcerescan (rescan existing devs)
--issue-lip (login reset, not sure if that works on your devs or might
reset your provisioning)
--forceremove (drop and re-add each device)

rescan-scsi-bus.sh should call that (also one of the devices changed for
you), but to make sure this is not taking any path through
rescan-scsi-bus.sh that ends without issuing this you could also run as
root:
$ echo 1 > /sys/block/device_name/device/rescan

Please let me know if any of above four options would get your device
properly detected.