Re: zLinux User Passwords on console
I keep wondering about all this insistence on emulation etc. There must be something in between the HMC ASCII console (one per LPAR), and total emulation in software (capable of running thousands) I am thinking of what OSA-ICC does for 3270. Looking like a telnet server to the network and looking like a local tube to the host. A KVM switch mainframe style. How hard can it be to provide an ASCII session type in there? That will provide for several hundreds of console sessions and is utterly independent of host software, config etc. I think it would do nicely for big machines needing salvage and most sites will have no more than a few hundred of those. When it comes to thousands most of them will be appliance type things, where probably no time will be spent on salvaging. They will just be re-cloned, thus no need for a local console. Just a thought.. Best regards, Pieter Harder [EMAIL PROTECTED] tel +31-73-6837133 / +31-6-47272537 [EMAIL PROTECTED] 29-9-2006 1:09 Alan Altmark wrote: On Thursday, 09/28/2006 at 08:17 MST, Brandon Darbro [EMAIL PROTECTED] wrote: You know, linux can use serial ports as a console device... So why hasn't IBM come up with a virtual serial port type of console system to use instead? Something like having the console on /dev/ttyS0, and that via some z/VM magic, is available on an IP as a port number. Telnet to the port, and Linux's getty takes it from there. Or better yet, through some z/VM magic, the serial ports could be mapped to another Linux host's serial ports, say one set up as a console appliance... Then that appliance could be configured to allow access to them in a variety of ways, whether it be by port numbers, account names, ssh key, whatever. I've been imagining this for a long time now, and just wondered why IBM never did it. IBM *has* been imagining this for a long time, too. The good thing is that the cold compresses have been effective and the migraines don't occur as often now as they used to The problem has to do with block 3270 vs. serial NVT mode. You would enter the system in line mode and switch to 3270 as usual to get a VM logo and logon, then, by some miracle TBD, switch back to line mode (emulators aren't so good at this, btw). And then there's the whole ASCII/EBCDIC/ASCII translation thing. You really want a passthru mode LDEV. Unless you're connecting to an EBCDIC guest, of course. [The light is hurting my eyes now...I have to go lay down.] Does z/VM support (remote) 2741 terminals or similar? I don't suppose there are many 2741 terminals in captivity, but an emulation shouldn't be hard to do. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ Please do not reply off-list -- 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 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
Re: zLinux User Passwords on console
Adam Thornton [EMAIL PROTECTED] wrote: snip Grumble grumble where's my Geritol? WHICH OF YOU KIDS STOLE MY GERITOL? Adam, we now know your political aspirations: http://www.washingtonpost.com/wp-dyn/content/article/2006/09/23/AR2006092300768_pf.html (Look for cough syrup and keep reading...) ...phsiii -- 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
2006-09-29 Recommended Linux on System z code drop to developerWorks
Please refer to: http://www.ibm.com/developerworks/linux/linux390/whatsnew.html for the 2006-09-29 change summary: October 2005 stream and April 2004 stream: - s390-tools 1.5.4 with bug fixes * end of message Mit freundlichem Gruß / Kind regards, Gerhard Hiller eServer Software Management, D4357 IBM Development Lab, Boeblingen/Germany Phone ext. +49-(0)7031 - 16 - 4388 Internet: [EMAIL PROTECTED] -- 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
R/O dasd + ramdisk rescue system
This doesn't address the topic of 3270 linux console limitations but, Has anyone implemented Rob van der Heij's idea about a read-only-dasd rescue system that run's from ramdisk? I don't want to reinvent the wheel if someone's documented how they did it. I want to build one that automatically self-configures itself with the dead server's hostname, IP addrs, LDAP config, and its Tivoli Storage Manager client configuration. It would have the same 3270 console limitations, but if the network's up I'd have ssh access to a working system that could access all the disk, dasd or scsi, of the dead system and be much more useful than IPL-ing the Suse installation system (aka rescue system) from my reader. This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Thursday, September 28, 2006 4:53 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: zLinux User Passwords on console snip How 'bout : XAUTOLOG deadone STORAGE 512M IPL 200 Where the R/O disk 200 has a rescue system that will run from ramdisk, uses your central LDAP to authenticate (or has the well known root password) and tries to mount the file system as /sysimage or what have you. It should probably come up only with an IP address in your service network, not at the live (outside) network, but that's up to you. Bonus points if you make the rescue system in an NSS with a cool name. Obviously you could also let PROP do the autolog or use a web site to trigger it. Rob -- 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
Re: Suse S390 help?
OK. I'm not sure if this will help but I ran into a problem installing SUSE 9 under zVM 5.1. Could not get the dasd to partition. Or it seemed to partition but couldn't use it, it's been a while. Anyway, the way I got around it was to format the disks in CMS first, then start the install. The system then formatted them correctly and I was able to complete the install without any more problems. Strange but true. Bob -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Paul Dembry Sent: Thursday, September 28, 2006 10:00 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Suse S390 help? I only use 3390-3 emulated DASD on Hercules. Who knows, some day I might actually be able to get a z/Linux system on my work zSeries machine. It would be nice to just backup my Hercules disk images in some manner which would allow them to be restored on real zSeries DASD and IPL'ed. Again, I'm weird. Hmm perhaps SUSE s390 has a problem with a 3390-9 ( 2GB?). Seems odd but I'll try it again. On my last try, I looked around before starting yast. I found fdasd and I used it to create my partitions, eg fdasd /dev/dasda fdasd /dev/dasdb I then started the yast install procedure. The System Information section found my drives as usual and also showed the partitions. But when I got to the actual install, it still insisted that it could not create a partition proposal and when I opened up the partitioning section, my partitions were not there. Perhaps a clue. Anyway I'll try with a smaller system DASD and see what happens. Once I get this to work, I would next like to get LVM to work as well. Thanks for all the help! If I can just get past this point, I think I will have it installed. Centos was nice but neither Oracle nor DB2 install on it. BTW are you running S390 or S390x SUSE? Paul -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.407 / Virus Database: 268.12.9/458 - Release Date: 9/27/2006 -- 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 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
Re: R/O dasd + ramdisk rescue system
On 9/29/06, Romanowski, John (OFT) [EMAIL PROTECTED] wrote: Has anyone implemented Rob van der Heij's idea about a read-only-dasd rescue system that run's from ramdisk? I don't want to reinvent the wheel if someone's documented how they did it. We did not finish that work because we found in our shop the approach of linking to the dead penguin's disks much more attractive for various reasons. With the SuSE starter system you have most of it. You can use zipl to write the kernel image, parmfile and initrd to a small disk. If you IPL that you get the install starter system. The rest of it would be in /linuxrc and maybe some packages you must add to the initrd. The biggest hurdle in the system's self-configuring is getting the IP configuration. Once you have that you can go to LDAP or even do a wget against a web server to get all the details. We have discussed on the list various ways to do that. What I used myself was a separate service guest LAN that each server couples to. On that guest LAN you run your own virtual DHCP server that uses a fixed table to assign IP address based on the MAC address in the directory. In theory it should be good enough to have a fixed IP address for the penguin in rescue mode (do you really expect to run several in rescue mode at the same time). However, we learned that the YaST configuration was not really designed towards an approach where you have a different network location during system installation. To have a separate service IP address seems to be a good alternative if you want to avoid connecting the system to the bad Internet while you're still doing the install and testing things. Rob -- 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
Re: zLinux User Passwords on console
I see no reason why a virtual serial connection between vm's can't be created. The main reason is because the amount of overhead involved in implementing a byte-oriented processing paradigm on a block transfer oriented piece of hardware is known to be prohibitive. Other operating systems have tried it and failed due to this problem (AIX/370 is a good example). Everything you've asked for relies almost entirely on inexpensive single-character, byte-oriented I/O. There are *no* byte-oriented devices in the zSeries architecture -- all the things that ever did serial I/O on these boxes did it with outboard front-ends actually doing the serial port management and assembling entire lines to send to the host system -- the host CPU never ever saw the individual keystrokes. You could poll for characters, but that would be unbelievably expensive in processor time, which you don't have much of in the first place. There are things that provide a bit path, like IUCV or APPC, but they are also block-oriented and require lockstep send/receive processing, which leads back to the overhead argument. There are CTC and IUCV-based drivers for network access which leverage the packet nature of network I/O by doing an I/O to transfer a whole frame or network segment, so this doesn't look so bad -- but at that point, you're just as well to get the network working. This is exactly why network access is so critical to Linux on Z; you'd eat the machine alive if you tried to do I/O for individual bytes. The CTC driver for network access relies on a pair of CTCs to basically emulate a SLIP link over a null-modem cable, plus the physical link startup processing to decide who's master and who's slave. We used to have enormous problems with configuring networking because you had to cross-connect the CTCs and keep track of that to get things to work. But there has to be a way, and if there isn't, IBM should create a way. The Integrated ASCII Console feature of the HMC is basically that attempt. It doesn't scale very well, and it doesn't virtualize at all. You can get to it by connecting to the HMC over the network, but that opens up a whole 'nother can of worms wrt to access control, etc. Virtual serial connections can be useful for a lot more than just consoles. Positing the console problem as a known issue, I guess I'm not following what else you would propose to do with them that couldn't be handled by network-based connections or by the existing IUCV driver talking to the CP *MSG service. If you want to connect to serial ports on external boxes, you can connect to external terminal servers as reverse milking machines via network connections or LAT, and if you want to connect between guests, you can use a network connection just as easily (and then the same technique works inside and outside the box). There is already a LAT client and server if you want to attach terminals to specific applications w/o using telnet. If you just want to log console output, you can already use SCIF and PROP to handle that. Could you toss out some examples? I'm just not understanding, which is why I think we're asking you all these questions. -- 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
Re: R/O dasd + ramdisk rescue system
To get the parameters for self-configuring I was thinking of having the rescue system read them from a CMS file using Rick Troth's CMSFS utility functions. The dead server's unique CMS parm file could be created by hand in advance, or populated once or periodically by some type of export process from the live server. For an IP address I'm thinking the rescue system can just use the dead server's 'admin lan' address probably similar function to your 'service' lan. Instead of basing the rescue system on the starter system I'd like to just copy and convert an existing full-fledged server; and make it maintainable by Yast Online Update. That way I could easily add and maintain any packages I need for our environment, like the TSM restore client. When I boot the rescue system off R/W disk I can update it; when I boot it off R/O disk it assumes its rescue role. This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Friday, September 29, 2006 9:46 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: R/O dasd + ramdisk rescue system On 9/29/06, Romanowski, John (OFT) [EMAIL PROTECTED] wrote: Has anyone implemented Rob van der Heij's idea about a read-only-dasd rescue system that run's from ramdisk? I don't want to reinvent the wheel if someone's documented how they did it. We did not finish that work because we found in our shop the approach of linking to the dead penguin's disks much more attractive for various reasons. With the SuSE starter system you have most of it. You can use zipl to write the kernel image, parmfile and initrd to a small disk. If you IPL that you get the install starter system. The rest of it would be in /linuxrc and maybe some packages you must add to the initrd. The biggest hurdle in the system's self-configuring is getting the IP configuration. Once you have that you can go to LDAP or even do a wget against a web server to get all the details. We have discussed on the list various ways to do that. What I used myself was a separate service guest LAN that each server couples to. On that guest LAN you run your own virtual DHCP server that uses a fixed table to assign IP address based on the MAC address in the directory. In theory it should be good enough to have a fixed IP address for the penguin in rescue mode (do you really expect to run several in rescue mode at the same time). However, we learned that the YaST configuration was not really designed towards an approach where you have a different network location during system installation. To have a separate service IP address seems to be a good alternative if you want to avoid connecting the system to the bad Internet while you're still doing the install and testing things. Rob -- 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 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
Best Swap Disk Strategy?
My past installations have used 4 same-sized v-disk areas with ascending priorities. I was under the impression that Linux references an entire v-disk when it goes to swap, so smaller v-disks would be more efficient. But I'm not sure that's completely true. I want to simplify the fstab configuration and reduce the potential memory footprint, so I'm thinking of 1 moderate size v-disk, backed by 1 larger lower-priority DASD. The pair can be sized to whatever the applications require. Does anyone have a swap setup that optimizes performance and resource usage, i.e., more small v-disks vs fewer big ones, inclusion of real disk, etc.? Ray Mrohs U.S. Department of Justice 202-307-6896 -- 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
Re: zLinux User Passwords on console
A 2741 attached view a 270{1,2,3{ (I'd need to drag out tbe books to
rememebr which one) would probably do it.
You still didn't get the input at the host until the user pressed Enter,
so I'm not sure that that would be any significant improvement over the
3215. It still won't give you character-by-character I/O that vi and
friends demand.
--
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
Re: Best Swap Disk Strategy?
On 9/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: My past installations have used 4 same-sized v-disk areas with ascending priorities. I was under the impression that Linux references an entire v-disk when it goes to swap, so smaller v-disks would be more efficient. But I'm not sure that's completely true. I want to simplify the fstab configuration and reduce the potential memory footprint, so I'm thinking of 1 moderate size v-disk, backed by 1 larger lower-priority DASD. The pair can be sized to whatever the applications require. You're correct that it *does* make sense to have multiple vdisks for swap. The reason for that is the fact that Linux prefers to take fresh slots on the swap disk rather than re-use old slots that became free. Unfortunately VM does not know that Linux does not need those freed slots so it will go and write the pages to paging disk. That will eventually make your swap device slow. If you have vdisks for swap with different priority, Linux is forced to re-use the top one before using something else. The frequent references to that top disk also prevent that from being paged out when possible. The optimal size for those disks depends on the workload, but there's the rule of diminishing damage. Because the 2nd disk does not get used that much, the impact of slightly worse behavior is less as well. I think I once suggested to start with half the virtual machine size and double the size at each layer. That rule of thumb breaks with virtual machines 4GB :-) Your performance monitor will show you various things of the virtual disk. Like virtual I/O rate, resident pages, and paged out pages and paging rate. You want the top disk to be large enough that it still is used for swapping by Linux (and not sits there with swapped out stuff that is never referenced) and small enough that it does not get paged a lot by VM. If your memory requirements in Linux are very dynamic, you want the same analysis for the 2nd layer. Swapping to disk is only good for one thing, and that is to slow down the Linux server. While z/VM 5.2 does not slow it down as good as z/VM 5.1, swapping to disk is still pretty slow. If you don't mean to slow down Linux but only allocate swap space on disk just in case and not swap at it, why not give that to CP for paging device and give the virtual machine another big virtual disk. If you don't use the virtual disk, it's almost for free. When you do need to use it, it may be pretty quick if CP has real resources for you. I know someone who runs virtual machines with 16GB of swap space on vdisk each. You would need to monitor the behaviour of the system and set your tuning parameters right to prevent damage, but it can be very effective. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ -- 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
Re: zLinux User Passwords on console
Better yet, make them PVM clients over the CTC, and map that PVM session as /dev/console. Then you get all the cool automation stuff and multisession support of PVM as well. What kind of terminal are you sitting at? Seems to me if you're starting at a block-mode device you have problems. Well, actually not. After doing some digging around and by grace of friends with archives of ancient goodies (thanks, Arty!), the PVM link signon and session establishment protocols are really the only part that implies any structure on the communication. Once the link is active, it essentially boils down to passing data without translation (similar to the way tn3270 works -- negotiate a clean bitpipe, and then send raw 3270 frames back and forth over the connection, interpreting them at the endpoints as needed). PVM doesn't actually care what the data it's passing is, once the session is up and running -- you wouldn't even have to translate it to/from EBCDIC. The proposed console driver modifications would need to initialize the CTC connecting to PVM, initialize the link and signon, and then wrap the I/O to the console into PVM data packets. For completeness (and to keep PVM happy), the modified driver should also shut down the link and sign off properly at system shutdown. It might be a bit jerky due to the packetization of the I/O within the PVM protocols, but it won't be any worse than doing it over a console switch. With some slight adaptation of the way the 7171 provided a way to switch into a transparent mode, I think one could get a console stream that would permit what Brandon wants w/o re-engineering the world. What I haven't figured out yet is whether this would require substantial surgery to the client, or whether we'd be better off putting that surgery into a proxy server and doing it all once. The PVM internode protocol is quite sophisticated -- the designers planned very well for doing stuff like this. If we could get a Linux PVM daemon to communicate with PVM, and then do session mapping in that daemon, then we'd be home free without inventing lots of polyhedral wheels. This would also be a convenient way to be able to move the session mapping outside the 390 if we chose the PVM over IP driver as the communication to the console. Another thought is perhaps to use the existing LAT client and daemon as the starting point, since it already has the kind of session mapping code we want, and just rip out all the DECnet code and replace it with stuff to handle the PVM sessions. That could get us there quite quickly, and latd already has the concept of mapping specific terminals to specific applications, which (with a combination of some entries in inetd.conf) could allow 'telnet frontend ' to map to a specific console session with SSL protection, authentication, etc handled in the frontend. -- 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
Re: R/O dasd + ramdisk rescue system
On 9/29/06, Romanowski, John (OFT) [EMAIL PROTECTED] wrote: To get the parameters for self-configuring I was thinking of having the rescue system read them from a CMS file using Rick Troth's CMSFS utility functions. The dead server's unique CMS parm file could be created by hand in advance, or populated once or periodically by some type of export process from the live server. For an IP address I'm thinking the rescue system can just use the dead server's 'admin lan' address probably similar function to your 'service' lan. Sure. You can get the userid somewhere out of /proc and use that to pick up the file from a common R/O disk. But then you would probably also use this for normal configuration and not just rescue? If it's only used at startup you would still be pretty save in trying to update the files. And it's not even wrong to put the right parameters there just before you do the rescue IPL. Instead of basing the rescue system on the starter system I'd like to just copy and convert an existing full-fledged server; and make it maintainable by Yast Online Update. That way I could easily add and maintain any packages I need for our environment, like the TSM restore client. When I boot the rescue system off R/W disk I can update it; when I boot it off R/O disk it assumes its rescue role. I'm not sure it's that easy because with the way SuSE boots your normal system, the initrd role is already taken. So I think you would need to create something that merges the initrd (with the drivers) and the root file system. But your skills in that area or probably better than mine. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ -- 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
Re: Best Swap Disk Strategy?
Are there any plans for IBM and Novell to address this in the future with a patch to the kernel and re-use old slots? Managing multiple swap disks IMHO for each Linux is not an ideal solution. Mark -Original Message- From: Rob van der Heij [mailto:[EMAIL PROTECTED] Sent: Friday, September 29, 2006 7:44 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Best Swap Disk Strategy? On 9/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: My past installations have used 4 same-sized v-disk areas with ascending priorities. I was under the impression that Linux references an entire v-disk when it goes to swap, so smaller v-disks would be more efficient. But I'm not sure that's completely true. I want to simplify the fstab configuration and reduce the potential memory footprint, so I'm thinking of 1 moderate size v-disk, backed by 1 larger lower-priority DASD. The pair can be sized to whatever the applications require. You're correct that it *does* make sense to have multiple vdisks for swap. The reason for that is the fact that Linux prefers to take fresh slots on the swap disk rather than re-use old slots that became free. Unfortunately VM does not know that Linux does not need those freed slots so it will go and write the pages to paging disk. That will eventually make your swap device slow. If you have vdisks for swap with different priority, Linux is forced to re-use the top one before using something else. The frequent references to that top disk also prevent that from being paged out when possible. The optimal size for those disks depends on the workload, but there's the rule of diminishing damage. Because the 2nd disk does not get used that much, the impact of slightly worse behavior is less as well. I think I once suggested to start with half the virtual machine size and double the size at each layer. That rule of thumb breaks with virtual machines 4GB :-) Your performance monitor will show you various things of the virtual disk. Like virtual I/O rate, resident pages, and paged out pages and paging rate. You want the top disk to be large enough that it still is used for swapping by Linux (and not sits there with swapped out stuff that is never referenced) and small enough that it does not get paged a lot by VM. If your memory requirements in Linux are very dynamic, you want the same analysis for the 2nd layer. Swapping to disk is only good for one thing, and that is to slow down the Linux server. While z/VM 5.2 does not slow it down as good as z/VM 5.1, swapping to disk is still pretty slow. If you don't mean to slow down Linux but only allocate swap space on disk just in case and not swap at it, why not give that to CP for paging device and give the virtual machine another big virtual disk. If you don't use the virtual disk, it's almost for free. When you do need to use it, it may be pretty quick if CP has real resources for you. I know someone who runs virtual machines with 16GB of swap space on vdisk each. You would need to monitor the behaviour of the system and set your tuning parameters right to prevent damage, but it can be very effective. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ -- 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 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
Re: Best Swap Disk Strategy?
On 9/29/06, Brandt, Mark H [EMAIL PROTECTED] wrote: Are there any plans for IBM and Novell to address this in the future with a patch to the kernel and re-use old slots? It would need to be something that works for all platforms, not just for our virtual disks. The idea is that by using fresh slots you have a better chance to build long chains of adjacent blocks in a single I/O operation. If utilization is low enough, the moving cursor is an easy way to do that. With vdisk we're willing to take the overhead of many small I/O operations because the device is already fast enough (especially when your driver can exploit synchronous I/O completion). Managing multiple swap disks IMHO for each Linux is not an ideal solution. Am I overlooking something or is it just the extra entries in your fstab and the setup of the disks on VM ? Would your life be easier when CP would do the mkswap for you? I once suggested an enhancement to DEF VDISK ... LIKE name where name is the a DCSS that has the correct initial layout (because internally the structures are similar). But I think the idea is on the big pile outside behind building 250 in Endicott. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ -- 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
Re: Best Swap Disk Strategy?
On Sep 29, 2006, at 7:09 AM, [EMAIL PROTECTED] wrote: My past installations have used 4 same-sized v-disk areas with ascending priorities. I was under the impression that Linux references an entire v-disk when it goes to swap, so smaller v-disks would be more efficient. But I'm not sure that's completely true. I want to simplify the fstab configuration and reduce the potential memory footprint, so I'm thinking of 1 moderate size v-disk, backed by 1 larger lower-priority DASD. The pair can be sized to whatever the applications require. Does anyone have a swap setup that optimizes performance and resource usage, i.e., more small v-disks vs fewer big ones, inclusion of real disk, etc.? Depending on how big the guest is, I usually cascade three swap VDISKS of increasing size and decreasing (meaning the pri= number gets bigger), and then if I need it, a big swap on real disk below that. You could eliminate two of these VDISKS if you wanted. Adam -- 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
Re: zLinux User Passwords on console
David Boyes wrote: I see no reason why a virtual serial connection between vm's can't be created. The main reason is because the amount of overhead involved in implementing a byte-oriented processing paradigm on a block transfer oriented piece of hardware is known to be prohibitive. Other operating systems have tried it and failed due to this problem (AIX/370 is a good example). Everything you've asked for relies almost entirely on inexpensive single-character, byte-oriented I/O. There are *no* byte-oriented devices in the zSeries architecture -- all the things that ever did serial I/O on these boxes did it with outboard front-ends actually doing the serial port management and assembling entire lines to send to the host system -- the host CPU never ever saw the individual keystrokes. You could poll for characters, but that would be unbelievably expensive in processor time, which you don't have much of in the first place. There are things that provide a bit path, like IUCV or APPC, but they are also block-oriented and require lockstep send/receive processing, which leads back to the overhead argument. There are CTC and IUCV-based drivers for network access which leverage the packet nature of network I/O by doing an I/O to transfer a whole frame or network segment, so this doesn't look so bad -- but at that point, you're just as well to get the network working. This is exactly why network access is so critical to Linux on Z; you'd eat the machine alive if you tried to do I/O for individual bytes. The CTC driver for network access relies on a pair of CTCs to basically emulate a SLIP link over a null-modem cable, plus the physical link startup processing to decide who's master and who's slave. We used to have enormous problems with configuring networking because you had to cross-connect the CTCs and keep track of that to get things to work. But there has to be a way, and if there isn't, IBM should create a way. The Integrated ASCII Console feature of the HMC is basically that attempt. It doesn't scale very well, and it doesn't virtualize at all. You can get to it by connecting to the HMC over the network, but that opens up a whole 'nother can of worms wrt to access control, etc. Virtual serial connections can be useful for a lot more than just consoles. Positing the console problem as a known issue, I guess I'm not following what else you would propose to do with them that couldn't be handled by network-based connections or by the existing IUCV driver talking to the CP *MSG service. If you want to connect to serial ports on external boxes, you can connect to external terminal servers as reverse milking machines via network connections or LAT, and if you want to connect between guests, you can use a network connection just as easily (and then the same technique works inside and outside the box). There is already a LAT client and server if you want to attach terminals to specific applications w/o using telnet. If you just want to log console output, you can already use SCIF and PROP to handle that. Could you toss out some examples? I'm just not understanding, which is why I think we're asking you all these questions. Excellent information, thank you! An answer like this earlier would have shut me up right away. This was the can't be done or really shouldn't be done answer I needed to stop my dreaming. I really just didn't get that there was no byte oriented processing here. As for uses for serial connections and what to use them for, they are excellent for heart beats, for status and logging daemons, and even UUCP. Why use such old methods? Because they still work if the network goes down. Anyway, thanks for the information, and consider my push for this dropped. The guys in the mainframe group have seen this thread and one of them has asked me to leave it alone. (And to recognize you, Boyes, for the mainframe god that you are...) Sorry, *Brandon -- 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
Re: R/O dasd + ramdisk rescue system
There's an interesting start on this in the Bacula source distribution. It doesn't have the features that Rob listed, but most of the assembly parts needed to create such an animal are already in there. David Boyes Sine Nomine Associates Has anyone implemented Rob van der Heij's idea about a read-only-dasd rescue system that run's from ramdisk? I don't want to reinvent the wheel if someone's documented how they did it. I want to build one that automatically self-configures itself with the dead server's hostname, IP addrs, LDAP config, and its Tivoli Storage Manager client configuration. -- 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
Re: zLinux User Passwords on console
Excellent information, thank you! An answer like this earlier would have shut me up right away. This was the can't be done or really shouldn't be done answer I needed to stop my dreaming. I really just didn't get that there was no byte oriented processing here. That's the problem with mailing lists -- everybody looks smarter than they are from a distance...8-) The point isn't to shut you up, it's to understand what you're trying to accomplish. As for uses for serial connections and what to use them for, they are excellent for heart beats, for status and logging daemons, and even UUCP. Why use such old methods? Because they still work if the network goes down. Hey, nothing wrong with UUCP! I was the cause of the Apple II port of UUCP..8-) UUCP over TCP does work on 390, BTW. For the other stuff: check out the IUCV support for *MSG. VM has lots of nice ways to handle logging stuff, and that doesn't depend on the network. Anyway, thanks for the information, and consider my push for this dropped. The guys in the mainframe group have seen this thread and one of them has asked me to leave it alone. (And to recognize you, Boyes, for the mainframe god that you are...) That's wrong. You have as much right to pose problems and discuss them as anyone else. Some of the really useful stuff has come from exactly that kind of proposal. I'd rather you ask. In fact, consider yourself personally invited to do so. The discussion will be occasionally fairly stiff, but that's why it's useful. -- 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
Linux authentication/authorization via LDAP to ACF2 under zOS
does anybody know how to locate Peter (abresch). He was at Pepco in Aug/2005 but lost contact with him. As I understand it, Pepco implemented ACF2 version 8 under zOS with PAM/NSS on the Linux for z-Series communication via LDAP for authorization and authentication. This was accomplished without using the USS segment. if anybody has implemented this model, please let me know. We are trying to do the same. We got the password validation done but need to do the dataset validation next. -- 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
SUSE and FICON attached tape drives
A few years ago, I had SUSE 7 running, using my 3480 tape drives to backup to. It worked fine, but didn't handle end of volume too well. Then I upgraded it to use our escon attached 3590 B drives. No worry about EOV with 10 GB carts, at least not for what I was using it for. Now, I may have both, FCP attached IBM 3592-E05 (with encription) tape drives, and FICON attached IBM 3490 drives (virtual volumes within a VTS). The goal is to see if I can copy volumes that are stored in the VTS and stack them on a 3592 cart (with encription) for offsite storage. 1. Within the IBM unique code, can it handle FICON attached drives? 2. Within the IBM unique code, can it handle IBM 3490 drives (in this case, virtual drives)? 3. Within the IBM unique code, can I issue a mount command to the VTS to stage a particuler volser on a virtual 3490 drive? 4. Is there a Ditto for Linux or some other tape copying software that I might be able to copy hundreds of virtual 3490 volumes on a stacked 3592 volume? (A 3592-E05 can handle 500 GB native or 1.5 TB compressed.) I just got hit with a proposed change in our tape automation project, yesterday. Now it is time to explore other things that may now be available. Thanks Tom Duerbusch THD Consulting -- 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
Re: Best Swap Disk Strategy?
On 9/29/06, Adam Thornton [EMAIL PROTECTED] wrote: On Sep 29, 2006, at 7:09 AM, [EMAIL PROTECTED] wrote: My past installations have used 4 same-sized v-disk areas with ascending priorities. I was under the impression that Linux references an entire v-disk when it goes to swap, so smaller v-disks would be more efficient. But I'm not sure that's completely true. I want to simplify the fstab configuration and reduce the potential memory footprint, so I'm thinking of 1 moderate size v-disk, backed by 1 larger lower-priority DASD. The pair can be sized to whatever the applications require. Does anyone have a swap setup that optimizes performance and resource usage, i.e., more small v-disks vs fewer big ones, inclusion of real disk, etc.? Depending on how big the guest is, I usually cascade three swap VDISKS of increasing size and decreasing (meaning the pri= number gets bigger), and then if I need it, a big swap on real disk below that. You could eliminate two of these VDISKS if you wanted. Adam -- 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 We had problems when we ran out of SWAP space and the system locked up. At that time we had a v-disk of 512 MB only. We added two more SWAP spaces with a lower priority of 2 GB each. The linux guest machine has 4 GB of real memory defined. I have noticed that going over 512 GB of SWAP on the v-disk is a very rare occurence. am I better off with two additional SWAP spaces or should I break them up into smaller ones? -- 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
Betr.: Re: Best Swap Disk Strategy?
Depending on how big the guest is, I usually cascade three swap VDISKS of increasing size and decreasing (meaning the pri= number gets bigger), and then if I need it, a big swap on real disk below that. You could eliminate two of these VDISKS if you wanted. I beg to differ and second Rob's opinion. Give the real disk to CP as paging area and let CP figure it out. As Rob pointed out swapping on real disk just makes it slow. Think of all the processing required to do the I/O for that swap. That is the whole point of swapping to a DCSS, eliminate the I/O. Except that doesn't help when you are up to several GB in size. You then have to take the virtual I/O, but can at least eliminate the real part by using VDISK. The real I/O may still need to be done by CP to free up storage frames, but it is asynchronous to the guest, while guest swapping is totally synchronous. Best regards, Pieter Harder [EMAIL PROTECTED] tel +31-73-6837133 / +31-6-47272537 -- 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
Re: Suse S390 help?
OK. I'm not sure if this will help but I ran into a problem installing SUSE 9 under zVM 5.1. Could not get the dasd to partition. Or it seemed to partition but couldn't use it, it's been a while. Anyway, the way I got around it was to format the disks in CMS first, then start the install. The system then formatted them correctly and I was able to complete the install without any more problems. Thanks Bob. Someday I'll get around to installing VM over Hercules although I'm not sure that it's legal to do so. I have to check on that first. It sure would make life easier though. Paul -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.407 / Virus Database: 268.12.9/458 - Release Date: 9/27/2006 -- 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
Re: Best Swap Disk Strategy?
On Sep 29, 2006, at 10:47 AM, Yu Safin wrote: We had problems when we ran out of SWAP space and the system locked up. At that time we had a v-disk of 512 MB only. We added two more SWAP spaces with a lower priority of 2 GB each. The linux guest machine has 4 GB of real memory defined. I have noticed that going over 512 GB of SWAP on the v-disk is a very rare occurence. am I better off with two additional SWAP spaces or should I break them up into smaller ones? I would break them up smaller, but it basically boils down to a tradeoff of configuration complexity versus economy of allocation. If you have way more real storage than sysadmin time, leave two big ones; if you are short on storage, slice up the swap. Adam -- 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
Re: Suse S390 help?
On Sep 29, 2006, at 11:17 AM, Paul Dembry wrote: OK. I'm not sure if this will help but I ran into a problem installing SUSE 9 under zVM 5.1. Could not get the dasd to partition. Or it seemed to partition but couldn't use it, it's been a while. Anyway, the way I got around it was to format the disks in CMS first, then start the install. The system then formatted them correctly and I was able to complete the install without any more problems. Thanks Bob. Someday I'll get around to installing VM over Hercules although I'm not sure that it's legal to do so. I have to check on that first. It sure would make life easier though. I am pretty confident that it is, *if* VM is running in Hercules which is running on a Linux instance which is a guest of VM on the system that VM is licensed to. No, this is not a practical way to run VM. But it WAS cool seeing z/VM 4.4 come up (very very very slowly) in 64- bit mode on a 31-bit H70! Adam -- 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
Re: Best Swap Disk Strategy?
Would it be something as simple as a response time test to decide which swap algorithm to use? In a perfect world I'd like to simply give Linux one chunk of v-disk, and let the OS figure out how to use it. As server apps grow it gets riskier to mess with the fstab to add more v-disks, and we also end up with a bunch of non-standard disk layouts unless we plan well in advance. In the mean time, I think I'll standardize on 3 progressively sized v-disk addresses starting at .5 RAM, with no DASD swap. Thanks. Ray Mrohs U.S. Department of Justice 202-307-6896 It would need to be something that works for all platforms, not just for our virtual disks. The idea is that by using fresh slots you have a better chance to build long chains of adjacent blocks in a single I/O operation. If utilization is low enough, the moving cursor is an easy way to do that. With vdisk we're willing to take the overhead of many small I/O operations because the device is already fast enough (especially when your driver can exploit synchronous I/O completion). -- 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
Re: Best Swap Disk Strategy?
Ray, I defined eight vdisks as swap (the max that Linux can use, so I only have to mess with fstab once), each double the other, with descending priority so the smallest gets used first. When I see swap space starting to spill into some of the larger vdisks, I may increase the virtual machine size, and/or I may re-double the size of each in the VM directory, re-boot, and continue monitoring. For example, * /dev/dasds MDISK 212 FB-512 V-DISK 2000 MR * /dev/dasdt MDISK 213 FB-512 V-DISK 4000 MR * /dev/dasdu MDISK 214 FB-512 V-DISK 8000 MR * /dev/dasdv MDISK 215 FB-512 V-DISK 16000 MR * /dev/dasdw MDISK 216 FB-512 V-DISK 32000 MR * /dev/dasdx MDISK 217 FB-512 V-DISK 64000 MR * /dev/dasdy MDISK 218 FB-512 V-DISK 128000 MR * /dev/dasdz MDISK 219 FB-512 V-DISK 256000 MR Best regards, Mark [EMAIL PROTECTED] gov [EMAIL PROTECTED] To gov LINUX-390@VM.MARIST.EDU Sent by: Linux on cc 390 Port [EMAIL PROTECTED] Subject IST.EDU Re: Best Swap Disk Strategy? 09/29/2006 01:48 PM Please respond to Linux on 390 Port [EMAIL PROTECTED] IST.EDU Would it be something as simple as a response time test to decide which swap algorithm to use? In a perfect world I'd like to simply give Linux one chunk of v-disk, and let the OS figure out how to use it. As server apps grow it gets riskier to mess with the fstab to add more v-disks, and we also end up with a bunch of non-standard disk layouts unless we plan well in advance. In the mean time, I think I'll standardize on 3 progressively sized v-disk addresses starting at .5 RAM, with no DASD swap. Thanks. Ray Mrohs U.S. Department of Justice 202-307-6896 It would need to be something that works for all platforms, not just for our virtual disks. The idea is that by using fresh slots you have a better chance to build long chains of adjacent blocks in a single I/O operation. If utilization is low enough, the moving cursor is an easy way to do that. With vdisk we're willing to take the overhead of many small I/O operations because the device is already fast enough (especially when your driver can exploit synchronous I/O completion). -- 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 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
Re: Best Swap Disk Strategy?
Mark, When you're using that much vdisk, what is your total z/VM memory (real and expanded) how many guests are you running and are you in an overcommit state? The reason I ask is that we're running overcommited here and our head z/VM person had me stop using vdisk a long time ago because he was worried about our memory allocation. 6 gig real 1 gig expanded here, and we're using a goodly amount of it. -J Mark Wheeler [EMAIL PROTECTED] Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU To LINUX-390@VM.MARIST.EDU cc 09/29/2006 01:57 PM Subject Re: Best Swap Disk Strategy? Please respond to Linux on 390 Port LINUX-390@VM.MARIST.EDU Ray, I defined eight vdisks as swap (the max that Linux can use, so I only have to mess with fstab once), each double the other, with descending priority so the smallest gets used first. When I see swap space starting to spill into some of the larger vdisks, I may increase the virtual machine size, and/or I may re-double the size of each in the VM directory, re-boot, and continue monitoring. For example, * /dev/dasds MDISK 212 FB-512 V-DISK 2000 MR * /dev/dasdt MDISK 213 FB-512 V-DISK 4000 MR * /dev/dasdu MDISK 214 FB-512 V-DISK 8000 MR * /dev/dasdv MDISK 215 FB-512 V-DISK 16000 MR * /dev/dasdw MDISK 216 FB-512 V-DISK 32000 MR * /dev/dasdx MDISK 217 FB-512 V-DISK 64000 MR * /dev/dasdy MDISK 218 FB-512 V-DISK 128000 MR * /dev/dasdz MDISK 219 FB-512 V-DISK 256000 MR Best regards, Mark [EMAIL PROTECTED] gov [EMAIL PROTECTED] To gov LINUX-390@VM.MARIST.EDU Sent by: Linux on cc 390 Port [EMAIL PROTECTED] Subject IST.EDU Re: Best Swap Disk Strategy? 09/29/2006 01:48 PM Please respond to Linux on 390 Port [EMAIL PROTECTED] IST.EDU Would it be something as simple as a response time test to decide which swap algorithm to use? In a perfect world I'd like to simply give Linux one chunk of v-disk, and let the OS figure out how to use it. As server apps grow it gets riskier to mess with the fstab to add more v-disks, and we also end up with a bunch of non-standard disk layouts unless we plan well in advance. In the mean time, I think I'll standardize on 3 progressively sized v-disk addresses starting at .5 RAM, with no DASD swap. Thanks. Ray Mrohs U.S. Department of Justice 202-307-6896 It would need to be something that works for all platforms, not just for our virtual disks. The idea is that by using fresh slots you have a better chance to build long chains of adjacent blocks in a single I/O operation. If utilization is low enough, the moving cursor is an easy way to do that. With vdisk we're willing to take the overhead of many small I/O operations because the device is already fast enough (especially when your driver can exploit synchronous I/O completion). -- 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 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 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
Re: Best Swap Disk Strategy?
On 9/29/06, Mark Wheeler [EMAIL PROTECTED] wrote: Ray, I defined eight vdisks as swap (the max that Linux can use, so I only have to mess with fstab once), each double the other, with descending priority so the smallest gets used first. When I see swap space starting to spill into some of the larger vdisks, I may increase the virtual machine size, and/or I may re-double the size of each in the VM directory, re-boot, and continue monitoring. For example, * /dev/dasds MDISK 212 FB-512 V-DISK 2000 MR * /dev/dasdt MDISK 213 FB-512 V-DISK 4000 MR * /dev/dasdu MDISK 214 FB-512 V-DISK 8000 MR * /dev/dasdv MDISK 215 FB-512 V-DISK 16000 MR * /dev/dasdw MDISK 216 FB-512 V-DISK 32000 MR * /dev/dasdx MDISK 217 FB-512 V-DISK 64000 MR * /dev/dasdy MDISK 218 FB-512 V-DISK 128000 MR * /dev/dasdz MDISK 219 FB-512 V-DISK 256000 MR Best regards, Mark are those 512 Mbytes each? it seems like a lot to me to have that many unless you have a lot of real memory under zVM (central plus expanded). wouldn't you want to have a real disk just in case at the end for last resort? I am new at this game so it easy to get me confused but I am very attentive to the advise going on in this thread. -- 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
Re: zLinux User Passwords on console
On Sep 29, 2006, at 9:13 AM, David Boyes wrote: Adam, we now know your political aspirations: http://www.washingtonpost.com/wp- dyn/content/article/2006/09/23/AR2006092300768_pf.html (Look for cough syrup and keep reading...) Thornton for Congress. When you don't want to choose the *lesser* of two evils. 8-) -- db (and BTW, Adam did not approve this message. 8-)) Nor, indeed, do I wish a career in politics at such a paltry level. Thornton for Autocrat, that's my motto. Adam -- 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
NFS z/OS to z/Linux
there is a command on z/VM openvm pathdef create... Does anyone knows what is the z/OS for USS? Thanks - This message and its attachments may contain privileged and confidential information. If you are not the intended recipient(s), you are prohibited from printing, forwarding, saving or copying this email. If you have received this e-mail in error, please immediately notify the sender and delete this e-mail and its attachments from your computer. -- 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
Re: zLinux User Passwords on console
I want Beeblebrox's position. Jon snip Nor, indeed, do I wish a career in politics at such a paltry level. Thornton for Autocrat, that's my motto. /snip -- 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
Re: Best Swap Disk Strategy?
On 9/29/06, James Melin [EMAIL PROTECTED] wrote: The reason I ask is that we're running overcommited here and our head z/VM person had me stop using vdisk a long time ago because he was worried about our memory allocation. 6 gig real 1 gig expanded here, and we're using a goodly amount of it. Some of the fear for using vdisk comes from the days where CMS users used it as temporary disk space. That's a bit different from what we do with Linux swap disks. And some of us had the opinion that vdisk would not be paged out. It is good to overcommit a resource because that's the only way to share it. You just should not overcommit all your resources at the same time. I can't tell whether you should or should not use vdisk without seeing your data. I'm not even sure how you define your degree of memory overcommit and what data you use to measure it. But I can experiment and measure 100 running servers on a P/390 (128 MB real memory) and show what the performance penalty is for that. With z/VM 5.1 and before it was easy because Linux swapping to disk was a *real* bad idea for most installations. With z/VM 5.2 you can get away with a lot more. When you define big just in case swap disks it's almost for free as long as they don't get used. And when they do get used by some out-of-control process, it will just slow down things a bit if you tuned the system correctly. I only recall one case where that cause problems, and that was a system where they failed to use expanded storage for paging. If you don't trust it, do your experiments and measure. -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ -- 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
Re: Best Swap Disk Strategy?
Jim, I have 5.2 GB of vdisk allocated to 30 servers. q stor STORAGE = 14G Ready; T=0.01/0.01 16:30:43 q xst XSTORE= 2048M online= 2048M XSTORE= 2048M userid= SYSTEM usage= 48% retained= 0M pending= 0M XSTORE MDC min=0M, max=0M, usage=0% XSTORE= 2048M userid= (none) max. attach= 2048M Ready; T=0.01/0.01 16:30:48 q alloc page EXTENT EXTENT TOTAL PAGES HIGH% VOLID RDEV STARTEND PAGES IN USE PAGE USED -- -- -- -- -- -- L2PAG1 50D3 1001 10016 1585K 92403 245519 5% L2PAG2 50D4 1001 10016 1585K 115679 307496 7% L2PAG3 50D5 1001 10016 1585K 102740 245517 6% L2PAG4 50D6 1001 10016 1585K 181884 380158 11% -- -- SUMMARY6339K 492706 7% USABLE 6339K 492706 7% Ready; T=0.01/0.01 16:32:31 Best regards, James Melin [EMAIL PROTECTED] nepin.mn.us To Sent by: Linux on LINUX-390@VM.MARIST.EDU 390 Port cc [EMAIL PROTECTED] IST.EDU Subject Re: Best Swap Disk Strategy? 09/29/2006 02:07 PM Please respond to Linux on 390 Port [EMAIL PROTECTED] IST.EDU Mark, When you're using that much vdisk, what is your total z/VM memory (real and expanded) how many guests are you running and are you in an overcommit state? The reason I ask is that we're running overcommited here and our head z/VM person had me stop using vdisk a long time ago because he was worried about our memory allocation. 6 gig real 1 gig expanded here, and we're using a goodly amount of it. -J Mark Wheeler [EMAIL PROTECTED] Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU To LINUX-390@VM.MARIST.EDU cc 09/29/2006 01:57 PM Subject Re: Best Swap Disk Strategy? Please respond to Linux on 390 Port LINUX-390@VM.MARIST.EDU Ray, I defined eight vdisks as swap (the max that Linux can use, so I only have to mess with fstab once), each double the other, with descending priority so the smallest gets used first. When I see swap space starting to spill into some of the larger vdisks, I may increase the virtual machine size, and/or I may re-double the size of each in the VM directory, re-boot, and continue monitoring. For example, * /dev/dasds MDISK 212 FB-512 V-DISK 2000 MR * /dev/dasdt MDISK 213 FB-512 V-DISK 4000 MR * /dev/dasdu MDISK 214 FB-512 V-DISK 8000 MR * /dev/dasdv MDISK 215 FB-512 V-DISK 16000 MR * /dev/dasdw MDISK 216 FB-512 V-DISK 32000 MR * /dev/dasdx MDISK 217 FB-512 V-DISK 64000 MR * /dev/dasdy MDISK 218 FB-512 V-DISK 128000 MR * /dev/dasdz MDISK 219 FB-512 V-DISK 256000 MR Best regards, Mark [EMAIL PROTECTED] gov [EMAIL PROTECTED] To gov LINUX-390@VM.MARIST.EDU Sent by: Linux on cc 390 Port [EMAIL PROTECTED] Subject IST.EDU Re: Best Swap Disk Strategy? 09/29/2006 01:48 PM Please respond to Linux on 390 Port [EMAIL PROTECTED] IST.EDU Would it be something as simple as a response time test to decide which swap algorithm to use? In a perfect world I'd like to simply give Linux one chunk of v-disk, and let the OS figure out how to use it. As server apps grow it gets riskier to mess with the fstab to add more v-disks, and we also end up with a bunch of non-standard disk layouts unless we plan well in advance. In the mean time, I think I'll standardize on 3 progressively sized v-disk addresses starting at .5 RAM, with no DASD swap. Thanks. Ray Mrohs U.S. Department of Justice 202-307-6896 It would need to be something that works for all platforms, not just for our virtual disks. The idea is that by using fresh slots you have a better chance to build long chains of adjacent blocks in a single I/O operation. If utilization is low enough, the moving cursor is an easy way to do that. With vdisk we're willing to take the overhead of many small I/O operations because the device is already fast enough (especially when your driver can exploit synchronous I/O completion). -- For LINUX-390 subscribe / signoff /
Re: Best Swap Disk Strategy?
No, the first one is 2000 512-byte blocks. The second one is 4000 512-byte blocks, and so on. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Yu Safin Sent: Friday, September 29, 2006 3:36 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Best Swap Disk Strategy? On 9/29/06, Mark Wheeler [EMAIL PROTECTED] wrote: Ray, I defined eight vdisks as swap (the max that Linux can use, so I only have to mess with fstab once), each double the other, with descending priority so the smallest gets used first. When I see swap space starting to spill into some of the larger vdisks, I may increase the virtual machine size, and/or I may re-double the size of each in the VM directory, re-boot, and continue monitoring. For example, * /dev/dasds MDISK 212 FB-512 V-DISK 2000 MR * /dev/dasdt MDISK 213 FB-512 V-DISK 4000 MR * /dev/dasdu MDISK 214 FB-512 V-DISK 8000 MR * /dev/dasdv -snip- are those 512 Mbytes each? it seems like a lot to me to have that many unless you have a lot of real memory under zVM (central plus expanded). wouldn't you want to have a real disk just in case at the end for last resort? I am new at this game so it easy to get me confused but I am very attentive to the advise going on in this thread. -- 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
Re: Suse S390 help?
Adam Thornton wrote: On Sep 29, 2006, at 11:17 AM, Paul Dembry wrote: OK. I'm not sure if this will help but I ran into a problem installing SUSE 9 under zVM 5.1. Could not get the dasd to partition. Or it seemed to partition but couldn't use it, it's been a while. Anyway, the way I got around it was to format the disks in CMS first, then start the install. The system then formatted them correctly and I was able to complete the install without any more problems. Thanks Bob. Someday I'll get around to installing VM over Hercules although I'm not sure that it's legal to do so. I have to check on that first. It sure would make life easier though. I am pretty confident that it is, *if* VM is running in Hercules which is running on a Linux instance which is a guest of VM on the system that VM is licensed to. No, this is not a practical way to run VM. But it WAS cool seeing z/VM 4.4 come up (very very very slowly) in 64- bit mode on a 31-bit H70! I tell you, he's a nut. Next he'll be telling you he's run Windows on his zBox. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ Please do not reply off-list -- 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
Re: R/O dasd + ramdisk rescue system
Romanowski, John (OFT) wrote: To get the parameters for self-configuring I was thinking of having the rescue system read them from a CMS file using Rick Troth's CMSFS utility functions. The dead server's unique CMS parm file could be created by hand in advance, or populated once or periodically by some type of export process from the live server. For an IP address I'm thinking the rescue system can just use the dead server's 'admin lan' address probably similar function to your 'service' lan. Instead of basing the rescue system on the starter system I'd like to just copy and convert an existing full-fledged server; and make it maintainable by Yast Online Update. That way I could easily add and maintain any packages I need for our environment, like the TSM restore client. When I boot the rescue system off R/W disk I can update it; when I boot it off R/O disk it assumes its rescue role. This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Friday, September 29, 2006 9:46 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: R/O dasd + ramdisk rescue system On 9/29/06, Romanowski, John (OFT) [EMAIL PROTECTED] wrote: Has anyone implemented Rob van der Heij's idea about a read-only-dasd rescue system that run's from ramdisk? I don't want to reinvent the wheel if someone's documented how they did it. We did not finish that work because we found in our shop the approach of linking to the dead penguin's disks much more attractive for various reasons. With the SuSE starter system you have most of it. You can use zipl to write the kernel image, parmfile and initrd to a small disk. If you IPL that you get the install starter system. The rest of it would be in /linuxrc and maybe some packages you must add to the initrd. The biggest hurdle in the system's self-configuring is getting the IP configuration. Once you have that you can go to LDAP or even do a wget against a web server to get all the details. We have discussed on the list various ways to do that. What I used myself was a separate service guest LAN that each server couples to. On that guest LAN you run your own virtual DHCP server that uses a fixed table to assign IP address based on the MAC address in the directory. In theory it should be good enough to have a fixed IP address for the penguin in rescue mode (do you really expect to run several in rescue mode at the same time). However, we learned that the YaST configuration was not really designed towards an approach where you have a different network location during system installation. To have a separate service IP address seems to be a good alternative if you want to avoid connecting the system to the bad Internet while you're still doing the install and testing things. I reckon that once you have the corpse's /etc then you have close to all the info you need (unless there's a bit, maybe dhcp leases, in /var). -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ Please do not reply off-list -- 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
Re: zLinux User Passwords on console
Pieter Harder wrote: I keep wondering about all this insistence on emulation etc. There must be something in between the HMC ASCII console (one per LPAR), and total emulation in software (capable of running thousands) _I_ was suggesting a device that VM might emulate (present to Linux as a virtual keyboard-printer), and that being start/stop. might actually work well with Linux. I think there is/was an SNA start/stop device too, but I never programmed any SNA devices, so don't remember them so well. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ Please do not reply off-list -- 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
Re: zLinux User Passwords on console
David Boyes wrote:
I see no reason why a virtual serial connection between vm's can't be
created.
The main reason is because the amount of overhead involved in
implementing a byte-oriented processing paradigm on a block transfer
oriented piece of hardware is known to be prohibitive. Other operating
systems have tried it and failed due to this problem (AIX/370 is a good
example). Everything you've asked for relies almost entirely on
inexpensive single-character, byte-oriented I/O. There are *no*
byte-oriented devices in the zSeries architecture -- all the things that
ever did serial I/O on these boxes did it with outboard front-ends
actually doing the serial port management and assembling entire lines to
send to the host system -- the host CPU never ever saw the individual
keystrokes. You could poll for characters, but that would be
unbelievably expensive in processor time, which you don't have much of
in the first place.
There are things that provide a bit path, like IUCV or APPC, but they
are also block-oriented and require lockstep send/receive processing,
which leads back to the overhead argument. There are CTC and IUCV-based
drivers for network access which leverage the packet nature of network
I/O by doing an I/O to transfer a whole frame or network segment, so
this doesn't look so bad -- but at that point, you're just as well to
get the network working. This is exactly why network access is so
critical to Linux on Z; you'd eat the machine alive if you tried to do
I/O for individual bytes.
With a local 3270 (and presumably its related consoles) one can type
away and nothing happens in the host until you press an attention key
(enter, PFnn, PA{1,2,3} such).
That generates an interrupt in the host, and then the host issues a read.
This kind of approach, where the terminal generates an interrupt for
each key-press, wouldn't be so expensive. I imagine the host reading the
same kind of data from it as my PC reads/maintains from the keyboard -
shift-status key press/release.
Writing could, of course, be done in block mode as the byte-mode is just
a special case of a block.
This would require a local controller; perhaps a channel-attached
netvista would do,
Plus a driver for VM, and VM capability to emulate it and pass data through.
I don't think I'd recommend such a thing for regular use any more than
I'd suggest regular use of a 2741 (for those who don't remember it, it
was a terminal based on a Selectric golf-ball typewriter, not too
different from a 3210) or a 2740 (channel attached, similar device).
The CTC driver for network access relies on a pair of CTCs to basically
emulate a SLIP link over a null-modem cable, plus the physical link
startup processing to decide who's master and who's slave. We used to
have enormous problems with configuring networking because you had to
cross-connect the CTCs and keep track of that to get things to work.
But there has to be a way, and if there isn't, IBM
should create a way.
The Integrated ASCII Console feature of the HMC is basically that
attempt. It doesn't scale very well, and it doesn't virtualize at all.
You can get to it by connecting to the HMC over the network, but that
opens up a whole 'nother can of worms wrt to access control, etc.
Virtual serial connections can be useful for a lot
more than just consoles.
Positing the console problem as a known issue, I guess I'm not following
what else you would propose to do with them that couldn't be handled by
network-based connections or by the existing IUCV driver talking to the
CP *MSG service. If you want to connect to serial ports on external
boxes, you can connect to external terminal servers as reverse milking
machines via network connections or LAT, and if you want to connect
between guests, you can use a network connection just as easily (and
then the same technique works inside and outside the box). There is
already a LAT client and server if you want to attach terminals to
specific applications w/o using telnet. If you just want to log console
output, you can already use SCIF and PROP to handle that.
Could you toss out some examples? I'm just not understanding, which is
why I think we're asking you all these questions.
--
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
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
Please do not reply off-list
--
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
Re: Best Swap Disk Strategy?
Ray wrote: Would it be something as simple as a response time test to decide which swap algorithm to use? In a perfect world I'd like to simply give Linux one chunk of v-disk, and let the OS figure out how to use it. As server apps grow it gets riskier to mess with the fstab to add more v-disks, and we also end up with a bunch of non-standard disk layouts unless we plan well in advance. What I do is to just activate the swap in /etc/init.d/boot.local . It looks something like: /sbin/mkswap /dev/dasd/ff00/part1 /sbin/mkswap /dev/dasd/ff01/part1 /sbin/mkswap /dev/dasd/ff02/part1 /sbin/mkswap /dev/dasd/ff03/part1 /sbin/swapon /dev/dasd/ff00/part1 -p 4 /sbin/swapon /dev/dasd/ff01/part1 -p 3 /sbin/swapon /dev/dasd/ff02/part1 -p 2 /sbin/swapon /dev/dasd/ff03/part1 -p 1 Then I can control in the VM directory the sizes and if the disk(s) exist. The mkswap runs really really fast and no messing with /etc/fstab (or even logging in to linux to change it). Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -- 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
Re: zLinux User Passwords on console
David Boyes wrote:
A 2741 attached view a 270{1,2,3{ (I'd need to drag out tbe books to
rememebr which one) would probably do it.
You still didn't get the input at the host until the user pressed Enter,
Ah, I didn't know that. It was more a device I saw rather than used.
so I'm not sure that that would be any significant improvement over the
3215. It still won't give you character-by-character I/O that vi and
friends demand.
I'm starting to remember, the 3210 and 3215 had some kind of key to
press, to say Scuse me, I've got something to say.
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
Please do not reply off-list
--
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
Re: zLinux User Passwords on console
David Boyes wrote: I'd rather you ask. In fact, consider yourself personally invited to do so. The discussion will be occasionally fairly stiff, but that's why it's useful. For serious stiff, go read some Debian archives. We're the best of gentlefolk here. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ Please do not reply off-list -- 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
Re: Best Swap Disk Strategy?
Hi, On Fri, 29 Sep 2006 16:35:30 -0500 Mark Wheeler said: I have 5.2 GB of vdisk allocated to 30 servers. We have about 50G of vdisk allocated to 50 or so servers. I've completely removed the cap on vdisk allocation. We've also had great success using cmm to hide much of a server's memory, and dynamically adjusting the memory size based on swapping pressure. Yeah, we could DEFINE STORAGE and re-IPL, but why take an outage? Then again, z/VM 5.2 has completely spoiled us and we no longer fear very large virtual machine sizes. Cheers, Arty -- 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
