vCenter Server Appliance 6.0 in VMware Workstation

For demo’s, presentations, breaking environments or just killing time I have a portable testlab on my notebook. Yes I know there are also options for permanent labs, hosted labs and Hands-on labs for these same purposes. Great places for sure, but that is not really what I wanted to discuss here.

As I am break.. ehhh rebuilding my lab to vSphere 6.0 I wanted to install VCSA 6.0 in VMware workstation. Nice, import a my vmware downloaded VCSA-versionsomething.ova (after e-mail address number ####### registered over there) and we are done! …….. Well not quite.
First the vCenter download contains the OVA, but it is a little bit hidden. The guided installer will not help you here. You will need to mount or extract the downloaded ISO and look for vmware-vcsa in the vcsa/ folder.

VCSA Location
Copy the vmware-vcsa file to a writable location (when just mounted the ISO) and rename vmware-vcsa to vmware-vcsa.ova. And now we can import the ova to VMware Workstation. When the import finishes, do not start the VM yet. Certain values that are normally inserted via the vSphere Client or ovftool are to be appended to the VMX file of the imported VCSA. Open the vmx in the location where you let Workstation import the VM. Append the following lines: = “ipv4” = “static” = “” = “8” = “” = “”
guestinfo.cis.vmdir.password = “vmware-notsecurepassexample”
guestinfo.cis.appliance.root.passwd = “vmware-notsecurepassexample”

Note: Change the net and vmdir/appliance.password options to the appropriate values for your environment.

If not appended when you start the VCSA an error: vmdir.password not set aborting installation is shown on the console (next to root password not set) and network connection will be dropped even if you configure these on the VCSA console (via F2).

Save the VMX file.

And now it is time to let it rip. Start up your engines. And be patience until…lo and behold:

VCSA Running in workstation

And to check if the networking is accepting connections from a server in the same network segment open up the VCSA url in Chrome for example. After accepting the self signed certificate unsecure site (run away!) message you will (hopefully) see:

VCSA in Workstation

Next we can logon to the Web client (click and accept the unsecure connection/certificate) and logon via Administrator@VSPHERE.LOCAL and the password provided in the VMX (in the above example vmware-notsecurepassexample). As a bonus you now know where to look when you forget your lab VCSA password ;-).

VCSA 6 Web Client

(And now I notice the vCenter Operations Manager icon in the Web Client Home screen. Why is this not updated like vRealize Orchestrator :-) )




vSphere: Working with traffic filtering in the vNetwork Distributed Switch


Within a physical and virtual infrastructure there are several options to limit the inbound and outbound traffic from and to a network node, part of the network or entire network (security zone). A limit can be, filtering (allow or dropping certain traffic) or the prioritization of traffic (QoS / DSCP tagging of the data) where a defined type of traffic is limited versus a kind of traffic with a higher prioritization.

Options include filtering with ACL, tagging and handling sort of traffic with QoS / DSCP devices, firewalling (physical or virtual appliances), physical or logical separation or Private VLAN’s (PVLAN for short). Furthermore, an often overlooked component, keep all your layers in view when designing the required security. If required to filter traffic from a specific data source to a specific group of hosts where the requirement is that those VM’s are not allowed to see or influence the other hosts, traffic filters setup on the physical network layer will not always be able to “see” the traffic as for example blade servers in certain blade chassis can access the same trunked switch ports / VLAN, or VM’s with same portgroup / VLAN are able to connect to each other’s network as the traffic is not reaching or redirected to the physical network infrastructure where these filters are in place. That is when not using a local firewall on the OS. You could say this is bad designing, but I have seen these described “flaws” pop up a little too often.

 Options in the VMware virtual infrastructure

You have to option to use third party virtual appliances as firewalls, vCloud suite components or network virtualization via NSX (SDN) for example. Not always implemented due to constraints overheard around, like: overhead of the handled traffic by the virtual firewall (sizing), single point of failure when just using one appliance, added complexity for certain IT Ops where networking and virtualization are strict separated (Bad bad bad) or just no budget/intention to implement a solution that goes further than just the host virtualization the organization is at (as they probably just started). These are just a few, not all are valid in my opinion….

From vSphere 5.5 there is another unused option (mostly unknown); use the traffic filtering and tagging engine in the vNetwork Distributed Switch (vDS or dvSwitch). That is when you have an Enterprise Plus edition, but hey without this a vDS is not available in the first place. Traffic filtering is introduced in version 5.5 and therefore can only be implemented on vSphere 5.5+ members of the 5.5+ version of vDS. This vDS option is the one I want to show you in this blog post.

Traffic filters, or ACL, control which network traffic is allowed to enter or return (ingress and/or egress rules) from a VM, a group of VM’s or network via the port group, or a uplink (vmnic). The filters are configured at the Uplink or port group, and allow for an unlimited number of rules to be set at this level. These handle the traffic from VM to the portgroup and/or the traffic from portgroup to the physical uplink port, and vice versa. The rules are processed in the VMkernel, this is fast processed and there is no external appliance needed. With outgoing traffic rule processing happens before the traffic leaves the vSphere host, which also possibly will save on the ACL on the physical layer and networking traffic when only types of traffic or to a specific destination are allowed.

With the traffic filter we have the option to set rules based allow drop (for ACL) on the following Qualifiers:

vDS - image1

The tag action allows setting the traffic tags. For this example we don’t use the tag action.

System Traffic are the vSphere traffic types you will likely see around, where we can allow a certain type of traffic to a specific network. MAC let’s us filter on layer 2, and specific source and/or destination MAC addresses or VLAN ID’s. IP let’s us filter on Layer 3 for the IP traffic types TCP/UDP/ICMP traffic for IPv4 and IPv6.

The following System traffic type are predefined:

vDS - image2

Make it so, number One

I will demonstrate the filtering option by creating a vDS and adding a ESXi host and VM to this configuration. Just a simple one to get the concept.

My testlab vDS is setup with a VM like this screenshot:

vDS - image3

I got a DSwitch-Testlab vD switch with a dvPortgroup VM-DvS (tsk tsk I made a typo and therefore not consistent with cases, please don’t follow this example ;-)). A VM Windows Server 2012 – SRDS is connected to this portgroup.

 The VM details are as follow:

vDS - image4

The IP address we will be looking at.

A the VM-DvS and going to the manage tab, we can choose Policies. When we push the edit button we can add or change the traffic filtering (just look for the clever name).

vDS - image5vDS - image6

As you see I already have created an IP ICMP rule which action currently says something completely the opposite as the rule name. This is on purpose to show the effect when I change this action. When I ping the VM from a network outside of the ESXi host, I get a nice ICMP response:

vDS - image7

When we change the ICMP rule to drop action, we get the following response:

vDS - image8


That’s what we want from the action. Other protocols are still available as there are no other rules yet, I can open an RDP to this Windows Server.

vDS - image9

When wanting to allow certain traffic and others not you will have to create several rules. The applied network traffic rules are in a strict order (which you can order). If a packet already satisfies a rule, the packet might not be passed to the next rule in the policy. This concept does not differ from filtering on most physical network devices. Document and draw out your rules and traffic flows carefully else implementation/troubleshooting will be a pain in the $$.

This concludes my simple demonstration.

 – Enjoy!


Hey come out and play. Join the vSphere Beta Program

At June the 30th VMware announced the launch of the latest vSphere Beta Program. This program is now open for anyone to register and participate in the beta program. The Beta program used to be for just a select group, but with VSAN Beta VMware started to allow a wider group of participants. In my opinion this is good as the group of software testing participants is larger and the amount of feedback, learned lessons and experience will be greater. The community and it’s testers will make the product and it’s features even better. Hopefully more Beta’s will also be open to a larger group of participants.

A larger group will make it harder to keep information within the group and not publicly shared on for example the big bad Intarweb. As this Beta program seems open to everyone, it is still bound to NDA rules. Details are in the VMware Master Software Beta Test Agreement (MSBTA) and the program rules which you are required to accept before joining. After that share your comments, feedback and information in the private community that is offered with the program.

What can you expect from the vSphere Beta program?

When you register with a my VMware account, the participant can expect to download, install, and test vSphere Beta software for his or hers environment. The vSphere Beta Program has no established end date. VMware strongly encourages participation and feedback in the first 4-6 weeks of the program (starting on June 30 2014). What are you waiting for? 

Some of the reasons to participate in the vSphere Beta Program are:

  • Receive access to the vSphere Beta products
  • Gain knowledge of and visibility into product roadmap before others.
  • Interact with the VMware vSphere Beta team, a chance to interact with engineers and such.
  • Provide direct input on product functionality, configuration, usability, and performance.
  • Provide feedback influencing future products, training, documentation, and services
  • Collaborate with other participants, learn about their use cases, and share advice and learned lessons of your own.

What is expected from the participants?

Provide VMware with valuable insight into how you use vSphere in real-world conditions and with real-world test cases, enabling VMware to better align the products with business needs.


Sign up and join the vSphere Beta Program today at:

– Go ahead, come out and play. Join the vSphere Beta program now!


Protecting vCenter services, what is around (comes around)

Depending on your environment there is a need to protect vCenter or some of the services included in the vCenter system. A big question to ask yourself is what kind of downtime can you have according to your service levels and what kind of options do we have or need to have in place?

What will go down if you lose a vCenter component?

Like said this depends on your environment and components using vCenter services to connect to and from. A “plain” server virtualization workload for one company is different than a VD workload in a high demanding organization. The latter probably needs the ability to provision a little more urgent then the first example. Want to deploy a vCOPS vApp or VD Desktop, well wait until your vCenter is back. Using solutions like VMware Data Protection requires an operational vCenter with a functioning vCenter Single Sign-On server to restore a virtual machine. Losing that part of your environment could impact your recovery options seriously. Manage/Edit some VM version 10? How will you do that without vSphere Web client? You can’t. Have a HA or DRS cluster? Well HA will still partially function, it will react with restarts when needed. But to add to the cluster will need vCenter to make this posible. DRS needs vCenter to function in manual or automatic mode. And these are just a few examples.
Important to keep in mind, running VM’s will keep on running and HA will keep on HA’ing, no need to panic there.

Let see which components make up vCenter, a little vCenter architecture to start with.

A “standard” vCenter is made up of the components vCenter SSO (Single Sign-on), Lookup Service, Inventory Service, vSphere Web Client and the vCenter Server (with all of it’s services) itself. Optional services are Dump collector, Syslog Collector and Auto Deploy (and optionally TFTP and PXE DHCP service, but they can be on a separate system so not included in the model as a part). vCenter is also expanded by Update Manager, vCOPS and all sorts.


What are your standard protecting options?

  • Do nothing
    Not advisable, but if you are sure, have a small (just a few hosts and VM’s) environment and have an insight of your environment (or use some scripting to dump your configuration), you could do nothing. You lose part of your services and (in worse case) will have to manually rebuild vCenter and your configuration. You will lose any trending information. Recovery time is typically measured in days, and requires manual intervention.
  • Back-up Restore or Replication.
    Backup and restore should be an essential part of any availability solution, exclamation mark. This provides a recovery method utilizing tape, disk, replication or snapshot technology. This also enables a recovery method when data corruption occurs, depending on the solution that is. If data is corrupt on the primary VM then a replication to the recovery VM can occur after this moment. vCenter VM replication from primary to recovery site should be well monitored (and tested with SRM plans for example). Preferably used on several layers, application and application data (for example databases, certificates, logs, dump locations etc.). Be sure to know your backup  and recovery steps (look in the VMware KB’s for backing up the vCenter Server Appliance services and embedded vPostgres database), document, practice and test them. Recovery time is typically measured in hours or days, and typically requires manual intervention.
  • MS SQL Log shipping – database only
    A simple and cost effective solution. You can use log shipping to send transaction logs from one database (the primary database) to another (the secondary database) on a constant basis. Continually backing up the transaction logs from a primary database server and then copying and restoring them to a secondary database server keeps the secondary database nearly synchronized (depending on your plan) with the primary database. The destination server acts as a cold standby or backup server. Your destination server can also act as primary database for other databases so you will have some sort of active-active instead of a cold standby. Be ware of licensing in this case, log shipping target only or serving database is a different license show! Has to be setup for every database, include your vCenter, Inventory, SSO and such. Recovery time is depending on your plan, but can be minutes or hours. Requires manual intervention to fail over from primary to secondary.
  • SQL mirror / clustering – database only
    Depending on the license of MSSQL these are a more robust solution then the previously mentioned SQL log shipping. These have data replication mechanism in place and have the ability to automatically detect failures and do there fail overs with out manual intervention. Mostly used with a Witness out side the cluster/mirror pair to act as a tie breaker to prevent split brain scenario’s in case of partial failures. Mirroring, clustering has to be setup  for every database, include your vCenter, Inventory, SSO and such. Clustering can also be done per instance with it’s included databases. Oracle will have it’s own clustering, with Oracle RAC for example. Recovery time is typically measured in minutes. No intervention to fail over.
  • Hypervisor HA.
    Hypervisor HA will start your VM after a host failure or VMtools timeout. The time it takes to recover is depending on your amount of free slots, your priority of vCenter vs the other workload and the amount of VM’s needed to restart. Depending on your environment this can take some time to start up. Hypervisor HA will not protect against service failures as it will not monitor any application components, it will also not protect against any data corruption. Hypervisor HA is to be used in conjunction with one or more other protection options. For example a vCenter system on HA and SQL databases on MSSQL Cluster. Recovery time is typically measured in minutes or hours depending on your consolidation ratio and restart settings.
  • App Aware HA.
    If you have the correct edition and have the application aware components in place. Monitors the application and if it goes down, it can be restarted. There is no app aware HA specifically for vCenter yet. But you can protect parts of the applications with app HA, for example MSSQL services. Recovery time is typically measured in minutes or hours.
  • FT
    That is currently a no no. Why did I put it up here? Because it comes up as a question once in a while. FT creates virtual machine “pairs” that run in lock step—essentially mirroring the execution state of a virtual machine. This only protects against host or VM failures. Services that go down or corruption in the application data will be mirrored to the secondary VM.
    FT in vSphere 5.5 is still limited to 1 vCPU, and with a small inventory you still need a minimum of 2vCPU. Same goes for for example a database server these also tend to have more vCPU’s. Yes this has been a issue all along for FT, and we know from following those VMworld sessions demo’s that there is work in progress on multiple vCPU FT, but unfortunately this is not yet released. But a similar technique is next up.
  • vCenter Server Heartbeat
    vCenter Server Heartbeat is a separately licensed vCenter Server plug-in that provides protection of your vCenter system, (physical or virtual). Next to protecting against host failures, heartbeat adds application-level monitoring and intelligence of all vCenter Server components. Heartbeat replicates changes to a cloned virtual machine. The cloned virtual machine can take over when a failure event is triggered.
    imageThe vCenter recovery can be accomplished by restarting the vCenter service, by restarting the entire application, or by the entire failover of the vCenter system. Use in conjuction with a data protection like SQL mirroring to protect against corruption. Recovery time is measured in minutes and requires no manual intervention.
  • Scale out / HA service pair
    Move some of your vCenter services to other components or use multiple same role servers to provide high available and load balanced services. Not all of the vCenter services can be separated this way, but for example SSO can be. Those high availability service are placed behind a third-party network load balancer (for example, Apache HTTPD, vCloud Networking and Security vShield Edge load balancer or load balance appliance like Netscaler).
    imageMove logs to a log insight server, move statistics to vCOPS. Keep vCenter lean and mean.


vCenter Server Heartbeat is a done package for protecting your vCenter server system, but this is at an additional cost. More often you will have some back-end services, like Oracle/MSSQL clustering and back-up restore/replication solutions, already in place or products with a similar need. A combination of protection is the preferred way to utilize those in or to be in place solutions with the need for protection and the allowed recovery/down time. But this is the main thing, know your environment, know how the components interact, know what is needed at which time and know what will be (temporary) unavailable when services are down. Protect against unavailability, corruption and please randomly test to be sure all components are working as expected (even the manual procedures).

And yes sure there will be some other great options out there like a script collection or cold standby solution et al….. but hey isn’t that what the comments section is about. Tell me yours. Share.

– Happy managing your environment!

vCenter 5.1 installation on Windows 2012 fails at SPS – ProtectedStorage none existing service

In the middle of building a VMware Horizon Suite 5.2 lab for a comparison demo (VDI, mobility et al) I was installing vCenter 5.1 on Windows 2012. I can almost be sure I have tried an earlier installation that didn’t show this problem, but hay my memory sometimes plays a little trick on me (I’m used to VCSA in my lab environments). Could be Update 1 as vCenter 5.1 is not supported to run on Windows 2012 (and cue warning not for production only U1 is supported on Windows 2012 (and without the R2)). But vCenter 5.1 without update is in my Horizon Suite evaluation, and this is a lab…

Anyhow, with the installation of SSO en inventory service passed I tried to install the vCenter Server. Nothing new nothing fancy. Only at the SPS (the Profile Drive Storage part) the installer stops and redirects me to the logs. Okay… While checking the logs and system logs the following is registered as event id 7000.:


Okay ProtectedStorage. So fire up service manager via and protectedStorage in dependency of VMware VirtualCenter Server. And no ProtectedStorage service to be found (also no service ).


So power up those register skills and check the dependencies of the VPX service. You can find that at ComputrerHKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesvpxd and then DependOnService key.


Here we see ProtectedStorage, next to Workstation service and MSSQL Express (only if you combine this locally). Remove that ProtectedStorage entry and close registry. You will have to restart to server and on boot up the vCenter Server service is started. (Yes really check in your services ;-))

You will have to rerun the vCenter Server installation to complete the required components. It will start where it left off.

– Enjoy labbing!

Dissecting vSphere – Data protection

An important part of a business continuity and disaster recovery plans are the ways to protect your organisation data. A way to do this is to have a back-up and recovery solution in place. This solution should be able to get your organization back in to production with the set RPO/RTO’s. The solution needs to be able to test your back-ups, preferable in a sandboxed testing environment. I have seen situations at organisations where backup software was reporting green lights on the backup operation, but when a crisis came up they couldn’t get the data out and thus failing recovery. Panicking people all over the place….

Back-up and recovery solution can be (a mix of) commercial products to protect the virtual environment like Veeam or from within guest with agents like Veritas or DPM or from features of the OS (return to previous version with snapshots). Other ways included solutions on the storage infrastructuur. But what if your budget constrained….

Well VMware has the vSphere Data Protection that is included from the Essentials Enterpise Plus kit. This is the standard edition. The vSphere Data Protection Advanced edition is available from the enterprise license.
So there are two flavours, what is standard giving and lacking from advanced?
First the what; like previous stated VDP is the backup and recovery solution from VMware. It is a appliance that is fully integrated with vCenter. It’s easy to be deployed. It performs full virtual machine and File-LevelRestore (FLR) without installing an agent in every virtual machine.It uses data deduplication for all backup jobs, reducing disk space consumption.


VDP standard is capped with a 2TB backup data store, where VDP advanced allows dynamic capacity growth. This allows a growth of capacity to 4TB, 6TB or 8TB backup stores. VDP advance also provides agents for specific applications. Agents for SQL Server and Exchange agents can be installed in the VM guest os. These agents provides selecting individual databases or stores for backup or restore actions, application quiescing and advanced options like truncating transaction logs.


At VMworld 2013 further capabilities of VDP 5.5 are introduced:

– Replication of backup data to EMC.
– Direct-to-Host Emergency Restore. (without the need for vCenter, so perfect for backing up your vCenter)
– Backup and restore of individual VDMK files.
– Specific schedules for multiple jobs.
– VDP storage management improvements. Selecting separate backup data stores.

Sizing and configuration

The appliance is configured with 4vCPU’s and 4GB RAM. For the available backup stores storage capacity 500GB, 1TB or 2TB they will consume respectivily 850GB, 1,3 TB and 3,1TB of actual storage. There is a 100 VM limit, so after that you would need another VDP appliance (maximum of 10 VDP appliances per vCenter).

After the appliance deployment the appliance need to be configured at the VDP web service. The first time it is in installation mode. Items such as IP, hostname, DNS (if you haven’t added these with the OVF deployment), time and vCenter need to be configured. After completion (and sucessful testing) the appliance needs to be rebooted. A heads up, the initial configuration reboot can take up to 30 minutes to complete so have your coffee machine nearby.

After this you can use the webclient connected to your VDP connected vCenter to create jobs. Let the created jobs run controlled for the first time; the first backup of a virtual machine takes time as all of the data for that virtual machine is being backed up. Subsequent backups of the same virtual machine take less time, here changed block tracking (CBT) and dedup is preformed.


Well this depends on the kind of storage you are going to use as the backup data store. If you going for low cost storage (let say most of the SMB would want that), your paying in performance (or lacking it most of the time).

Storage Offsite

Most organizations want their backup data stored offsite in some way. vDP does not offer replication (or with VDP5.5 to only EMC), so you want to have some offsite replication or synchronization in place (and a how are you able to restore from this data if your VDP is lost also). vSphere Replication only protects VM’s and not your backup data store. Most SMB’s don’t have a lot of storage able replication devices in place, and when they do, there using it for production and not use that as a backup datastore. Keep this in mind when researching this product for your environment.

– Enjoy data protecting!

Dissecting vSphere 5.5 Enhancements – HA improvement and App HA

With the introduction of vSphere 5.5 there are two mayor HA improvements announced:

– vSphere App HA, on the Intarweb also known as App aware HA; High Availability at the application layer.
– vSphere HA detecting VM antiaffinity rules.

I’ll start with the latter.

HA detecting VM Anti-affinty rules

With vSphere DRS… Hey wait isn’t the subject supposed to be HA… Well yes, but the anti- or affinity rules are DRS rules. So a bit of DRS rule explanation;..these rules helps maintain the order of placements of VM’s on hosts throughout the cluster.  Affinity rules are rules that places VM’s together on certain hosts. Anti-affinity rules are rules that places VM’s separate from those VM’s in the rule. Think of VM’s that are already in a software availability service, such as the nodes of a cluster. You don’t typically want the nodes on one physical host.
With vSphere 5.1 and earlier vSphere HA did not detect a violation of these rules (these rules are unknown to vSphere HA). After a HA failover the VM’s could be place on the same host, after vSphere DRS would kick in and vMotion the VM’s so the anti-affinity rules are satisfied (DRS needs to be in full automated to enable the auto vMotion). Applications with high sensitivity to latency would not like this vMotion and there is a (very slight) moment that HA application clustering service are at higher risk as both VM’s are on the same physical host. A failure of the physical host before the vMotion is completed, would impact a downed service.
In a application cluster service you could also choose to use VM Overrides to disable HA restart for the VM cluster nodes as the application service handles the application HA actions. After a failure you would have to manually get the failed node online (or add a new one) in the application service. But that looses automation…

With vSphere 5.5 HA has been enhanced to conform with the anti-affinity rules. In a case of a host failure the VM’s are brought up accordant to the anti-affinity rules without the need of a vMotion action.This enhancement is configured as an advanced option.

vSphere App HA aka App aware HA

We already have host and VM monitoring, with vSphere 5.5 lifts this to application monitoring. vSphere App HA can be configured to restart an application service when an issue is detected with this service. It is possible to monitor applications as IIS, MSSQL, Apache Tomcat and vCenter. When the application service restart fails App HA can also reset the virtual machine. Service actions can be configured with the use of App HA policies. VM monitoring must be enabled to use application monitoring.

App HA Policies are definitions of the number of times vSphere App HA will attempt to restart a service, the number of minutes it will wait for the service to start, and the options to reset the virtual machine if the service fails to start and to reset the virtual machine when the service is unresponsive. They can also be configured to use other triggers, such as e-mail notifications or vCenter alerts.

When a configured App HA policy is assigned to a specific application service, vSphere App HA is enabled for that service.

Pretty nice.

But what’s needed:

For App HA to work two appliances are needed in the environment (per vCenter), vSphere App HA and vFabric Hyperic. The latter is used by the App HA architecture to monitor applications and is a vFabric Hyperic Server that communicates with vFabric Hyperic agents.
The roles of the both appliances are as follow: the vSphere App HA virtual appliance stores and manages vSphere App HA policies. The vFabric Hyperic appliance monitors applications and enforces the assigned vSphere App HA policies. For monitoring the applications of a VM, vFabric Hyperic agents must be installed inside the VM’s of these applications. These agents are communication brokers for the applications of the VM’s and the vFabric Hyperic appliance.

The vFabric Hyperic agents are supported to be deployed at Linux and Windows os’ses for 32-bit or 64-bit applications. How and what is supported for vSphere 5.5 HA is not yet completely clear (service support for IIS6/7/8, MSSQL 2005/2008/2012, Apache Tomcat, Apache HTTP and vCenter). Following the current vFabric Suite supported OS’ses these include Windows 2003, Windows 2008R2, Red Hat Enterprise Server and Suse Enterprise Linux.



Well. Good Question. App HA is part of the vSphere Enterprise plus edition only. Costs of vSphere 5.5 is expected to be around the current vSphere 5.1 costs. But with what options, constrains and limits…..unknown. The General Availability of vSphere 5.5 is yet unknown.

Separately VMware vFabric Suite is currently available as a one-time perpetual license under which support and subscription (SnS) contracts can be renewed annually – See more at:

How the both are combined at what options/editions/prices keep a look out for further vSphere 5.5 product announcements.

– Exiting. I have the HA BCO5047 – vSphere High Availability – What’s New and Best Practices in my Barcelona schedule to get some more insight at VMworld EU 2013.

Dissecting vSphere 5.5 Enhancements – vCenter Server Appliance ready for lift off

A real concern for implementing the vCenter Server appliance (vCSA) 5.1 in production environments is the environment limits with the use of the embedded database. The embedded database with 5.1 has a limit of 5 managed hosts and 50 managed VM’s. That is not the size of production in a lot of setups.
The maximums could be lifted, but needed an external database service that was limited to only Oracle (and with the 5.5 version still is limited to Oracle as an external database). Not a lot of organizations use Oracle for infrastructure services, so that option is not widely used (or at least haven’t seen that around much). I’ve only used the vCSA in lab / testing environments.

With the introduction of vCSA 5.5 one of the most important parts is a reengineered embedded database (vPostgres). This lifts the configuration maximums of the vCSA to (editted, still production worth though) 100 managed hosts and 3000 managed VM’s. Well that’s more like it, this is production worth.

Table with specification vCSA 5.1 vs vCSA 5.5.

*) Specifications of the minimum requirements are depending on your environment. Don’t expect a difference approach, 2vCPU and memory according to your environment size. Scale down or scale up the standards.

The 5.5 release makes vCSA a production appliance. It is deployed fast and in comparison to a vCenter server does not need a Windows license.

– I’m gonna see a lot more of the vCSA 5.5 in customer environments.

— This post has been edited to change the number of managed hosts to 100 and managed VM’s to 3000. Earlier numbers were unofficial.