Tag: <span>vCenter</span>

Dilpreet & Mohan did a great job laying out the install and upgrade paths to reach vCenter 6.0, whether in Appliance or Windows mode. As I mentioned yesterday, the VMware team is encouraging customers to choose the Appliance (VCSA) moving forward due to increased performance, decreased complexity, and overall conformity. You gain much and lose nothing…except:

vSphere Update Manager (VUM), which will be integrated into VCSA in a 2016 release (Yay!). Presumably this will be vSphere 6.1 as that would put vSphere 6.0 a year old and this landmark milestone is too big (in my opinion) for a mere “Update 2”.

Dilpreet was kind to explain that the update which brings VUM integration will pull the VUM configuration & data from existing VUM (Windows) servers and into the VCSA component. This is great to hear as I was unclear about this walking away from the “Part 2” session yesterday.

Please check out the notes below and remember to pay attention to the order of your upgrades. Reference the KBs mentioned so you’re on a supported model & path.

Technology Virtualization

Last week I ran across a tweet talking about a VMware Labs fling that introduces ESXtop statistics as a plugin into the vSphere Web Client. If you’re not familiar with “flings”, they are experimental tools made by VMware engineers and shared with the community. Anyways, this fling jumped on my list immediately.

Download ESXtopNGC Plugin: https://labs.vmware.com/flings/esxtopngc-plugin

The first thing you might notice is the System Requirements’ sole item: “vCenter Server Appliance 5.5”. Hmm. I run vCenter Server on Windows since Update Manager still requires it and I don’t see the value of having both the vCSA and a Windows VM, as opposed to just one Windows VM. A few comments quickly came in, though, confirming that it works just fine as a plugin on Windows vCenter, too.

Here’s how to install it:

1. Download ESXtopNGC (“Agree & Download” in the top left)


Technology Virtualization

Avamar Error Code: 10059

2014-08-05 11:13:27 avvcbimage Error <17780>: Snapshot cannot be performed because Host 'esx01.domain.com' is currently in Maintenance Mode (Log #1)
2014-08-05 11:13:27 avvcbimage FATAL <0000>: [IMG0009] The Host 'esx01.domain.com' is in a state that cannot perform snapshot operations. (Log #1)
2014-08-05 11:13:27 avvcbimage Error <0000>: [IMG0009] createSnapshot: snapshot creation failed (Log #1)

You may also notice these details in the session drill-down:

2014-08-05 11:13:23 avvcbimage Info <16005>: Login(https://vcenter.domain.com:443/sdk) problem with reused sessionID='52e2b2cb-225f-0229-9b25-929a652617fb' contacting data center 'Datacenter'.
2014-08-05 11:13:23 avvcbimage Warning <0000>: [IMG0014] Problem logging into URL 'https://vcenter.domain.com:443/sdk' with session cookie.

At first, the list of failed VM backups seemed to have no correlation–multiple hosts, various OSes, different policy groups. But the above session details revealed the root cause. Avamar thought the VMs were on a host that was in maintenance mode (or in a previous case, powered off). It’s a bit hard to snapshot a VM on a host that isn’t running the VM or even running at all.

Storage Technology Virtualization

A few weeks ago I updated our vCenter instances to 5.5 Update 1a to address the Heartbleed vulnerability. Now Update 1b has been released with further OpenSSL updates, plus host profile and VSAN  fixes (blog).

Normally, my update procedure involves extracting the downloaded ISO and installing after that. Today, I decided to simply mount the ISO in the vCenter server running on Windows 2012. That led to my only issue in the upgrade procedure, a problem noted in VMware KB 2050539 but which appears to apply to more than just “VMware vCenter Server 5.1.x”.

Please insert the disk: 1

Technology Virtualization

As part of a project consolidating mission critical services, I am moving a few VMs between vSphere / vCenter datacenters. The keyword here is “datacenters” and for emphasis, they are managed by different vCenter servers operating in linked mode. Because of this setup, the migration isn’t a simple cluster & storage vMotion.

Here’s the process I am following. I hope it helps; if you use another method, feel free to comment.

migrate_services1. Enable SSH on an ESXi host in the source and destination cluster; on the source host, also open SSH outbound on the host firewall

  • In vSphere Client, go to the “Configuration” tab on each host
  • Under “Software” on the left side of the right pane, select “Security Profile”
  • In the top right under “Services”, click “Properties…”
  • Scroll down to “SSH” and click “Options…”
  • Select “Start and stop manually”, then click “Start” and return to the Security Profile page
  • On the source ESXi host, also click “Properties…” under “Firewall”
  • In Firewall Properties, check “SSH Client” and click “OK”

Technology Virtualization

Storage Technology Virtualization