Meta

Kategoriler


Eskiden çok sevdiğim bir sitede vardı: Tamamen boş, fonksiyonu olmayan bir buton :) "stress tuşunda anlam arayan varsa, derhal siteyi terketsin..."


Olayı abartmamak lazım tabi:






View Ertürk İhsan Limon's profile on LinkedIn


Red Hat Certified Engineer


VCP5 Certified


VMware HA warnings on VMs with 3D Graphics and VMware Tools upgrades

Recently I’ve been busy with the upgrade of my vSphere 6.0U2 environment to 6.5U1. During and after the upgrade some of the VMs started getting rebooted by VMware HA. VMs were unresponsive at that stage and vSphere logged “OS crash” due to VMware Tools heartbeat loss. VMware HA VM monitoring naturally tried to reset the machines, however randomly for some it succeeded, for some it didn’t. All of the crashed VMs have one configuration in common: 3D Graphics enabled. At first I considered the reason was VMware Tools, but then I thought: “Is it possible to lose backward compatibility this much between vSphere versions?” Actually the running Tools versions were not updated since vSphere 5.5 and somehow it didn’t complain until this upgrade.

There were two different logs (screenshots below) on the VMs that HA failed to reset, first one recurring very frequently, almost every 20 seconds:

vSphere HA attempted to reset the virtual machine because of a heartbeat failure from VMware Tools or a guest application, depending on how vSphere HA was configured. However, the reset operation failed. The most likely reason for the reset failure is that the virtual machine was running another task at the time the reset was initiated. Action: Check to see whether the virtual machine requires attention and reset it manually if necessary.

&

This event is logged when vSphere HA did not reset a VM affected by an inaccessible datastore. It will attempt to reset the VM after storage failure is cleared. The VM is affected by an inaccessible datastore due to storage connectivity loss. Resetting such a VM might cause the VM to be powered off and not restarted by vSphere HA.

I couldn’t see any ongoing activity or an inaccessible datastore. These logs seemed misdirecting so I started updating VMware Tools and virtual HW as recommended. As suspected, it solved the problem: VMs stopped crashing and found some peace.

When you don’t have the luxury to restart the systems, you may choose to “postpone” the VMware Tools and virtual HW upgrade thinking that it is not compulsory and has an extended support. Here is a good old VMware blog entry about the subject: https://blogs.vmware.com/vsphere/2013/02/is-a-vmware-tools-upgrade-required-when-upgrading-vsphere.html. Although the VMware Product Interoperability Matrix shows Tools from 5.5 still works on ESXi 6.5U1, my case proved that there may be exceptions on rare configurations. The system needs to be kept as up-to-date as possible, as a whole.

Let’s finish with VMware’s statement:

Although upgrading VMware Tools is optional, it is still highly recommended.   The extended support is meant to facilitate upgrades and should not be seen as an excuse to avoid upgrading VMware Tools.

Windows 7 crashes after waking up from sleep mode

I have a habit of upgrading to a reliable Windows version (meaning not ME or Vista) only after its first service pack is available. However this time I was a little bit late. I’ve recently upgraded my Windows XP to 7 and applied all the updates. When I saw my first blue screen of death (IRQL_NOT_LESS_OR_EQUAL), I didn’t care much and just rebooted. But it got annoying when these BSOD’s kept coming with different bug check strings: MEMORY_MANAGEMENT, PFN_LIST_CORRUPT, etc.

I analyzed the minidump files created under C:\Windows\Minidump after each crash with BlueScreenView. They were all commonly addressing to ntoskrnl.exe, NT OS Kernel. I found a hotfix for the solution, but before applying I realized that I have the newer version of the file (from SP1) installed. So, back to square one.

I googled for each error string and found lots of possible solutions. People keep saying: do this and do that… but most of them are dead end and need filtering. All I needed to do is to update device drivers. As a result of analyzing these error messages, I updated my GigaByte 7GA-EP45-DS3R mainboard drivers from its website. I haven’t got any BSOD since, I hope I won’t again.

Apart from this, I was wondering why my computer became unresponsive after it woke up from sleep state. Crash time was totally random. My mouse seemed powered off, without any laser light, nothing. I just had to reboot. I tried:

  • Control Panel -> Device Manager -> (All the USB devices, keyboard, mouse etc.) -> Properties -> Power Management -> Uncheck: “Allow this device to wake the computer”
  • Control Panel -> Power Options -> Change (Active) plan settings -> Change advanced power settings -> Sleep -> Allow hybrid sleep -> Off
  • Control Panel -> Power Options -> Change (Active) plan settings -> Change advanced power settings -> USB -> USB selective suspend setting -> Disabled
  • Changing the sleep state from S3 (Sleep to RAM, which I prefer, quite useful) to S1 in BIOS Power Management

Nothing worked. Finally I decided to flash and update my BIOS. In the mainboard website says “Fixed Vista S3 resume sometimes failed” for the latest version. I backed up my old BIOS, downloaded the newer BIOS image (ep45ds3r.f10)  and applied it with the @BIOS utility:

 

 

 

 

 

 

 

 

 

 

I needed to go over my BIOS configuration after the update because it was the factory default. I reconfigured it with S3 sleep state this time and left the device manager changes above as it is, unchecked. Looks like it worked 🙂 This is apparently a BIOS based ACPI problem. I’m glad that I can use “Sleep to RAM” option now, because I think it is the “real” sleep mode.

The methods may vary depending on your hardware vendor and configuration. But for the two problems above I can suggest : “Update your BIOS and device drivers.” Good luck 🙂