Troubleshooting is time consuming. Sometimes the problem is obscure and hard to research but most of the time the issue becomes apparent early on in the process. One by one this troubleshooting methodology isn’t a huge time commitment, however as more break fix problems creep up it can consume more time than one realizes. I liken it to working a jigsaw puzzle. When you sit down to put the puzzle together you flip all the pieces over and sort them to make the problem easier.
Maintaining valid licensing in vRealize Operations Manager is crucial to getting the most out of the tool. There are two methods of licensing vROps: per processor with unlimited VMs or per virtual machine or physical server monitored. The latter method is also referred to as an Operating System Instance, or OSI. An OSI is any device, physical or virtual, that has an IP address and is capable of being monitored.
Sizing a vRealize Operations Manager Environment VMware vRealize Operations Manager is the flagship monitoring suite for the entire VMware Software Defined Datacenter stack. The software is incredibly powerful, but it can be a bit daunting to a newcomer. Each update has improved out of the box functionality, however there is a lot to learn to master the software and truly make the most out of its features. Every successful environment starts with a strong design.
Designing for a Home Lab A practical way to gain experience with vRealize Operations Manager is to deploy and implement it into a home lab. A design for a home lab almost seems too simple, but planning it out and diagraming a simple example can help when the time comes to design a production environment. The environment will need to support the following: Monitor 100 Objects Monitor 10 End Point Operations Management agents The environment is also resource constrained, and the node can be no larger than a Small node size.
Historically, one of my biggest little annoyances with a VMware version upgrade has been upgrading VMware tools. In vSphere 5.5, VMware added the ability to update tools without a reboot. If you were manually kicking off the tools upgrade all you need to do is enter the following features into the advanced settings box /s /v"/qn REBOOT=ReallySuppress? This is great and causes the tool update to only lose one ping instead of requiring a full restart.
As vCenter has evolved many programs and plugins depend on it for functionality. With the recent GA to vSphere 6.5 a discussion came up on twitter. Veeam released version 9.5 around the same time but it’s not compatible with vSphere 6.5. I tried to install Veeam into my lab but couldn’t. Instead I was met with an error warning me to wait until Veeam 9.5 Update 1. The discussion about Compatibility reminded me of the spreadsheet I use to track plugins and configuration of all my servers.
In part 1 of my discussion about Merging SSO Domains I discussed why I was required to make that change. To recap: Enhanced Linked Mode is a business requirement in 6.0 and that requires all vCenters to belong to the same SSO Domain. You can’t merge SSO domains in 6.0 so we need to do it before the upgrade. While the concept sounds simple enough execution gets a bit complicated. There are a lot of services that need to be modified and some architectural decisions to make.
I have publicly committed to submitting a design to the VCDX committee. My design is due in March 2017. I’m very glad I signed up to submit because it has kick started my motivation. Today I wanted to talk about my progress. I am using an actual design for a project I worked on. It’s a fairly complex system with many moving pieces. It mostly meets AMPRS requirements (Availability, Manageability, Performance, Recoverability, Security) so I shouldn’t have to do much tweaking to make it pass muster.
Sometimes tasks that seem simple at first can become very complicated. When I was first tasked with upgrading a vCenter 5.5 environment to 6.0 I imagined mounting an ISO, clicking through the wizard, and voila, upgrade complete. This may work when you only have one vCenter server in a simple environment, however in an enterprise this is typically far from the optimal way to approach the upgrade. Over the next couple of entries I will talk about my progress toward a vSphere 6 upgrade.
One of the biggest challenges in a new environment can be mapping out resources. In a large environment you may encounter ESXi hosts that were moved between clusters, datastores that were mapped to multiple unnecessary hosts, or any number of additional surprises or inconsistencies. I encountered such a challenge and needed to answer a seemingly simple question: Which hosts and which clusters would be impacted by a loss of a datastore?