> I suppose this is a normal behavior of z/VM to suspend dispatching the > guest due to the console I/O error. Do you think this is compatible with > running Linux under z/VM? Does anyone has this kind of concern when using > the console with Linux under z/VM ? CP Q SET shows RUN set to ON but it > seems this is not to sufficient, am I missing some other important > function > settings of the guest ?
Pardon if this sounds grumpy, but we've gone through this discussion several times in the recent past. To save recapping the entire argument again, the short summary is: 1) There is *zero* reason to log into the console of a running guest to do administration unless the guest system is completely broken and off the network entirely, and if it's *that* broken, it's not serving any useful functions anyway. 2) Your gun, your foot. The computer can't anticipate your desires; if you terminate the connection for some unexpected reason, the computer does what it's told architecturally; generate a console I/O error and halts execution (done as going to CP READ under VM). It's documented to do this, both in the VM manuals and in the Principles of Operation. It's working as designed, and more importantly, the way the real hardware would -- if the hardware console goes off on holiday during execution and generates a unanticipated hardware error in an LPAR or in basic mode, the machine stops. You lose, game over. VM gives you a 15 minute window to repent your sins and recover. This is Good. 3) If you're allowed to do that kind of open-skull brain surgery on a guest from the console, you have to be conscientious enough to ensure that you close down your sessions properly before you walk away. This behavior is not unique to VM at all -- it's exactly equivalent to hitting L1-A on a Sparc console and leaving it sitting at the "ok" PROM prompt -- you don't let people near your Sparc consoles if they don't know how to fix what they broke, or aren't responsible enough to be certain they fix it if they broke it. If your network between you and the VM system is *that* unreliable, then that's the problem you need to be fixing. Summary conclusion: Working as designed. Not likely to change. ---------------------------------------------------------------------- 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
