by Duncan Epping
Duncan Epping · ·
Many people have already asked for this as amazon’s shipping is slow or too expensive. After a short discussion we decided to also make the vSphere Quick Start Guide available via lulu.com. Lulu has printing shops in Europe which makes shipping a lot faster and a bit cheaper.
We are also currently discussing a PDF version of the book…. more soon!
Duncan Epping · ·
I’ve been following William Lam‘s VMTN account in my RSS reader for a while as William regularly releases useful scripts. Lately he has been pumping iron and releasing new scripts or new versions of scripts on an almost daily basis. One of the most useful scripts that William released lately is “getvSwitchMacTable.pl”. Make sure to add William to you RSS reader or just follow him on twitter.
This script allows you to dump information about your vSwitche(s) pertaining to the VM(s) that are attached, the portgroups in which the VM(s) are attached to and the corresponding MAC Address that maps to the portgroup/vswitch
You can specify a specific Cluster, Datacenter or if execute against vCenter without options, it will extract ALL VMs or you execute against an individual ESX(i).
Duncan Epping · ·
For those still on ESX 3.5 VMware has just released Update 5. Here are the full release notes, you can find the download here and make sure to read which issues have been resolved.
What’s New?
Notes:
- Not all combinations of VirtualCenter and ESX Server versions are supported. All of these highlighted features are available only if you are using VirtualCenter 2.5 Update 5 with ESX Server 3.5 Update 5. See the ESX Server, VirtualCenter, and VMware Infrastructure Client Compatibility Matrixes for more information on compatibility.
- VMware recommends VMware Tools upgrade for this version of ESX Server.
The following information provides highlights of some of the enhancements available in this release of VMware ESX Server:
Enablement of Intel Xeon Processor 3400 Series – Support for the Intel Xeon processor 3400 series has been added. Support includes Enhanced VMotion capabilities. For additional information on previous processor families supported by Enhanced VMotion, see Enhanced VMotion Compatibility (EVC) processor support (KB 1003212).
Driver Update for Broadcom bnx2 Network Controller – The driver for bnx2 controllers has been upgraded to version 1.6.9. This driver supports bootcode upgrade on bnx2 chipsets and requires bmapilnx and lnxfwnx2 tools upgrade from Broadcom. This driver also adds support for Network Controller – Sideband Interface (NC-SI) for SOL (serial over LAN) applicable to Broadcom NetXtreme 5709 and 5716 chipsets.
Driver Update for LSI SCSI and SAS Controllers – The driver for LSI SCSI and SAS controllers is updated to version 2.06.74. This version of the driver is required to provide a better support for shared SAS environments.
Newly Supported Guest Operating Systems – Support for the following guest operating systems has been added specifically for this release:
For more complete information about supported guests included in this release, see the VMware Compatibility Guide: http://www.vmware.com/resources/compatibility/search.php?deviceCategory=software.
- Windows 7 Enterprise (32-bit and 64-bit)
- Windows 7 Ultimate (32-bit and 64-bit)
- Windows 7 Professional (32-bit and 64-bit)
- Windows 7 Home Premium (32-bit and 64-bit)
- Windows 2008 R2 Standard Edition (64-bit)
- Windows 2008 R2 Enterprise Edition (64-bit)
- Windows 2008 R2 Datacenter Edition (64-bit)
- Windows 2008 R2 Web Server (64-bit)
- Ubuntu Desktop 9.04 (32-bit and 64-bit)
- Ubuntu Server 9.04 (32-bit and 64-bit)
Newly Supported Management Agents – See VMware ESX Server Supported Hardware Lifecycle Management Agents for current information on supported management agents.
Duncan Epping · ·
I am working on a large ESXi deployment and thought I would start writing down some of the lessons learned. I will try to create a single post every week, if I can find the time that is.
There are two things that stood out the couple of days, on a technical level, when I was reading the ESXi installable documentation:
One of the things that used to be a requirement was the Scratch Partition. It appears that with vSphere this requirement has been removed:
During the autoconfiguration phase, a 4GB VFAT scratch partition is created if the partition is not present on another disk. When ESXi boots, the system tries to find a suitable partition on a local disk to create a scratch partition. The scratch partition is not required.
Of course this does not necessarily mean that you do not need one as explained in the second part of the paragraph:
It is used to store vm-support output, which you need when you create a support bundle. If the scratch partition is not present, vm-support output is stored in a ramdisk. This might be problematic in low-memory situations, but is not critical.
So the question remains what would my recommendation be? The answer is it depends, yes I know the easy way out. But when you have enough RAM on a host and from experience know that usually you only create support dumps on hosts which are in maintenance mode then don’t worry about it and don’t create it. However if you feel there is a need to create vm-support dumps while running production make sure there is a scratch partition with enough free space available.
Yes ESXi is fully supported but there are some restrictions:
Now what does “experimental support” mean? According to the VMware website it means the following:
VMware includes certain “experimental features” in some of our product releases. These features are there for you to test and experiment with. VMware does not expect these features to be used in a production environment. However, if you do encounter any issues with an “experimental feature”, VMware is interested in any feedback you are willing to share. Please submit a support request through the normal access methods. VMware cannot, however, commit to troubleshoot, provide workarounds or provide fixes for these “experimental features”.
So does that mean that in the case of stateless the booting process is experimental? Or the installation process in the case of boot from FC SAN?
No it does not. Everything related to ESXi is “experimental”. So what does this mean? Imagine you are facing serious storage issues and you just called VMware. VMware analyzes your environment and notices that it’s a PXE booted environment, they will more than likely give your support call a lower priority. Not only a lower priority but the support is “best effort”, no guarantees.
Duncan Epping · ·
Since vSphere has been introduced more and more of my customers are migrating to ESXi. It makes sense as the thin hypervisor is the way of the future according to VMware.
One common used argument by the admins to not use ESXi is killing a rogue VM. Normally an SSH session would be opened to the Service Console and with “kill -9” the VM would be killed when a “power off” did not work”. Because ESXi is COS-less this is not an option. However, it is still possible to kill these VMs by using the following procedure:
login in unsupported mode:
Press <alt> + <f1> and type “unsupported” <enter>
List all running VMs:
vim-cmd vmsvc/getallvms
Kill VM with vm id:
vim-cmd vmsvc/poweroff <vm id>