On Tue, May 13, 2008 at 6:02 AM, Robert J Brenneman [EMAIL PROTECTED] wrote:
The problem will be when you've allocated huge vdisks for all your production
systems based on the old Swap = 2X main memory ROT. In that example -
you're basically tripling your overcommit ratio by including the
On Monday, 05/12/2008 at 01:53 EDT, Stephen Frazier
[EMAIL PROTECTED] wrote:
My recollection is that the port name must be the same everywhere or
absent
everywhere.
Try removing your port names and see if that works.
Port names are meaningful to z/OS, not Linux or z/VM. It is ok if some are
With the assumption that the real switch is configured properly, what
are
the best things to trouble-shoot on the VM side, to prove or disprove
my
definitions?
It would also be helpful to post the output of show interface for the
trunk port (do it in enable mode to get the full details) for
On Tue, May 13, 2008 at 5:32 PM, Alan Altmark [EMAIL PROTECTED]
wrote:
Port names are meaningful to z/OS, not Linux or z/VM. It is ok if some are
using port names and others are not. If you are using port names, then
all users must have the same port name. First one in wins.
Which means -
My use of the term over-commit is more simple with the objective of setting a target
that management understands. I don't include vdisk - that is a moving target based on
tuning and workload, as is the use of CMM1. The way I like to use the term is much higher
level that doesn't change based
My ratio is about 2.6 that represents a large (proportionately) number of CMS
users.
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Barton Robinson
Sent: Tuesday, May 13, 2008 10:20 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Overcommit ratio
On Tue, May 13, 2008 at 4:36 PM, Huegel, Thomas [EMAIL PROTECTED] wrote:
My ratio is about 2.6 that represents a large (proportionately) number of CMS
users.
That's unfair. CMS users just take what they need, not what you let
them have... You may be able to over-commit by 1000 when they
I only calculate it for the Linux images, for the reason that Rob states.
Our two systems are currently at 1.9:1 and 1.4:1. I found this number useful
enough that I have a rexx script that calculates it on the fly.
--
Robert P. Nix Mayo Foundation.~.
RO-OE-5-55 200
Ah yes, CMS is very different animal - it knows how to work well in a virtual environment.
I think I remember numbers way above 20, so high nobody bothered to measure.
Huegel, Thomas wrote:
My ratio is about 2.6 that represents a large (proportionately) number of CMS users.
-Original
Barton wrote:
Using this measure, what do y'all run?
Is there a Velocity screen that adds them all up? I don't want to
resort to excel :)
What I'm looking for is a fair way to determine who should be allocated
cost of the memory (not exactly chargeback) based on their impact to the
system.
A few weeks ago, I put a package on the VM download library called
VIR2REAL, which is an exec that calculates the ratio on your running
system. I just got an update out there today that gives you the ratio
for all users and also with out CMS users. (I figure a CMS user is
one IPLed with a
I'm the network side of this issue. Here is what I see on the interface and the
relevent config:
SMF02#sh int gigabiteth0/4
GigabitEthernet0/4 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 000a.b8ae.f504 (bia 000a.b8ae.f504)
MTU 1500 bytes, BW 10
My overcommit ratio is about 5:1 not counting CMS users. If you count them it is more like 15:1. It
seems to work fine. I don't think overcommit ratio is very useful for anything. It is two dependent
on the kind of users you have to be meaningful.
Marcy Cortes wrote:
I keep hearing things
Hello,
We're investigating the set up for vswitch in LACP mode.
We've discovered that unless you have a feature in your cisco switches
out there that make 2 of them appear to be one (something like feature
1440 on the 6509), you have a single point of failure in your switch
hardware.
There
Current configuration is;
z800 with 3 OSA cards (6 NIC)
all OSA used as QDIO
4 are 10/100 copper
2 are 1000 fiber (only 1 fiber cable but we plan to buy another)
z/VM 5.2 with TCP/IP using 1 dedicated 100Mb connection (very little traffic)
VSE guest with Barnard
You are on the right track, but you will want to look at the z/VM CONNECTIVITY
GUIDE for some good explainations and an example or two.
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Robert
Payne
Sent: Tuesday, May 13, 2008 3:27 PM
To:
Great !
THANKS !!!
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Huegel,
Thomas
Sent: Tuesday, May 13, 2008 3:41 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VSWITCH new to me and want to understand
You are on the right track, but you will
the space needs to have been dumped - what is the filetype that DUMPLOAD
created?
David
From: The IBM z/VM Operating System on behalf of Gillis, Mark
Sent: Tue 5/13/2008 4:55 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] Displaying data space storage in a
Does anyone know how to display data space storage in DUMPSCAN? The
DUMPSCAN DISPLAY command doesn't seem to know about ALETs.
Thanks in advance,
Mark Gillis
Senior Software Engineer
Tel: +61 2 9429 2337
Fax: +61 2 9429 2394
[EMAIL PROTECTED]
DUMP0001.
I don't see any operands on the display command, though, for specifying
an ALET, or anything else that would identify the data space.
Mark.
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of David Kreuter
Sent: Wednesday,
Shouldn¹t you be using VMDUMPTL? It has a command (VMDTSET) that allows you
to specify an ASCE when doing displays of storage.
Does anyone know how to display data space storage in DUMPSCAN? The DUMPSCAN
DISPLAY command doesn¹t seem to know about ALETs.
Thanks, I wasn't aware of the existence of VMDUMPTL - I'll check it out.
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Neale Ferguson
Sent: Wednesday, 14 May 2008 7:09 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Displaying data space
This list does not accept attachments, so we can not see it.
Alan Ackerman
Alan (dot) Ackerman (at) Bank of America (dot) com
23 matches
Mail list logo
