So with vSphere 6.5 now GA, I decided to upgrade my lab to vSphere 6.5. In my environment, I use a vCenter with an external Platform Services Controller (PSC). So as part of the upgrade, I have to upgrade the PSC first.
When you run the UI installer provided within the VCSA 6.5 Appliance ISO, you have the option to “Upgrade” a vCenter Server Appliance or a Platform Services Controller. The installer detects the component that you are trying to upgrade and prompts for settings appropriate to that upgrade.
Although there are “many” “new” features in vSphere 4.1, there are many changes that have been made “under the hood”. I noticed this whilst I was playing with the beta. One of these changes is the way the vpxa agent enforces admission control in ESX/ESXi.
Over the past few weeks I’ve heard a whole lot of arguments around vCenter design considerations. A few of the questions asked were:
- Do I install vCenter on 32 bit or 64 bit?
- vCenter as a physical or Virtual machine?
- vCenter Database – Local or Remote?
- Placement of the Update Manager Server and Database
Before I dig into the vCenter design topic, I think it would be good to put some perspective on this post and why I’ve decided to blog on this. Last week I attended a meeting with some fellow virtualisation consultants and one of the topics raised in the meeting was to find a common standard practise between us regarding vCenter Server design and specifically the “default” stance between the consultants in regards to the placement of the vCenter server and whether it should be a physical or a virtual machine. Some consultants were in favour of the idea of a default stace and others were against the idea, stating that the decision of vCenter being hosted on a physical or virtual machine is down to the circumstances of each consultancy engagement. Thinking back now, I don’t think we came to an agreement in the end.
This post is basically my opinion on vCenter design, and the steps that I take in deciding what my infrastructure design will look like.
I’ve been trying to install VMware vCenter Server on Windows Server 2008 R2 Enterprise Edition. This is because I am working on a few blog articles on protecting the vCenter Server against hardware failures. At the moment, I’m busy working on two blog posts.
1. Protecting vCenter with VMware vCenter Server heartbeat;
2. Protecting vCenter with Microsoft Cluster Services (MSCS).
Whilst trying to install vCenter on Windows Server 2008 R2, I ran into some issues I had to resolve before I could do anything useful.
This may not be the most technical post, but it should hopefully give VM administrators some ideas on managing their VMs.
Despite having tools like VirtualCenter, keeping track of your VMs can still be a mission. Today I look after thousands of virtual machines running on hundreds of ESX hosts in several data centres. Most of these VMs are production systems, some are clones of production systems, some are test and some are dev. Creating and managing machines for new services is not always an issue. We have processes in place to control VM sprawl. We know which VMs belongs to which customers. We also know who to contact in regards to which VM. This is all documented in change records and CMDBs. However, having to go back to CMDBs and change records every time you need to know who owns a VM is a bit of a slog. Sure we’ve tried adding relevant information into the “Notes” Attribute, but it gets messy and some administrators “forget” to add all the information we need into the notes.
To try and keep track of who owns what, I use a simple but very effective tool inside vCenter to manage VMs. It’s the “Custom Attribute” function of vCenter that allows administrators to specify custom attributes for all the VMs and hosts in vCenter. Custom Attributes are by no means a new feature in Virtual Infrastructure or vSphere, yet a lot of administrators don’t use them as they simply don’t realise that custom attributes functions exists or what custom attributes are for. I’ve seen many virtual Infrastructures built on VMware VI 3 (small environments to large enterprise environments) and I simply can’t recall ever seeing custom attributes being used.
As we are now busy doing P2V conversion of most of our physical servers I needed to use the Consolidation function in vCenter (previously known as VirtualCenter) to assess the workload of the physical servers (CPU and Memory Usage).
I was surprised to see that the "Consolidation" button disappeared from my VI Client! I checked if it was installed as a plugin and it was. I also checked if it was enabled and again, it was. However, the button was not there!
I found that although the plugin can be installed and enabled in the VI client, it is also a requirement to have VMware Capacity Planner installed on the vCenter server. I checked my vCenter server and confirmed that it was indeed already installed.
Here's the fix:
It seems like the Consolidation Function for vCenter is disabled by default in the vpxd.cfg file. To enable the consolidation function, do the following:
On the vCenter server, edit c:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\vpxd.cfg
(I'm still using VirtualCenter 2.5.0 Build 119598, so your path could be ...\vCenter\cpxd.cfg? I'm not sure!)
You will find the following three lines:
Change them to read:
Restart the VirtualCenter service using the Services.msc MMC snapin in Windows. The Consolidation Button should now be available in your VI, Providing that that it's installed and enabled and that VMware Capacity Planner is installed on the vCenter server.