I have never used Instant Recovery for SQL so cannot comment but would think restarting SQL services would be a bad idea regardless.  I would also think a restart would break the instant recovery connection to SQL server as well but again never used this method.

This is a new feature in v12 and apparently, Veeam does not have enough information what happens if the DB in Recovery Pending is restarted. I think the FLR running the background would not get affected but not sure what happens to the data in the IR cache or what state will the DB be after the restart. 

This feature is actually 2 processes. One is connecting a read-only version of the DB (updates are written to a cache), the 2nd part is the actual file restore of the DB files.

For our case, the read-only version DB went off-line due unable to access Veeam created pointers to the DB files. But the file restore continued. However, when it is time to merge, Veeam threw an error related to the errors that caused the DB to be offline

Error    Failed to instant recovery item asdfasdf (Type: Database; Source: server1; Target: server1). Database restore failed: Asynchronous read operation failed.  The request failed due to a fatal device hardware error.  

The system failed to flush data to the transaction log. Corruption may occur in VolumeId: C:\VeeamFLR\server1_5c8d2abc\Volume9, DeviceName: \Device\HarddiskVolume450.
(The request failed due to a fatal device hardware error.)

We verified that there is no error on vSphere/storage side. 

So now all of the new data that got stored in the Instant Recovery Cache are corrupted :-(

Wondering how do we salvage the situation. Definitely we can bring the DB online but need to recover most of the data if not all.