Ok, yes I see. The problem I wanted solve was that I need to know a zLinux server should umount and detatch a shared disk. We have the two z/VM systems connected and it allows only one to LINK to the disk at a time. But I cannot LINK if the disk isn't released, so the server having it mounted need to figure out when to disconnect the disk and send some signal to the other server that that one now should LINK to that disk.
So in case of network problem I figure I may could use vmur. But it may be kind of difficult. /Tore Cordialement / Vriendelijke Groeten / Best Regards / Med Vänliga Hälsningar Tore Agblad Volvo Information Technology Infrastructure Mainframe Design & Development SE-405 08, Gothenburg Sweden E-mail: [email protected] http://www.volvo.com/volvoit/global/en-gb/ ________________________________________ From: Linux on 390 Port [[email protected]] On Behalf Of Alan Altmark [[email protected]] Sent: Thursday, September 09, 2010 15:00 To: [email protected] Subject: Re: vmur usage ? On Thursday, 09/09/2010 at 03:55 EDT, Agblad Tore <[email protected]> wrote: > Hi all. > Is there anybody using vmur for communication, implemented > by any scripts or similiar ? > > We would like to use disks owned by a non-booting z/VM userid > that one out of two zLinux machines can LINK to in write mode. > It's used to get one filesystem accessible from any of two servers > to get redundancy/failover/you-know-what-I-mean :) > The two linux machines is in two separate z/VM systems - z10 boxes - > computer-halls > and the disk used here is shared. z/VM also controls that only one at a time > can LINK to the disk in Write mode. > ACF2 rules determine who can LINK to the disk (Yes we have ACF2 even in z/VM) > > I already have to scripts doing the LINK x x x W, dasd_configure .... 1 1, mount > and the opposite: umount, dasd_configure .... 0 0, DET > > works nice, but we also need some automatic switching, and using vmur will > get it working despite any network failure. I don't follow your reasoning, Tore. vmur isn't going to help you unless you have shared spool, and THAT won't help you if one of the systems goes down since cross-system spool (part of CSE) only operates when the system that generated a spool file is actually up. And it requires PVM which will be using some sort of comms channel. Detecting that another system is actually dead is more complicated than simple signalling. Remember that communication links can go down while servers remain up, and it is imperative that you do not start using resources that you cannot guarantee are not being used by someone else. There are free z/VM technologies like cross-system LINK (XLINK) that can help, but that simply moves the problem - it doesn't get rid of it. (The IT equivalent of the arcade game 'Whack-a-mole'.) That's why products like Tivoli Systems Automation were built. When z/VM Single System Image is available, it will greatly simplify your ability to reliably detect the loss of a peer VM system, since it uses two different signalling mechanisms. You'll be able to just issue LINK M every n seconds. If the LINK succeeds, the other VM system is down (detected or declared), or the other virtual machine has relinquished the link. Alan Altmark z/VM Development IBM Endicott ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/ ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
