Define "a LOT". We have Linux guests with over 100 DASD volumes in
LVM, and I've run Linux in LPAR with close to 1000 devices visible, and
haven't had any problem I couldn't explain.
One of the difficulties is, it can be hard to determine whether or not a
device is missing when there are that many. Examining the console log
from boot ("dmesg") can be useful, plus looking at "q v dasd" and
comparing against "lsdasd" under Linux. Keeping the device numbers
consistent and sequential makes this much easier, and as the previous
poster said, LVM doesn't care where the volumes are, as long as it can
collect them all.
Occasionally we have seen LVM get corrupted, but that was almost always
traceable back to some human error.
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[email protected]] On
Behalf Of Paul Raulerson
Sent: Friday, October 30, 2009 6:16 AM
To: [email protected]
Subject: Re: [IBMVM] z/LInux, LVM, and minor disasters.
Hi Mark - I would have agreed 100% with you up until a few days ago. I
am still not sure it was LVMs fault.
There were a LOT of DASD volumes attached to this instance, and I
think I may have blown some limit somewhere.
Part of the reason there were multiple LVMs is that I had a lot of
3390-3's around, and LVM, at least at one time,
seemed to have trouble with creating volumes that were much larger
than 100gigs using 3390-3s. Fell into a
historical habit I suppose.
It worries me enough, and the fact I can duplicate it, makes me
worried enough to not want to use LVMs for a while.
I was kinda hoping someone else had ran into this, but perhaps it is
more likely I am just doing something wrong
-Paul
On Oct 30, 2009, at 1:27 AM, Mark Post wrote:
>>>> On 10/30/2009 at 1:23 AM, Paul Raulerson <[email protected]>
>>>> wrote:
> -snip-
>> Has anyone else ran into this?
>
> Not without some error messages and the like to go on.
>
> LVM doesn't care about device names, or DASD address ordering, etc.
> All it cares about is if it can find the UUIDs it expects for all
> its PVs. Those are written on the disk volumes when pvcreate and
> vgextend is done.
>
> If it can't find all those UUIDs, then it will throw a fit. Usually
> that means that a PV was added to the VG, and that volume was not
> available at the next reboot. Most often that's the result of not
> re-running mkinitrd and zipl. (YaST will do that for you
> automatically if you use it, otherwise you have to remember to do
> it. Not sure if Red Hat has a similar mechanism to keep things in
> synch.)
>
>
> Mark Post
>
--------------------------------------------------------------------------
This message w/attachments (message) may be privileged, confidential or
proprietary, and if you are not an intended recipient, please notify the
sender, do not use or share it and delete it. The information contained in this
e-mail was obtained from sources believed to be reliable; however, the accuracy
or completeness of this information is not guaranteed. Unless specifically
indicated, this message is not an offer to sell or a solicitation of any
investment products or other financial product or service, an official
confirmation of any transaction, or an official statement of Merrill Lynch.
Subject to applicable law, Merrill Lynch may monitor, review and retain
e-communications (EC) traveling through its networks/systems. The laws of the
country of each sender/recipient may impact the handling of EC, and EC may be
archived, supervised and produced in countries other than the country in which
you are located. This message cannot be guaran teed to be secure or error-free.
References to "Merrill Lynch" are references to any company in the Merrill
Lynch & Co., Inc. group of companies, which are wholly-owned by Bank of America
Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are
Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a
Condition to Any Banking Service or Activity * Are Not Insured by Any Federal
Government Agency. Past performance is no guarantee of future results.
Attachments that are part of this E-communication may have additional important
disclosures and disclaimers, which you should read. This message is subject to
terms available at the following link:
http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you
consent to the foregoing.
--------------------------------------------------------------------------
