More Elegant udev rules

[Greg Stevenson]

I found the following udev rules on the citrix forums designed to expose
hard drive devices to VMs. By adding these rules to 50-udev.rules it does
the job but exposes a bunch of other rubbish I could do without.



ACTION=="add", SYSFS{vendor}=="ATA ",
ID=="1:0:0:0|2:0:0:0|3:0:0:0|4:0:0:0",

SYMLINK+="xapi/block/%k", \

RUN+="/bin/sh -c '/opt/xensource/libexec/local-device-change %k 2>&1

/dev/null&'"

ACTION=="remove", SYSFS{vendor}=="ATA ",
ID=="1:0:0:0|2:0:0:0|3:0:0:0|4:0:0:0", \

RUN+="/bin/sh -c '/opt/xensource/libexec/local-device-change %k 2>&1

/dev/null&'"

Can anyone see how I could alter these rules to only expose my 3 2Tb Seagate
sata drives? And while we are at it, is there a way to use IOCTL or hdparm
within the rules to turn write cache off on each of my three drives without
turning it off on the drive holding the system? (a completely separate
drive, SSD in this case, which is also exposed to the VMs by the above
rules)



Cheers



Greg Stevenson

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Daniel Lawson]

Post by Greg Stevenson
I found the following udev rules on the citrix forums designed to expose
hard drive devices to VMs. By adding these rules to 50-udev.rules it does
the job but exposes a bunch of other rubbish I could do without.
ACTION=="add", SYSFS{vendor}=="ATA ",
ID=="1:0:0:0|2:0:0:0|3:0:0:0|4:0:0:0",
SYMLINK+="xapi/block/%k", \
RUN+="/bin/sh -c '/opt/xensource/libexec/local-device-change %k 2>&1

/dev/null&'"

ACTION=="remove", SYSFS{vendor}=="ATA ",
ID=="1:0:0:0|2:0:0:0|3:0:0:0|4:0:0:0", \
RUN+="/bin/sh -c '/opt/xensource/libexec/local-device-change %k 2>&1

/dev/null&'"

Can anyone see how I could alter these rules to only expose my 3 2Tb Seagate
sata drives?

Yes, you can use one of the sysfs variables to limit on the specific
serial number of the drive. Or you could limit it to a model number, or
manufacturer, etc

In the "ACTION" line, it currently selects based on the SYSFS{vendor}
variable being "ATA ", you could change that to SYSFS{serial} =
"yourserial". Get the serial number via sysfs itself to make sure you're
referring to the right thing

Post by Greg Stevenson
And while we are at it, is there a way to use IOCTL or hdparm
within the rules to turn write cache off on each of my three drives without
turning it off on the drive holding the system? (a completely separate
drive, SSD in this case, which is also exposed to the VMs by the above
rules)

You already run a script in that rule on add/remove events. You could
either modify that script or write a new wrapper script that calls your
hdparm command and then calls the local-device-change script. Or maybe
the semantics of the RUN command allow multiple RUN lines, I can't recall.

Either way, reading the udev manuals will help you a lot.




_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[g***@primesoft.co.nz]

Thanks Daniel

Post by Daniel Lawson

Post by Greg Stevenson
I found the following udev rules on the citrix forums designed to expose
hard drive devices to VMs. By adding these rules to 50-udev.rules it does
the job but exposes a bunch of other rubbish I could do without.
ACTION=="add", SYSFS{vendor}=="ATA ",
ID=="1:0:0:0|2:0:0:0|3:0:0:0|4:0:0:0",
SYMLINK+="xapi/block/%k", \
RUN+="/bin/sh -c '/opt/xensource/libexec/local-device-change %k 2>&1

/dev/null&'"

ACTION=="remove", SYSFS{vendor}=="ATA ",
ID=="1:0:0:0|2:0:0:0|3:0:0:0|4:0:0:0", \
RUN+="/bin/sh -c '/opt/xensource/libexec/local-device-change %k 2>&1

/dev/null&'"

Can anyone see how I could alter these rules to only expose my 3 2Tb Seagate
sata drives?

Yes, you can use one of the sysfs variables to limit on the specific
serial number of the drive. Or you could limit it to a model number,
or manufacturer, etc
In the "ACTION" line, it currently selects based on the SYSFS{vendor}
variable being "ATA ", you could change that to SYSFS{serial} =
"yourserial". Get the serial number via sysfs itself to make sure
you're referring to the right thing

I had considered that but was more looking for code that would work in
all instances instead of a specific instance.
Not being a programmer I can't fully comprehend why the combination of
SYSFS{vendor} and ID doesn't isolate devices more than it seems to
already.
Literally hundreds of devices appear in the removable storage list
using the above code.

Post by Daniel Lawson

Post by Greg Stevenson
And while we are at it, is there a way to use IOCTL or hdparm
within the rules to turn write cache off on each of my three drives without
turning it off on the drive holding the system? (a completely separate
drive, SSD in this case, which is also exposed to the VMs by the above
rules)

You already run a script in that rule on add/remove events. You could
either modify that script or write a new wrapper script that calls
your hdparm command and then calls the local-device-change script. Or
maybe the semantics of the RUN command allow multiple RUN lines, I
can't recall.

Thanks, I'm a little worried about the warning to not run long running
tasks using RUN. To make this elegant I would need to run hdparm on all
possible hard disk devices. As part of a wrapper script would this be
regarded as long?

Post by Daniel Lawson
Either way, reading the udev manuals will help you a lot.

I have read and re-read this site
http://reactivated.net/writing_udev_rules.html and tried to understand
the man pages prior to asking for help.
My lack of programming knowledge is restricting my progress.
I'm sorry I'm a real novice, particularly at low level interactions
with hardware.
Can anyone point me to a link better addressing the specific example
with respect to udev rules writing?

Post by Daniel Lawson
_______________________________________________
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Volker Kuhlmann]

On Tue 22 Nov 2011 09:57:01 NZDT +1300, ***@primesoft.co.nz wrote:

I recently needed some rules to create constant names in /dev specific
to particular FTDI USB/RS232 adapters. Your problem isn't quite the same
but probably needs the same solution.

The website I noted is this one:

http://answers.ros.org/question/65/how-can-i-get-a-unique-device-path-for-my

The udev manual is also handy. Points I noted in particular:

# *) There have been some changes. Some websites with descriptions and howtos
# are out-of-date and should be ignored.
# *) You can't change the kernel-assigned device name (other than by changing
# the kernel driver). You can only put a symlink, with the symlink name
# remaining constant and its target adjusted to the same hardware piece.
# *) The device information is in a tree structure. Use udevadm. You can match
# to any node, but only to one(!) node. Messing that up results in a non-match.
# *) I'm unsure whether long lines can be broken.

After changes run /etc/init.d/boot.udev restart
Contrary to specified behaviour reload didn't work reliably. Don't use
stop and start.

udevadm is very handy to find the attributes you can use to match on.
Pay attention to the 1-node-only restriction or you will be sorry (read
it won't work, and it fails silently).

Turning write cache off on drives related to your new rules must be
possible through udev's action mechanism but I don'tknow the details of
that.

HTH,

Volker

[Greg Stevenson]

Thanks Volker

Udevadm isn't part of xenserver distribution but udevinfo is. I guess that
is the important utility to determine what combination of variables will
most uniquely define the devices I want to work with.

I guess I'm after some combination that uniquely defines hard drives no
matter if they are SATA, PATA or pure SCSI with no concern for manufacturer
or model.

I'm picking something like KERNEL=="[h,s]d[a-c]" within the rule would go
some way to achieving what I'm after given that in this instance the system
resides on dev/sdd.
Unfortunately that won't always be the case, and in a big system, many more
drives would be involved. I guess without the udev rules knowing where the
system resides there isn't a way of achieving this programmatically.

I would have loved your way of reloading the udev rules below to have worked
on xenserver but unfortunately I continue to have to reboot each time to
check the result of my changes.

Thanks for your help.

-----Original Message-----
From: nzlug-***@linux.net.nz [mailto:nzlug-***@linux.net.nz] On
Behalf Of Volker Kuhlmann
Sent: Wednesday, 23 November 2011 12:17 a.m.
To: NZLUG Mailing List
Subject: Re: [nzlug] More Elegant udev rules

On Tue 22 Nov 2011 09:57:01 NZDT +1300, ***@primesoft.co.nz wrote:

I recently needed some rules to create constant names in /dev specific to
particular FTDI USB/RS232 adapters. Your problem isn't quite the same but
probably needs the same solution.

The website I noted is this one:

http://answers.ros.org/question/65/how-can-i-get-a-unique-device-path-for-my

The udev manual is also handy. Points I noted in particular:

# *) There have been some changes. Some websites with descriptions and
howtos # are out-of-date and should be ignored.
# *) You can't change the kernel-assigned device name (other than by
changing # the kernel driver). You can only put a symlink, with the symlink
name # remaining constant and its target adjusted to the same hardware
piece.
# *) The device information is in a tree structure. Use udevadm. You can
match # to any node, but only to one(!) node. Messing that up results in a
non-match.
# *) I'm unsure whether long lines can be broken.

After changes run /etc/init.d/boot.udev restart Contrary to specified
behaviour reload didn't work reliably. Don't use stop and start.

udevadm is very handy to find the attributes you can use to match on.
Pay attention to the 1-node-only restriction or you will be sorry (read it
won't work, and it fails silently).

Turning write cache off on drives related to your new rules must be possible
through udev's action mechanism but I don'tknow the details of that.

HTH,

Volker
--
Volker Kuhlmann is list0570 with the domain in header.
http://volker.dnsalias.net/ Please do not CC list postings to me.

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug


_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Nick Rout]

Post by Greg Stevenson
Thanks Volker
Udevadm isn't part of xenserver distribution but udevinfo is. I guess that
is the important utility to determine what combination of variables will
most uniquely define the devices I want to work with.
I guess I'm after some combination that uniquely defines hard drives no
matter if they are SATA, PATA or pure SCSI with no concern for manufacturer
or model.
I'm picking something like KERNEL=="[h,s]d[a-c]" within the rule would go
some way to achieving what I'm after given that in this instance the system
resides on dev/sdd.
Unfortunately that won't always be the case, and in a big system, many more
drives would be involved. I guess without the udev rules knowing where the
system resides there isn't a way of achieving this programmatically.
I would have loved your way of reloading the udev rules below to have worked
on xenserver but unfortunately I continue to have to reboot each time to
check the result of my changes.
Thanks for your help.
I found the following udev rules on the citrix forums

Have you been back to the author in the citrix forums?

Please don't top post.

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Greg Stevenson]

Post by Greg Stevenson
-----Original Message-----
On Behalf Of Nick Rout
Sent: Wednesday, 23 November 2011 10:52 a.m.
To: NZLUG Mailing List
Subject: Re: [nzlug] More Elegant udev rules

Post by Greg Stevenson
Thanks Volker
Udevadm isn't part of xenserver distribution but udevinfo is. I guess
that is the important utility to determine what combination of
variables will most uniquely define the devices I want to work with.
I guess I'm after some combination that uniquely defines hard drives
no matter if they are SATA, PATA or pure SCSI with no concern for
manufacturer or model.
I'm picking something like KERNEL=="[h,s]d[a-c]" within the rule would
go some way to achieving what I'm after given that in this instance
the system resides on dev/sdd.
Unfortunately that won't always be the case, and in a big system, many
more drives would be involved. I guess without the udev rules knowing
where the system resides there isn't a way of achieving this

programmatically.

Post by Greg Stevenson
I would have loved your way of reloading the udev rules below to have
worked on xenserver but unfortunately I continue to have to reboot
each time to check the result of my changes.
Thanks for your help.
I found the following udev rules on the citrix forums

Have you been back to the author in the citrix forums?

He was looking for support from Citrix for an unsupported configuration. He
didn't get anywhere as one would expect. Citrix doesn't want to make their
support issues any more complex than they already are. He wasn't attempting
to replicate the configuration and pass it on to others to use, he was quite
happy that he found something that works and was somewhat rubbing the Citrix
support's nose in it. I'm just trying to make it more elegant so it
replicates in multiple hardware configurations. Perhaps opening up the
possibility of scripting something that would help others make use of zfs on
low end hardware very cheaply. Functions like dedup and compression are
things you don't have to pay for.

Post by Greg Stevenson
Please don't top post.
_______________________________________________
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Daniel Lawson]

Post by g***@primesoft.co.nz

Post by Daniel Lawson
Yes, you can use one of the sysfs variables to limit on the specific
serial number of the drive. Or you could limit it to a model number,
or manufacturer, etc
In the "ACTION" line, it currently selects based on the SYSFS{vendor}
variable being "ATA ", you could change that to SYSFS{serial} =
"yourserial". Get the serial number via sysfs itself to make sure
you're referring to the right thing

I had considered that but was more looking for code that would work in
all instances instead of a specific instance.
Not being a programmer I can't fully comprehend why the combination of
SYSFS{vendor} and ID doesn't isolate devices more than it seems to
already.
Literally hundreds of devices appear in the removable storage list
using the above code.

How much less specific do you want? Could you filter on a partial
serial number (all Seagate drives start with ST, for example)

If the drives are USB-connected, there is a "removable" variable you can
filter on, which will only be set to 1 if the drive is a removable one
(usb, floppy, cdrom etc).

And if you know which device nodes you want to connect (eg, sdb, sdc,
sdd) and they don't change, then you can just filter on that.

Post by g***@primesoft.co.nz

Post by Daniel Lawson
You already run a script in that rule on add/remove events. You could
either modify that script or write a new wrapper script that calls
your hdparm command and then calls the local-device-change script. Or
maybe the semantics of the RUN command allow multiple RUN lines, I
can't recall.

Thanks, I'm a little worried about the warning to not run long running
tasks using RUN. To make this elegant I would need to run hdparm on all
possible hard disk devices. As part of a wrapper script would this be
regarded as long?

Why would you run it on all devices? udev will call this script for
every device add event, and as you only care about updating the current
device anyway, you should only need to run hdparm on the specific device
that udev is referring to right now, which is far more elegant than
attempting to run it on all possible devices IMO. Any other devices
you've added prior to that will have already had hdparm run on them, for
example. In the code you pasted, the script gets called with a
parameter called %k, which expands out to the kernel name for the device
I believe, which will be f.e. /dev/sdb.

I believe the cavaet about long-running tasks refers to things taking
many seconds or minutes to run. hdparm to turn the write cache off for a
single device shouldn't take more than a few seconds. Time it yourself
and see though.

Post by g***@primesoft.co.nz

Post by Daniel Lawson
Either way, reading the udev manuals will help you a lot.

I have read and re-read this site
http://reactivated.net/writing_udev_rules.html and tried to understand
the man pages prior to asking for help.
My lack of programming knowledge is restricting my progress.
I'm sorry I'm a real novice, particularly at low level interactions
with hardware.
Can anyone point me to a link better addressing the specific example
with respect to udev rules writing?

If you could give a clearer example of what's going wrong, I may be able
to help more.

A quick google search reveals these links, which may help you more
specifically:

http://kiekeboe100.hoefman.be/blog/2009/06/attaching-disk-to-xenserver-guest/
http://techblog.conglomer.net/sata-direct-local-disk-access-on-xenserver/

Both use more specific variants of the same udev rule than the one you
are using, so will probably help you.
_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug