Tag Archives: VCSA

vCenter to VCSA migration tool released

vCenter, vSphere,

It’s out!  You can finally migrate a Windows vCenter install to a vCenter appliance VCSA based install using a supported VCSA migration tool!

https://blogs.vmware.com/vsphere/2016/09/vcenter-server-migration-tool-vsphere-6-0-update-2m.html

Just a heads up, here are the requirements:

  • It only migrates from Windows installations to VCSA based installations
  • It only migrates from 5.5 (any revision) to VCSA 6.0 Update 2
  • You must used the embedded database in VCSA
  • It will not migrate VUM if VUM is installed on the same OS as your vCenter (no big deal IMO, not hard to reinstall VUM)

Cool things I noticed about this migration utility according to the link above:

  • Preservation of original vCenter settings including
    • IP address
    • FQDN
    • Certificates
    • Alarm settings (AWESOME!)
  • It doesn’t touch your current vCenter’s stuff, so easy rollback.

Not so cool things:

  • You can’t change deployment models during the migration.  A simple deployment in 5.5 becomes an embedded deployment in VCSA, which you don’t want to do, but you can always transition out of that.

I’m sure you’ll be seeing a blog article here kicking the tires on this thing.  But this will definitely help me convince people to go to the VCSA.

vCenter 6 – Windows vs Linux Appliance?

vSphere, ,

One of the first questions for a vSphere 6 design is which version should be used – the linux based VCSA appliance, or the traditional Windows installable version?

The debate on whether to go with the Linux based vSphere Appliance vs. the Windows installable version began when the first version of the appliance was introduced.  Through vSphere 5.5, I generally recommended the Windows version for numerous reasons:

  • It’s more mature
  • VCSA didn’t support linked mode
  • It uses a SQL database
  • You need Windows anyway for VMware Update Manager
  • It scaled better with backend databases that were more common (MS SQL)

Many blog articles have compared the two, and I don’t want to rehash a lot of that information here.  A case could be made for either.

vSphere 6 has been out for awhile, and I’ve deployed it for numerous customers, both the appliance and Windows versions.  I feel like now I can make offer something more on the debate, based on practical experience.

Which works best generally speaking?

I’m going to be honest, I’m coming at this from a Windows centered background.  I’ve worked with linux a bit, don’t get me wrong.  But at the end of the day, I am far more comfortable with Windows.  So, I’ve generally been partial to Windows based vCenter servers for my customers partly because I can support Windows based OS’s easier than linux based, and most of the customers I’ve dealt with are also more familiar with Windows.

With all that said, after deploying vSphere 6 for awhile now, it’s time for the vCenter Appliance.  I preface this with that doesn’t mean for everyone.  It does mean I start with the assumption of the appliance first.  If the customer has reasons why a Windows version makes more sense for them, I’ll recommend the Windows version.  But my de facto recommendation otherwise is go with the VCSA.  This is the first time in my entire workings with vSphere I’ve recommended the VCSA over the Windows version generally speaking.

Why the VCSA is better?

Some reasons for the VCSA have been consistent since its introduction:

  • No need for licensing of Windows or SQL
  • It’s more secure (honestly this is debatable)
  • If you’re a linux shop, you don’t need to introduce Windows for vCenter
  • It’s faster to deploy

But this version is different for numerous reasons.

VCSA is faster

After you work on both, you start noticing the VCSA is noticeably faster.  As a consultant, I jump around between environments that have different hardware that varies drastically.  I started to wonder if I truly remembered correctly which environments were faster.  Maybe the faster environments had faster storage arrays or servers?

One customer I did work for, they had hardware issues that caused me to rebuild their vCenter environment.  We elected the second time to deploy it as a VCSA instead since it had to be rebuilt from scratch to save time.  This provided a rare opportunity to compare them on the same hardware.  I don’t have numbers or benchmarks to provide.  I can only say that the customer commented it was noticeably faster within the Web Client.  I noticed it as well.

It’s faster to deploy

I know, I said this version was different for numerous reasons.  Why bring that up again?  Because vCenter 6 works best by deploying the Platform Services Controller into a separate OS from the vCenter server.  That’s two VMs to build.  It’s far faster to deploy two VCSA’s than two Windows servers.  There’s no contest there.

It scales better without a licensed database

You can scale vCenter to its highest limits of VMs and hosts with the included database within the VCSA.  If you deploy the Windows version and use the vPostgress database, it only scales to 10 hosts and 200 VMs.

Who doesn’t have full VM backup capabilities now?

Back when the VCSA first came out, I dealt with numerous customers who used traditional in guest agent backup products such as Backup Exec without the ability to do whole VM based backups.  To backup the vCenter database, they needed to use a SQL database, which locked them into using the Windows vCenter version.  Now, most environments have whole VM based backup products, whether it be Veeam, add-ons for backup products they’ve been using for a long time such as Backup Exec, or using the generally included VMware Data Protection in most licensed versions of vSphere.  How to backup the VCSA just isn’t a challenge to overcome anymore.

No feature limitations

There used to be functional limits with the VCSA compared to the Windows version of VCSA.  Almost always, this centered around Linked Mode.  Why deploy any version of vCenter that might stop you from using included features, even if you aren’t using those today?  VMware since rewrote Linked Mode, and it works with both versions.  There isn’t any other native VMware feature you can’t use in conjunction with the VCSA.

It’s the future of vCenter

This is speculation on my part, but I think it’s clear VMware wants vCenter to become the VCSA.  Best to go that direction now than later.

Why might the Windows version still be better for some environments?

There can still be some compelling reasons to go with the Windows version.

Windows in place upgrades and SQL based databases

vCenter 6 is supported on Windows 2008 R2 and above.  If your old vCenter runs on a supported Windows OS instance, this potentially allows you to do in place upgrades.  The same can be said for the SQL backend database.  With that said, if VCSA becomes the only version down the road, it might be better to bite the bullet now instead of later to migrate to it.

No whole VM backup products

If a customer doesn’t have any whole VM backup products and doesn’t wish to deploy anything, including VDP, then they may need a SQL backend database that can be backed up with their backup product.

Better operational skills with Windows

Sometimes environments have IT personnel better skilled with Windows than linux.  With that said, linux based appliances, whether it be vCenter or for some other service or application, are far more common than in the past.  It’s increasingly likely the customer has or will have one or more in their environment, whether it be a Cisco wifi controller, or perhaps a security appliance.  Perhaps the VCSA is a good starting point before learning some linux is suddenly forced on the staff unexpectedly.

vCenter High Availability

With vCenter Heartbeat gone, Microsoft clustering is the only way to provide application layer high availability for vCenter.  That can only come through the Windows version.  However, for most customers, they often elect for HA as sufficient protection of vCenter.  Windows Failover Clustering often caused more service loss than it avoids, especially if there is insufficient knowledge and/or experience, on managing it within environments.

VUM still needs Windows

Unfortunately, VUM must be installed within a Windows OS.  You can use VUM in conjunction with the VCSA.  It must run in its own Windows OS.  I don’t think that’s a good justification to not go with VCSA.  I prefer to run VUM within its own OS instance anyway.  However, some customers would rather not mix them, or prefer to deploy VUM in the same VM as vCenter.

vCenter 6 – The appliance rocks!

I highly encourage using the appliance in most cases.  The one piece of advice I can give is don’t dismiss the appliance because you’ve never used it.  Also, unfamiliarity with linux may not be a good reason either.  That one is tricky.  On the one hand, you don’t want to introduce risk due to the lack of linux skills.  On the other hand, you’ll rarely need to be in the linux parts of the appliance anyway.

Either way, the VCSA for vCenter 6 is a solid option, and should be heavily considered.

VCSA can’t enumerate AD accounts

vSphere,

Ran into an interesting issue.  After deploying greenfield vCenter 6 Server Appliances (VCSA) using an external PSC for a remote branch site, when I tried to do some permissioning with AD accounts.  Joining the PSC to the domain wasn’t a problem, nor was adding the AD domain as an identity source.  But when I tried to enumerate accounts for permissioning, that would fail with the error: “Cannot load the users for the selected domain”.

I found an excellent VMware KB article that gave lots of things to check when troubleshooting this.

I verified DNS was working.  No surprise there.  However, when I ran the command less /var/lib/likewise/krb5-affinity.conf, I noticed the DCs used were not the correct DCs that should be using, rather DCs from a different remote branch office site.  When I checked AD Sites and Services, it was clear that a subnet  object was associated to the wrong branch office that included the IP of the PSC.  Therefore, PSC was attempting to use the DCs in that site.  That’s good to know that vCenter Appliances are apparently AD Site aware.  Furthermore, the first DC used of the two in the remote branch site didn’t have a PTR record because the Reverse Lookup Zone for that subnet for the wrong remote branch didn’t exist.  Apparently, if the first domain controller to be used can be contacted but doesn’t have a PTR record, the PSC won’t enumerate users and groups for permissioning.

Creating the Reverse Lookup Zone and forcing the PTR record creation along with some AD replication fixed the issue, and I kindly suggested to the customer it was time for some tender loving care with AD Sites and Services, along with DNS.

So, FYI, it’s not a bad idea to review your Active Directory Sites and Services, and your DNS Forward and Reverse Lookup zones before you deploy the VCSA.