On 7/25/05, Joerg Reuter <[EMAIL PROTECTED]> wrote: > Quite frankly, in my opinion you really don't gain that much from this > feature (unless you have a great amount of almost identical guests, all > of them running the same kernel) and upgrading the kernel probably > becomes an administrative nightmare, if I understand the procedure > outlined in the redpaper on this correctly. If you want to be able to > reproduce the memory footprint of guests sharing the same files DCSS and > xip2 provide far more flexibility.
While we have the € in common, I beg to differ... We have the kernel modules on a disk that is shared R/O by all guests, and each of them simply IPL the NSS for the kernel they want. The good thing is that this way we have no serviceable parts inside and can upgrade / backout the kernel as we like for each of the guests. I do admit we have an easier way to save the NSS that aligns well with the way we manage system software in general but I have not been able to convince the relevant people that this approach is easier... There's also some goodness in having kernel code and static structures less likely paged out by z/VM. And you're right, the potential savings with sharing binaries in DCSS are larger (and probably harder to manage from a software management point of view). The kernel in NSS and binaries in DCSS are independent issues that must be implemented separately. Rob -- Rob van der Heij rvdheij @ gmail.com
