While looking for VMA 4.1 documentation I came across this bit of time travel. VMA version 5.0 with a realease date of August 5 2011, which is just about 2 months from now. If VMA is being upgraded to 5, I would suspect vSphere would also see an update around that same time. I should note that the links for the VMA 5 docs were broken.
I ran into an issue with VMWare converter hanging while in block conversion mode while trying to virtualize an instance of Microsoft SQL server. It turns out that it’s a known issue in version 4.3 of the standalone converter. My conversion was hanging due to the cluster size of some disks being larger than 4k. It’s very common to use 64k cluster sizes for SQL data volumes and converter was completely hung up while trying to convert those disks. Thankfully there is a workaround.
First you’ll have to stop the conversion by closing converter and stopping the vmware converter services. Then remove the partially imported virtual machine giving you a clean slate from which to start.
To determine which disks are affected run the following command as an administrative user on each drive of the target you’re converting to determine if “Bytes Per Cluster” is larger than 4096:
fsutil fsinfo ntfsinfo c:
If “Bytes Per Cluster” is larger than 4096, you can force a file level copy by reducing the volume size for each volume affected. In my case I simply recreated my conversion task and reduced each affected volume by one gigabyte.
ESX 4.1 (update n) will be the last installable version of ESX to retain the service console. There is no upgrade path for ESX to ESXi, you must reinstall to migrate or upgrade. Upgrading is a great reason to consider modernizing your virtualization infrastructure. VMWare currently recommends that new deployments of vSphere 4.x are done on ESXi and that existing ESX deployments of vSphere 4.x or older are migrated to ESXi.
What is the primary difference between VMware ESX and VMware ESXi?
The service console has been removed from ESXi, drastically reducing the hypervisor footprint.
VMware agents run in Console OS.
Nearly all other management functionality provided by agents running in the Console OS.
Users can log into Console OS in order to run commands for configuration and diagnostics.
VMware agents ported to run directly on VMkernel.
Authorized 3rd party modules can also run in VMkernel These provide specific functionality, like hardware monitoring or drivers.
VMware components and third party components can be updated independently.
No other arbitrary code is allowed on the system.
Why is it as good or better than ESX?
Improved Reliability and Security — fewer lines of code and independence from general purpose OS, ESXi drastically reduces the risk of bugs or security vulnerabilities and makes it easier to secure your hypervisor layer.
Streamlined Deployment and Configuration — ESXi has fewer configuration items than ESX, greatly simplifying deployment and configuration and making it easier to maintain consistency.
Simplified Hypervisor Patching and Updating — Due to its smaller size and fewer components, ESXi requires far fewer patches than ESX, shortening service windows and reducing security vulnerabilities.
AD Integration — The ability to configure the host to join an Active Directory domain, and any user trying to access the host will automatically be authenticated against the centralized user directory. You can also have local users defined and managed on a host-by-host basis and configured using the vSphere Client, vCLI, or PowerCLI. This second method can be used either in place of, or in addition to, the Active Directory integration.
Scripted Installation. New to ESXi 4.1 is the ability to do a scripted installation of the ESXi software to the local disk of a server. Various deployment methods are supported, including booting the ESXi installer off a CD or over PXE, and accessing the configuration file over the network using a variety of protocols, such as secure HTTP. These scripts run locally on the ESXi host, and can perform various tasks such as configuring the host’s virtual networking and joining it to vCenter Server.
Boot from SAN support for ESXi. Support for Boot from SAN has been added to ESXi 4.1. This support includes Fibre Channel SAN, as well as iSCSI and FCoE for certain storage adapters that have been qualified for this capability.
How does one upgrade?
The simple answer is that you cannot upgrade from ESX to ESXi. ESXi requires a new installation, which requires you to reconfigure a server to the desired state. There are a few ways to reduce the amount of time you spend migrating. For instance, using host profiles to leverage common configuration settings across your environment, combined with distributed virtual switches to make configuration of host networking much easier. These configurations settings can be automated to save lots of time when provisioning new ESXi servers.
Since you’ll be reinstalling, you might as well consider a standard deployment method, like VMWare Auto Deploy or PXE Manager. This is a technical preview of what will likely become a future product, or productized enhancement for ESXi / vCenter. Ideally you could use this system to run servers which had no operating system on physical media. Meaning that when they reboot the state of the machine is lost. Simply bootstrap and download as a part of the boot process for your physical ESXi server and load the appropriate configuration for that host. You can now grow or shrink your clusters at will.
A stack consisting of the following would be a good start towards a fully managed vSphere infrastructure.
Licensing works just about the same as it does for ESX. If you have an existing ESXi infrastructure and you simply want to license your installations (ESXi) can be seamlessly upgraded to more advanced editions of vSphere. Simply upgrade the free license to the desired license type and take advantage of all the features.
The Common Information Model (CIM) is an open standard that defines a framework for agent-less, standards-based monitoring of hardware resources for ESXi. This framework consists of a CIM object manager, often called a CIM broker, and a set of CIM providers. Any software tool that understands one of these APIs, such as HP SIM or Dell OpenManage, can read this information and hence monitor the hardware of the ESXi host. ESXi also exposes hardware status information via SNMP for other management tools that rely upon that standard. SNMP Traps are available from both the ESXi host and vCenter.
The majority of systems management and back up vendors in the VMware ecosystem support ESXi today. Partners such as BMC, CA, HP, IBM, EMC, NetIQ, Quest Software, Commvault, Vizioncore, Double-Take Software, SteelEye, and Symantec are among the many partners that have systems management or back up products that support ESXi.
How do I manage it?
Management and integration points have been moved from the individual servers to vSphere Management Assistant and PowerCLI. This means that if you’ve got an extensive set of scripts hooking directly into vimsh or other features of the console, you’ll probably need to spend some time evaluating how long it will take you to port your scripts to vMA or PowerCLI.