Tuesday April 21st VMware announced they will be releasing vSphere 4 by the end of 2nd quarter. This is exciting news for many looking to take advantage of some of the new features available with this release. In this post I’m going to walk through a handful of some of these new features. There are over 100 new features in vSphere 4 and this post doesn’t come close to covering them all but I will be touching on some really exciting ones with more to come in my next few posts.
Let’s start with the new home screen. It’s a handy way to navigate all the configuration areas of vSphere.
Read more…
Share on Facebook
Categories: Cloud Computing, VMware, vSphere Tags: ESX, green technology, HA, host profiles, vCenter, VI Toolkit, Virtual Center, virtualization, VMware, vsphere
Some are speculating that next Tuesday VMware is going to announce the release of VMware vSphere which is what essentially is Virtual Infrastructure 4.0 which would include ESX 4.0. I can’t say what VMware is going to do but over the next few weeks I will be publishing information on vSphere as well as some instructional videos. For now I have some teasers for you.
Here is a screen shot of the alarms available in vSphere. A you can see they have expanded the alarm feature from what was available in VI3.
Read more…
Share on Facebook
Categories: VMware Tags: Automated Deployment, ESX, ESXi, green technology, HA, installtion, vCenter, Virtual Center, virtualization, VMware, vsphere
Over the years there have been some controversy over this topic. Should Virtual Center (vCenter) be physical or virtual? There is the argument that it should be physical to ensure consistent management of the virtual environment. Of course there is also the fact that Virtual Center requires a good amount of resources to handle the logging and performance information.
I’m a big proponent for virtualizing Virtual Center. With the hardware available today there is no reason not to. Even in large environments that really tax the Virtual Center server you can just throw more resources at it.
Read more…
Share on Facebook
Categories: VMware Tags: Capacity, ESX, ESX 3.5, ESXi, Failover, HA, service console, vCenter, Virtual Center, virtualization, VMware
To properly size a HA fail over cluster there are a few things that need to be determined. You need to know how many hosts are going to be in your cluster, how many hosts you want to be able to fail (N+?), and it helps to know resource utilization information about your vm’s to gauge fluctuation. Once we know this information we can use a simple formula to determine the maximum utilization for each host to maintain the appropriate DRS fail over level.
Here is an example:
Read more…
Share on Facebook
I’ve been asked this question a lot lately, “How much memory should we assign to the service console?” My default answer is always 800Mb. I have a number of reasons why I would recommend this, but the short answer is “Why not?” What do you really have to loose by assigning the service console 800Mb? The answer is nothing, but you do have a lot to gain. Even if you are not running any agents there are benefits to this. One thing most people dont’ realize is even if you don’t install any third party agents at the service console you are still running agents. There is the vpxa agent that allows you to communicate with vCenter, and there is the HA agent if you are running VMware HA, and if you have more than 4Gb of memory installed VMware recommends increasing the RAM to 512Mb.
Considering all this and that most systems today have 16Gb of memory or a lot more I just don’t understand why anyone would leave the service console at 272mb. When deploying a new server always create a swap partition of 1600Mb which is double the maximum amount of service console memory. This will at least allow you to increase the service console memory later without having to re-deploy your host.   Having an easy option when you call tech support with a problem and they tell you to increase the memory to 800Mb is always a great idea. I’ve seen a large number of users having HA issues that have called tech support and the first thing they are told is to increase the SC memory to 800Mb. So before you deploy your next ESX server take the Service Console memory into consideration, and at least create the 1600Mb SWAP partition so you can easily bump the memory up to the max of 800Mb.
Share on Facebook
