> > No no ... it's not a question of how many guests can share an > > FCP adapter. The trouble is that directly connected guests are > > managerially more like discrete systems, so there is no way from VM > > to manage the storage. > > Why is it important that VM manage the storage? Why can't "give me a disk > xxx GB in size" be sent to the SAN fabric directly instead of to VM? I > mean, you still have to send the "give me a disk" request to the SAN in > order to provision the "primordial" pool managed by VM.
I think it has more to do with corporate structure and operations than any technical reason (although there are some good technical reasons, too). If your SAN is managed by a different group, then you gotta go hassle them for every single LUN you want. Asking them for a number of great big blobs that can be suballocated within VM w/o bugging anyone is a big win, especially given that almost none of the major SAN vendors really has any good handle on automation for allocating space (and getting the zoning and access control right is a bloody nightmare). This is an area where IBM, EMC, everyone that makes SAN hardware needs to do some work; the tools for managing storage virtualization in the SAN world *suck*. Even the arcane implementation in DIRMAINT is light-centuries ahead of the SAN world. So I can see Rick's point; putting the allocation management in the hands of something that DOES understand it and how to automate it is a good thing. > Just give the guest's WWPN access to the LUN(s). There's no need to move > adapters around. Of course, if you don't have a good management interface > on your SAN (storage and switches), then I can understand your point. See above. Even the few vendors who have usable automation can't get around the implementation piece and corporate politics.
