On Sunday, 12/09/2007 at 09:18 EST, David Boyes <[EMAIL PROTECTED]> wrote: > > > 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).
The zoning and access control isn't going to go away just because CP is involved. Are you really suggesting inserting CP into the middle of SCSI I/O in order to create FC minidisks? If so, that requirement needs to be made with bold underscored italics to get attention. The current thinking is that guests need to be managed just like their distributed cousins when it comes to SAN connectivity. > 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. 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? There is a school of thought that VM needs to be treated as a 2nd-order storage controller that holds all that partially allocated storage and that those tools would first allocate physical storage to VM and then talk to VM to suballocate that storage (in physical storage increments, not minidisks!) to guests. Alan Altmark z/VM Development IBM Endicott
