I’ve been holding off upgrading my lab to vSphere 6.5 because NSX 6.2.x doesn’t support it. With the release of NSX 6.3 and vSphere 6.5a, I can now upgrade. The sequence of the upgrade is slightly different to the generic one published by VMware because vSphere 6.5 isn’t supported with NSX 6.2. If follows that I need to upgrade NSX to 6.3 (which supports vSphere 6.0u2) before I can upgrade vSphere to 6.
Equal Cost Multipathing (ECMP), for the vSphere admin, is ability to create routes with an equal cost, which allows multiple paths to the same network to be created and traffic can be distributed over those paths. This is good for a couple of reasons - firstly is availability. If we were to lose a host, and an NSX Edge, the route will time out quicker than NSX Edge High Availability - thus providing higher availability for our network traffic.
My vSphere lab is split into two halves - a low power management cluster, powered by 3 Intel NUCs, and a more hefty workload cluster powered by a Dell C6100 chassis with 3 nodes. The workload servers are noisy and power hungry so they tend to be powered off when I am not using them, and since they live in my garage, I power them on and off remotely.
Back in January 2015 I wrote an article on how to modify the Java heap settings for the vCenter Orchestrator client when working with very large workflows. Since vRealize Orchestrator 7.x has been released, we no longer have an installable client, just a Java WebStart file (.jnlp) that you run, or a package that you can download - but nothing that installs. Note that none of this is official or supported by VMware as far as I know - it’s the results of my experimentation which has shown some performance improvement by increasing the configured memory pool.
Recently I’ve been working on some ideas in my lab to leverage the AWS endpoint on vRealize Automation. One of the things I needed to get working was getting Software Components working on my AWS deployed instances. The diagram to the right shows my end-stage network - the instance deployed by vRA into AWS should be in a private subnet in my VPC, and should use my local lab DNS server and be able to access my vRA instance.
When you’re working with Amazon and vRealize Automation Software Components, one of the requirements is for the Guest Agent (gugent) to talk back to the vRealize Automation APIs - the gugent polls the API for tasks it should perform, downloads them from the API and executes them, then updates the tasks with a status. This means that Virtual Machines deployed as EC2 instances in an AWS VPC require the ability to talk back to internal corporate networks - not something you’d want to publish on the internet!
I have been musing this a little while and decided to write this post/rant/opinion post, feel free to post your thoughts and opinions in the comments. OK so here it is, one thing I have observed for a good while now is how much noise there is about how -you- should be in the cloud (Public) and if you are not you’re already dead. I call Bull****! Public, Hybrid and Private clouds are solutions not final destinations, regardless of whether you are a customer, partner, or any other third thing you should be purely focused on what is best for you or (if you provide IT services) your customer.
So, this is something I’ve been waiting to write up for a while! PowerShell for macOS has been available for a while now, but what a lot of PowerCLI fans have been waiting for is to be able to use PowerCLI direct from their Mac. Today, amidst all of the noise from VMWorld, PowerCLI Core dropped as a Fling! That means that although it’s not ready for production use yet, it is ready to start testing - and I’m way more excited than I should be!
I ran into a strange one with my lab today where the previously working VSAN cluster couldn’t be enabled. Symptoms included: The button to enable VSAN was missing from vSphere Web Client vsphere_client_virgo.log had the following error: [2016-09-16T14:49:03.473Z] [ERROR] http-bio-9090-exec-18 70001918 100023 200008 com.vmware.vise.data.query.impl.DataServiceImpl Error occurred while executing query: QuerySpec QueryName: dam-auto-generated: ConfigureVsanActionResolver:dr-57 ResourceSpec Constraint: ObjectIdentityConstraint TargetType: ClusterComputeResource Target: ManagedObjectReference: type = ClusterComputeResource, value = domain-c481, serverGuid = a44e7d15-e63f-46c2-a1aa-b9b1cbf972be
vRealize Automation vExperts Workshop I attended a workshop with Jad El Zein in Barcelona last year and it was one of the best sessions I attended, especially as it was just on the news of vRA7’s release. This workshop was this year’s equivelant, but because the session included a lot of people just getting started with vRA a lot of the time was taken to explain what vRA does, so there was no real time for the more in depth details on the new features that are coming (some already announced and in Tech Preview).