VMware has so many new shiny gadgets it is sometimes easy to forget the simplicity it can add to an administrators life. One such example was a few weeks ago.
I was upgrading the memory in a Windows 20
00 VM to 8GB, and had to alter the boot.ini to use more than 4GB. Unfortunately I was doing this remotely and during the save process my VPN died. When I rebooted the server I was faced with the dreaded ‘NTBTLDR.EXE is missing’. Now I knew that the problem must lie with the boot.ini, but how to get at it?
Because I was remote I did not have a Windows 2000 disk to get a recovery console up and I needed to get the server up and running again. I then realised that I did not need to boot from a CD to get to the VM’s hard drive.
I shut the VM off again, and jumped on to another server on the same host. In Edit Settings, I simply added the vmdk of the troubled host to the other machine and rescanned for the disk in Disk Management. Lo and behold the disk appeared and I could access the boot.ini file – I had managed to add a space at the beginning of the file during the save process which was causing the problem.
I rectified the file, removed the disk from the spare server and then the vmdk from the client. I crossed my fingers and restarted the VM … and gratefully saw the windows splash screen appear.
If this had been a physical box I would not have had a chance of fixing this remotely, and even on site there would have been much more time expended
on finding a chassis with spare slots, array controller configurations etc. so it goes to show even the most basic functions of VMware are worth
the effort of putting it in in the first place
This Thursday is the first London VMUG of 2010 and it looks like it may well be one of the most popular yet – this is hardly surprising when you see who is going to be in attendance. Based on various tweets etc, the presenters and attendees include no less than 8 of the bloggers on Eric Siebert’s Top Virtualization Bloggers and many more who appear on his Top 100 Twitter List.
Simon Long has created a Linked In Event to see who may be going – if you are going
then add your name to the list here:
Based on this and Twitter it looks like the following will be there Thursday:
There will no doubt be others I haven’t seen comment
I will see you all there!
I have been battling to try and find out where my HP servers store and provide serial numbers for vCentre in the Hardware Status plugin – to no avail I am sad to say so far. However while investigating I have had to work out how to use Wireshark to decode the SSL traffic between the vCentre and an ESX host, which is very useful for
troubleshooting connectivity or other issues between a VC and ESX host, so I thought I would record the process for reference …
For Wireshark (Download the latest version here http://www.wireshark.org/download.html ) to be able to decode the SSL traffic between a VC and host, it needs the private key of the SSL certificate. To get this you will need to copy it from the host via an SCP client ..
The file you are looking for is rui.key and is located in /etc/vmware/ssl folder.
Once you have copied the file to your local machine you can fire up Wireshark and head to the Edit > Preferences.
In there under the Protocols menu on the left hand side, select SSL and you will see the following fields:
The RSA keys list field is where you tell Wireshark to look for the server source i.p. (the ESX host),port,protocol and location of the private key you want to use to decrypt.
In this example I am using the same key to decrypt both standard 443 and 5989 (Secure CIM) traffic – to do more that one you simply use a semi-colon to separate the string:
The SSL debug file field allows Wireshark to write out how it is using the key to aid troubleshooting.
Once you have this you can load up a capture from your vCentre and look for some SSL traffic – you should see in the lower frame something like this:
As you expect the output is unreadable in the standard tab, but if you look at the Decrypted SSL data tab you should see the data magically become a lot more useful:
Wireshark helpfully will now also display a context menu called Follow SSL Stream, once it can decrypt the traffic, and will piece all the traffic
it can find back together and pop up a window with the whole transaction in one place.
Once you get into the underlying transactions it is great to see what is going back and forth between the vCentre and hosts – I hope this helps you figure out whatever problem you may be having …