jump to navigation

VMWare ESX CHAP password recovery January 20, 2012

Posted by jamesisaac in Uncategorized.
Tags: , ,
2 comments

Just a quick note, once again brought about by necessity.

This evening I needed to hook up a new VMWare ESX host to an old SAN (and by old, I mean it was about four years old). The original configuration notes were long gone. After plugging the new host into the SAN switch and configuring an iSCSI ip address, I was faced with the dilemma of finding out what the iSCSI CHAP authentication username and password was. I could see from the existing ESX hosts that we were using CHAP authentication, and I could get the username from the GUI. But what’s the password? I tried a few of our “tried and true” passwords, but had no luck.

Option 1: log into the SAN and reset the CHAP authentication. Change the passwords on the VMWare hosts at the same time. Downside: outage. Upside: know we know what the password is.

There’s got to be another way… and there is!

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003095

This KB gave me the info in a roundabout way. If you can read the /etc/vmkiscsi.conf file on an existing VMWare host, then the CHAP username and password are listed in cleartext. Yay.

I grabbed this information, put it into the new host, rescanned the iSCSI adapter, and away we went.

 

Advertisements

“cannot change the host configuration” August 14, 2009

Posted by jamesisaac in Uncategorized.
Tags: ,
2 comments

Here’s a bizarre problem I encountered with vSphere and VMFS.

I have an iSCSI SAN presenting 5 LUNs to vSphere. I set up the first server, added the LUNs, formatted and named them, and all is well. I added the second server, and could only add two of the 5 LUNs. With the other three, I could see the LUN in the “add storage” configuration page, but after going through the wizard, vSphere errored out with “cannot change the host configuration”. There’s not a lot of documentation on this error, but I found the secret here – it’s a bug in Virtual Center. Or at least it appears to be.

The solution is to use the vSphere client to connect directly to the host, not Virtual Center, and add the LUNs there. Works perfectly and they show up in Virtual Center as you’re adding them.

DSS iSCSI failover solved July 25, 2009

Posted by jamesisaac in Uncategorized.
Tags: , ,
add a comment

Two weeks ago I was in the throes of a confusing puzzle of how to make iSCSI failover work with the open-e DSS. I was searching for the magic switch that would make it work, and I found it – “it” being ASCII character 20h, 32 decimal, good ol’ space.

Here’s the rundown – the DSS high availability construction kit goes like this:

  1. Create a volume on your “source” DSS.
  2. Create an iSCSI lun in that volume.
  3. Create a replica volume on the “target” DSS (“target”, “replica”, whatever you want to call it)
  4. Create an identical iSCSI lun, same name, same lun number.
  5. Configure a volume replication job on your source DSS. Here’s the important thing: don’t create the job name with a space. So, “replicate lv0000” will work for the replication job, but it won’t even show up in the iSCSI failover job list. Create your job and call it “replicate_lv0000” instead.
  6. Start the replication job and wait until the volumes are synchronized.
  7. Configure iSCSI failover – you should see your replication job listed.

It’s amazing and a little disconcerting to think of all the time wasted because one part of the UI allowed a job with a space in the name, and another part of the UI wouldn’t list jobs with spaces in their names.

Now, arguably, I didn’t run this by support, nor have I seen the source code, so I may be barking up the wrong tree. All I know is that 20 hours later, the space character is the one change that I made which allowed everything else to work.