Monthly Archives: November 2012

The Hung VM on reboot

I recently had a crashed VM running on ESXi4 that hung during reboot on the black VMware boot screen.

After many frustrating hours I realised that it was due to one of its many RDMs.  Initially the only way to get the VM to successfully reboot was to remove all the RDM disks.  I then proceeded to add the RDMs back in one by one with successive reboots to make sure there where no issues.

I identified the faulty RDM when I went to add it back in.  I received the following error message.

File [datastorename] foldername/filename.vmdk is larger than the maximum size supported by datastore

A few online docs pointed to a few areas to investigate but none seemed to be my issue.  The datastore was formatted on VMFS3 with an 8 MB block size.  More than sufficient to handle a 10 GB RDM.

I checked the vmware.log file of the VM.  There was one error that repeated itself multiple times.

A one-of constraint has been violated (-19)

I tried adding the disk in as both a Virtual and Physical RDM without success.  I tried added it to a different VM without success.  As a final resort i mounted the volume from the SAN to a physical Windows server.  While I was expecting a corrupt volume I was surprised to find it in a clean state with accessible data.

As much as i would have like to keep troubleshooting the issue time was a factor.  I created a new 10 GB volume.  Mounted this new volume to the physical server.  Then performed a simple file copy from the original volume at issue to the newly created volume.

I un-presented the volumes to the physical server.  Then back in ESX, went through the process of adding the newly created volume as an RDM and ignoring the original faulty volume.

In conclusion, it’s time to get the hell away from these RDMs.  There’s just little justifiable reason to keep using them nowadays.

Worse yet, as I’m told, I may have resolved the issue but haven’t found the root cause.

 

Appendix

VMware KB article to RDM error

 

Worst folder naming convention ever!

I have to give credit to my co-working, Stu, for finding this one.

Disable Time Synchronization of ESX guest

One thing that I hate is time syncing of VMs.  It’s caused me grief for years.  For the most part, true, it’s not an issue.  Though one issue is too many for me nowadays.

When you install VMware Tools into a guest VM there is an option we are all familiar with, “Time synchronization between the virtual machine and the ESX Server”.  Even with this setting unchecked what you probably don’t realise is that there are “special” events that will still initiate a time sync between the guest and host.

Time will resync with a vMotion, snapshotting, disk shrink, or a restart of the tools.  I can understand the logic of why they are doing this.  All these events are touching the guest in some way and you want logs and timestamps in sync, but it’s still not cool.

I had seen this behavior in the past and though it was more a bug rather than a design feature.  There are certainly situations where you might have time sensitive VMs that rely on external time sources.  Telephony is an example.  There are also other side effects like time jumping over scheduled tasks.

Turns out all these special events can be individually disabled by entering them into the Configuration Parameters section of vCenter for the VM or editing the VMX file.

Configuration Parameters can only be edited while the VM is off.  The settings can be accessed by access the Edit Settings of a VM.  Clicking on VM Options and then Advanced.

The VMX file can be edited anytime but you will need to do it on the ESX server that is hosting the guest VM or you will get a Resource Busy error message.

All VMs will have the below line in their config.  0=Disable, 1=Enable.

tools.syncTime = “0”

The other parameters to disable “special” event time syncing are below.

time.synchronize.continue = “0”

time.synchronize.restore = “0”

time.synchronize.resume.disk = “0”

time.synchronize.shrink = “0”

time.synchronize.tools.startup = “0”

time.synchronize.tools.enable = “0”

time.synchronize.resume.host = “0”

.

Appendix:

Vmware KB article to disabling time synchronization

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

vCenter Web Client timeout

New in vSphere 5.1 is a completely redesigned vCenter Web Client.  Many of us would have never used the Web Client in previous versions of vSphere and for the few that did would have been quickly turned off by it.

VMware have put a lot of effort in this new version, to the point where many of the new features in 5.1 are only available in the Web Client.  Moving forward the C# client will no longer be developed and 5.1 will be the last version.

One of the features of the C# client was the ability to stay logged in indefinitely.  For good or for bad (from a security view) I like it.  My workstation is always secured when away from it and I liked being able to come back and have the vCenter Client connected and running.

With the new 5.1 Web Client a session is ended after 2 hours of being idle.  In all honesty this isn’t too impractical and will suit most people.  That being said I like being able to log in at the start of the day and know that I will still be logged in at the of my day even if I having been active on the new web client.

Currently there is no setting within the Web Client that will allow you to change the idle login timeout.  The timeout can be changed through a config file, both in Windows and the vCenter Virtual Appliance.

Windows

Navigate to %SYSTEMDRIVE%UsersAll UsersVMwarevSphere Web Clientwebclient.properties

Uncomment the line (remove #) and change the value in minutes for session.timeout = 120

Restart the VMware vSphere Web Client service

 

Virtual Appliance

Navigate to /var/lib/vmware/vsphere-client/webclient.properties

Uncomment the line and change the value in minutes for session.timeout = 120

Restart the Web Client using /etc/init.d/vsphere-client restart