Don't know what you consider a lot, but as of right now, I am pretty well convinced that there is a bug, and a rather nasty one at that, in the LVM code.
Do you do much adding and/or removal of DASD to your Linux instances? If not, it would be interesting to hear what happens when you do try to add additional DASD to the Linux guest, and from there on into the LVM. Perhaps it is human error. The question is where? :) -Paul > -----Original Message----- > From: The IBM z/VM Operating System [mailto:[email protected]] On > Behalf Of Hall, Ken (GTS) > Sent: Friday, October 30, 2009 7:15 AM > To: [email protected] > Subject: Re: z/LInux, LVM, and minor disasters. > > 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. > ----------------------------------------------------------------------- > --- >
