On Saturday, 12/08/2007 at 07:31 EST, Rick Troth <[EMAIL PROTECTED]> wrote: > > > Handing each guest its own HBA (host bus adapter, > > > the open systems term for and FCP adapter) kind of blows > > > one of the reasons to go virtual. > > > > Eh? 480 servers can use a single FCP adapter (chpid) concurrently. That's > > the whole point of N_port ID virtualization: 480 separate fabric > > endpoints. > > 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'm interested to know how the value of virtualization diminished by the lack of virtual FCP adapters. > N_port ID virtualization adds to this because the storage > is restricted to a specific FCP adapter. Then if we need to > give that LUN (or LUNs) to a different guest, we have to give > the FCP adapter to it. What if the recipient already has an FCP > adapter? It might be better to leverage the adapter already there. 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. But I don't think I'd lay that problem at VM's feet. Alan Altmark z/VM Development IBM Endicott
