A whitpaper was posted in the VMTN communities Thursday outlining the differences between the ESX 3.x and ESX 4.x service console. It further offers resources for transitioning COS based apps and scripts to ESXi via the vSphere Management Assistant and the vSphere CLI. Also mentioned briefly was the vSphere PowerCLI. If you are a developer or write scripts for VMware environments, also check out the Communities Developer section.
I hear it time and time again…The full ESX console is going away. ESXi is the way to go. I know there are valid arguments for keeping ESX around, but they are few. Failing USB keys may be a valid argument, but I have not heard of this happening. If that is the case, use boot from SAN. You need SAN anyway. As for hung VM processes, there are a few ways to address this in ESXi.
Read more…
Share on Facebook
Everyone at this point should be aware that the Service Console is now located in a vmdk on a VMFS partition. The Service Console vmdk must be stored on a vmfs datastore and the datastore must either be local stoage or SAN storage that is only presented to the one host. So I guess no shared vmfs datastores to house all the Service Consoles……. The next question I had about the new service console was the /boot partition. Where is it and how is the server bootstrapping? Well I can’t say I have totally gotten to the bottom of this yet but I have discovered a few things. When digging into scripting installations of vSphere I first looked at the disk partitioning which sheds a little light on the boot process. Here is what the disk partitioning portion of the script looks like:
part /boot –fstype=ext3 –size= –onfirstdisk
part storage1 –fstype=vmfs3 –size=30000 –grow –onfirstdisk
part None –fstype=vmkcore –size=100 –onfirstdisk
# Create the vmdk on the cos vmfs partition.
virtualdisk cos –size=8000 –onvmfs=storage1
# Partition the virtual disk.
part / –fstype=ext3 –size=0 –grow –onvirtualdisk=cos
part swap –fstype=swap –size=1600 –onvirtualdisk=cos
Read more…
Share on Facebook
Categories: ESX 4, Kickstart, Other, Scriptng, VMware, vSphere Tags: Automated Deployment, datastore, datastores, ESX4, kickstart, service console, 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
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
