At its core, SIOC is doing rapid checks against the datastore to test current storage conditions, including populating an always open file (iormstats.sf) with latency data used to help determine actions. These operations in essence block the unmount/detach process, which I imagine is a safety measure to protect hostd.
In normal operations this is not a big deal – an administrator can disable SIOC against a particular datastore and carry on doing their unmounts or whatnot. Even in a disaster failover in SRM, say for example you're doing a forced failover during a disaster, things should carry on quite happily. If the primary datastore can't get unmounted it won't stop the failover from ocurring, though it may generate some errors.
The problem comes when doing a planned migration, as a few of our customers and the gentleman at blocksandbytes documented.
Planned migration wants to ensure a clean unmount and detach of any datastore used by SRM and it will fail and halt the recovery plan should any errors be encountered. Since SIOC blocks an automated unmount/detach we can't do this step, and the planned migration will never complete until SIOC is disabled for the relevant datastores.
This is something that we're looking at doing differently in the future, but for now make sure this is part of your change control process:
When doing a planned migration, make sure you disable Storage IO Control before beginning.
Thanks to our great community (Messieurs McKaige, Lloyd) for bringing this to light!
