VCSA 6.0 under the covers

The home lab is pretty small (32GB ram between two hosts) so being able to reduce the overhead of software/virtual machines allows me to get the most use out of the limited resources. The upgrade to vSphere 6 recently brought with it the updated vCenter virtual appliance that has new requirements for it’s use cases (tiny/medium/large). Also in the changes was the use of dynamic memory allocation detailed by William Lam here, introducing more gotchas whilst trying to tailor the VCSA deployment.

I decided to see what I could do to get my VCSA 6 to use a more conservative 4GB of ram, which had always been OK for VCSA 5.5. After enabling shell access and having a poke around I could see that the second largest utiliser of memory inside the VCSA was the vmware-vdcs process, which was the VMware Content Library process.

chkconfig vmware-vdcs off

This immediately shaved off around 1GB of ram utilisation, so a quick test had my vCenter running happily at around 4.5GB allocated (minimal swapping during the VMware services starting.



Examining what remains..


Upgrading the home lab to vSphere 6.0 with Gigabyte BRIX

I finally decided that this easter weekend was going to be the time to update the lab to vSphere 6.0, which meant that some messing around was going to be required due to the Gigabyte Brix using unsupported network adapters.

Hardware overview (2x):

Gigabyte BRIX i5-3337U CPU @ 1.80 Ghz (Turbo upto 2.7Ghz) 2 cores and hyper threading.

16Gb Ram and a 256Gb SSD.

A WD NFS data store (4Tb) for large slow storage..









HP OneView – Part 2: Server Profiles

Apologies for the delay I was busy..

What is a Server Profile

The “Server Profile” is the defining phrase that comes to mind when thinking about the SDDC (Software Defined Data Centre). It allows a server administrator to define a hardware identity or configuration (MAC addresses, WWNN, BIOS, Boot, RAID config etc.) in software and then apply this to a “blank” server.

This brings a number of key advantages:

  • Pre-designed hardware identities allow configuration tasks to be pre-provisioned before hardware deployment (SAN zoning, firewall ACLs etc..)
  • Designated addresses allow easier identification e.g.  aa:bb:cc:dd:01:01 = Management /  aa:bb:cc:dd:02:01 = Production
  • Server failure/replacement doesn’t require upstream changes, software identity (server profile) is applied and all previous configuration is still relevant.


Following on from the previous HP OneView post, this is a continuation of the same simple VMware vSphere deployment. As before, a good design should exist before implementation, so again i’ve embedded a diagram detailing where and how these networks are going to be defined to the virtual interfaces on a blade. VMware OneView Service Profiles

Quite Simply:

  • Two virtual interfaces defined for all of the Service networks.
  • Two virtual interfaces defined for the Production networks.
  • Two HBAs on each fabric, providing resilience for Fibre Channel traffic.

As mentioned, this is a simple design for a vSphere host but allows expansion in the future with the ability to define a further virtual interface on each physical interface inside the blade.


HP OneView – Part 1: Enclosures and Uplinks (logical or otherwise)

The initial configuration of HP OneView is a pretty simple and intuitive process, it just isn’t documented as well as it could be. I’ve decided to put together a few posts detailing some of the areas of configuration that could possibly do with a bit more detailed procedures. I’d expect that someone who wishes to use any thing that is documented here is already acquainted with Virtual Connect, Onboard Administrator, VMware vSphere and iLO’s etc.


Before any implementation work is carried out there has to be a design in place, otherwise what and how are you going to configure anything.. The design for these posts will be a simple VMware environment consisting of a number of networks to handle the standard traffic one would expect (Production, Vmotion etc.) at this point we have defined our networks and these have been trunked by our network admin on the switches out to the C7000’s we will be connecting too.

c7000 VMware


From this diagram, you can see the coloured VLANs represent the traffic designated management/service traffic and the grey VLANs represent production traffic. All of these VLANs are trunked from the Access switches down to the virtual connect modules located in the back of the C7000 enclosures.


Note: I’ve omitted SAN switches from this and just presented what would appear as zoned storage direct to the Virtual Connect. I may cover storage and flat san at a later date, if there is any request to do so.



This represents the external connectivity being presented to our Enclosure, it’s now time for the logical configuration with HP OneView…


OpenStack on CentOS 7.0 (manual install)

This is a very very basic overview of all of the steps (and there are a lot of them) to deploy OpenStack controllers on a single node, purely for testing purposes..

Update: Turns out that a lot of this can be automated.. but i’m leaving this up as it took so long 🙁

Hopefully you’ll end up with something looking like this:

lsvm – list virtual machines in vSphere from CLI

Whilst I’m aware that it’s simple enough to type vim-cmd vmsvc/getallvms from the cli in vSphere/ESXi, having a program spawning another program is a bit of a pain, especially having to parse the results(vim-cmd output is a bit of a mess). To programmatically handle this requires a bit of messing around with xml and then having to parse a number of files that are listed in the xml files to get your results. However the code is quite easy to modify so that you could do things such as list allocated vCPUs, or total allocated memory.

I’ve uploaded the code to github here.

Example output:


HP Oneview API with cURL

As part of a PoC i’m spending quite a bit of time pulling apart the APIs of HPs OneView application, and pulling this functionality into a Objective-C application.


HP Oneview is based upon a REST API and is interacted with directly via the https interface, this is the same API that the HTML5 web interface interacts with (more than likely in a loopback fashion). Connections require the following initial steps:



  1. Initial rest connection passing JSON containing the userName and password variables.
  2. The response is some JSON containing an id, which is comparable to a cookie when using UCS Manager.
  3. This id is then passed as an Auth: header when used to interact with various areas of the API.


These are a few one liners that can be used to communicate with the HP OneView interface.


  •  Login

curl -v -H "Content-Type: application/json" -d '{"userName":"Administrator","password":" <PASSWORD> "}' -X POST -k https:// <IP> /rest/login-sessions

  • List server profiles

curl -k -v -H "Content-Type: application/json" \
-H "Auth: <id> " \
-H "X-API-Version: 101" \
-X GET https:// <IP> /rest/server-profiles

Creating a server profile requires a little bit more work, even for a blank profile that isn’t attached to a physical server. This goes agains the examples in the API guide, so I think there is a mistake somewhere. However, two pieces of information are a requirement to create a un-attached server profile. These two pieces are a server hardware type and an enclosure group and these can be found through the following api calls:

  • List Server Hardware Types

curl -k -v -H "Content-Type: application/json" \
-H "Auth: <id> " \
-H "X-API-Version: 101" \
-X GET https:// <IP> /rest/server-hardware-types

  • List Enclosure Groups

curl -k -v -H "Content-Type: application/json" \
-H "Auth: <id> " \
-H "X-API-Version: 101" \
-X GET https:// <IP> /rest/enclosure-groups

These will result in a large amount of data being dumped, however what is being looked for is the URI of the enclosure groups or the particular server hardware type that your profile is being attached to. With these URIs you can construct a simple one liner to create a blank Server profile as show below:

curl -k -v -H "Content-Type: application/json" \
-H "Auth: <id> " \
-H "X-API-Version: 101" \
-d '{"type":"ServerProfileV4","name":"blankProfile01","serverHardwareTypeUri":"/rest/server-hardware-types/XXXXX","enclosureGroupUri":"/rest/enclosure-groups/XXXXX"}' -X POST -k https:// <IP> /rest/server-profiles

VM creation from CLI

For testing purposes, whilst developing a zeroconf daemon I needed to be able to quickly create some VMs and register them on vSphere. The process of opening infrastructure client and running through the wizard etc. or other methods of creating virtual machines was just too slow. After a bit of searching around and looking at, it became apparent that VMware don’t support creating virtual machines from their CLI toolset.

I found script from 2006 that uses commands that don’t even exist anymore, but with a bit of of tweaking will happily create test virtual machines.