Accepted Solutions
Hi ginger8990,
It's me again 
In reviewing some of your recent posts I see you are hungry to learn, so I will throw a few more tidbits out there to nibble on. This is just my advice and how I do things, yours and other approaches may vary. Much of it you will already know so forgive me, but better too much than not enough I say.
Compatibility
Always check the compatibility and interoperability matrixes for all vendors involved. When in doubt escalate to a vendor and ask, it's their job to answer.
BIOS / Firmware
When upgrading, you may also take the opportunity during this downtime to update your server BIOS, Firmware, etc. to the desired standard.
vmkping
Once the server is back online and ESXi has been updated, you can confirm clean access to the storage by performing a vmkping to the filer IP from a putty/SSH session on the VMHost (especially useful for testing jumbo frames if you use that). Other than that, if you see that the datastores are not grayed out (i.e. you can right click and browse to them) then you should be good to go. Bring up a test VM and check things out.
NetApp VSC and Data OnTap Versions
Since you are upgrading your VMHost from 4.x to 5.x, this implies that the vCenter version was already upgraded (hard requirement as you know). I see you mentioned you are using the vCenter appliance (VCSA). Are you also using the Netapp VSC? If so this would be installed on a Windows server of some sort as I don't think it's supported on VCSA yet (but I could be wrong).
Review the version of your NetApp VSC plugin and talk to your Storage team to decide if they want to upgrade it. They might want to review their Data OnTap version among other things before deciding (OnTap version is also very relevant if seeking VAAI and SIOC features... don't worry about those last 2 if you haven't started down that path yet).
SMVI
After upgrading the VSC you should review the SMVI schedule (NetApp snapshots) if you use those. Don't skip the review of the SMVI or you may violate SLAs by missing nightly snapshots. The reason is that after a VSC upgrade your snap schedule may need to be reconfigured. Anyway, the VSC upgrade is optional, but desired.
Advanced Settings (vmkernel)
Using the traditional vSphere fat C#lient, you should also confirm that each of the ESXi hosts have the vmkernel advanced best practice settings for NFS. You can view your VMhost's compliance from the Home > NetApp plugin on the vSphere client. I don't have it in front of me now, but I think it's under "Host Discovery" within the plugin. Just scroll down to your host within the plugin and see if it's compliant. If not, you can right click and apply the settings to the VMHost in question (ESXi reboot required). The advanced settings can also be done manually in the vSphere Client for each host, or by using PowerCLI.
CDP Reports and Clean Communication
As always, before performing any upgrades, it's always handy to gather an RVTools report and save it off to Excel for reference. Also helpful is a CDP report (like this or that). The CDP report shows the network switch ports your host is connected to. Send this report to your network guys and tell them to "disregard reboots on the following interfaces while host upgrades are performed". It's always nice to communicate that, plus if you get into any trouble the ports in question are clear to everyone.
OOB (out-of-band access)
Ideally you should have out of band access to the server (i.e. KVM over IP, HP ILO, Dell iDRAC, IBM RSA, etc.). Those are all examples of technology used to reach the server when the mgmt interface cannot be reached on the network. If you don't have that, you should have physical access to the server, or schedule your upgrade when you know someone who does have physical access can reach the server if you get in trouble.
Time Sync and DNS
Just make sure the host is syncing to NTP properly and that the DNS addresses are correct. This is a common one that gets missed on fresh builds. Your upgrade should carry that over though without issue.
Host Profiles
If you use Host Profiles, the final step would be to update or create a new Host Profile from the newly updated reference host (Home > Host Profiles), then check the compliance of each upgraded host. This is done from the Hosts and Clusters view by selecting the Cluster in the left pane, and clicking on the "Profile Compliance" tab from the right pane. Next, right click the desired host and select "Check Profile Compliance" (then scroll way down to see if anything is failing the check). When in doubt, stick with upgrading one host at a time and test/prove your success.
Tools and vHardware for VMs
After the upgrade you may choose to update the VMware Tools, then the virtual hardware as usual (both optional and can be deferred to a later date to support easy roll-back to 4.x if required).
Note: Since you're going to 5.1 we still call it vHardware. In 5.5 it's called virtual compatibility. You can be several versions behind on this and still be supported. Most folks just get it done sooner than later though. Just always remember to do the Tools before the hardware. I think you have this one mastered though
Summary/Closing
Ok so that's a bunch of techno babble I just typed out (and trust me there's more) but the reality is you'd be fine not reading any of it and just upgrading. Just try and do your best to organize your approach and research / ask questions until you're comfortable. The best way to learn ultimately is by doing. Anyway, NFS is very forgiving and is probably the easiest thing to support in VMware. Good luck and have fun!
Some Additional Links:
New NFS Best Practices Whitepaper available | VMware vSphere Blog - VMware Blogs
https://communities.netapp.com/docs/DOC-23811
http://www.vmware.com/files/pdf/techpaper/VMware-NFS-Best-Practices-WP-EN-New.pdf
Hi ginger8990,
It's me again In reviewing some of your recent posts I see you are hungry to learn, so I will throw a few more tidbits out there to nibble on. This is just my advice and how I do things, yours and other approaches may vary. Much of it you will already know so forgive me, but better too much than not enough I say.
Compatibility
Always check the compatibility and interoperability matrixes for all vendors involved. When in doubt escalate to a vendor and ask, it's their job to answer.
BIOS / Firmware
When upgrading, you may also take the opportunity during this downtime to update your server BIOS, Firmware, etc. to the desired standard.
vmkping
Once the server is back online and ESXi has been updated, you can confirm clean access to the storage by performing a vmkping to the filer IP from a putty/SSH session on the VMHost (especially useful for testing jumbo frames if you use that). Other than that, if you see that the datastores are not grayed out (i.e. you can right click and browse to them) then you should be good to go. Bring up a test VM and check things out.
NetApp VSC and Data OnTap Versions
Since you are upgrading your VMHost from 4.x to 5.x, this implies that the vCenter version was already upgraded (hard requirement as you know). I see you mentioned you are using the vCenter appliance (VCSA). Are you also using the Netapp VSC? If so this would be installed on a Windows server of some sort as I don't think it's supported on VCSA yet (but I could be wrong).
Review the version of your NetApp VSC plugin and talk to your Storage team to decide if they want to upgrade it. They might want to review their Data OnTap version among other things before deciding (OnTap version is also very relevant if seeking VAAI and SIOC features... don't worry about those last 2 if you haven't started down that path yet).
SMVI
After upgrading the VSC you should review the SMVI schedule (NetApp snapshots) if you use those. Don't skip the review of the SMVI or you may violate SLAs by missing nightly snapshots. The reason is that after a VSC upgrade your snap schedule may need to be reconfigured. Anyway, the VSC upgrade is optional, but desired.
Advanced Settings (vmkernel)
Using the traditional vSphere fat C#lient, you should also confirm that each of the ESXi hosts have the vmkernel advanced best practice settings for NFS. You can view your VMhost's compliance from the Home > NetApp plugin on the vSphere client. I don't have it in front of me now, but I think it's under "Host Discovery" within the plugin. Just scroll down to your host within the plugin and see if it's compliant. If not, you can right click and apply the settings to the VMHost in question (ESXi reboot required). The advanced settings can also be done manually in the vSphere Client for each host, or by using PowerCLI.
CDP Reports and Clean Communication
As always, before performing any upgrades, it's always handy to gather an RVTools report and save it off to Excel for reference. Also helpful is a CDP report (like this or that). The CDP report shows the network switch ports your host is connected to. Send this report to your network guys and tell them to "disregard reboots on the following interfaces while host upgrades are performed". It's always nice to communicate that, plus if you get into any trouble the ports in question are clear to everyone.
OOB (out-of-band access)
Ideally you should have out of band access to the server (i.e. KVM over IP, HP ILO, Dell iDRAC, IBM RSA, etc.). Those are all examples of technology used to reach the server when the mgmt interface cannot be reached on the network. If you don't have that, you should have physical access to the server, or schedule your upgrade when you know someone who does have physical access can reach the server if you get in trouble.
Time Sync and DNS
Just make sure the host is syncing to NTP properly and that the DNS addresses are correct. This is a common one that gets missed on fresh builds. Your upgrade should carry that over though without issue.
Host Profiles
If you use Host Profiles, the final step would be to update or create a new Host Profile from the newly updated reference host (Home > Host Profiles), then check the compliance of each upgraded host. This is done from the Hosts and Clusters view by selecting the Cluster in the left pane, and clicking on the "Profile Compliance" tab from the right pane. Next, right click the desired host and select "Check Profile Compliance" (then scroll way down to see if anything is failing the check). When in doubt, stick with upgrading one host at a time and test/prove your success.
Tools and vHardware for VMs
After the upgrade you may choose to update the VMware Tools, then the virtual hardware as usual (both optional and can be deferred to a later date to support easy roll-back to 4.x if required).
Note: Since you're going to 5.1 we still call it vHardware. In 5.5 it's called virtual compatibility. You can be several versions behind on this and still be supported. Most folks just get it done sooner than later though. Just always remember to do the Tools before the hardware. I think you have this one mastered though
Summary/Closing
Ok so that's a bunch of techno babble I just typed out (and trust me there's more) but the reality is you'd be fine not reading any of it and just upgrading. Just try and do your best to organize your approach and research / ask questions until you're comfortable. The best way to learn ultimately is by doing. Anyway, NFS is very forgiving and is probably the easiest thing to support in VMware. Good luck and have fun!
Some Additional Links:
New NFS Best Practices Whitepaper available | VMware vSphere Blog - VMware Blogs
https://communities.netapp.com/docs/DOC-23811
http://www.vmware.com/files/pdf/techpaper/VMware-NFS-Best-Practices-WP-EN-New.pdf
