When I first started with virtualization, the only option you had at the time was single core processors in the hosts. Scale up or scale out was the hot debatable topic when designing your infrastructure. On one side of the coin the idea was to scale up in that it was best to get a few of the biggest servers you could find and load them up with as much memory and processors that you could fit in the box. The end result were some very expensive servers able to run a lot of virtual machines for its time. The other side of the coin presented the idea that it was better to scale out with more, smaller servers to make up the cluster. I have worked in both type of environments and attitudes over the years and as for me, personally, I aligned myself with the scale out philosophy. The simple reason for aligning with the scale out group was host failure. When you have sixty to eighty virtual machines per host and lose that host it was really a lot of eggs in one basket and took some time to recover. When you have more, smaller servers, then the shock of losing a host was not as severe because there were not as many virtual machines running on single host and it would take less time to recover. This was during the time before vCenter, vMotion, HA and DRS when it was just you and the VMware ESX hosts.
Articles Tagged with ESX
VMworld is clearly the largest dedicated virtualization conference, and yet from an Open Source perspective it is slightly disappointing because the VMware ecosystem naturally attracts proprietary software vendors, and also some of the more interesting activities in Open Source are through multi-vendor foundations which do not have the same marketing budgets as vendors themselves.
Nevertheless, there are a number of key Open Source players, and some interesting smaller players, represented at VMworld.
Have you ever considered the best way to plan, design and work with VMware Update Manager (VUM)? In the early days, using VMware 3.x when VUM was first released, I would end up installing VUM on the vCenter server itself. After all, that was the recommendation from VMware at the time. I propose that this is no longer the case and I would like to present a list of best practices to follow when working with VMware Update Manager. This list came from VMware, but should only be considered as a guide. Each environment is different and your mileage may / will vary.
When you hear the term “host” when talking about virtual environment, what is the first thing you think of? For me, the answer is simple, a host is an appliance. For years now I have been standing on my soap box and preaching the power and fundamentals of automation in building and configuring your virtual environment. I came across a thread on the VMware VMTN Community Forum where a concerned individual was in a position that he was going to have to rebuild his host from scratch. What he did to get himself into this position was to run a hardening script on the host and then the host became broken and unusable. This person was concerned that he did not have a backup of the host and was looking for a way to rollback.
Unless you have been on vacation or hiding under a rock then you have heard the latest buzz in the industry that vSphere 4.1 has been released. There have been a lot of blog posts on the topic already including one of our own. The thing I want to hit on for this post is the fact that this release will be the last release for full version of ESX. Moving forward on any new releases of ESX will be strictly ESXi. Anyone that knows me over the years knows that I have not really been a big fan of getting rid of the full version ESX. Call me old school and the fact that I have spent a great deal of time developing the automation used in the environments that I have supported over the years and have been really happy with what I was able to accomplish via kickstart and the command line.
This day seemed to start like any other but it seems like as soon as I was logged in to start my day issues arose. It seems like I lost one of my VMware 3.5 ESX servers and all the virtual machines on the host were knocked offline. This should not have been a big deal since HA was enabled but, Murphy’s Law has a way of making life really interesting. So as I logged into the vCenter client I noticed that the host in question was in a disconnected state and all the virtual machines showed up as disconnected. In past experiences I have seen HA, during a host failure, recover the virtual machines in under five minutes. So I waited and waited thinking HA should have kicked in by now. Time for a little further investigation!!