Category Archives: Procedures

vBrownbag VCAP6-DCV Design – Security in Logical Designs

Recently (18th of April 2017)  I covered Objective 2.7 from the VCAP6-DCV Design (VMware Certified Advanced Professional – Data Center Virtualization) certification blueprint on vBrownbag EMEA.

The objective had the ominous title of “Build Security Requirements into a vSphere 6.X Logical Design“. Among other things it covers the security aspects of a vSphere design and what needs to be kept in mind when addressing topics such as regulation compliance, Role Based Access Control and analyzing security requirements and how they can map to various design characteristics and IT processes.

Here is the slide deck:

I hope this helps someone on their path to achieving the VCAP-DCV Design exam (and than the VCDX of course).

Here is a link to all the other Objectives covered by vBrownbag

Here is the Youtube video as promised!


vCenter & Distributed vSwitch on two ESXi hosts with a single NIC

I was doing some lab work the other day with two IBM Flex nodes that only had a single 10Gb NIC.

The vCenter for the environment was located on the afformentioned ESXi hosts and my plan was to use the Distributed vSwitch, rather than the Simple vSwitch.

If you ever tried moving a ESXi host to a Distributed vSwitch which hosts the vCenter, it easy when you have more than one NIC. Just move one of the NIC’s to the Distributed vSwitch,  and then change the network configuration for the vCenter.

But when you are trying to move a ESXi host with a single NIC (whitebox, demo equipment, etc) things get a little bit more complicated.

When you attempt to move the vCenter and the ESXi host to a new Distributed Portgroup, the vCenter loses its connection and the process is rolled back. But you are still stuck with the NIC on the Simple vSwitch. Status quo…

The best way to make this work is to:

  1. Move the ESXi host that doesn’t run the vCenter VM hto the Distributed vSwitch. Create VM traffic portgroups.
  2. Clone the vCenter VM and place it on the ESXi host that doesn’t run the vCenter VM.
  3. Connect the newly cloned vCenter VM to a Distributed Portgroup on the ESXi host (that was connected to the DVS previously)
  4. Turn off the original vCenter.
  5. Turn on the cloned vCenter and configure the network settings (accept the error about a previous network using the IP if using Microsoft Server)
  6. Move the existing host to the Distributed switch.

Now you have a working vCenter on hosts with single NICs with  a Distributed vSwitch.

Custom alarms for events in vCenter 5.x

Some customer have been asking if I know why some machines are failing at consolidating the snapshot in the end of the backup job. It seems as the job finishes, but the snapshot deletion fails, some times leaving behind a large snapshot, or even some “ghost” snapshots.  Sometimes the event isn’t noticed until days later, or even worse. when the datastore fills up.

When this happens, an event is logged for the virtual machine, stating that the VM’s disks consolidation fails:

Virtual machine {} disks consolidation failed on {} in cluster {} in {}.

This is a perfect case for a custom alarm so the administrator can be informed when the consolidation failed.

  1. First you need a way to create custom alarms in vCenter. My main source of information is this handy document from the VMware communities (author hmundt): More fun with vSphere Alarms
  2. Second you need a list of event for the vSphere API. Veeam has been so kind to publish a list of events from the API for vSphere 5.0 which they make available for users for their great product Veeam One (and if anyone from Veeam reads this, an updated list for vSphere 5.1 will be much appreciated).
  3. Next you create a new alarm on the vCenter level, choose Virtual Machine, Event and for the Event trigger you just paste the vSphere API event text. In this case its:

Next time a consolidation job fails an Alarm will light up that VM and bother all the people you added on the email notification list.

Of course this list can be used to watch for EVERY event know in the vSphere API and is very handy when you need to watch for a specific event in one of those troubleshooting sessions.