Bob,
could you please explain your pain points with GDPS/XRC in your Linux/VM
setup? While z/VM itself doesn't seem to timestamp its I/O Linux does and
z/VM would carry all Linux timestamps out to the storage control unit as it
re-issues the Linux I/O requests. Do you have problems with these
Bob,
AFAIK GDPS/XRC is a supported configuration except that only the Linux I/O
is timestamped and hence XRC eligible while I/O on VM's own behalf is not
(unless it changed recently). I.e. if this is acceptable for your setup you
should be able adding Linux volumes to your XRC configuration. Not
We are new to z/Linux here, so I could be wrong in what I'm about to say.
Please correct me if I am.
We run z/OS in one LPAR and z/VM, with several Linux guests, in another. I
don't think that the presences of z/VM makes a difference with respect to
backups.
We were told by the consultant who
Mary Anne,
Any gotchas in your XRC setup?
Bob Richards
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Mary Anne Matyaz
Sent: Thursday, June 28, 2007 7:25 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: GDPS/XRC for z/VM and Linux volumes
We haven't
On 6/29/07, Rich Smrcina [EMAIL PROTECTED] wrote:
It's exactly like rebooting a Linux PC after some sort of crash, it goes
through a filesystem check (fsck).
There's a big difference. If the PC crashes you have a consistent
state as it was at that time. But when you have z/OS on the other end
Dave should know. My local IBMer is trying to find out from Noshir
Dhondy. Between those two, there should be a good answer! :-)
Out of curiosity, Alan, why aren't z/VM writes timestamped?
Bob Richards
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Ingo,
My setup won't exist for a few weeks yet. What I am trying to find out
is how GDPS and XRC can provide failover capability to a z/VM - Linux
environment. Based on what you are telling me, in an XRC/SDM pull
operation, the timestamps for all Linux volumes should be reassembled
just fine on
Paul,
Your method provides you with the best backup possible with the tools
that you have. It's benefit is that is that it is a consistent backup,
whereas if you did not shut down the Linux machines you would have an
inconsistent backup where on startup your Linux machines would have to
attempt
Well OK, maybe the analogy wasn't absolutely perfect. The point is on
reboot Linux will think it crashed, Linux will attempt to rebuild it's
filesystem, it may or may not work. Don't take the chance with your
corporate data.
Rob van der Heij wrote:
On 6/29/07, Rich Smrcina [EMAIL PROTECTED]
It should be noted that, as far as we've been able to find out (and there
are still IBM'ers working on it, so this may not be true shortly), z/VM
cannot participate in GDPS if you are running CSE, or if you have any DASD
shared between two z/VM LPARs. As I understand it currently, if our z/OS
could you please explain your pain points with GDPS/XRC in your
Linux/VM
setup? While z/VM itself doesn't seem to timestamp its I/O Linux does
and
z/VM would carry all Linux timestamps out to the storage control unit
as
it
re-issues the Linux I/O requests. Do you have problems with these
Correct on all counts. Using a tool like Bacula (open source, but
support available and z/OS friendly) or TSM (from IBM) provides the file
level backup and recoverability required in this environment.
Paul Noble wrote:
So, if I'm understanding this correctly, taking a backup of a running Linux
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On
Behalf Of Paul Noble
Sent: Friday, June 29, 2007 10:01 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Backup and Restore Strategies For Z/Linux
So, if I'm understanding this correctly, taking a backup of a
So, if I'm understanding this correctly, taking a backup of a running Linux
system from another LPAR gives you, at best, an unreliable backup.
That means that there are only two viable alternatives:
Shut down Linux and do the backup from another LPAR or,
Use a backup client that runs within
So, if I'm understanding this correctly, taking a backup of a running
Linux system from another LPAR gives you, at best, an unreliable
backup.
Yep.
That means that there are only two viable alternatives:
Shut down Linux and do the backup from another LPAR or,
Use a backup client that runs
Along this same track - if one uses a Linux based backup and restore
utility, then how does one restore a base image in a disaster
situation? D.R. providers generally have a z/OS and z/VM environment.
How many have a Linux environment to do the restores? I would ASSuME
that if I used Linux to
On Fri, Jun 29, 2007 at 11:59 AM, in message
[EMAIL PROTECTED], McKown,
John [EMAIL PROTECTED] wrote:
Along this same track - if one uses a Linux based backup and restore
utility, then how does one restore a base image in a disaster
situation?
Funny you should ask.
Along this same track - if one uses a Linux based backup and restore
utility, then how does one restore a base image in a disaster
situation? D.R. providers generally have a z/OS and z/VM environment.
How many have a Linux environment to do the restores? I would ASSuME
that if I used Linux to dump
On Fri, Jun 29, 2007 at 11:00 AM, in message
[EMAIL PROTECTED], Paul Noble [EMAIL PROTECTED]
wrote:
-snip-
The problem, as I see it, with backing up from another LPAR is that there is
no incremental or differential backup capability. Nor is there any selective
restore capability. Its an
David,
After reading your reply, feel free to pass yourself off as me anytime!
:-)
Extremely well stated! And it is exactly where I was going with this
thread.
Bob Richards
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
David Boyes
Sent: Friday,
I think there is two or more issues, backing up the data using DDR type
backup only gives you full backup. therefore you need to install/get
software package to do you back.
The problems are:
- Many linux server where password changes, many other thing get
installed on that servers.
Robert,
I do not understand your last sentence. Why would your z/VM systems
crash? Is it because they are on DASD that is under XRC?
Bob Richards
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
RPN01
Sent: Friday, June 29, 2007 10:53 AM
To:
The ultimate, I think, would be a VM based backup tool that plays nice
with the Linux file system. It would:
1. Recognize if Linux is running.
2. If Linux is running, tell it to purge it's file cache and 'go to
sleep'.
3. Access a Linux minidisk and understand the file system that resides
there.
A customer has a security policy that only allows ipv4, so they can't
assign an ipv6 address to eth0, and can't have an ipv6 over ipv4 tunnel.
Ideally, they'd like to remove the ipv6 kernel module altogether.
In RHEL 4 and SLES 9, they were able to do this. In RHEL 5 and SLES 10,
they're finding
On Fri, Jun 29, 2007 at 3:09 PM, in message
[EMAIL PROTECTED],
Mrohs, Ray [EMAIL PROTECTED] wrote:
The ultimate, I think, would be a VM based backup tool that plays nice
with the Linux file system. It would:
1. Recognize if Linux is running.
2. If Linux is running, tell it to purge it's
On Fri, Jun 29, 2007 at 3:42 PM, in message
[EMAIL PROTECTED], Brad Hinson
[EMAIL PROTECTED] wrote:
A customer has a security policy that only allows ipv4, so they can't
assign an ipv6 address to eth0, and can't have an ipv6 over ipv4 tunnel.
Ideally, they'd like to remove the ipv6 kernel
Hi Listers.
I am trying to issue a vmcp command within a boot script and receive the
following message during boot:
Error: Could not open device /dev/vmcp: No such device
+++ RC=3 +++
Once the system is booted, I can see the device...
Any ideas on how to make this device permanent?
On Fri, Jun 29, 2007 at 4:31 PM, in message
[EMAIL PROTECTED],
Susan Zimmerman [EMAIL PROTECTED] wrote:
Hi Listers.
I am trying to issue a vmcp command within a boot script and receive the
following message during boot:
Error: Could not open device /dev/vmcp: No such device
On Friday, 06/29/2007 at 09:36 AST, Richards.Bob
[EMAIL PROTECTED] wrote:
Out of curiosity, Alan, why aren't z/VM writes timestamped?
Host-generated timestamps are part of the older XRC architecture (z/OS
Global Mirror) that z/VM can't really use. When multiple LPARs or CECs
are involved, you
I think we should ask at what condition that we want to do the restore.
If a users lost some data... DDR types restore is not a good ideal... again
you need software that are friendly to the user. And this is the
same for system ADMIN erase the /etc. Then ADMIN would wish it had done
a
On Fri, 2007-06-29 at 14:34 -0600, Mark Post wrote:
On Fri, Jun 29, 2007 at 4:31 PM, in message
[EMAIL PROTECTED],
Susan Zimmerman [EMAIL PROTECTED] wrote:
Hi Listers.
I am trying to issue a vmcp command within a boot script and receive the
following message during boot:
Error:
Well, I back up both ways...
DDR type backup of the Linux system disk (/hda).
Sometimes I throw in a tar of the system disk as well.
But all data, I backup logically. Either tar for NFS and Samba, or the
database backup utilities that come with DB2/UDB and Oracle. Not only this
keeps the
An alternative to An image that can have access to all Linux disks is a
sharable rescue system on read-only dasd that any Linux VM userid can LINK and
boot from. Like the Linux install system IPL-ed from the guest's reader, it has
access to all the guest's disks.
Mrohs, Ray wrote:
The ultimate, I think, would be a VM based backup tool that plays nice
with the Linux file system. It would:
1. Recognize if Linux is running.
2. If Linux is running, tell it to purge it's file cache and 'go to
sleep'.
Suspend to disk. Linux does it on Intellish systems.
I built 3.05 on SUSE 10.2 x64. Running Suse s390x, my compile test went from
7+ hours to just under 3 hours. Well done!
Paul
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with
We are starting our Linux POC and all has been going well. Until I got
to the Hipersockets, that is.
We are trying to talk to two z/OS LPARs, one development and one
production. in our IFL
LPAR, z/VM 5.2 RSU 0701 and SLES9x SP3. POC is a Java app that gets
messages via
MQ Series and reformats
So are your OSA devices and Hipersocket devices all on the same network?
In other words do they all have a 172.20.1.x address with a netmask of
255.255.255.0?
Kim Goldenberg wrote:
We are starting our Linux POC and all has been going well. Until I got
to the Hipersockets, that is.
We are
37 matches
Mail list logo
