New draft redbook: Virtualization Cookbook Volume 2: RHEL 7.1
The Virtualization Cookbook for IBM z Systems Volume 2: Red Hat Enterprise Linux 7.1 http://www.redbooks.ibm.com/redpieces/abstracts/sg248303.html?Open Abstract This IBM® Redbooks® publication is Volume 2 of a series of three books called The Virtualization Cookbook for IBM z Systems . The other two volumes are called: The Virtualization Cookbook for IBM z Systems Volume 1: IBM z/VM® 6.3, SG24-8147 The Virtualization Cookbook for IBM z Systems Volume 3: SUSE Linux Enterprise Server 12, SG24-8890 It is recommended that you start with Volume 1 of this series as IBM z/VM is the base "layer" when installing Linux on z Systems. Volume 1 starts with an introduction, discusses planning, then describes z/VM installation into a two-node single system image (SSI) cluster, configuration, hardening, automation, and servicing. It adopts a cookbook format that provides a concise, repeatable set of procedures for installing and configuring z/VM using the Single System Image (SSI) clustering feature. Volumes 2 and 3 describe how to roll your own Linux virtual servers on IBM z Systems hardware under IBM z/VM. The cookbook format continues with installing and customizing Linux. Volume 2 focuses on Red Hat Enterprise Linux (RHEL). It consists of the following chapters: Chapter 1, "Install RHEL on LNXADMIN" on page 3, describes how to install and configure RHEL 6.4 onto the Linux Administration server, which does the cloning and other tasks. Chapter 2, "Automated RHEL installations using kickstart" on page 27, describes how to use Red Hat's kickstart tool to create Linux systems. This is fundamentally different from cloning in that an automated installation is implemented. You can try kickstart and you can also try cloning. Understand that they try to accomplish the same goal of being able to quickly get Linux systems up and running, and that you do not need to use both. Chapter 3, "Service RHEL with Red Hat Customer Portal" on page 37, describes how the Red Hat Network works. It provides centralized management and provisioning for multiple RHEL 6.4 systems. Kickstart is a very easy and fast way to provision you Linux guests in any supported Linux platform. It re-creates the operating system (OS) from scratch by using the kickstart profile configuration file that installs the new OS unintended and sets up the new guest according to what was predefined in the kickstart file. Usually, Linux administration is done by the same team that manages Linux on all platforms. By using kickstart, you can create a basic profile that can be used in all supported platforms and customize Linux profiles as needed. Cloning is another technique to provision Linux guests. This requires a better understanding of the z/VM environment and z/VM skills. It is a very fast process if the client has the FLASHCOPY feature enabled. It basically clones the discs from a golden image to new discs that will be used by the new Linux guest. The process can be automated using the cloning scripts supplied with this book.. -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: How to find a memory leak?
Let me try a different example than Mike's 'Q DASD DETAILS 0-': Suppose you are writing software for disaster recovery of LVM disks. The Linux that owned them will not come up so you link them from another Linux. Get a list of minidisk addresses and their owners and issue LINK against each. LINK needs a local virtual address that is also free. You don't know who will be using this so this needs to work in any configuration. You can ask the user to provide a range in a config file, but it would be nicer if you could find the range automatically. You could run QUERY VIRTUAL and find which virtual addresses are occupied. Once you start doing this, you run QUERY VIRTUAL every time you need to find free address, i.e. even when you have a few minidisks linked. But at this point you realize that you program is unreliable because it can occasionally fail due to memory fragmentation, because to list all the used virtual addresses you need a large contiguous buffer in the kernel. What people wrote about reading the response of vmcp and enlarging the buffer if needed helps in the average scenario but does not help the worst case scenario. So if you are using vmcp in critical code you have to be very careful about keeping buffers small. It would be nice if this was not necessary, i.e. if there was a way to run DIAG 8 without the need for contiguous buffer. Tomas
Re: How to find a memory leak?
On Monday, 07/13/2015 at 11:12 EDT, Michael MacIsaac wrote: > I thought you also pointed out that CMS found a way to work around it (or > maybe that was Chuckie). I thought, perhaps naively, that Linux may be > able to work around it also. Sorry, Mike. I thought you were still talking about the "large memory" problem. There are two different (and independent) issues: 1. DIAGNOSE 8 requires contiguous memory. In a memory-constrained or highly-fragmented environment, Linux may not be able to allocate memory of the needed size. 2. vmcp doesn't perform automatic buffer allocation for query-type functions the same way as CMS. Not fatal, but annoying, given the history of CMS. Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems & Technology Group ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: How to find a memory leak?
Quick test on devices that actually exist shows that 9 devices seem to fit in the default 8192 buffer. So you may need many more calls, depending what size buffer you decide you can use. What one device looks like, FWIW (880 bytes): D008 CUTYPE = 2107-E8, DEVTYPE = 3390-0A, VOLSER = VDL439, CYLS = 3339 CACHE DETAILS: CACHE NVS CFW DFW PINNED CONCOPY -SUBSYSTEM YY N -N N -DEVICE Y- - YN N DEVICE DETAILS: CCA = 08, DDC = --, DED = NO, SSD = YES, SS = 0 DUPLEX DETAILS: -- HYPERPAV DETAILS: BASE VOLUME IN POOL 8 PPRC DETAILS: PRIMARY VOLUME CU DETAILS: SSID = D000, CUNUM = D000 FENCED STATE: NONE HOST ACCESS: CPU PARTITION GROUPED RESERVED MPATHMODE 82C70EY N Y 784A04Y N Y 784A06Y N Y 82C70FY N Y 82C703Y N Y 82C708Y N N Q DASD DETAILS - on a test system reports that it would need over 4MB. Since 1MB is the biggest buffer you can ask for, splitting it up is going to have to happen anyway if you intend to run this at larger shops. -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy Cortes Sent: Monday, July 13, 2015 7:46 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] How to find a memory leak? How about dividing it up in a little loop? Issue Q D DETAILS 000-FFF, Q DA DETAILS 1000-1FFF -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Michael MacIsaac Sent: Monday, July 13, 2015 7:42 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] How to find a memory leak? Ursula, Any chance the requirement for contiguous memory in vmcp could be relaxed? In my test case, 'Q DA DETAILS 0-' requires ~2.5 MB and, as I understand it, that output can simply not be obtained through vmcp. Thanks. -Mike MacIsaac On Mon, Jul 13, 2015 at 10:28 AM, Ursula Braun wrote: > Tomas, > > the qeth driver has been improved in 2014 to reduce its demand for > contiguous storage: > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/ > drivers/s390/net/qeth_core.h?id=d445a4e28c0ff740e946ae22860be85428814c > 39 > > Regards, Ursula Braun, IBM Germany, Linux on System z Dev. > > On Mon, 2015-07-13 at 13:39 +, Pavelka, Tomas wrote: > > > I wouldn't really put that at the feet of s390 (z/Architecture). > > > > Bad wording on my part. When I said s390 I meant the s390 part of > > the > Linux kernel implementation, not the entire architecture. I meant to > point out that the other parts of the kernel are working on getting > out of the requirement of large contiguous buffers. AFAIK the vmcp > driver uses the largest buffer and as you say, if the diag allowed to > return discontiguous memory then it would solve the fragmentation > problem. There are few other places that used larger buffers, NIC > driver was one of them. So not sure if "all over" was the good wording > either, maybe I should have said "multiple places" ;-) > > > > Tomas > > > > > > -- For LINUX-390 subscribe / signoff / archive access instructions, > > send email to lists...@vm.marist.edu 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 lists...@vm.marist.edu 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 lists...@vm.marist.edu 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/
Re: How to find a memory leak?
Alan, > Mike, I already posted that the vmcp problem is caused by the DIAGNOSE > 0x08 requirement for contiguous memory. Thanks. I thought you also pointed out that CMS found a way to work around it (or maybe that was Chuckie). I thought, perhaps naively, that Linux may be able to work around it also. Actually, I don't really want the output of 'Q DASD DETAILS 0-', rather, it was the best test case I could think of to generate a lot of output. What I do want is to be able to get the output of any CP command the user wants, and display it. -Mike M. On Mon, Jul 13, 2015 at 10:46 AM, Alan Altmark wrote: > On Monday, 07/13/2015 at 10:43 EDT, Michael MacIsaac > wrote: > > Any chance the requirement for contiguous memory in vmcp could be > relaxed? > > In my test case, 'Q DA DETAILS 0-' requires ~2.5 MB and, as I > > understand it, that output can simply not be obtained through vmcp. > > Mike, I already posted that the vmcp problem is caused by the DIAGNOSE > 0x08 requirement for contiguous memory. > > Alan Altmark > > Senior Managing z/VM and Linux Consultant > Lab Services System z Delivery Practice > IBM Systems & Technology Group > ibm.com/systems/services/labservices > office: 607.429.3323 > mobile; 607.321.7556 > alan_altm...@us.ibm.com > IBM Endicott > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu 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 lists...@vm.marist.edu 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/
Re: How to find a memory leak?
Am 10.07.2015 um 14:18 schrieb Bruce Hayden: > The message sent to stderr is not documented in the device drivers book. > It tells you about the response code of 2, but the description of that > response code doesn't say anything about the error message to stderr or > that the message tells you how long the output was. I will have a look, if I can add something to the man page and the book. At least the 2 message Error: non-zero CP response for command '': #" and Error: output ( bytes) was truncated, try --buffer to increase size should be documented, yes. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: How to find a memory leak?
Am 13.07.2015 um 16:42 schrieb Michael MacIsaac: > Any chance the requirement for contiguous memory in vmcp could be relaxed? That would require a change in the diagnose definition of z/VM. diag 8 does require the buffer contiguous in guest real storage. > In my test case, 'Q DA DETAILS 0-' requires ~2.5 MB and, as I > understand it, that output can simply not be obtained through vmcp. Splitting this up is propably the easiest workaround. Christian -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: How to find a memory leak?
> the qeth driver has been improved in 2014 to reduce its demand for contiguous > storage: Thanks Ursula, the memories keep coming back ;-) I remembered that the vmcp is still problematic but managed to forget that the qeth driver got fixed.
Re: How to find a memory leak?
On Monday, 07/13/2015 at 10:43 EDT, Michael MacIsaac wrote: > Any chance the requirement for contiguous memory in vmcp could be relaxed? > In my test case, 'Q DA DETAILS 0-' requires ~2.5 MB and, as I > understand it, that output can simply not be obtained through vmcp. Mike, I already posted that the vmcp problem is caused by the DIAGNOSE 0x08 requirement for contiguous memory. Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems & Technology Group ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: How to find a memory leak?
How about dividing it up in a little loop? Issue Q D DETAILS 000-FFF, Q DA DETAILS 1000-1FFF -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Michael MacIsaac Sent: Monday, July 13, 2015 7:42 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] How to find a memory leak? Ursula, Any chance the requirement for contiguous memory in vmcp could be relaxed? In my test case, 'Q DA DETAILS 0-' requires ~2.5 MB and, as I understand it, that output can simply not be obtained through vmcp. Thanks. -Mike MacIsaac On Mon, Jul 13, 2015 at 10:28 AM, Ursula Braun wrote: > Tomas, > > the qeth driver has been improved in 2014 to reduce its demand for > contiguous storage: > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/ > drivers/s390/net/qeth_core.h?id=d445a4e28c0ff740e946ae22860be85428814c > 39 > > Regards, Ursula Braun, IBM Germany, Linux on System z Dev. > > On Mon, 2015-07-13 at 13:39 +, Pavelka, Tomas wrote: > > > I wouldn't really put that at the feet of s390 (z/Architecture). > > > > Bad wording on my part. When I said s390 I meant the s390 part of > > the > Linux kernel implementation, not the entire architecture. I meant to > point out that the other parts of the kernel are working on getting > out of the requirement of large contiguous buffers. AFAIK the vmcp > driver uses the largest buffer and as you say, if the diag allowed to > return discontiguous memory then it would solve the fragmentation > problem. There are few other places that used larger buffers, NIC > driver was one of them. So not sure if "all over" was the good wording > either, maybe I should have said "multiple places" ;-) > > > > Tomas > > > > > > -- For LINUX-390 subscribe / signoff / archive access instructions, > > send email to lists...@vm.marist.edu 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 lists...@vm.marist.edu 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 lists...@vm.marist.edu 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/
Re: How to find a memory leak?
Ursula, Any chance the requirement for contiguous memory in vmcp could be relaxed? In my test case, 'Q DA DETAILS 0-' requires ~2.5 MB and, as I understand it, that output can simply not be obtained through vmcp. Thanks. -Mike MacIsaac On Mon, Jul 13, 2015 at 10:28 AM, Ursula Braun wrote: > Tomas, > > the qeth driver has been improved in 2014 to reduce its demand for > contiguous storage: > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/s390/net/qeth_core.h?id=d445a4e28c0ff740e946ae22860be85428814c39 > > Regards, Ursula Braun, IBM Germany, Linux on System z Dev. > > On Mon, 2015-07-13 at 13:39 +, Pavelka, Tomas wrote: > > > I wouldn't really put that at the feet of s390 (z/Architecture). > > > > Bad wording on my part. When I said s390 I meant the s390 part of the > Linux kernel implementation, not the entire architecture. I meant to point > out that the other parts of the kernel are working on getting out of the > requirement of large contiguous buffers. AFAIK the vmcp driver uses the > largest buffer and as you say, if the diag allowed to return discontiguous > memory then it would solve the fragmentation problem. There are few other > places that used larger buffers, NIC driver was one of them. So not sure if > "all over" was the good wording either, maybe I should have said "multiple > places" ;-) > > > > Tomas > > > > -- > > For LINUX-390 subscribe / signoff / archive access instructions, > > send email to lists...@vm.marist.edu 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 lists...@vm.marist.edu 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 lists...@vm.marist.edu 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/
Re: How to find a memory leak?
Tomas, the qeth driver has been improved in 2014 to reduce its demand for contiguous storage: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/s390/net/qeth_core.h?id=d445a4e28c0ff740e946ae22860be85428814c39 Regards, Ursula Braun, IBM Germany, Linux on System z Dev. On Mon, 2015-07-13 at 13:39 +, Pavelka, Tomas wrote: > > I wouldn't really put that at the feet of s390 (z/Architecture). > > Bad wording on my part. When I said s390 I meant the s390 part of the Linux > kernel implementation, not the entire architecture. I meant to point out that > the other parts of the kernel are working on getting out of the requirement > of large contiguous buffers. AFAIK the vmcp driver uses the largest buffer > and as you say, if the diag allowed to return discontiguous memory then it > would solve the fragmentation problem. There are few other places that used > larger buffers, NIC driver was one of them. So not sure if "all over" was the > good wording either, maybe I should have said "multiple places" ;-) > > Tomas > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu 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 lists...@vm.marist.edu 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/
Re: How to find a memory leak?
On Monday, 07/13/2015 at 09:40 EDT, "Pavelka, Tomas" wrote: > > I wouldn't really put that at the feet of s390 (z/Architecture). > > Bad wording on my part. When I said s390 I meant the s390 part of the Linux > kernel implementation, not the entire architecture. I meant to point out that > the other parts of the kernel are working on getting out of the requirement of > large contiguous buffers. AFAIK the vmcp driver uses the largest buffer and as > you say, if the diag allowed to return discontiguous memory then it would solve > the fragmentation problem. There are few other places that used larger buffers, > NIC driver was one of them. So not sure if "all over" was the good wording > either, maybe I should have said "multiple places" ;-) The QDIO architecture doesn't require contiguous page frames. Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems & Technology Group ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: How to find a memory leak?
> I wouldn't really put that at the feet of s390 (z/Architecture). Bad wording on my part. When I said s390 I meant the s390 part of the Linux kernel implementation, not the entire architecture. I meant to point out that the other parts of the kernel are working on getting out of the requirement of large contiguous buffers. AFAIK the vmcp driver uses the largest buffer and as you say, if the diag allowed to return discontiguous memory then it would solve the fragmentation problem. There are few other places that used larger buffers, NIC driver was one of them. So not sure if "all over" was the good wording either, maybe I should have said "multiple places" ;-) Tomas -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: bacula vs amanda
On Mon, Jul 13, 2015 at 7:29 AM, David Boyes wrote: > > > In 2008, I looked at several options to backup the machines on my home > > > network. I settled on bacula, because at the time it had the most > > > options and was the easiest to configure(from my point of view). > > > Since that time, I've been backing up Linux clients and servers, > > > Windows servers and OSX clients with few issues. I run the director > > > on a Linux server that hosts a RAID5 array for storage. > > To add to this, Amanda assumes that a backup for a single host will fit on > one tape. Given the small size of a 359x tape, this assumption usually > fails in the 390 environment. Bacula can span multiple tapes. > There was a tape-spanning patch introduced for Amanda 5+ years ago. I remember using it at work, before we mostly abandoned backups in favor of snapshots and cross-site replication. I use Bacula at home to do backups to my tape library. Amanda seems more like a wrapper for tar, and Bacula seems more like an enterprise backup solution. I'm a bit surprised that Suse doesn't include Bacula. Pat -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: How to find a memory leak?
On Friday, 07/10/2015 at 02:09 EDT, "Pavelka, Tomas" wrote: > Where the s390 is different is that it uses large continuous buffers all over. I wouldn't really put that at the feet of s390 (z/Architecture). As you noted, the DIAGNOSE 0x08 problem is because CP requires the buffer to be contiguous guest-absolute memory. It has never been enhanced to use scatter/gather the way other DIAGNOSE instructions have. (And the way most of the architecture operates.) That would enable vmcp to request logically contiguous memory that would be backed by memory that's discontiguous page frames. Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems & Technology Group ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: bacula vs amanda
> > In 2008, I looked at several options to backup the machines on my home > > network. I settled on bacula, because at the time it had the most > > options and was the easiest to configure(from my point of view). > > Since that time, I've been backing up Linux clients and servers, > > Windows servers and OSX clients with few issues. I run the director > > on a Linux server that hosts a RAID5 array for storage. To add to this, Amanda assumes that a backup for a single host will fit on one tape. Given the small size of a 359x tape, this assumption usually fails in the 390 environment. Bacula can span multiple tapes. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
