This is a old thread, but hopefully someone finds this useful:
1) To reassign disk ownership, you have to first unassign the disks.
This goes over that, but make sure you know exactly what you are doing first, have backups, etc.
Make sure you are not doing the base ONTAP aggregates.
https://communities.netapp.com/docs/DOC-5030
2) Yes, in your setup you have three disks per controller for the ONTAP install, that's the initial hit on usage.
After that, you could easily put them all in one aggregate, you just lose the full active/active controller speed.
Only one controller will be doing the work, which may be OK depending on your workload. Splitting it up
gives you more potential performance that is only lost during a controller failover. But then you lose some space by needing parity disks for each aggregate, and have to manage it more to maintain free space in each aggregate.
If you are going for a simple setup with less demanding I/O, one aggregate of all the free disks (with a spare reserved of course) is the simplest setup. Switching to a two aggregate setup later would be a very big hassle.
3) Consider getting the Netapp System Manager, or try the command line. Either one makes visualizing some of
these things easier, the web filer view will work but is a little less intuitive. Especially if you are networking guy,
the semi guided command line is a good way to drill into and organize the information quickly. Just be
careful when you issue commands, some of them execute immediately with no confirmation step.
4) You said two heads, no fiber switches, direct connect. You did not list the number of servers you are connecting. But you are right, you have 4 fiber connections per controller for a total of 8. And yes, something plugged into controller "2" will be able to see an aggregate currently controlled by controller "1". BUT - the performance is substandard on that. The two heads talk to each other over a "less than full speed" link. So a host only connected to controller "2" has to go through 2, over this link, then through 1 to get to the disk. This is not as fast as going through a switch and talking to the owning controller directly. I can't say how much slower, as in how much bandwidth you lose or latency you add, but it's a degraded setup. Best practice would be to have 4 ESX hosts in your scenario, and hook each of them up to each controller. IE host A has two HBA ports, one to controller 1 and one to controller 2. That way you have direct access to each controller. From there, use a multi pathing driver on the ESX hosts and ALUA on the NetApp (you set it per "initiator" or ESX host when setting them up) so the ESX boxes can figure out which controller is the fastest path to the disk. Or if you made one big aggregate, you could just plug all your Controller 1 connections in first, note them in your ESX servers and tell the multipathing driver to prefer that.
Don't know your ESX version but this is a good overview - notice the "Array Preference" uses ALUA.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1011340
If you are going over 4 ESX hosts and relying on that cross controller connection to access the disks,
I would seriously consider at least a single if not two smaller fiber switches like a Brocade 300.
If you have a bunch of hosts stacked on an ESX platform, you are concentrating a lot of I/O on
each fiber connection. A four way mesh from a pair of switches gives two paths to each controller from each
host and give the traffic some options and chances to load balance. You also get no outage
redundancy if you do it right - a single cable to storage from an ESX box will work but if that
cable or HBA goes flaky you have all those stacked virtuals in trouble then.
