A recent research study has unveiled a security risk in Transparent Page Sharing (TPS), as acknowledged by VMware in kb2080735.
The researchers were able to discover that from a virtual machine A, an AES encryption key could be retrieved from machine B. While the steps to achieve this seem difficult to reproduce, the risk is real. In fact, the risk is so real that VMware decided to disable TPS for all future versions of ESXi, as well as all current versions for the next update release.
For example, version 5.5 is currently in update 2: TPS will be disabled with update 3. More exactly, inter-vm page sharing will be disabled per default. Pages can still be deduplicated within a virtual machine world, for a much smaller benefit of course.
Until these new releases hit the market, patches are available for those who wish to disable TPS in versions 5.5 and 5.1. And a patch is coming for version 5.0.
In the previous article we deployed the vCenter Server Appliance and made a basic setup. In this article, we will go a step further and cover the licensing and authentication for your new vCSA
I’m a huge fan of the vCSA (vCenter Server Appliance). Since version 5.5, I consider it suitable for production and will perfectly replace a manually installed Windows server. In fact, the Windows-version even looks like a dinosaur now :).
In this article, we are going to deploy a new virtual appliance on a standalone ESXi host and make the initial configuration.
Recently an old, old CBT (Changed Block Tracking) bug has been discovered. This bug exists since ESX 4.x! As a reminder, CBT keeps track of the changed blocks of a virtual machine disk, which enables incremental backups of virtual disks. As far as I know, all software vendors rely on CBT to provide virtual machine backup, so that’s a big issue!
The problem appears when virtual disks are extended past specific disk sizes: 128GB, 256GB, 512GB or 1024GB. When this happens, CBT transmits incorrect information and backups become corrupt. The very bad part is that the bug is completely silent and you won’t notice until you (try to) restore the virtual machine.
Last time we discovered a new localcli command to clear the IPMI SEL Event Log after the “”Host IPMI Event Log Status” error. This time, we are going to automate this command with a script, so that future errors will be handled automatically.
Basically, the script is going to:
- identify which servers have the IPMI alarm active.
- for these servers, enable SSH.
- connect with plink (think: putty on command line) and run the commands that will reset the IPMI System Even Log.
- disable SSH.