> The zoning and access control isn't going to go away just because CP is > involved.
Correct, but you don't have to do it as frequently, which is the point. There are too many places in the world where this stuff is done by hand by people with mouses. A lot of people like the EDEV approach because it minimizes the amount of time you have to wait for other people to do stuff, and the tools we have understand how to manage that right now without modifications. > The current thinking is > that guests need to be managed just like their distributed cousins when it > comes to SAN connectivity. I think this argument is full of "it depends on your organization". I'd argue that VM needs to provide a virtual analogue to a SAN switch, just as you currently provide the VSWITCH for data networking connectivity. IF that were the case, and VM implemented the SMI standard interconnects with external switches, then this problem goes away and we all live happily ever after because the SAN people connect me once and I look like any other peer switch in their fabric. Then we can talk about tooling and automation as peers, not as clients. 8-) > Wouldn't it be better to use tools that can talk to the storage > controllers, the switches, and VM (via SMI-S or CIM) in order to properly > orchestrate storage provisioning rather than trying to get the tail to wag > the dog? See above. That'd be the ideal solution, but that involves convincing people who normally report to different food chains, and going against the "management by glossy magazine" crowd who believe that GUI is god. 3 to 5 years out, this is the way to go. Right now, it's not a realistic or practical view in most organizations. If you're saying that we should port Aperi or one of the general storage manager tools that understand SMI-S, that's more interesting, especially if we can get it to understand CMS volumes.
