Thin provisioning has been a feature within VMWare Workstation and VMWare ESXi Server for quite some while. To manage the growth of space use/reuse within a VMWare VMDK for VMWare Workstation, one usually periodically compresses the VMDK. Of course, such compression requires a shutdown of the virtual machine.
With ESXi Server based VMDKs, what I have found is that I have a preference for using Thin Provisioning, because when I take a snapshot, I follow taking such a snapshot by copying the VMDK to either another local or remote storage media, and of course such copying takes much less time with thinly provisioned VMDKs. The copy of the VMDK is a logical copy, not a physical copy; meaning only the in-use data blocks get copied, with one noted exception. This exception happens to be how free space is identified and re-used. If a utility like SDELETE is used periodically to zero out the free space within the VMDK then such free space is not copied to the destination location. For example; if after executing SDELETE used space is 25% of the VMDK, then the destination VMDK will occupy only 25% of the VMDK provisioned size. Also, the source thinly provisioned VMDK may have grown to the full thinly provisioned size.
I generally allow my ESXi Server thinly provisioned VMDKs to grow to the full thinly provisioned size, and of course this requires that the production VMDKs will require the provisioned size, however there is tremendous advantage during the copying/backup process, as noted above.
One of the more compelling reasons to use ESX/ESXi Server for virtual server management is the feature called Snapshot backups. Snapshot backups provide the ESX/ESXi Server administrator with the ability to essentially freeze a virtual machine (VMDK virtual server) at a point in time while scheduled updates or upgrades are being attempted. Snapshot backups are managed using the VMWare VI Client, discussed in a earlier post.
When a snapshot is taken all updates (regardless of origin) which occur to the virtual machine will be written to a set of snapshot files, rather than the VMDK virtual machine image; thus providing the administrator with the opportunity to copy the VMDK virtual machine image. A snapshot can be taken for two reasons; 1) if an administrator wants to copy the VMDK virtual machine, or 2) if the administrator wants to apply updates or upgrades (update from Microsoft, application upgrades, etc) to the virtual machine.
Once the VMDK virtual machine has been copied successfully, using simply copy/paste commands against the VMDK Virtual machine, or once the updates/upgrades have been verified as having applied successfully, then the snapshot is customarily deleted. Snapshot deletion will force ESX/ESXi Server to apply all queued updates/ upgrades (queued in the snapshot set of files) to the actual VMDK virtual machine.
If the updates/upgrades failed for some reason then the administrator can revert the VMDK virtual machine back to the point in time when the snapshot was originally taken. If the VMDK virtual machine is reverted to the point in time when the snapshot was originally taken then all updates/upgrades after that point in time will be lost, including the failed updates/ upgrades.
Snapshot backups are indeed a handy tool for virtual machine management. How many times have you applied an upgrade only to sadly find out that the upgrade failed and it needed to be backed out.
The functionality and performance of VMware ESX and ESXi are the same; the difference between the two hypervisors resides in their architecture and operational management. VMware ESXi is the latest hypervisor architecture from VMware. It has an ultra thin Linux kernel footprint with no reliance on a general-purpose OS, setting a new bar for security and reliability. The small footprint and hardware-like reliability of VMware ESXi enable it to also be available preinstalled on industry standard x86 servers.
ESXi Server is also available as a no-cost entry level hypervisor. During my deployment of ESXi Server I found a lack of available information on when ESXi Server is free and at what point ESXi Server incurs a license fee. Even internal VMWare personnel were unclear about the differentiation between an ESXi no-cost option versus ESXi Server available on a license fee basis.
One can download ESXi Server for a 60 day evaluation trial period. The 60 day trial provides one with a restricted function ESXi Server. It is not always clear what features are restricted, however during my use it appears that functions relating to cloning and backing up of virtual machines are indeed restricted. One can register their no-cost ESXi Server license to ensure one has a working ESXi Server longer than 60 days, however the functions relating to cloning and backup are still restricted. The functions relating to cloning and backup appear to only be available once one licenses a VMWare product, such as VSphere Essentials, which includes what is referred to a VMWare Consolidated Backup (VCB).
The VI Client is a desktop application used to communicate with ESXi Server. The VI Client can be used to configure an ESXi Server, monitor ESXi Server performance and take snapshot backups, however VI Client cannot easily be used to backup a virtual machine outside of a single ESXi Server environment. With the VI Client, the best backup one can hope to achieve is taking a snapshot backup to an alternate hard drive, also attached to the same ESXi Server. ESXi Server backups will be explorer in detail in another blog post.
Other available interfaces for managing the ESXi Server include the VI Command Level interface, essentially a batch like command level interface; commands being issued from a PC to the ESXi Server.
A Secure Shell (SSH) interface can also be enabledvia the ESXi console. Once enabled, programs like PuTTY and WinSCP can be used to communicate with the ESXi Server. SSH is available for diagnostic purposes (in theory), however I found the SSH interface to be essential for a stable on-going ESXi Server environment. I have found PuTTY necessary for monitoring the Linux based file system. I have had problems where the Linux based file system will fill up due to ESXi log file usage. I have to login via PuTTY and move log file out of the base Linux file system using either Linux commands or WinSCP. Once the Linux based file system starts filling up the ESXi Server will either become quite sluggish or an unexpected re-boots may occur.
In summary, I find essential single ESXi Server management tools to be VI Client, PuTTY and WinSCP. With SSH enabled, I had very little use for the VI Client command level interface. Having SSH enabled allows me to use PuTTY for what is essentially ESXi Server console access. I can issue Linux commands and ESXi Server specific commands directly.
Over the next several weeks I will be making posts related to my recent experience of deploying VMWare ESX Server. ESX Server is a bare metal hypervisor offered by VMWare. Supported guest operating systems include just about any Windows or Linux based server based OS. For me, I am initially deploying four instances of Windows Web Server 2008 R2.
My principal objective in deploying ESX Server was/is the ability to snapshot backup a running guest OS, thus simplifying software upgrades. Other reasons include the ability to start-up a new guest server OS for any reason without the need for deploying new hardware.
The principal candidates in the virtualization marketplace include VMWare, Microsoft and the Citrix XEN offering. I have always found Microsoft to be several steps behind the marketplace with respect to virtualization technology. I was quite disappointed with Microsoft’s virtualization offerings for the desktop at the time of the Windows 7 release, and as a result I moved from Microsoft Virtual PC 2007 to VMWare’s Workstation 7.0 for my development environment. I had my share of problems in moving to VMWare Workstation, however I now consider it a smart move. Many of the issues encountered with the VMWare Workstation migration are outlined in my Sep/Oct 2009 blog posts.
I also had many problems in migrating to VMWare ESX Server, however again, I think it was worth the move. The forthcoming blog posts will discuss some of the challenges.