> So how > do you tell: > (1) z/VM - bring up TCPIP with this alternate networking > information, and
I think also that VM TCPIP is smart enough to look at the system ID and execute a specific profile based on the system id. So, if your normal systemID is FOO1, if you have entries in SYSTEM NETID on the S disk that assign your normal CPUID to FOO1 and have a default value of DISASTER (or something like that) if there is no CPUID match, then you could have a FOO1 PROFILE for TCPIP as the "normal" setup and DISASTER PROFILE with the new information, and TCPIP would figure it out on it's own. No need to have a 2nd machine. Having VM be capable of being a DHCP client would be a nice improvement. Might be hard to do with the current OSA design, though. > The contingency of a real disaster occuring during the DR > test must be addressed. At that time the DR test must be > abandoned and the DR site must be brought online with the > real network information (so modifying the Linux networking > info in the DR site file systems is not a good option). IF you have your VM and guests in subdomains of your main domain, you can have a list of authoritative delegations for the subdomains. If you can make the primary unavailable (by definition in a DR, the primary is probably fried), then DNS will recurse to the secondaries, which could be a virtual machine. Or you can modify the responses sent via DHCP to point at a local DNS instance which has different data than the normal DNS servers. -- db ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
