Hello, We receive frequently this activity at Server Profile level:
The server profile's connections have access to volumes that are not managed by OneView. OneView may delete zones when the last managed volume is removed which could result in the loss of access to unmanaged volumes.
The Server Profile has only his 'Boot from SAN' created and managed by OneView, not other 3PAR volumes. We don't want that!
Is it possible to automatically clear those activities like in the HP SIM era? HP OneView: 2.00.02-0219211
This is an expected Warning message indicating that OneView cannot manage the other storage volumes, or paths to other unsupport FC/FCoE storage device. If you remove the BfS volume, which would be the only volume managed by OneView, it can delete the Host Alias on your Fabric switches, which in turn would remove FC Zone access to the other storage device. You can Clear this message, but you cannot delete it. This is by design of HPE OneView.
We have recently upgraded to 3.00.07 and have found ourselves plagued with the same pervasive message. I will be calling support to address the issue, but it would be a sad day if the answer I received back from HPE support was inline with your comment Chris. The problem with useless alerts (or alertable conditions which we have specifically put in place from a design perspective) is that they mask those that are USEFUL. For example, I can no longer see when my profiles have drifted from the templates because the valid warning that "The server profile is incosistent with its server profile template" (which turns the profile a yellow color), which is actually helpful and actionable, is now masked by a sea of useless "warnings" also turning the node a yellow color. Sure, I can clear the useless alerts, but they come right back the next day. And the fact that you can't "opt out" of them makes it simply a nuisance.
BTW, I couldn't build my peer-persistence-based custom OSStores into my profile templates if I wanted to. And even if I could, talk about a nightmare just to add two more peer-persistence-enabled volumes to an existing ESX cluster...
