On Wed, Feb 13, 2013 at 12:49 PM, Mark Post <[email protected]> wrote:
> >>> On 2/12/2013 at 06:38 PM, Leland Lucius <[email protected]> wrote:
> > As a followup to a posting over on the IBM/VM mailing list about using
> > dasd_configure to bring a device online and create the necessary udev
> > rules, I wanted to contribute this as I think having a separate rule file
> > for every disk device attached to my guests is just wrong.
>
> I would disagree with the "wrong" bit. There are a number of reasons why
> you might want to do this. Keeping things fairly simple and therefore
> easier to understand is one of them.
Could just be my screwy grey matter (probably is ;-)), but I find the
static rule files more difficult to deal with (trust issues) and get much
more of a warm fuzzy knowing that if I add a disk to my Linux guests, it
will be there when I boot. I can only hope that it will be there with the
static rules.
> Trying to handle all the various attributes for all DASD from one file is
> not easy. Things like readonly, use_diag, eer_enabled, and so on.
>
Here's an addition to my previous post that updates the readonly attribute:
# Bring ECKD devices online
ACTION=="add", SUBSYSTEM=="ccw", DRIVER=="dasd-eckd", ATTR{online}="1"
# Set them to readonly if linked R/O
ACTION=="add", SUBSYSTEM=="ccw", DRIVER=="dasd-eckd", PROGRAM="/bin/sh -c
'/sbin/modprobe vmcp;/sbin/vmcp q v dasd|grep ${DEVPATH##*.}|grep -q R/O'",
ATTR{readonly}="1"
But I totally agree with you. Get anymore complicated and an external
script to (dynamically) handle all of the attributes would be the way to go.
>
> -snip-
> > All of our Linux disks are defined at address 1000 or greater. Anything
> > below that address is a CMS disk and is detached in the guests PROFILE
> > EXEC. So, Linux only sees the disks that we want him to see and
> everything
> > above 1000 SHOULD be seen without having to have another file to worry
> > whether it's there or not.
>
> That's fine in a well-controlled z/VM environment. I would definitely
> _not_ recommend this for anyone running any Linux in an LPAR. Too much
> potential for damage, and it will certainly slow down the boot process if
> all devices are visible to all LPARs as most sites have things defined
> these days.
>
Yepper, I thought about that last night and wished I'd put in a blurb about
z/VM only. That little udev rule would NOT be a good thing if running bare.
>
> -snip-
> > Yes, dasd_configure will still create additional rules files, but it
> won't
> > hurt.
>
> As will YaST, since it calls dasd_configure under the covers. So don't be
> surprised if they show up again even if don't use dasd_configure directly.
>
We're good to go there too as we never really use YaST and uninstall most
of the yast rpms (all of them that we can without breaking dependencies).
Leland
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
