VMware vCenter Server 5.5: Installable vs Appliance

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- 0 Flares ×

With the new release of vCenter Server Appliance (VCSA) 5.5, VMware has made a huge step forward in order to make the appliance a real choice not only for test and small business environments, but also for medium and large ones. Specifically, the new limit of 100 hosts and 3000 VM make the VCSA a good candidate not only for small clusters (tipically the Essentials Plus bundle with 3 servers) but also for large clusters. Environments with 100 hosts and 3000 VM are not so common.

But in my opinion, there are nonetheless some further reflections that need to be made, other than the maximums.


I think the ongoing talk about the new and increased maximums of the VCSA, had partially distracted paople from other elements that to me sound more important when choosing which version to use. Even in environments where the VCSA is more than enough to manage the whole infrastructure, I’ve never see anyone reaching those numbers with a single vCenter, not even using the installable (able to manage 1000 hosts and 10000 VM ).

Usually even in large environments, it better to limit the number of hosts and VMs per vCenter and use several vCenter, maybe connected with linked mode. There are two reasons: first, in order to lower the failure domain. If vCenter stops, many activities are disabled. ESXi clusters have no impact, but no activity on them is possible, and also if you have vCloud Director or View Composer you cannot do anything… Second, the required resources (RAM and CPU) to execute a vCenter with so many hosts and VMs are quite prohibitive.

In these designs, one big limit of the VCSA scalability comes right from the lack of Linked Mode support. From an high availability perspective instead, the lack of support for vCenter HeartBeat is for sure another problem.


VCSA use and internal database by default, that is Postgres (please, VMware guys, DO NOT call it vPostgres as I read around…). The management of this database is all in charge of the appliance, and I thinka DBA would have some problems to add it to the overall database managament he’s in charge of. The other option is to use an external database; this is a suppoted configuration for VCSA but only using Oracle. The use of an external database to me is a non-sense and completely against the idea of the VCSA: you use it to save the Microsoft license for Windows OS, and you then have to license an Oracle database. Where is the advantage?

vCenter Update Manager

One of the biggest limit to me of the VCSA, even when used in small environments that represents the ideal situation to use it, is the lack of Update Manager inside the appliance itself. It’s possible to install Update Manager in a separate VM, but this needs to be a Windows VM. Again, you saved the Windows license for vCenter but you need to have another one for Update Manager.


Future improvements

I have no idea what they will be, but I have some suggestions.

First,the support for embedded Update Manager. I do not know why after several releases still VCSA has no support for it, but for sure this improvement is much needed.

Then, if it already uses Postgres internally, what about giving support for it even as an external database, or even more available also for the installable vCenter? Postgres is a rock solid and really powerful solution. I know a possible excuse: it’s open source, so there is no vendor to officially support it. This is another non-sense to me, since as an internal database is already supported. Today the only way to guarantee high availability for the backend database is to use clustered installation of Oracle or MS SQL, but this is another expense for customers, since cluster licenses has a higher price. A clustered Postgres would really help to save budgets.

Even more important, a real future solution should be a scale-out vCenter, with several vCenters working side-by-side, sharing the same informations, and protecting each other from failures. Linked Mode has the ability to centrally manage different vCenter, but they do not share the same infrastructure.

A couple of years ago, during VMworld 2011 if I remember correctly, VMware shocased at its booth a “technology preview” a solution called “distributed vCenter”. What happened to it?


[This post was originally written by Luca Dell’Oca, and published on the blog www.virtualtothecore.com ]

3 thoughts on “VMware vCenter Server 5.5: Installable vs Appliance

  1. A scale-out VCSA would be great for VDI environments where Composer operations could be scaled across multiple vCenters instead of having to break environments up into “pods” of 2000 desktops.

  2. 100% agree. a Scale-out approach is great in many many aspect, regarding both scalability and high availability. Let’s see what will happen in the future… vCloud director cells are already using a scale-out model…


  3. I agree on the vcenter distributed idea.

    MS has this with SCVMM already (although MSSQL licensing required)

    If vmware was to implement the ability to have multiple vcenter appliances all using embedded postgresql and have these in an active/active configuration.

    Or for larger environments, have a separate appliance for the postgreSQL as well and distribute both the web front end and db backend

    then use a clustered virtual ip and point everything at that.

    Many advantges like previous comments mentioned; viewbroker operations load balanced, API authentications load balanced, user logins to the web interface means more users from the 180 limit in 5-5, as you would add 180 per VM deployed.

    Then all we need is an appliance for VUM or integrate it into the VCSA itself!

    hopefully this comes in vSphere 6-0!


    vcenter-1 –
    vcenter-2 –
    vcenter-2 –

    vcenter-vip –

Comments are closed.