I went to install the VMware SDK for vSphere 4.0 on to my desktop running Windows 7 64-bit, Visual Studio 2008, and .Net 3.5 SP1 and discovered the SDK setup is not friendly with these versions. According to VMware you need Visual Studio 2005 and .Net 2.0 if you want to run the SDK.
So like most of you reading this I turned to my trusted adviser…google to find the answer I was looking for. Much to my disappointment after 5 minutes of searching around I didn’t find any instant gratification for my problem so I decided to just go ahead and figure it out on my own.
Read more…
Share on Facebook
Categories: Other, Scriptng, VMware Tags: ESX 3.5, ESX4, ESXi, Installation, Script, scripting, SDK, vCenter, VI4, Virtual Center, VMware, VMware Workstation, vsphere
Back in the summer, I saw Stu’s Post about automating the installation of ESXi. I was reminded again by Duncan’s Post. Then, I found myself in a situation when a customer bought 160 blades for VMware ESXi. With this many systems, it would be almost impossible to do this without mistakes. I took the ideas from Stu and Duncan and created an ESXi automated installer that works from a PXE deployment server, like the Ultimate Deployment Appliance. I took it a step further and added the ability to use a USB stick or a CD for those times when PXE is not allowed. The document below is a result of it.
This is a little different than the idea of a stateless ESXi server, where the hypervisor actually boots from PXE. This is the installer booting from PXE so that the hypervisor can be installed on local disk, an internal USB stick or SD card. You could also use it for a “boot from SAN” situation, but extreme care should be taken so you don’t accidentally format a VMFS disk.
Read more…
Share on Facebook
Categories: Cloud Computing, ESX 4, ESXi, Scriptng, VMware, automation Tags: Automated Deployment, ESXi, Installation, VI4, VMware, vsphere
For over a year now, I have started off telling customers in Plan and Design engagements that they would be using ESXi unless we uncovered a compelling reason to NOT use it. The “which do I use” argument is still going strong. Our blog post “ESX vs. ESXi which is better?“ was posted in April and is still the most popular. It seems to be a struggle for many people to let go of the service console. VMware is trying to go in the direction of the thinner ESXi hypervisor. They are working to provide alternatives to using the service console.
VMware has provided a comparison of ESX vs. ESXi for version 3.5 for a while. Well, VMware posted a comparison for ESX vs. ESXi for version 4 last night. It’s a great reference.
Share on Facebook
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
Have you ever needed an easy to reference way to see what the configuration maximums are for different versions of VMware ESX. I know I seem to need this all the time. I find it a huge pain to keep referring to each of the individual VMware documents to get the answers. Sometimes I also want to see what the changes are between versions and I can’t seem to memorize this information in my tiny little brain. So I went ahead and created a “Configuration Maximums Comparison Matrix” based on the VMware Configuration Maximums for each version.
You’ll notice some settings don’t have values for each version. This is because they were not published in the VMware documents. As I go through some additional documents and extract these values I will update the document to reflect. For no the document does include everything from the VMware Configuration maximums published for each of these Versions:
Read more…
Share on Facebook
Categories: ESX 4, VI4, VMware, vSphere Tags: ESX, ESX 3.5, ESX4, ESXi, vCenter, VI4, 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
So the question is which is better VMware ESX or VMware ESXi. A lot of die hard Linux fans will always say VMware ESX because of there attachment to the service console. The service is a great tool and once upon a time it served it’s purpose. Today there are many other options available to manage your VMware ESX servers without the service console. There is the Remote CLI, the VI ToolKit for Windows (powershell), and last but not least the VIMA.
With these tools you can effectively create scripts to help manage your VMware ESX environment without the service console. The service console opens up an additional security risks for each and every VMware ESX host you have deployed. Mitigating this risk increases the management overhead involved in the maintaining and deployment of these server in your environment. VMware ESX also consumes more server resources than VMware ESXi. The service console in VMware ESX uses CPU cycles and memory that you could be utilizing for virtual machines on VMware ESXi.
Read more…
Share on Facebook
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
This really isn’t a script but more of a command but I think everyone gets the idea.
Find VM Snapshots for all servers in Virtual Infrastructure and display the VM Name, Snapshot Name, Date Created and power state. You can limit the VM’s this affects by using the location specific commands covered earlier.
Get-snapshot –vm (get-vm) | select vm, name, created, powerstate | export-csv [path_filename_csv]
Read more…
Share on Facebook
