Luke

VMware Virtual SAN Health failed Cluster health test

Here’s the error

While building a new environment for my lab, I ran across an interesting thing yesterday.

I looked at my cluster’s VSAN health and saw this error:

It’s complaining that my hosts don’t have matching Virtual SAN advanced configuration items.

If you click on that error, you’ll see at the bottom where it shows comparisons of hosts and the advanced configurations:

It shows VSAN.DomMaxLeafAssocsPerHost and VSAN.DomOwnerInflightOps as being different between a few of my hosts. Looking at the image above, you’ll see node 09 has values of 36000 and 1024, respectively, while the other nodes 10-12 show 12000 and 0.

I immediately went to the host configuration advanced settings in the web client, searched VSAN and don’t see either of those. I even checked through PowerCLI and can’t see those:

VMware vSphere 5.5 Web Client authentication fails with ‘cannot connect to the vCenter Single Sign On server.’

Earlier this week we were greeted with this awesome message:

It’s so descriptive we knew exactly where to start! Okay, yeah, not really. Sarcasm aside, you’d think the culprit would be SSO. I began checking the two SSO servers we have in an HA configuration and they appeared fine. What’s even more strange is the fat clients were all authenticating fine. I started checking logs on the SSO servers and saw several things similar to this:

2015-08-25 23:20:49,538 INFO [ActiveDirectoryProvider] Failed to find user snip@snipPrincipal id not found: {Name: snip, Domain: snip} via ldap search
and
2015-08-26 00:29:37.709:t@21945040:ERROR: ldap simple bind failed. Error(4294967295)

So I assumed it was SSO again, maybe related to the domain we auth against.

Great! So now what?

vSphere Replication 5.8 lets you violate VSAN Storage Policies

I’m sure many of you know VSAN’s Failures To Tolerate, or FTT, is something that adds overhead to both your cluster & your data. It’s no secret FTT of 1 doubles your data, think of it as N+1 copies of your data. You could essentially have two, three, or four copies of your data, redundancy is a good thing!

When you look at the cluster side of it, there is another ‘gotcha’. The host needs becomes 2N+1. Let’s look at FTT of one, that’s saying you need 2(1)+1 hosts, so 2+1 = 3. And of course, FTT2 requires 5 hosts, and FTT3 requires 7.

What’s the problem?

VMworld 2015 Public Voting is OPEN!

It’s that time of year again, and I know you’re as excited as I am, VMworld has opened up the sessions to public voting!

There are TONS of sessions to choose from, and I submitted a handful listed here:

The last one is something special with GS Khalsa, so please vote for us!

If you like any of these and would like to see these presentations on the big stage, please vote for them!

Go to http://vmw.re/1Pj6Lcc and you can either search for my last name or session ID.

Microsoft System Center 2012 R2 Configuration Manager Setup – The network path was not found

This error may be old news to a lot of you, but I’m finally getting back into playing with the goodness known as Microsoft’s System Center Configuration Manager, aka ConfigMgr, aka SCCM, and went through quite a bit to get it set up in my lab.

I jumped right in and did it blindly, which, although worked fine, I did have some speed bumps along the way.

I used several PowerShell one-liners I slapped together to install all the Windows’ features & WADK; however, when I got to the SQL portion of the SCCM installer (where you point to the SQL FQDN, Insance Name, Database name, etc), I kept getting a very generic error that simply said

The network path was not found.

and the log file, ConfigMgrSetupWizard.log, said

Exception details: [System.IO.IOException: The network path was not found.

1	Exception details: [System.IO.IOException: The network path was not found.

At face value, this sounds like a simple network connectivity issue. However, I could nslookup the FQDN of the SQL server, which happened to be the same box (all-in-one install), I could ping the FQDN, netstat showed port 1433 was listening, my firewall was turned off, so I started googling.

Everyone points at these as the problem:

Firewall
SPN
SQL Port
Maybe a few others I’m forgetting?

As it turned out, I forgot to enable and start the Remote Registry service. That’s all it was. I actually had this in my notes:

Set-Service RemoteRegistry -StartupType Automatic
Start-Service RemoteRegistry

1 2	Set-Service RemoteRegistry -StartupType Automatic Start-Service RemoteRegistry

But forgot to run them, lol!

Oh well, live & learn! I think I’m going to do another post regarding the different one-liners I ran to get SCCM 2012 R2 up and running.

Site Recovery Manager Error: Placeholder VM creation error: No hosts with hardware version 10

If you attended my SRM session at VMworld 2014, or one of the VMUG User Conference sessions I’ve presented at, you’ve heard me talk about upgrading SRM and the entire infrastructure.

I stressed the importance of upgrading the Recovery/Target Site’s hosts before upgrading the Protected/Source Site’s hosts.

As you can imagine, upgrading out of order does happen, and I got to see exactly what happens when you’re in that situation. Well, not in a disaster, but in regular day-to-day tasks.

Have you seen this error when trying to protect a VM in SRM, specifically trying to create the placeholder?

Placeholder VM creation error: No hosts with hardware version ’10’ and datastore(s) [datastore01] which are powered on and not in maintenance mode are available

Setting EMC’s RecoverPoint SRM SRA to Authenticate over SSL for 4.0 and 4.1

You may or may not know that EMC’s SRA defaults to authenticating over non-SSL communication. It basically hits the RecoverPoint Appliance (RPA) on port 80 when doing anything. RPAs don’t handle a NAT, so chances are your devices are not publicly facing, at least I hope not!

It’s always a better idea to encrypt any traffic containing usernames and passwords, so why wouldn’t you do this? In RPA versions up to 4.0, they defaulted to non SSL, although they refer to it as non-https. RPA 4.1 no longer accepts port 80 and requires you to use 443, or https, or SSL encrypted, whatever you want to say.

This is great, until you try to add RPA 4.1 to a standard install of RecoverPoint’s 2.2 SRA. Why? Well, because it defaults to non-https and doesn’t give you an intuitive way to change it.

Adding RPA 4.1 to SRA 2.2 will give you this error:

“SRA command ‘discoverArrays’ failed. Failed opening session for user to site mgmt IP.
Please see server logs for further details.”

Check the vmware-dr.log and you’ll likely see something like

Error code=”1049″

and what’s funny is I even found “Ouch!” in the log, lol! I love when devs throw things like that out there.

Keep reading for the fix!

Storage vMotion Compatibility Failed – File is larger than the maximum size supported by datastore

We ran into an interesting issue last week. While trying to migrate some VMs onto a replicated datastore for SRM, we got this interesting error:

File [source-datastore]path/to.vmdk is larger than the maximum size supported by datastore ‘target-datastore

file-larger-max-size-datastore

It’s strange because this is a 5.5 vCenter, 5.1 hosts, both datastores are vmfs5 and the vmdks were 60GB & 80GB. From what I could tell, everything was identical. Further testing revealed I could storage vMotion from the SRM datastore to regular datastores, but I could not move anything onto the SRM datastore.

After googling, I found the standard VMware response of ‘select a different datastore’, and further research didn’t show much else beyond the differences of the vmfs versions, and differences between vmfs5 among 5.0, 5.1, and 5.5. That’s nice and all, but none of these applied to me.

Restarted vCenter services on a whim, and guess what? It worked! LOL! Sometimes the strangest of issues can be fixed by the simplest of things.

Public Voting Now Open for VMWorld 2014!

When you get a chance, stroll on over to vmworld.com and click the link “Vote for your favorite proposals today”:

I’m bringing this up because I submitting a session, 1152 “vCenter Site Recovery Manager: Architecting a DR Solution”.

It’s pretty simple to find, it’s one of only two sessions for Site Recovery Manager at the Advanced Technical Level under Software Defined Data Center in the subtrack Storage and Business Continuity. An easy way to find it is set the keyword filter to “site recovery manager” and mine’s the first one:

The abstract states:

VMware’s vCenter Site Recovery Manager is the market-leading disaster-recovery management product. It ensures the simplest and most reliable disaster protection for all virtualized applications. However, it is not a turn-key DR solution. Architecting your SRM solution requires deep thought and heavy planning. This presentation will help you with planning and architecting your SRM solution as well as addressing specific configuration and installation challenges. Our goal is to help you deploy and maintain a solid SRM solution to enable your DR Plan.

The agenda will flow like this:

Basic SRM Functions
Planning
Designing & Architecting SRM
Deployment Considerations & Road Blocks
Maintaining, Migrating, & Upgrading

Everyone knows what SRM, and most understand what it does; however, very few actually understand how it works. This session will briefly cover how each function of SRM works, but will go deeper into how to plan & architect your DR solution leveraging SRM. There are several design considerations you need to keep in mind when planning & building it out, and I’ll also touch on migrating & upgrading your SRM installation to make sure you’re protected, even during an upgrade.

If this looks like something you’d like to see at VMworld 2014, please sign in and vote!

Thanks, and happy scripting!

Building a Disaster Recovery Solution using Site Recovery Manager – Part 1: Planning

I wrote this blog article for Rackspace to go on their Blog. Original can be found HERE on the Rackspace Blog site.

VMware® vCenter™ Site Recovery Manager™ is used to orchestrate the failover of a group of virtual machines (VMs) from one location to another. It’s a really useful tool to have in your arsenal to tackle the daunting task of disaster recovery (DR), especially if you take a little time to plan for how and when it will be used.