Sagar wrote:
" Hope SP2 solves it but it comes with its own issues- kernel 3.0"
Happily running kernel 3 on nearly 200 servers here. What kind of issues are
you having?
Marcy
This message may contain confidential and/or privileged information. If you are
not the addressee or authorized to re
I do the same with 5 seconds and run the I still have outages once in a
while.( I use device names by path -like
/dev/disk/by-path/ccw-0.0.0500-part1)
Dasd_configure on my SLES11 SP1(with latest patches) is still buggy.
Hope SP2 solves it but it comes with its own issues- kernel 3.0
Sagar
---
On Tue, Jul 17th, 2012 at 6:37 AM, Alan Altmark wrote:
...
> TCPIP is connected to two HiperSocket networks: one real (to MVS) and one
> virtual (to Linux).
Now, hold it right there fella. I want the order number for one of those
*real* hipersockets.
(haven't we been here before ... ;-)
Shane ...
On Monday, 07/16/2012 at 09:44 EDT, Mark Post wrote:
> Alternatively, he could just attach a real HiperSocket device to the
Linux
> system and cut out the middle man (z/VM TCPIP) entirely. Unless there's
some
> value to be had by having z/VM manage the traffic, it's just unnecessary
> overhead.
On Jul 16, 2012, at 8:03 AM, Lee Stewart wrote:
> I'd never thought about it before, but a customer pointed out that when
> you clone a system, each Linux clone has the same Host RSA key
> fingerprint as it's master. I can't think of anything that would cause
> a problem with. On the other hand
>>> On 7/16/2012 at 04:37 PM, Alan Altmark wrote:
> TCPIP is connected to two HiperSocket networks: one real (to MVS) and one
> virtual (to Linux). So TCPIP will need two HiperSocket interfaces, each
> with it's own IP address in each of the two networks. You have the real
> one (5.1.1.1), but
[Steffen asked:] How is the (dynamic?) traffic allowance planned to be realized
on vnphost?
I'm not quite sure what your question means. I think the answer is that we're
using promiscuous interface(s) to listen for all traffic. Allowed traffic is
forwarded. All other traffic is allowed to drop.
On Monday, 07/16/2012 at 02:38 EDT, "Norris, Chet"
wrote:
> I'm not able to get any response back to my zlinux guest over a guest
LAN I've
> set up for Hipersocket connections.
>
> I've defined IP/ADDR 5.1.1.1 as a VM home address, 5.1.1.3 as the MVS
home and
> set up the Linux guest as 5.1.2.10.
Hi Mauro,
Thanks for this hint. But my script looked in the beginig like yours :-)
I have tried it out.
CHCCWDEV -d gives sometime rc 256.
and the fdasd rc: 65280 (Disk in use!).
I added now retries: In case I have a nonzero rc I redo the command up to
five times with a sleep of one second.
Up
I usually put some sleeps and syncs along the way to give time to this
settle down:
dasdfmt -y -b 4096 -p -f /dev/dasdx
sleep 2
sync
fdasd -a /dev/dasdx
sleep 2
sync
mkfs.ext3 /dev/dasdx1
It works almost all the time. You could put some error checking routines
around, but I think this is simple en
Dear all,
>From time to time I am confronted with an weird problem with the s390-tools
which is really a PITA.
I have a small script that should simply execute a dasdfmt afterwards a
fdasd and finally a mkfs to prepare a new DASD.
What happens is that after the dasdmft the fdasd gets sometimes t
On Mon, Jul 16, 2012 at 04:59:49PM +, Norris, Chet wrote:
> I've defined IP/ADDR 5.1.1.1 as a VM home address, 5.1.1.3 as the MVS home
> and set up the Linux guest as 5.1.2.10.
It would be preferable if you could use RFC 1918 allocations for your legacy IP
interconnections. Just using random I
I'm not able to get any response back to my zlinux guest over a guest LAN I've
set up for Hipersocket connections.
I've defined IP/ADDR 5.1.1.1 as a VM home address, 5.1.1.3 as the MVS home and
set up the Linux guest as 5.1.2.10.
A static route for 5.1.2.0/24 has been defined under MVS to point
Hi All,
Just in case you need it, this is a reminder that SHARE is approaching rapidly
and the "Linux and VM" program is looking for session chairs.
Below is a list of the sessions. If you are planning on attending SHARE in
Anaheim CA, please volunteer to chair a session or two! Please res
I'd even go beyond what Alan said, since I don't treat any system or network as
"trusted." Deleting the keys on the source system should be all you need to do
for new clones. Deleting them from the existing guests and restarting sshd will
be enough for the rest. People who have already accessed
And the solution is simple:
rm /etc/ssh/*key*
service sshd restart
I set my golden image to have no SSH keys before cloning. One step less to
make the clones ready.
Em 16/07/2012 11:23, "Alan Cox" escreveu:
> On Mon, 16 Jul 2012 09:03:09 -0600
> Lee Stewart wrote:
>
> > I'd never thought about
Only if your post-cloning process does not include generating new RSA keys.
It's all in how you set up your cloning process, and the planning you've put
into it.
--
Robert P. Nix Mayo Foundation.~.
RO-OC-1-18 200 First Street SW/V\
507-284-0844 Rochester,
On Mon, 16 Jul 2012 09:03:09 -0600
Lee Stewart wrote:
> I'd never thought about it before, but a customer pointed out that when
> you clone a system, each Linux clone has the same Host RSA key
> fingerprint as it's master. I can't think of anything that would cause
> a problem with.
If you hav
I'd never thought about it before, but a customer pointed out that when
you clone a system, each Linux clone has the same Host RSA key
fingerprint as it's master. I can't think of anything that would cause
a problem with. On the other hand, if they wanted to regenerate the
keys, does it take mo
19 matches
Mail list logo
