VMXNET3 compatibility problem

Microsoft released convenient rollup update for Windows 7 and Server 2008 R2 in late May 2016. This rollup update will bring your installation to the latest patch level with only a few installations but it has a bad side effect. All VMs running on vSphere (it seems that ALL vSphere versions are affected) and use the VMware proprietary VMXNet3 type of virtual network card will prbably being hit by network issues. The reason behind this is that after applying the update, the OS will create a new vNIC but the settings for the old vNIC will still reside in the registry. This will lead to network problems.

You can get some more details on the link above or here. VMware currently recommends to delay installation of this rollup package until there is a resolution from Microsoft.

Comment (0) Hits: 4298

VMware VSAN 1-2-3

VMware VSAN is a cool technology and probably something you already heard of (100% if you constantly follow my blog). As there are a huge amount of information available on the internet I decided to strap them down a bit and focus on the key aspects in form of a FAQ. This blog post is not meant to give you any special technical information about how to configure or use any VSAN component but rather gives the VSAN newbies a quick overview what VSAN is, what it does and if it fits for you.

Read More Comment (0) Hits: 3128

vSphere 6 - critical VMXNET3 bug

With vSphere 6 update 2 VMware fixed several bugs but also introduced a new one. Update 2 includes a critical bug in the VMXNET3 vNIC that can produce PSODs (purple screen of death). The problems occur if:


  • the VM is running virtual hardware version 11
  • the VM is configured with VMXNET3 virtual nic
  • Large Receive Offload (LRO) for VMXNET3 NICs is enabled

Currently there is no resolution but a workaround. All details are published in KB2144968.

Comment (0) Hits: 4245

VMware VSAN - Introduction

Choosing the right storage solution for a VMware environment is a hard thing to do. Luckily because that's the reason you would call someone like me. But during the last few months/years new storage vendors came to market with products that are easy to understand, easy to manage and easy to scale. The offer a lot of functionality and are perfectly suited for virtual environments as they are not build on top a a general usage rule but rather optimized for virtual workloads. Examples for theses systems are Nimble, Nutanix, Tintri, Pure Storage, Simplivity etc. 

On the other hand the software defined storage market evolved and promised to be the solution for nearly every workload.

VMware began to talk about the Software Defined Datacenter a few years ago. Compute was never a problem, with vSphere they already were and still are market leader in this area. Next was storage. With the VSA they tried to go to market but this VM-based storage solution was never a success. So they went to network. With Nicira they bought a company already developed a software defined networking solution and integrated NSX completely in their vSphere network stack. So the last area that wasn't covered in a good way was storage.

Read More Comment (0) Hits: 2760

Patch for VMware ESXi 6.x CBT bug

Recently I wrote about the newly observed CBT bug in ESXi 6.x that, once again, could render your backups unusable. For the last two weeks only workarounds were available which could potentially lead to a extremely larger backup window and therefore making things not really better.

Fortunately VMware is used to fix these kind of problem quite fast these days and on 25th November they released an update to KB 2136854 with a hotfix included.  VMware ESXi 6.0, Patch Release ESXi600-201511001 (2137545) will fix the new CBT bug and hopefully this is the last patch we have to wait for until CBT works as designed.

As also written in the notes to Patch 201511001 there is still a problem with HP ProLiant Gen9 servers that won't see their local disks after patching to ESXi 6 Update 1 and later. Keep this in mind when patching an older unaffected version of ESXi 6 to Update 1 or newer on a Gen9 server.

Update 11/30/2015

Veeam tested the patch against their backup product and it seemes that resetting CBT on all VMs is 100% mandatory to get the patch to work. So simply installing the patch is not enough, you HAVE TO reset CBT.

Comment (0) Hits: 2941

Major updates to vSphere 5.5 and 6.x

A few weeks ago I wrote about several critical issues with vSphere 5.5 and 6.x versions. The 5.5 version was affected by a serious bug that causes VMs to crash during snapshot removal processes. That made backups a real challenge because you had to choose between having backups or keeping your VMs running. Not a decision you want to make.

vSphere 6.x was hitten by a random loose of network connectivity for the service console port so a stable use was nearly impossible.

Fortunately for both problems VMware released bugfixes. For vSphere 5.5 Update 3a is now available, for vSphere 6.x Update 1a fixes the problem. You can get access to these bugfixes by simply using the Update Manager or if you prefer to get some more information you can follow these links to Update 3a and Update 1a.

Comment (0) Hits: 2428

VMware vSphere 6 CBT bug - the nightmare continues

For all of you who hoped to see the CBT bug vanishing at least with the latest patches and rollups like vSphere 6 update 1a, you have to wait a bit longer.

Once more a critical bug was found in CBT that affects all VM backups, fulls as well as incrementals. The root cause is found (but not published by VMware) and it seems that heavy write I/O on a VM will cause CBT information to be wrong and thus causing incremental backups to contain corrupt data.

Full backups are also affected as CBT is used to find zeroed out space regions to be skipped by the backup solution.

Currently there are only two workarounds: downgrade to vSphere 5.5 (not really an option for all of the users already made the effort to upgrade to version 6) or disable CBT usage inside their backup application. To do this in Veeam foolow this link. This will make backups take longer as all data has to be read from the source disk to compare which blocks have benn changed since the referencing backup but has a lower impact on your environment.
A third workaround is mentioned in the KB article from VMware but I don't think that shutting down a VM before taking incremental backups doesn't really make sense.

Probably VMware will release a patch soon but how long is "soon" and how long can you take the risk of having corrupted and therefore unusable backups? So my recommendation is to switch off CBT, make a new full backup of your VMs just to be sure you have a valid base and then wait for another CBT patch from VMware.

VMware has a KB article, to be found here. Subscripe for updates and patches to this bug.

Comment (0) Hits: 3322

Still existing problems with vSphere 6.0 Update 1

A few days ago VMware released Update 1 for vSphere 6.0. Most customers decide not to upgrade to new major versions until Update 1 or ServicePack 1 or whatever you may call it, is available to fix the most critical bugs. Well, in my experience, vSphere 6.0 RTM release was a bit buggy and waiting for the Update 1 release seemed to be the most appropriate way to keep your vSphere infrastructure up and running. Unfortunately with Update 1 things won't get any better. First Update 1 was a showstopper for alle Veeam installations as VMware changed to SSLv3 and Veeam had problems to connect to the virtual infrastructure. In the meantime Veeam admitted that it was their fault and they provide a hotfix (available via support case and ref id 56246 or within Update 3 coming late September).

More important to note is that VMware announced a general bug in all existing vSphere 6.0 versions that causes the service console connection to drop randomly. This causes ESXi installations to become unmanageable. Currently there is no fix for the bug, only a reboot of the host solves the problem (perhaps only for a while). As the SC connection is also neccessary to move VMs to another host before rebooting it this bug can will probably cause service donwtime. VMware currently provides a workaround and is "aggressively working on a fix", latest information is available at VMware KB2124669.

We have currently only two customers already upgraded to vSphere 6.0 and never seen this problem here. Perhaps it is hardware related, all our vSphere 6 installations run on HP hardware.

So if you waited for Update 1 to solve this problem you probably have to wait for Update 1a or even Update 2.


Comment (0) Hits: 4180


joomla templatesfree joomla templatestemplate joomla
2018  v-strange.de   globbers joomla template