Hi,
I am pretty sure you will run into problems if you use vMotion or storage vMotion and your datastore is named (for example) datastore00 on one host and NFS_store00 on another (even if that is only temporary while you change it over.) As you are probably aware, both hosts need to be able to communicate to the same named datastores and virtual switches for these operations. So it's probably not a good idea to change the datastore name on the fly if you are using these features. From memory, if you do change it on the fly, you can end up with orphaned virtual machines and the inability to vMotion/storage vMotion the VMs between hosts during the change over.
Previously when faced by similar problems, I have provisioned a new datastore (which I mount on each of the hosts) and storage vMotioned the Virtual Machines (VMs) across before unmounting the old datastore from the hosts and remounting it with the new name. This of course requires available storage, network, processing overhead, and more importantly your time, while you move the VMs around. You might however, be able to perform (if you haven't already) a bit of deduplication and thin provisioning of your current volumes to free up some space in your aggregate to accommodate a new volume and datastore. You can then move the virtual machines back to their original datastores. Depending on the number of VMs you have this could take a while.
If you haven't already, you might also find it handy to look at jumbo frames on your storage VMKernel vSwitch, and physical switches, as well as looking into NetApp multi vifs and IP aliases. The NetApp VMWare Best practice guide (TR3749 is the most recent iteration I think) is pretty good at explaining this stuff.
Hope this helps
