vRealize Operations Passwords

When setting up a new vRealize Operations 6.6 environment (using the vRealize Operations Manager Initial Setup wizard) the password is not accepted despite apparently meeting the complexity requirements.

The criteria stated are that passwords must:

  • Be at least eight characters long
  • Be different from your username
  • Contain lowercase, uppercase, numeric, and non-alphanumeric characters

VROps Manager Initial Setup


It appears that full stop and question mark do not count as the “non-alphanumeric” characters required.


Choose another password which includes a different, acceptable, non-alphanumeric character such as the exclamation mark.


Vendor Brief: Runecast

runecast3This evening I was amongst a group of vExperts attending a webinar briefing from Runecast. The company is relatively new on the scene at only a couple of years old, but the product has created a stir in the VMware community. In this briefing CEO Stanimir Markov gave an overview of the product before Senior Engineer Ivaylo Ivanov dived into a walkthrough of the vRealize Operations integration they have developed.

Runecast Analyzer is a platform which takes the VMware knowledge base,along with some expertise, best practises, and regulations (for example the DISA STIGs used by US Federal Agencies) and runs an analysis to determine which of these advisories or best practises apply to the target virtual infrastructure. This produces a report of findings – perhaps there’s a missing patch, or a configuration issue which has been flagged as a potential trouble-spot – which exposes existing issues and enables the admin to keep their infrastructure running smoother. Runecast also scour social media, blog articles, and online forums to pick up on potential issues sometimes before they have been officially recognised by VMware and made it into the Knowledge Base.


The application is deployed as a virtual appliance and sits in the datacentre where it can talk to vCenter(s) and the ESXi hosts themselves (for example to receive host logs via syslog). The current version – Runecast Analyzer 1.6.2 – will support vSphere 5.x and 6.x versions. Although it usually requires an internet connection to download the latest updates, no data is sent back and in high security environments it’s even possible to run the system totally disconnected from the internet- providing updates on downloaded and tested ISO images.


VMworld this year saw the launch of the vRealize Orchestrator plugin which was covered in the demo portion of this briefing. This integration allows the potential for more automated responses to issues. As an example,  if there’s a Knowledge Base article which states that a certain configuration may cause an error and suggests a fix or workaround, a vRO workflow could be put together to interrogate the Runecast Analyzer instance, spot affected objects in the environment and apply the fix.



The Analyzer product is continually developing. vSAN and NSX support are on the roadmap along with integration with PCI-DSS compliance checks. If all this sounds interesting, check it out- there’s a free 14-day trial available through the Runecast.biz website.


Beginners Guide to….. Runecast Analyzer
What does it do?

imageMonitors your environment against a list of VMware KB articles, and other industry guidelines to proactively avoid problems ensure your virtual infrastructure is running to best practises.

What do I need to buy?

Runecast Analyzer deploys as a virtual appliance with licensing based on ESXi sockets. There is a free 14-day trial.

How do I use it?

Deploy the OVA to your environment and point it at vCenter. Management of the product is via an HTML5 web interface, the vSphere (or VRO) Client via a plugin, or a REST API.

Where can I find out more?


Please read my standard Declaration/Disclaimer and before rushing out to buy anything bear in mind that this article is based on a sales presentation rather than a POC or production installation. I wasn’t paid to write this article or offered any payment.

How To… Patch VCSA

With VMware vCenter Server Appliance 6.5 patching has become very straightforward and both the vCenter software and the underlying Photon OS can be updated using a simple GUI. This short run through covers patching a single VCSA where the VCSA High Availability has not been configured.

Login to the vCenter Server Appliance admin console at https://my-vcenter-name:5480/

2017-10-03 (1)

Click on Images to Enlarge

Select “Update” from the Navigator menu on the left hand side, and then choose “Check Repository” from the “Check Updates” drop down in the main panel. This will check the VMware website for any new patches.

2017-10-03 (3)
Continue reading

Vendor Brief: Turbonomic

I’ve blogged about Turbonomic before– when they evolved from VMTurbo in 2016 and at VMworld 2017 in Barcelona I had a sit down with Perry and Giampiero from the company to see where the product was at 12 months on.

This is a single product company- “Turbonomic” is both the company name and the product name. The product “enables workload self-management” – in a nutshell monitors the environment to ensure that whenever possible applications are given the resources they require. Consider this at its core to be “DRS on steroids”- I was told they can get a density of 30% more VMs per host compared to normal VMware DRS.

turbonomic logo

The thinking behind the resource allocation by Turbonomic is very focussed on a desired state, rather than looking out for something broken they look at the situation from another perspective by defining what a good state looks like and then worrying about how to get there. To get to this good state the software will take into account placement (host, datastore etc), scaling (looking for oversized VMs as well as undersized), and the capacity of resources available.

The Turbonomic software tries to look at the big picture of the estate- for example “will migrating a hot virtual machine using high CPU onto a new host have a knock on effect on the memory available to other VMs already present on that host?”. The aim, as with any resource scheduler, is to make the best use of the resources available and when an application has a requirement for certain resources it will find the best location and (in Turbonomic’s case) size for that VM.

One example application of this resizing process that was suggested is the deployment of new VMs. Rather than deploying T-shirt sized VMs a company could just deploy “Small” and then Turbonomic could automatically scale those VMs up (or down) through their lifecycle to ensure that the application had the resources it required (subject to availability). In my opinion this sounds like an improvement over the normal “T-shirt” model as it allows more flexibility for applications which need more memory, or more CPU, but perhaps not both. If VMs are sized according to their current requirements, rather than their original template this must surely reduce wastage and therefore potentially save money.


Similar to the affinity rules in DRS, Turbonomic also allows multi-tier apps to be grouped together in units they call “vPods”. For example if an application has a web server and database server and you’d like them to stay together to keep any network traffic in-host. On the subject of DRS, existing policies from vCenter can be imported into the software.

Public clouds are obviously an important tool when manipulating workloads that can scale on demand, and unsurprisingly Turbonomic has integrations here. As well as being able to negotiate with your on-premises environment, the software can talk to the major cloud providers. This provides additional benefits as an oversized VM in the cloud can have big financial implications and the ability to automatically downsize is possibly more important here than in an on-premises environment. Also in the modern multi-cloud world Turbonomic can monitor cloud pricing across vendors along with real-time workload usage and suggest moving services to a different provider, including a real pound/dollar/euro/etc figure of how much a migration could save.

In summary, Turbonomic is worth a look if you’re looking to implement a new monitoring solution and want some automation around it, or if you are looking to reduce your outlay on servers in your own datacentre or your monthly bill from the public cloud.

Beginners Guide to….. Turbonomic

What does it do?

Monitors your environment and moves and scales workloads to give them the resources they need wherever possible.

What do I need to buy?

Turbonomic is a virtual appliance with licensing based on the physical core count or virtual machine count. There is a free 30-day trial.

How do I use it?

Deploy the OVA to your environment and point it at vCenter (and any cloud providers). Management of the product is via a web interface.

Where can I find out more?


Please read my standard Declaration/Disclaimer and before rushing out to buy anything bear in mind that this article is based on a sales discussion at a trade show rather than a POC or production installation. I wasn’t paid to write this article or offered any payment, although I did pick up a branded drink bottle.

vSphere Encryption- Knowing your limits

SecurityI’ve been running a Proof of Concept system for vSphere Encryption using vSphere 6.5u1 and a HyTrust KeyControl 4.0 KMS cluster. This has been very straightforward to implement and use and there’s plenty of documentation out there on how to do so, but in this post I’ll be highlighting some of the limitations. A few of these are things you can’t do that you may currently do day-to-day with normal VMs but there’s usually a sound technical reason why it’s not possible to do so with an encrypted VM.

Encrypting and Decrypting

The power state of a VM limits some encryption processes. For example, a powered-on Virtual machine can not be encrypted or decrypted. This example shows what happens when PowerCLI (with the encryption module described here) is used to encrypt a running VM:

PS C:\> Get-VM -Name "KMSTest6" | Disable-VMEncryption
Disable-VMEncryption : The VM can only be decrypted when powered off,
 but the current power state of KMSTest6 is PoweredOn!

The encryption can be changed (a re-key operation), possibly to a different KMS server- however whilst a “Shallow Re-key” operation where the key is re-encrypted is fine, the “Deep Re-key” where the disk itself is re-encrypted with the new key is not possible when the VM is powered on.

Snapshots and Clones

Similarly, a snapshot including memory of a running VM is not possible. It is possible to snapshot a powered off VM, or a running VM without the memory state (which creates a powered-off snapshot), but not to include the memory. This makes sense as the VM Encryption process runs as the hypervisor writes to disk, memory would be outside this process and potentially reveal unencrypted data in the snapshot.

It’s also not possible to decrypt or encrypt a VM with snapshots:

PS C:\> Get-VM -Name "KMSTest5" | Enable-VMEncryption
Enable-VMEncryption : KMSTest5 has snapshots,
 please remove all snapshots and try again!

You can however clone an encrypted VM- the resulting clone is also encrypted and uses the same keys. vMotion also works as expected.


vSphere Replication does not work with encrypted VMs. Replication can be configured but will fail when it tries to sync.



In most environments where vSphere Encryption is in use, the hosts will probably be all licensed with Enterprise Plus (see the license comparison table). However, if you are running a mixture of licenses (including any regular non-plus Enterprise licenses) the limitations of  those licenses comes into play. It’s not possible to turn on encryption on a VM allocated to a host with anything but a full Enterprise-Plus license.

Any hosts with Standard, or the no longer available to purchase Enterprise licenses will not allow their VMs to be encrypted- or for encrypted VMs to be migrated onto them. Additionally if you have one or more of these “inferior” hosts in a cluster you will not be able to power on an encrypted machine in that cluster- even if other hosts are licensed to Enterprise Plus.


There’s lots of flexibility down at the disk level. You can use different keys (or even KMS Clusters) for different virtual hard disks (i.e. each .vmdk has a different key) and you can take an encrypted disk and attach it to another VM. The limitation here is you cannot attach an encrypted virtual hard disk to an unencrypted VM- this again makes sense as the key information in the configuration would then be in the clear.


The encryption model introduced in vSphere 6.5 is a very useful feature and straightforward to implement however consideration needs to be taken on the continuing activities surrounding virtual machines post-encryption to ensure that operational processes are still valid.