VM /ETC

Posts Tagged ‘issues’

Like everyone else, I have been reviewing the Release Notes for the latest Update 1 release of vSphere 4.1, but I decided to point out specific fixes that will make full image VM backups better for everyone. Note that I work for Veeam Software, but the fixes I am referring to are all VMware resolved issues that surface from time to no matter what backup solution you use. There are numerous other fixes and impovements in the U1 release, but, since most of my world is backup these days, these particular items “popped out” at me.

For a great overview of the entire U1 release check out Rick Vanover’s post vSphere 4.1 update 1 released from his Rickatron Blog and via his Servers and Storage Column/Blog at TechRepublic.

The rest of this post contains cut and pastes from the Release Notes and some commentary about them from me. I want to stress again that these are issues that have now been fixed!

Finally, I’ll point out the one huge VM backup issue (that I can think of right now) that still does not appear to be resolved.

Read the rest of this entry »

Earlier this week VMETC.com fell victim to a WordPress hack that redirected readers to a malware infested site. Best estimate is that early Thursday morning (9/17) the site was compromised by an attacker that was able to add several lines of code to the beginning of every PHP file in my public_html directory. With several other WordPress sites hosted in the same directory, there were thousands of files that needed to be cleaned up. All site RSS feeds were rendered unavailable as a result.

The hacker left a “silence is golden” message in a few of the files. There are 18,900 hits on Google for this WordPress attack.

Lucky for me, the social community not only notified me of the issue (thanks Ken Fury, @kculw, @ericsiebert and @jasonboche), but came to the rescue as well.

@SirStan (Stan Brinkeroff), A Twitter follower (that I follow as well), offered some assistance if needed and I jumped at the chance.  Stan figured out the exploit, identified the rogue code, deciphered it’s evil, implemented a temporary work around for Friday night, and then found, tweaked,  and t-shooted the script to bulk remove the offending lines in each file. Stan is definitely a PHP master and a ‘nix wizard. For saving this site Stan is now an Ugly Green Hero as well!

Stan lost 3+ hrs of his weekend to help me. I hope the VMETC and VIRTUMANIA t-shirts I am sending him are an adequate payment (let me know if not, Stan).

VMETC.com and VIRTUMANIA.net are back in business. Please let me know if anything is still messed up.

Do me a huge favor, tweet @sirstan and tell him thanks and great job! I can’t say it enough by myself.

VMware announced the U2 (update 2) release of ESX 4.0, and unfortunately early adopters quickly discovered VMware View virtual desktop connections using the PCoIP protocol were failing. This post provides some quick info on both the new release and the new VDI problem it creates.

UPdate 2 Info

VMware ESX 4 Update 2 is available for download here. The following is a cut and paste of What’s New from the Release Notes:

• Enablement of Fault Tolerance Functionality for Intel Xeon 56xx Series processors— vSphere 4.0 Update 1 supports the Intel Xeon 56xx Series processors without Fault Tolerance. vSphere 4.0 Update 2 enables Fault Tolerance functionality for the Intel Xeon 56xx Series processors.
• Enablement of Fault Tolerance Functionality for Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors— vSphere 4.0 Update 1 supports the Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors without Fault Tolerance. vSphere 4.0 Update 2 enables Fault Tolerance functionality for the Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors.
• Enablement of IOMMU Functionality for AMD Opteron 61xx and 41xx Series processors— vSphere 4.0 Update 1 supports the AMD Opteron 61xx and 41xx Series processors without input/output memory management unit (IOMMU). vSphere 4.0 Update 2 enables IOMMU functionality for the AMD Opteron 61xx and 41xx Series processors.
• Enhancement of the esxtop/resxtop utility— vSphere 4.0 Update 2 includes an enhancement of the performance monitoring utilities, esxtop and resxtop. The esxtop/resxtop utilities now provide visibility into the performance of NFS datastores in that they display the following statistics for NFS datastores: Reads/s, writes/s, MBreads/s, MBwrtn/s, cmds/s, GAVG/s(guest latency).
• Additional Guest Operating System Support— ESX/ESXi 4.0 Update 2 adds support for Ubuntu 10.04. For a complete list of supported guest operating systems with this release, see the VMware Compatibility Guide.
• Resolved Issues – In addition, this release delivers a number of bug fixes that have been documented in the Resolved Issues section.

PCoIP Connections Issue

The following cut and paste is from the VMware KB Article Upgrading VMware Tools in a virtual desktop causes PCoIP connections to fail: Read the rest of this entry »

Tom Howarth, VMware Communities Moderator and blogger at PlanetVM.net, posted this week how he was informed by a developer of a virtualization backup vendor about a scenario involving reverting to an ESX snapshot that results in corrupted incremental backups when using vSphere’s Change Block Tracking (CBT). Howarth’s post Major issue with Change Block Tracking recounts his conversation and exploration of the problem with the developer. In summary, Howarth reported “there is a major issue with the way VMware handles the indexing of the ChangeID.”

Almost a week later and after a flurry of comments from most of the vendors leveraging CBT for virtual machine backups, VMware has published a KB article on the subject.

VMware KB: Reverting to a pre-existing snapshot under specific conditions can cause incremental backups based on CBT (Changed Block Tracking) to become inconsistent

The KB Article describes the exact scenario that causes the problem:

Read the rest of this entry »

A new patch for VMware ESX 3.5 Update 3 was released last week that fixes the previously reported iSCSI and FC Alert – “Queue for device has been blocked” issue. The fix was part of a bundle of patches released for ESX 3.5, ESXi 3.5 and ESX 3.0.x products.

Duncan’s summary post over at yellow-bricks.com pointed me to the new VMware KB article specific to the patch with the I/O alert fix: VMware ESX 3.5, Patch ESX350-200901401-SG: Updates VMkernel, VMX, and hostd

Upon reading the KB article I noticed that the VI Client NTP configuration issue I have posted about, and continue to run into, has also been fixed.

Read VMware’s KB for all “the other issues” corrected along with some information about applying the patches with or without Update Manager.

I was surprised to find there is not a “send ctrl+alt+del” menu command in VMware Server 2.0 (updated 01.30.09) when connecting from an Ubuntu desktop. It’s not in the Remote Console menus nor in the Commands section of the Web Interface. Normally that is not a big deal because you can always use “ctrl+alt+ins” to log on to a Windows VM, but it did not work.

I was banging away at my keyboard wondering what was wrong. I had just finished installing Server 2008 remotely from one of my Intrepid desktops and was ready to log back in to run dcpromo but I could not get to the log on prompt. I thought maybe my ins key went bad, but I knew that could not be the case. When I tried to use another Ubuntu desktop I had the same problem. Then I discovered there was not a menu command either! I silently questioned whether the VMware Server team’s parents were married when they were born, and then I did some research.

I quickly found the answer at the following thread on the Ubuntu Forums: vmware server 2.0 in intrepid ibex [Archive] – Ubuntu Forums. Turns out you have to use the Del key from the number pad on your Ubuntu desktop’s keyboard because the keyboard mappings in Ubuntu 8.10 are not correct! The working key combination is therefore “ctrl+alt+[numberpad]del.

updated 4.30.09 – if you do not have a number pad on your keyboard (laptops) then make this quick config change.

add just one line to the file ~/.vmware/config:

xkeymap.nokeycodeMap = true

Close the VM web console and reopen it for the change to take effect.

VMware please add a “send ctrl+alt+del” command to the (update 01.30.09) Linux Remote Console in the next update/version of VMware Server. Ubuntu, why are the keyboard mappings messed up?

updated 01.30.09 – I added the following screen shots to show the menu options when using the Remote Console from my Ubuntu desktops. I should point out I am using Firefox 3.0.5. I also updated the opening sentence of this post by adding “when connecting from an Ubuntu desktop” and the last sentence with “Linux Remote Console”. As Dracolith points out in his comment and screen shot link below, the “send ctrl+alt+del” command exists when connecting from a Windows host. I confirmed The ctrl+alt+ins key combination works as expected too. Read the rest of this entry »

A few virtualization bloggers have reported that they received an alert email from VMware about an I/O failure issue involving iSCSI or Fiber Channel (FC) SANs. There is also an alert currently dispalyed at http://www.vmware.com/support. In summary, an indefinite block occurs between ESXi/ESX 3.5 Update 3 hosts and VMFS 3 Luns which results in all paths to the storage entering a standby state. The issue is apparently isolated to the Update 3 version only.

Eric Sloof is one blogger that received the email and he has published his copy on his NTPro.nl blog. Here’s a brief quote from the email about the issue:

PROBLEM STATEMENT AND SYMPTONS:

• ESX or ESXi Host may get disconnected from Virtual Center
• All paths to the LUNs are in standby state
• Esxcfg-rescan might take a long tome to complete or never complete (hung)
• VMKernel logs show entries similar to the following:
• Queue for device vml.02001600006006016086741d00c6a0bc934902dd115241 49442035 has been blocked for 6399 seconds.
• Please refer to KB 1008130.

SOLUTION:

A reboot is required to clear this condition.

VMware is working on a patch to address this issue. The knowledge base article for this issue will be updated after the patch is available.

VMware KB 1008130 is titled VMware ESX and ESXi 3.5 U3 I/O failure on SAN LUN(s) and LUN queue is blocked indefinitely and provides the pattern of vmkernel messages that identify you have this issue:

Error messages matching this pattern are repeated continually in vmkernel:
<date and time> <hostname> vmkernel: <server uptime> cpu6:1177)SCSI: 675: Queue for device vml.<Vol. Dev. ID> has been blocked for 7 seconds.
<date and time> <hostname> vmkernel: <server uptime> cpu7:1184)SCSI: 675: Queue for device vml.<Vol. Dev. ID> has been blocked for 6399 seconds.

As stated in both the email and the KB article, unfortunately the only solution is to reboot your ESXi/ESX 3.5 Update 3 hosts until VMware is able to provide a patch.