Tag Archives: CBT

ESXi Bugs – VMware Can’t Keep Letting This Happen!

VMware is at an interesting place at this point in time…there is still no doubting that ESXi and vCenter are the market leaders in terms of Hypervisor Platform and that the vCloud Suite offers a strong portfolio of management, automation and monitoring tools. However VMware has become the hunted and is suffering what most massivly successful tech companies go through after a sustained period of uninterrupted success…there are those that want to see it burn!

There are a number of competing vendors (and industry watchers) waiting to capitalize on any weakness shown in the VMware stack and with the recent number of QA issues leading to a significant bugs popping up not abating, I wonder how much longer VMware can afford to continue to slip up before it genuinely hurts its standing.

The latest couple to watch out for have become common repeat offenders since the 5.5 release…problems with vMotion, Pathing leading to PDLs/APDs and CBT issues have seemed to be on repeat if you search through the VMwareKBs over the past twelve to eighteen months.

KB2143943 – vMotion Fails After Upgrading from a number of builds
KB2144657 – ESXi 6 may not fail over correctly after encountering a PDL

As a Service Provider the CBT bugs are the most worrying because they fundamentally threaten the integrity of backup data which is not something that IT Operation staff or end users who’s data is put at risk should have to worry about. Veeam have done a great job circumventing the issue, though these issues are being fixed with drastic measures like full CBT resets…On a IaaS Platform where machines are not easily scheduled for downtime this is a massive issue.

I know that VMware are not purposely going out of their way to produce these errors, and I am sure that there are individuals and teams getting an ass whipping internally. But it has to stop…the quality of what is released to the public for consumption can’t continue to suffer from these issues. Their lead is secure for the moment and VMware have an extremely passionate and committed supporter base and even though their hypervisor competitors are not free of devastating bugs themselves (in fact ESXi was still the least patched hypervisor platform of in the last 12 months) it’s not a lead VMware can afford to let slip any more…specially with ESXi and vCenter are still at the heart of what VMware is trying achieve through new focus products like NSX and VSAN.

To be fair the VMware team do a great job and keep everyone up to date with issues as they arise and are generally fixed in quick time…VMware can’t afford to have many more:

Resolution:
This is a known issue affecting ESXi 6.0.
Currently, there is no resolution.

Especially if they are repeat bugs!

http://blogs.vmware.com/kbdigest/ 

January vCenter and ESXi 5.5 Patch Releases: Critical CBT Bug Fixed

VMware released new builds for vCenter and ESXi 5.5 today. The builds contain mostly bug fixes, but I wanted to point out one fix that had affected those who use CBT as part of their VM backup strategy. Veeam users where initially affected by the bug…though Veeam released a work around in subsequent Veeam 8 builds this ESXi patch officially fixes the issue.

When you use backup software that uses the Virtual Disk Development Kit (VDDK) API call QueryChangedDiskAreas(), the list of allocated disk sectors returned might be incorrect and incremental backups might appear to be corrupt or missing. A message similar to the following is written to vmware.log:

DISKLIB-CTK: Resized change tracking block size from XXX to YYY

For more information, see KB 2090639.

There are also a couple of other interesting fixes in the build:

  • Storage vMotion of thin provisioned virtual machine disk (VMDK) takes longer than the Lazy Zeroed Thick (LZT) disk.
  • When a quiesced snapshot is created on a Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, or a Windows Server 2012 virtual machine, duplicate disks might be created in the virtual machine.
  • On an ESXi 5.5 host, the NFS volumes might not restore after the host reboots. This issue occurs if there is a delay in resolving the NFS server host name to IP address.

For those who backup VMs with disks larger that 128GB I would be looking to deploy this patch ASAP.