I’ve written before about using VM tags with Cohesity to exclude VMs from a backup. I wanted to write up a quick article using a real world example in the test lab. In this instance, we had someone deploying 200 VMs over a weekend to test a vendor’s storage array with a particular workload. The problem was that I had Cohesity set to automatically protect any new VMs that are deployed in the lab. This wasn’t a problem from a scalability perspective. Rather, the problem was that we were backing up a bunch of test data that didn’t dedupe well and didn’t need to be protected by what are ultimately finite resources.
As I pointed out in the other article, creating tags for VMs and using them as a way to exclude workloads from Cohesity is not a new concept, and is fairly easy to do. You can also apply the tags in bulk using the vSphere Web Client if you need to. But a quicker way to do it (and something that can be done post-deployment) is to use PowerCLI to search for VMs with a particular naming convention and apply the tags to those.
Firstly, you’ll need to log in to your vCenter.
PowerCLI C:\> Connect-VIServer vCenter
In this example, the test VMs are deployed with the prefix “PSV”, so this makes it easy enough to search for them.
This assumes that the tag already exists on the vCenter side of things, and you have sufficient permissions to apply tags to VMs. You can check your work with the following command.
PowerCLI C:\> get-vm | where {$_.name -like "PSV*"} | Get-TagAssignment
One thing to note. If you’ve updated the tags of a bunch of VMs in your vCenter environment, you may notice that the objects aren’t immediately excluded from the Protection Job on the Cohesity side of things. The reason for this is that, by default, Cohesity only refreshes vCenter source data every 4 hours. One way to force the update is to manually refresh the source vCenter in Cohesity. To do this, go to Protection -> Sources. Click on the ellipsis on the right-hand side of your vCenter source you’d like to refresh, and select Refresh.
You’ll then see that the tagged VMs are excluded in the Protection Job. Hat tip to my colleague Mike for his help with PowerCLI. And hat tip to my other colleague Mike for causing the problem in the first place.
This is a quick and easy one. I came across a virtual appliance the other day that had an expired certificate.
When you click Next you’ll get an error saying the package is signed with an invalid certificate.
It’s a relatively easy fix (or at least workaround) and I followed Stephen Wagner‘s guidance here. In short, grab a copy of the VMware OVF Tool from here. You then run the following command:
You’ll then be able to deploy the appliance without it barfing. Remember, though, that this is a bit of a rough workaround, and you should really contact the appliance vendor in the first instance as they’ll likely be keen to fix the issue. In my case I was able to continue with my testing while the vendor went ahead and fixed things on their side.
I’ve been evaluating a data protection solution in the lab recently and wanted to create a custom role in vCenter for the solution to use. It’s a basic thing, but if you don’t do it often it might not be that obvious where to click. The VMware documentation site has more information on creating a custom role as well. Why would you do this? In the same way it’s a bad idea to give every service Domain Administrator privileges, it’s also a bad idea to give your data protection solutions elevated privileges in your environment. If you’re into that kind of thing, read this guidance on roles and permissions too. In this example, I created a “CohesityTest” user as a domain user in Active Directory. I then wanted to assign that user to a custom role in vCenter and assign it certain privileges. In this example I’m using vCenter 6.5 with the Web Client. The process is as follows.
Go to the Home screen in vCenter and click on “Administration”.
In this example, I’ve already created a Role called Cohesity (following the instructions above) and assigned privileges to that Role.
Click on “Global Permissions” and the click on the green plus sign.
I want to add a user to a role. Click on “Add”.
The user I want to add is a domain user, so I use the drop down box to select the domain the user resides in.
Typing “coh” into the search field yields the only user with those letters in their name.
Once the user is selected, you can click on “Add” and then “OK”.
Make sure the user has the appropriate Role assigned. In this example, I’m assigning the CohesityTest user to the Cohesity Role and propagating these changes to child objects. Click “OK”. And then you’re done.
To check your role has the correct privileges, click on “Roles”, “Role Name”, and then “Privileges” and you can expand the items to check the correct privileges are assigned.
Once I’d done this I went back and re-added the vCenter to the Cohesity environment using the CohesityTest user and I was good to go.
Oracle VM came up in a project I was working on recently. This overview page was a reasonable starting point. Finally, check out Stephen Foskett’s article on ZFS. I thought it was well-balanced and a good read, and the article comments reminded me why I’ve stayed the hell away from that particular community. In any case, if you’re going to be at VMworld US this year, come and say hi.
I did an article on the vSphere 6 Platform Services Controller a while ago. After attending a session on changes in vSphere 6.5 at vFORUM, I thought it would be an idea to revisit this, and frame it in the context of vCenter 6.5 upgrades.
vSphere Components
In vCenter 6.5, the architecture is a bit different to 5.x. With the PSC, you get:
VMware vCenter Single Sign-On
License service
Lookup service
VMware Directory Services
VMware Certificate Authority
And the vCenter Server Service gives you:
vCenter Server
VMware vSphere Web Client
VMware vSphere Auto Deploy
VMware vSphere ESXi Dump Collector
vSphere Syslog Collector on Windows and vSphere Syslog Service for VMware vCenter Server Appliance
vSphere Update Manager
Architecture Choices
There are some basic configurations that you can go with, but I generally don’t recommend these for anything outside of a lab or test environment. In these configurations, the PSC is either embedded or external to the vCenter Server. The choice here will be dependent on the sizing and feature requirements of your environment.
If you want to use Enhanced Linked Mode an external PSC is recommended. If you want it highly available, you’ll still need to use a load balancer. This VMware KB article provides some handy insights and updates from 6.0.
vCenter Upgrade Scenarios
Your upgrade architecture you’ll choose depends on where your vCenter services reside. If your vCenter server has SSO installed, it becomes a vCenter Server with an embedded PSC.
If, however, some of the vSphere components are installed on separate VMs then the Web Client and Inventory Service become part of the “Management Node” (your vCenter box) and the PSC (with SSO) is separate/external.
Note also that vSphere 6.5 still requires a load balancer for vSphere High Availability.
Final Thoughts
This is not something that’s necessarily going to come up each day. But if you’re working either directly with VMware, via an integrator or doing it yourself, your choice of vCenter architecture should be a key consideration in your planning activities. As with most upgrades to key infrastructure components, you should take the time to plan appropriately.
VMware recently announced that applications for the next VMware vSphere Beta Program are now open. People wishing to participate in the program can now indicate their interest by filling out this simple form. The vSphere team will grant access to the program to selected candidates in stages. This vSphere Beta Program leverages a private Beta community to download software and share information. There will be discussion forums, webinars, and service requests to enable you to share your feedback with VMware.
So what’s involved? Participants are expected to:
Accept the Master Software Beta Test Agreement prior to visiting the Private Beta Community;
Install beta software within 3 days of receiving access to the beta product;
Provide feedback within the first 4 weeks of the beta program;
Submit Support Requests for bugs, issues and feature requests;
Complete surveys and beta test assignments; and
Participate in the private beta discussion forum and conference calls.
All testing is free-form and you’re encouraged to use the software in ways that interest you. This will provide VMware with valuable insight into how you use vSphere in real-world conditions and with real-world test cases.
Why participate? Some of the many reasons to participate include:
Receiving early access to the vSphere Beta products;
Interacting with the vSphere Beta team consisting of Product Managers, Engineers, Technical Support, and Technical Writers;
Providing direct input on product functionality, configurability, usability, and performance;
Providing feedback influencing future products, training, documentation, and services; and
Collaborating with other participants, learning about their use cases, and sharing advice and learnings.
I’m a big fan of public beta testing. While we’re not all experts on how things should work, it’s a great opportunity to at least have your say on how you think that vSphere should work. While the guys in vSphere product management may not be able to incorporate every idea you have for how vSphere should work, you’ll at least have an opportunity to contribute feedback and give VMware some insight on how their product is being used in the wild. In my opinion this is extremely valuable for both VMware and us, the consumers of their product. Plus, you’ll get a sneak peak into what’s coming up.
So, if you’re good with NDAs and have some time to devote to some testing of next-generation vSphere, this is the program for you. So head over to the website and check it out.
I’ve finally gotten some time to dig into the changes in vSphere 6 with regards to deployment options and architecture. I thought I’d do a few posts covering some key enhancements from VMware, paying particular attention to the Platform Service Controller (PSC) and VMware’s preferred deployment options. I haven’t received any briefings from VMware, so I can’t comment on what is coming in future releases. Note that most of this information was made available to me via access to VMware’s partner program, and I think it’s important that more people understand what’s going on when it comes to PSC and how it works.
vSphere Components
The PSC is a new feature in vSphere 6.0. As background, I recommend you first check out this blog post – vCenter Server 6 Deployment Topologies and High Availability. There is also an excellent FAQ from VMware available here. I thought, before diving too much into PSC deployment options, it’s a good idea to revisit VMware’s semi-new approach to vSphere components.
The PSC contains the following services:
VMware vCenter Single Sign-On (SSO);
License Service;
Lookup Service;
VMware Directory Service; and
VMware Certificate Authority (CA).
Everything else is now referred to as “vCenter Services”, providing the remainder of the vCenter Server functionality. This includes:
vCenter Server;
VMware vSphere Web Client;
Inventory Service;
vSphere Auto Deploy;
VMware vSphere ESXi Dump Collector; and
VMware vSphere Syslog Collector (Windows) / VMware Syslog Service (Appliance).
Enhanced Linked Mode with an External PSC Without HA
The PSC is configured on a separate VM and then the vCenter Servers are joined to that domain, providing Enhanced Linked mode functionality.
Enhanced Linked Mode with an External PSC in an HA Configuration
In this case, the PSCs are configured on separate VMs behind a load balancer to provide HA for the configuration. The vCenter Servers are then joined to that domain using the shared load balancer IP address, providing Enhanced Linked mode functionality that is fault-tolerant.
And here’s a few ways that you can do it that aren’t really recommended.
Enhanced Linked Mode with Embedded PSCs (Not Recommended)
In this scenario, vCenter is installed in an embedded configuration on the first server. Subsequent installations are then configured in embedded mode but joined to an existing SSO domain. Linking the embedded PSCs is possible, but VMware does not recommend this configuration.
Enhanced Linked Mode in Combination Deployment (Not Recommended)
In a combination deployment, the embedded and external PSC architectures are combined. While linking an embedded PSC and an external PSC is possible, VMware does not recommended this configuration.
Enhanced Linked Mode using only an Embedded PSC (Not Recommended)
In this case there is an embedded PSC and vCenter Server linked with an external standalone vCenter Server. Linking a second vCenter Server to an existing embedded vCenter Server and PSC is possible, but VMware does not recommended this configuration.
Sizing Considerations
If you’re not going to use enhanced linked mode, use an embedded PSC. You still have availability via VMware HA. The failure domain is limited to a single vCenter Server, as there is no dependency on external component connectivity for PSC connectivity. This is most suitable for lab environments.
For sites that will use enhanced linked mode use external PSCs. The number of controllers depends on the size of the environment:
Between 2 and 4 VMware solutions – a single PSC for no HA, and 2 will be required for HA configured behind a single load balancer.
Between 4 and 8 VMware solutions – two PSCs linked together for no HA, and four will be required for HA configured behind two load balancers (two behind each load balancer).
Between 8 and 10 VMware solutions – three PSCs linked together for no HA, and six will be required for HA configured behind three load balancers (two behind each load balancer).
VMware maintain that, with the improvements to the vCenter appliance platform, the choice of Windows-based vs vCenter appliance is now a matter of preference rather than performance. I recommend the appliance wherever possible, but some people will feel more comfortable with a Windows-based platform. The cool thing is that, if you want to make things complicated, the PSC supports mixed-mode (i.e. appliance and Windows-based vCenter deployments).
Final Thoughts
This may have gone a bit beyond basics, and it’s not something that’s necessarily going to come up each day. But if you’re working either directly with VMware, via an integrator or doing it yourself, this new approach should be a key consideration in your planning activities. The addition of the PSC concept to the vCenter architecture improves the flexibility and availability options of the product, something that I think VMware has struggled with in the past. The key takeaway, in my opinion, is that if you’re upgrading from 5.5 or below, you need to take the time to plan appropriately, particularly if you want to leverage some of the new features that are available.
As part of a recent vSphere 5.5 deployment, I installed a small vSphere Replication 5.8 proof-of-concept for the customer to trial site-to-site replication and get their minds around how they can do some simple DR activities. The appliance is fairly simple to deploy, so I thought I’d just provide a few links to articles that I found useful. Firstly, esxi-guy has a very useful soup-to-nuts post on the steps required to deploy a replication environment, and the steps to recover a VM. You can check it out here. Secondly, here’s a link to the official vSphere Replication documentation in PDF and eBook formats – just the sort of thing you’ll want to read while on the treadmill or sitting on the bus on the way home from the salt mines. Finally, if you’re working in an environment that has a number of firewalls in play, this list of ports you need to open is pretty handy.
One problem we did have was that we’d forgotten what the password was on the appliance we’d deployed at each site. I’m not the greatest cracker in any case, and so we agreed that re-deploying the appliance would be the simplest course of action. So I deleted the VM at each site and went through the “Deploy from OVF” thing again. The only thing of note that happened was that it warned me I had previously deployed a vSphere Replication instance with that name and IP address previously, and that I should get rid of the stale version. I did that at each site and then joined them together again and was good to go. I’m now trying to convince the customer that SRM might be of some use to them too. But baby steps, right?
Note also that, if you want to deploy additional vSphere Replication VMs to assist with load-balancing in your environment, you need to use the vSphere_Replication_AddOn_OVF10.ovf file for the additional appliances.
I waffled on some time ago about using proper certificates in your vSphere 5.5 environment. You can read about some of how to do that here. Eric has a nice summary of the steps here. I got a call recently from the customer about a few things and they mentioned some issues with vSphere Replication 5.8. Turns out I’d forgotten about vSphere Replication when I’d gone through the certificate replacement process, as it was done as a PoC. The fix is simple: power off the appliance and power it on again. VMware has a KB for most every situation, including this one – VMware vSphere Replication appliance no longer able to communicate with the VMware vCenter Server after changing the vCenter certificates (2063955). It also helps that I’m a bit late to this particular party.
The next step should be to replace the certificates on your vSphere Replication infrastructure as well. I was going to put together a post on that too, but it’s probably simplest if you read the VMware KB – Configuring CA Signed Certificates for VMware vSphere Replication (2080395). Friedrich also has a great post on some of the basics – including the certificate replacement process – here.
A colleague of mine has been doing some data centre failover testing for a customer recently and ran into an issue with VMware’s Site Recovery Manager (SRM) 5.8 running on vSphere 5.5 U2. When attempting to perform a recovery, and you’re running Linked Mode, and the protected site is off-line, the recovery may fail. The upshot of this is “The user is unable to perform a recovery at the recovery site, in the event of a DR scenario”. Here’s what it looks like.
I don’t know what to say about this. I’d like to put the boot into whomever at VMware is responsible for this SNAFU, but I’m guessing that they’ve already had a hard time of it. At least, I guess, there’s a workaround, if not a fix. But you’d be a bit upset if this happened for the first time during a real failover. But that’s why we test before we handover. And what is it with everything going pear-shaped when Linked Mode is in use?
*Update – 29/10/2015*
Marcel van den Berg recently pointed out that updating to SRM 5.8.1 resolves this issue. Further detail can be found here.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
