Altering a Mount Point While Something Mounted, Easier in Linux than Solaris

Sooner or later, you'll be bitten by a strange permissions bug:  although you seem to be able to move around and through a mountpoint, you'll notice that stupid things don't work:

# cd .
Permission Denied
# pwd
/mnt/foo
# cd /mnt/foo
# cd ../foo
..:  Permission Denied

Just weird stuff.  You finally get to it, and realize that your mountpoint has bad permissions.

This happens -- usually when adding an NFS or drive mount quickly, and it's not often that bad permissions on the mountpoint will be noticed or a problem;  but it will, that one day.

But now what?  You can't be sure, since when you ls-ld it you'll just see the permissions granted on the mounted volume, which are usually what we want except today the ones on the mountpoint itself is what we need to see.  We can't unmount the volume because, usually, this kinda thing is discovered when people need - need, you understand - the volume to be mounted.  Reboot?  Nuh-uh.

The fix is fun, and, as I may have mentioned, it's easier in Linux.

1. create a mountpoint
   # mkdir /mnt/save
2. nfsmount your root volume on itself at the mountpoint
   # mount -t nfs localhost:/ /mnt/save
3. check and fix the mountpoint
   # ls -ld /mnt/save/mnt/foo
   # chmod 755 /mnt/save/mnt/foo

How does it even work?  Well, since mounting a filesystem (now) doesn't re-export the mounts on top of it, when you mount the root volume on top of itself, all you get is the bare filesystem and not the things mounted on it.  But unless you know the trick, you can neither inspect the mountpoint nor anything normally underneath it before something else gets mounted on top of it -- and squashes what's there from view.

 .. which is why you should always keep your bikini pics in /boot on the root, before the /boot is mounted on top of it.  The wife will never find them there !

How is Linux easier?  Check out and confirm that your autofs is configured out of the box, and usually it is.  Start autofs if it's not already, and navigate to /net/localhost/mnt/foo .  Too easy.

The Prophesy Fortells

It's funny, because I mentioned it only a few days ago.

I was ranting or whining about the service console on the the HP1810G-8 and the Netgear GS108T-100NAS being very weak and prone to bailing a lot:  the switch is fine, and keeps switching, but the SC has crashed and one can no longer change or see the configuration on the switch via the dinky web UI.

So I'm chatting with my project manager for Atlantis, and he starts talking about the bizarre setup in the Sticks project.  We start working out the options and details around some FortiGate firewall out there, and how we should replace it with something we can use a bit better for what it can do, and what's he say?

You know, I'd just love to get some OpenWRT router out there instead.

No word of a lie!  He said it!  I didn't even coerce him.

Some more chatting ensues, and some speculation.  Yep, the FortiGate router seems to be a Linux machine, based on the lawsuit a few years back where they were apparently in violation of a licensing agreement around free software and forgot to make the Linux source code available as part of the process of using the Linux kernel in their product.

So the FortiGate product uses Linux.  X ports, some routing and VPN gear, a processor of unknown arch and speed, and some RAM.  How's that different from an OpenWRT-installed router?  The processor speed?  That'd seem to be about it.  Yeah, the UI is going to be really harsh, but I'm not so sure that's a bad tradeoff for getting 32 flavours of VPN, routing, bridging, switching, vLANs and all in a pretty box.

See the box?  Ohhhhhh.

Installing VMware Tools in Linux after ESX 4.1

Tried to install VMware-Tools lately?  Not sure how it goes on Windows, but on Linux it's a bit more challenging than it used to be.  Used to be there was an RPM on the ISO that popped into the Linux machine's vCDROM drive when the option to install VMware Tools was chosen.

No more.  Like ESXi4.0 before it, ESX4.1 seems to ship with an ISO containing, for Linux, a little tarball with the stuff.

Those who've worked for a distro or packaged anything will know that shipping and installing bare tarballs is really not the best way to go.  Sure, it's fine for the cowboys who maintain 1-2 machines at the home or home-office, but for anyone who has to maintain more than one, has to roll back or verify a package level, or who just wants a clean system, a good package is the only way to go.

Note that I said good package.  If you hear anyone mention "dependency hell" or anything like that, they weren't paying attention.  Stop using bad packages!  Stop mixing repositories.  The pathetic blunt object that pass for packages is the topic of many blogwails past and many blogwails to come.

The great news?  VMware seem to have a few packages for us.  In fact, they come in 4 flavours of RedHat and some even for the you-bunt-you crowd.  Seems all you have to do is mark up the apt config ...

cat <<EOF> /etc/apt/sources.list.d/esx.list

repomd  http://packages.vmware.com tools/esx/4.1/rhel$(VERSION)/$(ARCH)
EOF
apt-get update

... or yum config if you don't build your own packages and know where apt excels ...

cat <<EOF> /etc/yum.repos.d/esx.repo

[esx]
name=VMware-tools for RHEL\$releasever - \$basearch

baseurl=http://packages.vmware.com/tools/esx/4.1/rhel\$releasever/\$basearch
enabled=1
gpgcheck=1
gpgkey=http://packages.vmware.com/tools/VMWARE-PACKAGING-GPG-KEY.pub

EOF

yum update

and after refreshing, just install the package:

apt-get install vmware-tools
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
   vmware-open-vm-tools (8.3.2-257589.el5)
   vmware-open-vm-tools-common (8.3.2-257589.el5)
   vmware-open-vm-tools-kmod (8.3.2-257589.el5)
   vmware-open-vm-tools-nox (8.3.2-257589.el5)
   vmware-open-vm-tools-xorg-drv-display (10.16.7.0-0.257589.el5)
   vmware-open-vm-tools-xorg-drv-mouse (12.6.4.0-0.257589.el5)
   vmware-open-vm-tools-xorg-utilities (8.3.2-257589.el5)
   vmware-tools-common (8.3.2-257589.el5)
   vmware-tools-nox (8.3.2-257589.el5)
The following packages will be REPLACED:
   xorg-x11-drv-vmmouse (12.4.0-2.1)
   (by (10.13.0-2.1)
   vmware-open-vm-tools-xorg-drv-mouse) ()
    (12.4.0-2.1)
   xorg-x11-drv-vmware (10.13.0-2.1)
   (by ()
   vmware-open-vm-tools-xorg-drv-display) (12.4.0-2.1)
The following NEW packages will be installed:
   vmware-open-vm-tools (8.3.2-257589.el5)
   vmware-open-vm-tools-common (8.3.2-257589.el5)
   vmware-open-vm-tools-kmod (8.3.2-257589.el5)
   vmware-open-vm-tools-nox (8.3.2-257589.el5)
   vmware-open-vm-tools-xorg-drv-display (10.16.7.0-0.257589.el5)
   vmware-open-vm-tools-xorg-drv-mouse (12.6.4.0-0.257589.el5)
   vmware-open-vm-tools-xorg-utilities (8.3.2-257589.el5)
   vmware-tools (8.3.2-257589.el5)
   vmware-tools-common (8.3.2-257589.el5)
   vmware-tools-nox (8.3.2-257589.el5)
0 upgraded, 10 newly installed, 2 replaced, 0 removed and 0 not upgraded.
Need to get 44.8kB/13.7MB of archives.
After unpacking 41.1MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://packages.vmware.com tools/esx/4.1/rhel5/x86_64/ vmware-open-vm-tools-kmod 8.3.2-257589.el5 [524kB]
Get:2 http://packages.vmware.com tools/esx/4.1/rhel5/x86_64/ vmware-open-vm-tools-common 8.3.2-257589.el5 [5283kB]
Get:3 http://packages.vmware.com tools/esx/4.1/rhel5/x86_64/ vmware-open-vm-tools-nox 8.3.2-257589.el5 [2631B]
Get:4 http://packages.vmware.com tools/esx/4.1/rhel5/x86_64/ vmware-open-vm-tools-xorg-drv-mouse 12.6.4.0-0.257589.el5 [17.5kB]
Get:5 http://packages.vmware.com tools/esx/4.1/rhel5/x86_64/ vmware-open-vm-tools-xorg-drv-display 10.16.7.0-0.257589.el5 [33.4kB]
Get:6 http://packages.vmware.com tools/esx/4.1/rhel5/x86_64/ vmware-open-vm-tools-xorg-utilities 8.3.2-257589.el5 [7828kB]
Get:7 http://packages.vmware.com tools/esx/4.1/rhel5/x86_64/ vmware-open-vm-tools 8.3.2-257589.el5 [2811B]
Get:8 http://packages.vmware.com tools/esx/4.1/rhel5/x86_64/ vmware-tools-common 8.3.2-257589.el5 [39.4kB]
Get:9 http://packages.vmware.com tools/esx/4.1/rhel5/x86_64/ vmware-tools-nox 8.3.2-257589.el5 [2635B]
Get:10 http://packages.vmware.com tools/esx/4.1/rhel5/x86_64/ vmware-tools 8.3.2-257589.el5 [2763B]
Fetched 44.8kB in 0s (46.5kB/s)
Committing changes...
Preparing                                ############################## [100%]
Updating / installing
  vmware-open-vm-tools-xorg-drv-display- ############################## [100%]
  vmware-open-vm-tools-xorg-drv-mouse-12 ############################## [100%]
  vmware-open-vm-tools-kmod-8.3.2-257589 ############################## [100%]
  vmware-open-vm-tools-common-8.3.2-2575 ############################## [100%]
  vmware-open-vm-tools-nox-8.3.2-257589. ############################## [100%]
  vmware-open-vm-tools-xorg-utilities-8. ############################## [100%]
  vmware-open-vm-tools-8.3.2-257589.el5. ############################## [100%]
  vmware-tools-common-8.3.2-257589.el5.x ############################## [100%]
  vmware-tools-nox-8.3.2-257589.el5.x86_ ############################## [100%]
  vmware-tools-8.3.2-257589.el5.x86_64   ############################## [100%]
Cleaning up / removing
  xorg-x11-drv-vmmouse-12.4.0-2.1.x86_64 ############################## [100%]
  xorg-x11-drv-vmware-10.13.0-2.1.x86_64 ############################## [100%]
Done.

While I avoid Yum, it should look like this:

[root@0-50-56-bc-0-7 ~]# yum install vmware-tools
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * addons: mirror.raystedman.net
 * base: mirror.skiplink.com
 * extras: mirror.skiplink.com
 * updates: styx.biochem.wfubmc.edu
Setting up Install Process
Resolving Dependencies
:
[blah blah]
:
Dependencies Resolved

==================================================================================================================================
 Package                                           Arch               Version                               Repository       Size
==================================================================================================================================
Installing:
 vmware-open-vm-tools-xorg-drv-display             x86_64             10.16.7.0-0.257589.el5                esx              33 k
     replacing  xorg-x11-drv-vmware.x86_64 10.13.0-2.1

 vmware-open-vm-tools-xorg-drv-mouse               x86_64             12.6.4.0-0.257589.el5                 esx              17 k
     replacing  xorg-x11-drv-vmmouse.x86_64 12.4.0-2.1

 vmware-tools                                      x86_64             8.3.2-257589.el5                      esx             2.7 k
Installing for dependencies:
 vmware-open-vm-tools                              x86_64             8.3.2-257589.el5                      esx             2.7 k
 vmware-open-vm-tools-common                       x86_64             8.3.2-257589.el5                      esx             5.0 M
 vmware-open-vm-tools-kmod                         x86_64             8.3.2-257589.el5                      esx             512 k
 vmware-open-vm-tools-nox                          x86_64             8.3.2-257589.el5                      esx             2.6 k
 vmware-open-vm-tools-xorg-utilities               x86_64             8.3.2-257589.el5                      esx             7.5 M
 vmware-tools-common                               x86_64             8.3.2-257589.el5                      esx              39 k
 vmware-tools-nox                                  x86_64             8.3.2-257589.el5                      esx             2.6 k

Transaction Summary
==================================================================================================================================
Install      10 Package(s)
Upgrade       0 Package(s)

Total download size: 13 M
Is this ok [y/N]: y
Downloading Packages:
:
[ more blah blah ]
:
Running Transaction
  Installing     : vmware-open-vm-tools-xorg-drv-display                                                                     1/12
  Installing     : vmware-open-vm-tools-kmod                                                                                 2/12
  Installing     : vmware-open-vm-tools-common                                                                               3/12
  Installing     : vmware-open-vm-tools-nox                                                                                  4/12
  Installing     : vmware-tools-common                                                                                       5/12
  Installing     : vmware-tools-nox                                                                                          6/12
  Installing     : vmware-open-vm-tools-xorg-drv-mouse                                                                       7/12
  Installing     : vmware-open-vm-tools-xorg-utilities                                                                       8/12
  Installing     : vmware-open-vm-tools                                                                                      9/12
  Installing     : vmware-tools                                                                                             10/12
  Erasing        : xorg-x11-drv-vmmouse                                                                                     11/12
  Erasing        : xorg-x11-drv-vmware                                                                                      12/12

Installed:
  vmware-open-vm-tools-xorg-drv-display.x86_64 0:10.16.7.0-0.257589.el5
  vmware-open-vm-tools-xorg-drv-mouse.x86_64 0:12.6.4.0-0.257589.el5
  vmware-tools.x86_64 0:8.3.2-257589.el5

Dependency Installed:
  vmware-open-vm-tools.x86_64 0:8.3.2-257589.el5                      vmware-open-vm-tools-common.x86_64 0:8.3.2-257589.el5
  vmware-open-vm-tools-kmod.x86_64 0:8.3.2-257589.el5                 vmware-open-vm-tools-nox.x86_64 0:8.3.2-257589.el5
  vmware-open-vm-tools-xorg-utilities.x86_64 0:8.3.2-257589.el5       vmware-tools-common.x86_64 0:8.3.2-257589.el5
  vmware-tools-nox.x86_64 0:8.3.2-257589.el5

Replaced:
  xorg-x11-drv-vmmouse.x86_64 0:12.4.0-2.1                        xorg-x11-drv-vmware.x86_64 0:10.13.0-2.1

Complete!

 The experience will be very similar -- if a bit more verbose.


That, my friends, may be it.  It seems convoluted but, really, once you ship a metapackage out with a proper apt+yum config, and your Linux VMs upgrade themselves overnight (well, maybe the test ones get the new metaRPMs first) then you'll be so much more pleased at the ability to do all that automatically.  Add in Spacewalk and/or cobbler and stir for best results.

Switching in the Home

I need to bump up the switching at home.

Right now it's not all that fancy, as I'm just moving into the gigabit age at home (I know, I know).  I've got the expected gaggle of unmanaged crap switches, and they're performing well.  The planet GSD-803 performs the best of all, I think, as it doesn't need the monthly reset like the D-Link and Netgear unmanaged switches do.  But enough of that.  I want to get Gbit all the way into the home, and I need at least one managed switch.

I was looking at two cheapo switches, the HP1810G-8 and the Netgear GS108T-100NAS .  Considering the ridiculous SC problems I've been having with the HP1810G-24 I'm using for the Atlantis ESX cluster,

I mean, really, even in the lower-end enterprise space, what kind of load-testing wasn't done on this thing that let a problem like "oh, the SC freakin' bails all the time under load" get through?  Why is it not recalled or replaced by a better-tooled device?  But I know why:

... I'm still considering buying their even-lower-end 8-port model.  It does fewer vLANs, it does slower switching and it probably crashes on the SC even more often than the currently-floptastic HP1810G-24 unit.

Why would I consider buying it?  Because the Netgear apparently has the same damned problem.  Is it a perception issue, that we are somehow wrong to expect the dinky-toy management service console of this product to actually perform as designed?  Do they get a free ride on quality control in that aspect, simply because they're merely a $100 switch?

Why not just grab a Netgear 3500L router, shut off the wireless (or use it; your choice) and use its massively expended capabilities, thanks to OpenWRT (white russian fo' life) and the ability of linux to set up multiple vLANs at will.  It seems that, if I can stand the loss of the ports or foot the cost of another crap gigabit router (where I get failing hardware for 1/3 the price) it's less of a loss.

Disabling LACP with iSCSI in ESXi4 to Enable MPIO

My mini Atlantis cluster is working well, but I found a document suggesting it can be better -- or another way that it can be better, at least.

It's using iSCSI for the storage, right now, and I have it configured with LACP for redundancy off one bonded channel.  I'd hoped to also get some load-balancing from it, but I was young and naive (last week) when I set it up.  I've since learned of a better way to set it up.  It's all in A Multivendor Post on using iSCSI with VMware vSphere at Virtual Geek .

Here's the money-shot, as I told DD in email:

1. don't have your iSCSI set up with LACP
2. set up one vmkX for each NIC you're going to dedicate for iSCSI
3. have them not team
4. subscribe to each effective target on each interface on the remote side separately
5. drop your IOps per path factor to a lower number to reduce stickiness on a particular path and improve the MP part of the IO on lower-speed iSCSI configs.

Not sure about the last part, but it's what passes for the sense it's making right now.  I'm off to read it more fully and plan a migration from one method to another in Atlantis.

I'm actually excited that I can improve performance on this little cluster without requiring more capital.  Let you know how it goes.

Techtarget and Search Exchange -- Heavy and Cumbersome

While searching for some tips on the potential possibility of managing a tiny vmware-server v1 machine with a temporary VCenter (4) server, I stumbled on yet another of those Expert Exchange-type sites:  Techtarget, it looks to be called.  Specifically, I found my way to their SearchVMware sub-site.

The routine is typical of them all:  tease you with a paragraph, and lock anything useful behind a paywall.  If this didn't present a few concerns, I wouldn't be thinking about it a moment past that, and thus wouldn't have a thing to write about.

1. What are the search engine implications - specifically, bannination for baiting and switching the search terms with different (reduced) content?  I seem to remember a bunch of similar schemes were shut down a decade ago.  While those guys were stuffing unrelated crap keywords in white-on-white text in the hopes of luring more irrelevant searchers to their site, what these guys may be doing - luring searchers with one set of data, presenting something much worse - does appear to be a sale of their reputation under a false pre-text.
   
2. What's the best way to config a black hole for these useless sites?  They offer no value to me, and I'd like to ensure I never, ever even have these sites show up in my results.  It's a time waster, really, and I'd like my internet to exclude all the baiters and switchers.

I guess, really, I don't want to remove them completely.  Since I'd only ever, really consider going to sites I consider to be somewhat shady as an absolute last resort, I think that I'd be okay if their search results turned up on the very last page of my searches.  That way if I don't find what I'm looking for on the Internet, I can search off the Internet as well.  It's like Broadway and Off-Broadway -- or, in this case, off-off-off-off-off-Broadway.

vLANs on Linux (physical) Hosts

vLANs on VMware virtual linux guests is easy.  Set it and you're done, right?

On physical hosts, though, it can be a bit more tricky.  It seems the format's changed a bit, too, between RHEL4 and RHEL5 -- for the better!

By example, though, to add vLan 101 to your eth2, it's like this:

(emacs /etc/sysconfig/network-scripts/ifcfg-eth2.101)VLAN=yes
DEVICE=eth2.101ONBOOT=yes

BOOTPROTO=none
IPADDR=10.101.2.17NETMASK=255.255.255.0

 Yeah, it's that easy.  The scripts extract the device name (eth2) and vLan (101) from the DEVICE tag, if it sees the VLAN=yes setting.  When you're done:

ifup eth2.101

Your machine should (wait an agonizing 2 seconds and) display something like this:

Added VLAN with VID == 101 to IF -:eth2:-

And you know you're done.  You can use all the tools you would expect, just like with regular devices and/or ipaliased devices:

ifconfig eth2.101
tshark -i eth2.101 host sniffme.mynet.com
ping -I eth2.101 sniffme

One bit of caution, though:  vLANs are privacy; not security.  What this means is that you should never have vLANs carrying data where anything-but-completely trustable machines can hear it, even if it's in a vLAN.  It's trivial to peel the leading vLAN tag off a packet and read it from the untagged network (eg eth2).

Get your stuff onto a managed switch!  Segregate your traffic!  If you aren't 100% sure, the best security between two networks is an air gap.

Pra Pra Pra

I've lost a machine.

In the monster setup I'm doing in the 404, I blew a static DHCP setup and directed an IPMI NIC over to an address it couldn't have -- it was taken.  After the dust cleared from the resulting fight between it and a photocopier that was squatting on that IP - right in the middle of the range I'd pre-allocated - the IPMI NIC seems to have gone away.  It's not at the IP it should be, it's not at the IP I set aside for it during the squabble and to which it never went, and it's not sleuthable at a 169.254.x.y IP as it also could be.  I'm all but sunk on that one machine until I can get a human to dump the power on the box (that's why we have IPMI) and bring it back up.  It should kick the IPMI back onto the state table and get it networking again.  Ugh.

I've since learned two things:  arping and inarp.

Arping, here, helps me ensure an IP is really vacant before I allocate it.  DHCP should, too, but it wasn't doing so well in this case since I hard-coded it into the config.  This, folks, is why we define pools and stick to them.  All the problems with "dhcp causing IP conflicts", as some hicks in the 561 claimed, were all through mis-use like I did here.  So, do this next time:

# arping -D 192.168.1.6 -w 5
ARPING 192.168.1.6 from 0.0.0.0 eth0
Unicast reply from 192.168.1.6 [00:04:01:EF:D8:4C] for 192.168.1.6 [00:04:01:EF:D8:4C] 0.650ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)

arping -D 192.168.1.112 -w 5
ARPING 192.168.1.112 from 0.0.0.0 eth0
Sent 6 probes (6 broadcast(s))
Received 0 response(s)

And we can be sure that something's there if it replied within 5 seconds.

The next thing, which I dearly need now, is a linux implementation of Inverse ARP, or inarp.  It's different from RARP ("who am I on this MAC") because it solicits for a third party, essentially asking "What IP is on that MAC?"

No inarp.c though.  I found one for Windows, but I don't have control of a winbox on that network, where I can inject arps.  Argh.

Anyone found a decent Inverse ARP tool for linux?  I'll even take one in perl.

Busy

I'm nearing the end of my project.  That's it, mostly, depicted on the left.

I use a bugzilla to keep my sanity, and I break jobs down into discrete chunks.  I keep it mostly macro-atomic, when possible, and group whole tasks together, but I often need to break things up into separate bits so that I can finish the job in a set period of time and wait some unknown period before the next chunk begins.

I also use dependencies in BZ a lot.  I use them for not only a job that follows another, as you'd expect, but also to indicate a common component or the previous version of a repeated task or issue.  this drives everyone else nuts.

The one above is the report of a drive failure killing a RAID and tanking a VM - no really - but also deals with the purchase of some larger hard drives, their install, the migration onto the new drives from the old and it will show the removal of the old hardware as well.

In this way, BZ shows me a project at a glance, and it's easy to see my place in that project.  For a guy who constantly needs reminding where he is in projects, be they an hour or a year old, or is coming back to something with all but completely fresh eyes, the ability to quickly see my place in the grand scheme of things is invaluable.

Go get Bugzilla.  Or something.  And use it.

Smartest Guy in the Room

So I'm at the sweatshop today, and HB's logged into a box. He's doing some 8-key sequence and I think he's trying to move to a previous command.

"What was that," I ask, perplexed.
"I was trying to repeat a command," he answers.
"But how?  You were doing an odd key combination there."
"That was an Escape-K combination I did.  Once or twice."

And it struck me.  That's the old korn-and-vi way of doing things, and I'd just not noticed it.

"Why didn't you just hit Up-Arrow?" I ask
"Oh, I'm so used to the old way"
"Ahh, you're a vi guy, then?"

It was a bit of a leap, but I think that's how vi people go up a line (because it's just intuitive to hit ESC-K for 'up').  He admitted that he was, but here's the money-byte:

"No matter where I go, the smartest guy in the room uses Emacs.  I need to learn emacs one day because there's got to be something to it."
(over my protests) "No, really:  everywhere I go, there's like 10 people in a hack lab, and the genius people, the smartest guys there, have all been emacs guys.  It's weird, but it's true."

And thus my plan - to approach genius by emulating it and copying their habits - has been revealed.  Like those 1980s guys who said you should act rich if you wanted to be rich,  could I really resemble a smart guy just by doing what smart guys do?

Nah.

I only use emacs because I had a choice between it and vi in the beginning.  I like to think that's all I needed, since I like to hit the up-arrow to, well, go up.  I guess I can't work with something as intuitive as [ESC][K], that marvel of efficiency and intuitive design.

Identifying RDM mappings End-to-End in ESXi4

When you're using RDMs in ESXi4 - it's just so easy to fall back to a standard non-VMware box if so - it can be hard to ensure the disk you're modifying/replacing is the correct one.  Here's one method of checking that you're on the right disk:

~ # grep scsi0:4.fileName /vmfs/volumes/datastore1/alligator/alligator.vmx
scsi0:4.fileName = "/vmfs/volumes/4b918cf4-f5f48288-506c-0030489f09a1/gator/gatorsdc.vmdk"

~ # cd /vmfs/volumes/4b918cf4-f5f48288-506c-0030489f09a1/gator
~ # vmkfstools -q gatorsdc.vmdk
Disk gatorsdc.vmdk is a Non-passthrough Raw Device Mapping
Maps to: vml.0100000000533133554a314b5136303035333520202020202053414d53554e
esxcfg-scsidevs  -u| grep \
 vml.0100000000533133554a314b5136303035333520202020202053414d53554e
t10.ATA_____SAMSUNG_HD753LJ_________________________S13UJ1KQ600536______vml.0100000000533133554a314b5136303035333520202020202053414d53554e

And hey, look! 

On linux, then, /dev/sde (0:4) is our Samsung HD753 with serial number S13UJ1KQ600536 .  That's almost too easy. But be careful, though, as one misstep will probably hose something in ways you really don't want.  Measure twice, hack once.

Find your RAID MD Device Name from a Member Device

So you've got a bajillion RAID arrays; that's okay, really.  Thing is, if you need to find its mdX device, it can get tricky.  vGrep taxing the eyes?  Mine too, and I haven't had much luck with an alternative.  I know there's one out there, but I have yet to trip over it.

Here's what I've started doing:

mdadm --detail --scan |\
awk '/'`mdadm -E /dev/sde3|awk '/UUID/{print $NF}'`'/{print $2}'

/dev/md6

 Substitute in your own values for /dev/sde3.