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.

 

Can’t delete snapshots after failed Veeam job May 4, 2011

Posted by jamesisaac in Uncategorized.
Tags:
add a comment

http://www.kendrickcoleman.com/index.php?/Tech-Blog/issues-with-consolidate-helper-0-snapshot.html

Ran into this issue today after testing a Veeam backup job in “hot add” mode. The job failed and left several snapshots in the VM’s directory. I attempted to delete the snapshots using the VI Client snapshot manager, and it showed that the snapshots were deleted, but they were still present on the disk.

The issue was that the disk was still attached to the Veeam virtual machine. The quick fix is to edit the properties of your Veeam guest and remove the other VM’s disk, then remove the snapshots. In my case I had jumped the gun already by attempting to delete the snaps through snapshot manager. I followed the clone process listed in the link above, then removed the hard disk from the Veeam guest, then was able to delete the source of the clone. And finally just to restore my environment to its original condition, I cloned the clone back to the original server name and deleted the clone.
And all is well!

vSphere Essentials licensing and vmotion rant September 9, 2009

Posted by jamesisaac in Uncategorized.
Tags:
add a comment

Apparently I almost made up a new product a few days ago.

After running my vSphere servers in eval mode for 50+ days, I was getting ready to apply the licenses to them and the vCenter server which was managing them. I logged into my VMWare account, found the license code, and applied it to the vSphere servers. They happily said “O Hai, I’m now a vSphere Essentials Plus server!”

So then I used the same code on my vCenter server, and it said, “O Noes! You can’t use that code here.”

I was confused, as I thought that was the only code I had. It turns out that I was wrong, as there was a code listed in my VMWare account that said “vCenter Essentials”. I thought that was the wrong thing, as I had purchased Essentials Plus. Time to chat with support.

The support guy looks up my account and gives me the vCenter Essentials keycode. “But that’s not Essentials Plus,” I respond. “I bought Essentials Plus.”

“Yeah, you’re correct… this will not allow you to use HA or DRS. You’d better talk to your reseller to find out why you have Essentials Plus vSphere but only Essentials vCenter.”

After further research, I have drawn this conclusion: there is no such thing as vCenter for Essentials Plus. There’s only vCenter Essentials. And after licensing the server, it does in fact say that it’s vCenter Essentials – but it does allow you to configure HA. Which is pretty much what I would expect, as HA is really a vSphere server feature, not so much a vCenter feature. You can’t configure DRS, as that fails with an improper license error message. So I guess the tech guy I was working with assumed (just like I did) that because you can buy vSphere Essentials Plus, you should also get a vCenter Essentials Plus. There’s no such thing.

Here’s one of the things that bothers me about Essentials and Essentials Plus: vmotion is disabled (which I understand), but storage vmotion is also disabled. Now I seem to remember that back in the 3.5 days, storage vmotion was kind of an undocumented feature available only through the CLI, so there were a number of authors who wrote plug-ins, either scripts or GUI’s and eventually a VCenter plugin. But storage vmotion didn’t depend on a license, it just worked.

Now VMWare has integrated storage vmotion into vCenter directly, but turned it off for the low-end (SMB-target) systems. I understand that they see this as a feature worthy of purchasing the pricier versions to get, but it kinda sucks to lose what was a “free” feature by upgrading to 4.0.

Furthermore, the Essentials packages don’t appear to have the “ala carte” pricing model (unlike their high-end brothers), so I can’t just go out and buy a storage vmotion license. Grr. It just frustrates me because there’s no technical reason why VMWare can’t do it.

Storage vmotion is also one of those features that would appeal to the SMB market even more, as we are more apt to be dealing with low-end storage, where you’re juggling 1 TB on one IET OpenFiler, 500 GB on a Windows Storage Server, 500 GB on a NAS box, and so on… being able to seamlessly move servers between dissimilar storage media was a KILLER feature. I found it even more useful than vmotion, as I could relocate virtual drives to where the best i/o performance was. But what VMWare giveth, VMWare taketh away.

Unless someone’s writing a script…

“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.