it depends what you understand as "disrupt connectivity"  a reboot - no matter how fast - will always be kind of disruptive on the lower levels and a client will have to at least re-establish the TCP connection The question is more how much of that is visible to the client OS and application  NFS clients using default hard mounts will just see a pause in I/O but no error to applications The OS and protocol stack will of course re-establish the connection, recover locks, ....  for CIFS clients it depends on the application and OS Windows itself will automatically reconnect cluster aware application that retry internally should be ok simple applications like copying files via explorer.exe can stop and show a "Try again" dialog  For those application that really require transparent failover  - like SharePoint or Hyper-V over SMB shares you can enable SMB CA (Continuous Availability) per share then they will also just pause and resume I/O similar to NFS  See the NAS white paper and Microsoft details about CA in SMB3  Why dont you just try it ??  all an upgrade is doing is a SP reboot - which you can easily do even from the GUI If you dont want to use your hardware Unity as VSA will show the same behaviour
Hi All,  Is the Unity OE upgrade going to disrupt connectivity to the CIFS and NFS shares that are configured on the array? As far as I understands how it is configured, and how it is supposed to work, it will be a disruptive activity. However I cannot find any kind of confirmation for that on the DELL EMC support site, or any KBs, whitepapers that would prove the opposite.  Has anyone had any recent experience with upgrading Unity OE on the Unity that has file shares configured? If so, can you please share what exactly happened to the client connections to the file shares and how you handled it, if you had to do anything at all?  Appreciate your input.
Upgrading OE on Unity that is configured for file services only