Archive for the ‘esxi’ Category
ESXi U4 Ends Free Version Read and Write Access from the RCLI
VMware’s release of ESXi Update 4 (U4) has apparently restricted Remote Command Line Interface (RCLI) administration of the free version of ESXi again. I followed a link in a tweet today from fellow vExpert William Lam which led me to a VMware Communities thread titled ESXi 3.5u4 is out, does the RCLI still have r/w access for the free version?. In this thread Dave Mishchenko reports:
“I tried vicfg-advcfg and vicfg-snmp and both failed to write ( Failed : fault.RestrictedVersion.summary). They worked fine to read configuration.”
Of course, the licensed version of ESXi U4 will allow remote read and write access.
Readers may recall that remote read and write access to free ESXi U3 via the RCLI was announced here on VM /ETC and then quickly reported as a mistake that VMware would “fix” in an upcoming version.
I find it hard to believe VMware will not allow remote configuration of it’s free version. Seems to me that free hypervisor alternatives from Microsoft and Citrix would warrant a competitive justification. Besides, vCenter offers the real, GUI based ease of administration. Why not allow command line read and write access to the free ESXi version?
William ends the thread with a thought worth considering:
“Too bad to hear, looks like if users are happy with their r/w access with the RCLI, they may not want to upgrade to U4 just yet.”

ESX/ESXi 3.5 Update 4 Released – PXE Boot ESXi Experimentally Supported
VMware has released Update 4 (U4) of ESX and ESXi. There are some new features available with these latest builds, so check out the Release Notes of each product (linked below).
Although there are a lot of new enhancements, probably the biggest surprise for me was the experimental support for PXE booting ESXi U4. PXE boot allows stateless servers without local hard drives. For a “how to” on PXE booting ESXi 3.5 U4 check out VMware KB Article 1008971
“The main benefit of PXE booting ESX Server 3i version 3.5 Update 4 is that it allows you to run the deployment on systems with no disk or other local persistent storage. Furthermore, PXE booting greatly simplifies both the booting and upgrading processes. Therefore, scaling to many machines is greatly facilitated. No manual installation steps are necessary when the system is fully-realized.”
This sounds like an obvious Cloud enabling technology to me!
In the past, Chris Wolf and Mike Dipetrillo both gave us glimpses of a PXE boot future for ESXi. As both bloggers have described, it appears VMware architect Lance Berc is the man to thank for this new feature. Check out their posts for more info on what is possible and how it is done.
Another major enhancement of Update 4 in my opinion is the expanded and improved Enhanced VMXnet virtual network driver. Improved network performance is now possible for the 32 bit versions of Windows Server 2003 as well as Windows XP. Update 4 appears to make my recent post on enabling the VMXnet driver obsolete!
I’ll highlight (using cut and pastes) what else caught my attention from the Release Notes of both ESX and ESXi in this rest of this post. Read the rest of this entry »
Using the Enhanced Vmxnet Adapter and TSO in ESX VMs
Part of the magic hosting multiple virtual machines (VMs) on VMware ESX server is accomplished by leaning on the host’s CPUs to simultaneously handle networking loads. The more network I/O generated the more the CPUs have to work. When this happens the performance of the ESX host and the VMs can suffer because the result is limited access to available physical processing. Some common network I/O examples are software iSCSI adapter or NFS access to data stores, live migration of VMs between ESX servers via VMotion, and even administrator access with the VI Client.
Fortunately, ESX/ESXi 3.5 TCP Segmentation Offload, or TSO, can remove some of the networking burden from the host’s CPUs and improve overall performance. When the ESX server’s physical NICs support it, enabling TSO is as simple as choosing the right virtual network adapter, the Enhanced VMxnet adapter, for the VM. Surprisingly, making the Enhanced VMxnet adapter available to the VM is not a straightforward process because the Enhanced VMxnet adapter might not be an option in the virtual NIC properties or the Add New Hardware wizard.
First, you may be wondering how TSO reduces CPU overhead. Read the rest of this entry »
VMware ESX Memory Over Commit Technology Explained
Jason Boche’s post titled Idle Memory Tax is a great read if you are trying to understand ESX memory allocation between virtual machines (VMs). Specifically, the post does a great job explaining how it works when you over commit your physical host’s memory. In other words, the sum of all the RAM assigned to the VMs running on a host is greater than the actual physical RAM of the ESX server.
Here’s a quote from Jason that briefly explains part of the technology that makes over commit possible: the Idle Memory Tax (IMT).
“Quite simply it’s a mechanism to take idle/unused memory from guest VMs that are hogging it in order to give that memory to another VM where it’s more badly needed. Sort of like Robin Hood for VI. By default this is performed using VMware’s balloon driver which is the more optimal of the two available methods. Out of the box, the amount of idle memory that will be reclaimed is 75% as configured by Mem.IdleTax under advanced host configuration. The VMKernel polls for idle memory in guest VMs every 60 seconds.”
Read the entire post for much more technical details and examples.
I’ve blogged before about the symptoms when the IMT and the ESX balloon driver can no longer keep up and it’s time to add another ESX host and spread the VM load.
I believe that ESX 3.x changed the need to Read the rest of this entry »
ESXi/ESX 3.5 Update 3 iSCSI and FC Alert – Queue for device has been blocked
A few virtualization bloggers have reported that they received an alert email from VMware about an I/O failure issue involving iSCSI or Fiber Channel (FC) SANs. There is also an alert currently dispalyed at http://www.vmware.com/support. In summary, an indefinite block occurs between ESXi/ESX 3.5 Update 3 hosts and VMFS 3 Luns which results in all paths to the storage entering a standby state. The issue is apparently isolated to the Update 3 version only.
Eric Sloof is one blogger that received the email and he has published his copy on his NTPro.nl blog. Here’s a brief quote from the email about the issue:
PROBLEM STATEMENT AND SYMPTONS:
- ESX or ESXi Host may get disconnected from Virtual Center
- All paths to the LUNs are in standby state
- Esxcfg-rescan might take a long tome to complete or never complete (hung)
- VMKernel logs show entries similar to the following:
- Queue for device vml.02001600006006016086741d00c6a0bc934902dd115241 49442035 has been blocked for 6399 seconds.
- Please refer to KB 1008130.
SOLUTION:
A reboot is required to clear this condition.
VMware is working on a patch to address this issue. The knowledge base article for this issue will be updated after the patch is available.
VMware KB 1008130 is titled VMware ESX and ESXi 3.5 U3 I/O failure on SAN LUN(s) and LUN queue is blocked indefinitely and provides the pattern of vmkernel messages that identify you have this issue:
Error messages matching this pattern are repeated continually in vmkernel:
<date and time> <hostname> vmkernel: <server uptime> cpu6:1177)SCSI: 675: Queue for device vml.<Vol. Dev. ID> has been blocked for 7 seconds.
<date and time> <hostname> vmkernel: <server uptime> cpu7:1184)SCSI: 675: Queue for device vml.<Vol. Dev. ID> has been blocked for 6399 seconds.
As stated in both the email and the KB article, unfortunately the only solution is to reboot your ESXi/ESX 3.5 Update 3 hosts until VMware is able to provide a patch.
6 Server Virtualization Platforms with Free product offerings
5 Linux-based Virtualization Companies to Watch on Ken Hess’s Linux Blog is a post about the 5 main server virtualization platforms based on Linux. Ken also mentions the only non Linux based hypervisor, Microsoft’s Hyper-V.
“There’s only one company that doesn’t use Linux for its server virtualization platform. Can you guess which one it is? If you guessed Microsoft, you’re correct. Microsoft is a newbie in the virtualization space but wants in and may make significant dents in the already well-established market that is significantly owned by VMware. For Windows-only virtualization, there may be some validity to the switch to Hyper-V.
For the rest of us, who are either too stubborn or too smart to make the shift to Hyper-V, what are our choices? The following is a list of 5 of the main players in Linux-based virtualization.”
Use the link above to read all of Ken’s original post for some brief info about each platform, but I am listing the 6 products and the links to their free versions for quick reference here. Ken does not discuss nor am I including free hosted platforms such as Microsoft Virtual PC or VMware Server. Read the rest of this entry »
VMware free ESXi 3.5 Update 3 RCLI APIs opened unintentionally
Unfortunately this post is an update to my post from last week titled ESXi Update 3 enables full remote administration via RCLI. Today I have received new information from VMware about the current and future status of the Remote Command Line Interface’s (RCLI) ability to manage the free version of ESXi 3.5.
With the release of VMware ESXi 3.5 Update 3, some API calls became freely available. As it turns out, these new APIs were opened up unintentionally. This inadvertent change happened when VMware was resolving an API-related bug.
Only customers who downloaded the free version of ESXi have been affected. VirtualCenter and VI (Foundation, Standard, Enterprise) customers are not affected.
My VMware contacts tell me that this bug will be fixed shortly, and the next release will lock down the RCLI again.
Remote administration and configuration of the free version of ESXi 3.5 remains possible from the VMware Virtual Infrastructure Client.
I have updated my original post with this information as well.











