> that forcing the entire virtual machine to page out and let it page > back in on the other side sounds logical and maybe not the most > complicated part. But remember it would be to DASD unless we also > architect shared XSTORE while we're at it.
Another approach would be to implement NUMA in CP. That would be useful for a number of scenarios (not just Linux) and not impose the idea of shared page space (shudder). IBM controls the ex-Sequent patents on NUMA implementation, which would be adaptable to this use; NUMA remote storage could be conceptually treated as another level of XSTORE, so the paging system could bring the guest to be transferred into main store and then page it out to the NUMA task on the destination host, allowing the destination to deal with it as it came in, and you'd get XSTORE support as a freebie (page from central to XSTORE to XXSTORE...8-)). > So most likely you would need something like PPRC over ISFC to build a > copy of the working set at the receiving side. The actual delay would > be just packing up the stuff that changed very recently, and restore > that on the other side. To do this efficiently, you'd need something like the above NUMA idea, I'd think. But, this is essentially what VMotion does, and it seems to work pretty well. > > One area that might be interesting would be to investigate a Linux > > device driver using CP *BLOCKIO services for disk I/O instead of > > directly addressing the disks. There would be a performance impact, but > > the additional layer of isolation would effectively remove any disk > > Most certainly. A high level interface offers gives much more > flexibility for running the guest. A "Virtual SAN" that offers the > guest "some blocks of disk" would make things much easier. VM would > then decide if and where to put the data in the SAN. > The current approach where intimate details about the disk device > (like WWPN etc) are kept inside Linux configuration files makes things > also very hard for what we talk about here. iSCSI support in CP would solve that problem relatively easily. That reduces the problem to network failover, which is a question of MAC takeover once you have the connectivity issues settled. This mailing list really needs a virtual whiteboard facility...8-) -- db
