On 1/23/07, Thomas Kern <[EMAIL PROTECTED]> wrote:
Could this "Virtual San" be some modification of the Shared/Byte File System server? With IPGATE, that could even be used across LPARs via hypersockets and across physical machines via other TCPIP connections.
Well, that's basically NFS to serve BFS space. While I admit we never had the need to study it in more detail, so far I have not been impressed by the performance of the VM NFS server. If you're going NFS then I suppose it would be more realistic to have a Linux server host it. But each Linux virtual machine would still need its own local disk space to hold the basic materials to get the network going (or maybe do something with an NSS or implement booting from network). Have not looked at iSCSI in detail yet. Some folks I respect tell me not to do that... You sort of have the concept with the "emulated FBA device" where you give the server a chunk of disk space and let z/VM determine where it is kept. Unfortunately both Linux and CP have to go a long way in dealing with emulation details because the underlaying model was not meant for this. While standing at the virtual white board... Since CP can already provide some form of virtual QDIO devices, it would seem more attractive to enhance that into virtual FCP. The good thing about that is also that it allows CP flexibility in reordering the I/O requests and perform them in a way that makes sense on a global level. Some interaction between CP paging and this virtual FCP might be very attractive. The scope of things like WWPN in Linux would be local to the z/VM system, and up to CP to interpret (e.g. to distinguish between swap space and real data). Rob
