Yes, the "other bank formerly based in SF" posted this before. Here it
is again:
Guest RDev VDev
-------- ---- ----
GUEST1 DC00 DC00
GUEST1 DC01 DC01
GUEST1 DC0A DC02
GUEST2 DC02 DC00
GUEST2 DC03 DC01
GUEST2 DC0B DC02
GUEST3 DC04 DC00
GUEST3 DC05 DC01
GUEST3 DC0C DC02
GUEST4 DC06 DC00
GUEST4 DC07 DC01
GUEST4 DC0D DC02
GUEST5 DC08 DC00
GUEST5 DC09 DC01
GUEST5 DC0E DC02
Dennis O'Brien
"A society that gets rid of all its troublemakers goes downhill." --
Robert A. Heinlein
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Marcy Cortes
Sent: Wednesday, April 23, 2008 21:43
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] OSA rdev and vdev requirements for Linux guests.
Well, I know all about moving cheeses here :)
But how would those Internet security people know? :) I dare them to
find that vswitch!
Some one here long ago and far away (I'm pretty sure it was the other
bank formerly based in SF), posted his scheme of reclaiming. Yes, you
can use non-sequentials.
No doubt Alan will respond before too long with the real location of the
doc. I don't think he ever sleeps.
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."
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Mike Walter
Sent: Wednesday, April 23, 2008 9:36 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] OSA rdev and vdev requirements for Linux guests.
VSWITCH is the answer, of course.
But that's the next great leap through our company Internet Security
group. Baby steps first. We have OSA rdevs available, and the need for
three new zLinux guests in a hurry, of course.
VSWITCH is already being planned, but it has a longer timeline since it
involves moving the cheese a great many more recalcitrant people.
So... the question remains (if a reply from Alan is not already winding
its way through the net at this late hour on the east coast)
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.
"Marcy Cortes" <[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
04/23/2008 11:29 PM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: OSA rdev and vdev requirements for Linux guests.
Wait, what are you doing attaching osa's to Linux?
VSWITCH!
Seriously, I think you use a lot more storage on the Linux guest and
make him less likely to be idle.
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."
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Mike Walter
Sent: Wednesday, April 23, 2008 9:25 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] OSA rdev and vdev requirements for Linux guests.
Way back when, in the olden days, I seem to remember that the first OSA
address of a triplet used by Linux guests had to be an even address.
But then there are also vague memories of more recent information that
as long as the first OSA vdev of a triplet seen by a guest is even, it
does not matter if its rdev is odd. Is that true, or have I been
sneaking sips of Adam's cough medicine?
If the first vdev of the triplet being even is all that matters, do all
the rdevs have to be in ascending sequential order?
Or could we harvest all those lone, odd-numbered OSA rdevs? E.g. "7000,
7001, 7002" used, reclaim the abandoned 7003 rdev to be assigned as an
even-numbered vdev, "7004, 7005, 7006" used, reclaim the abandoned 7007
rdev to be assigned as an even-numbered vdev, etc.)?
And... where is this documented that I obviously overlooked? Of course
if a restriction were removed, where would one find it documented except
in old manuals and folklore? :-)
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.
The information contained in this e-mail and any accompanying documents
may contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if
this message has been addressed to you in error, please immediately
alert the sender by reply e-mail and then delete this message, including
any attachments. Any dissemination, distribution or other use of the
contents of this message by anyone other than the intended recipient is
strictly prohibited. All messages sent to and from this e-mail address
may be monitored as permitted by applicable law and regulations to
ensure compliance with our internal policies and to protect our
business. E-mails are not secure and cannot be guaranteed to be error
free as they can be intercepted, amended, lost or destroyed, or contain
viruses. You are deemed to have accepted these risks if you communicate
with us by e-mail.
The information contained in this e-mail and any accompanying documents
may contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if
this message has been addressed to you in error, please immediately
alert the sender by reply e-mail and then delete this message, including
any attachments. Any dissemination, distribution or other use of the
contents of this message by anyone other than the intended recipient is
strictly prohibited. All messages sent to and from this e-mail address
may be monitored as permitted by applicable law and regulations to
ensure compliance with our internal policies and to protect our
business. E-mails are not secure and cannot be guaranteed to be error
free as they can be intercepted, amended, lost or destroyed, or contain
viruses. You are deemed to have accepted these risks if you communicate
with us by e-mail.
