The dig +short command (such as described in "dig show only answer") is great for batch processing names into IP addresses. It does a simple job and does it well.

Unfortunately when there's a CNAME even +short isn't short enough. For example:

$ dig +short docs.sbonds.org
ghs.google.com.
173.194.69.121

I've tried +noall but it doesn't seem like it changes the behavior of +short. I've also tried specifying -t a just to ensure it didn't think I meant an A record or CNAME, but that (unsurprisingly) changes nothing.

$ dig +noall +short docs.sbonds.org
ghs.google.com.
173.194.69.121

I'm using RedHat 7's dig:

# dig -v
DiG 9.9.4-RedHat-9.9.4-73.el7_6

I can filter out the CNAMEs with trusty grep, but it seems like dig should have some way to give "Just the IP, ma'am."

What is that way?

Current Method

In the past I've done this by copying the ISOs to a Windows desktop then using the vCenter client to upload the ISO to a temporary datastore location on the ESXi server, then using "Datastore ISO file" to make the ISO available to the guest. This works, but requires multiple delays waiting for copies to complete, uses up more storage than necessary, and leads to situations where the extra copies get forgotten.

Background

The question Mounting ISO image on VMware ESX guest OS without VMware client is similar to this situation, except they were looking for a way to make an already-uploaded ISO connect to the VM.

Based on current VMware documentation, it appears that "esxcli" is the current preferred CLI. The older vicfg and esxcfg commands are deprecated.

So far, the closest I've found is a vmware-cmd that connects and disconnects the CD/DVD drive:

vmware-cmd /vmfs/volumes/storage1/MyVM/MyVM.vmx connectdevice "CD/DVD Drive 2"

If I can't find a better option, I could also use vicfg-advcfg (preferably preceded by a vicfg-cfgbackup in case something goes wrong) to change the CD/DVD path variable.

I have not found any CLI or API method that appears to let me upload a file to a datastore like the Windows/Web client does.

Restrictions

If necessary, I can also use the Python, Perl, or Ruby APIs from a Linux server. Installing PowerCLI for Linux might be tricky, but I'm not completely ruling it out.

I cannot use a direct ssh connection to the ESXi servers. There is not a shared NFS server where I could copy the ISOs and have both the Linux server and the vCenter farm accessing the same share.

Question

How can I make an ISO file local to a Linux server available to a VMware ESXi/vCenter guest using command line tools?

Usually this works great-- boot from the SPP ISO, walk away for a beverage, come back and everything's updated. Not so on a few of my servers...

The final SPP release for these old DL360 G6 servers was Oct 2016, so that's what I'm using. Here's what I see during the automatic update process:

So far I've tried to update it from the OS (ESXi 5.5) using the downloaded standalone driver from HP (which has ESXi 5.5 listed as a supported OS) but that process fails with issues like:

# cd /tmp/usr/lib/x86_64-linux-gnu/hp-firmware-smartarray-14ef73e580-6.64-2
# ./hpsetup
./hpsetup: line 226: tr: not found
./hpsetup: line 226: tr: not found
./hpsetup: line 226: tr: not found
./hpsetup: line 226: tr: not found
./hpsetup: line 226: tr: not found
./hpsetup: line 293: syntax error: bad substitution

Running the raw .scexe has similar issues. Clearly a case of the OS not supporting the patch script.

I found this article which coincidentally has my identical starting firmware version (2.50) so I'm wondering if perhaps there's a bad version out there that breaks future automatic updates (fun!) https://bugs.centos.org/view.php?id=13184

Based on that, I plan to try and find a live CD that will work for this HP firmware update. Has anyone found one that works well for this process? Alternatively, is there a way to get the SPP update process to work correctly? (I would expect that boot environment to be VERY HP-firmware-update-friendly, yet in this case it seems to not work properly.)

THE PROBLEM

We've all been there. The server is toast. It's not booting and something seems really odd.

Sure, there are recovery boot options with most operating systems and a collection of helpful ISOs out there to assist. Good examples might be the System Rescue CD, a Knoppix liveCD, or even the built-in rescue boot of CentOS / Red Hat Enterprise Linux. But what if the problem seems to be within the hardware or related to it?

There are vendor tool DVDs available, such as HP/HPE's ServicePack for Proliant (SPP) or Dell's System Update. These contain useful hardware diagnostics and tools that would be perfect for a recovery environment. Except, they're not available in any recovery environment.

I suspect that actually distributing a recovery disk with 3rd party closed-source tools on would run into some copyright issues. However, presuming we can get hold of the tools/drivers needed it seems like a useful thing to build ourselves and keep around.

THE REAL QUESTION

Has anyone ever built something like this? How did you do it? What issues did you run into?

Summary

When I try to install ESXi 5.5U3 on a DL360 G6, it fails because no storage is seen.

Details

Hardware

Server: HP Proliant DL360 G6

CPUs: 1 CPU, Intel Xeon E5506 @ 2.13GHz

RAM: 48GB RAM

Storage Adapter: P410i

Storage: 2x 1TB HP SATA drives

Storage config: RAID "10" on two drives, single 1TB "Logical Volume"

Install Process

ESXi compatibility for DL360 G6: https://www.vmware.com/resources/compatibility/detail.php?deviceCategory=server&productid=14664

ESXi source: HPE custom ESXi 5.5 U3 from https://my.vmware.com/web/vmware/details?downloadGroup=OEM-ESXI55U3B-HPE&productId=353

I'm booting using the ILO virtual media on an HTTP-provided ISO. This process works fine and I've had no issues with it on my local LAN. Here are some details about that generic boot process using the ILO CLI:

</>hpiLO-> power
power: server power is currently: Off
</>hpiLO-> cd /map1/oemhp_vm1/cddr1
</map1/oemhp_vm1/cddr1>hpiLO-> set oemhp_image=http://server.name.here/ESXHP55.iso
</map1/oemhp_vm1/cddr1>hpiLO-> set oemhp_boot=connect
</map1/oemhp_vm1/cddr1>hpiLO-> power on

After answering the usual VMware prompts, I eventually arrive at this screen and can go no farther:

I've tried wiping the RAID logical volume using DBAN, just in case any prior data on there was confusing ESXi, but that changed nothing. This also shows that the storage hardware works since I was able to see the storage using DBAN just fine.

The closest related question I found so far that would be similar to this was this question: ESXi 5.5 on HP ProLiant DL380 G7 Server. In that case, the admin wanted a JBOD disk pass-through, which isn't possible on the HP Proliant internal storage P410i controllers.

Normally I'd try loading a special HPE storage driver, but those are supposedly included on the HPE custom images. Anyone else running ESXi 5.5U3 on a DL360 G6 see this problem and get past it? Are there logs available somehow to show what's failing on the storage detection?

Thanks in advance for any help!

The documented solution doesn't seem to actually work. The documented solution:

In ~/.gnupg/gpg.conf change to use an HTTP keyserver and honor the environment variable http_proxy. The proxy I'm using is a special proxy that requires no authentication other than source IP. Yay!

keyserver http://http-keys.gnupg.net
keyserver-options honor-http-proxy verbose

Check my environment:

$ echo $http_proxy
http://proxy.name.com:8080

Check the proxy via other means:

$ telnet proxy.name.com 8080
Connected to proxy.name.com.
Escape character is '^]'.
^]
telnet> close
Connection closed.

strace -f gpg --recv-keys 0xABCDEF shows that it's ignoring the proxy and unsuccessfully trying to connect directly.

Any ideas?

From Red Hat Enterprise Linux 6 how can I tell the difference between a SAN zoning problem (e.g. cannot reach the storage at all) versus a LUN masking issue (e.g. LUNs not assigned to the right HBA WWN)?

On HP-UX (yeah, I know...) this is pretty simple-- the disk array presents targets with a different SCSI ID string in the "ioscan" output:

LUNs from that disk array show the virtual LUN emulation type "OPEN-V" (way over to the right):

target      11  0/5/2/0/4/0.117.7.0.0.0      tgt          CLAIMED     DEVICE
disk         3  0/5/2/0/4/0.117.7.0.0.0.0    sdisk        CLAIMED     DEVICE       HP      OPEN-V

The disk array itself shows "DISK-SUBSYSTEM" instead of "OPEN-V" on every SCSI target even if no LUNs are assigned:

target      16  0/5/2/0/4/0.117.7.0.0.5      tgt          CLAIMED     DEVICE
disk        29  0/5/2/0/4/0.117.7.0.0.5.0    sdisk        CLAIMED     DEVICE       HP      DISK-SUBSYSTEM

This could also simply be a result of choosing HPUX-compatible emulation on the array. I know ancient versions of HPUX got super angry when they saw a SCSI target without a LUN 0 present so the storage may be forcing itself to present a placeholder LUN 0 only in this emulation mode.

On Linux, is there a similar diagnostic test to help identify if the storage is visible at all (e.g. zoning is good, LUN assignments are bad) versus storage not visible at all (e.g. zoning is bad)?

"lsscsi", "lsblk", "blockdev --report", and "cat /proc/scsi/scsi" all seem to only report once the LUNs are visible all the way through (both zoning and LUN masking are good.)

I poked through /sys/class/scsi_generic thinking that perhaps a target assigned without a disk device might show up with at least a generic SCSI device, but the only sgX devices are those associated with disk block devices meaning the LUNs are working fine all the way from storage to host.

What do you use to help identify zoning vs. LUN assignment issues on Linux?