My new Thinkpad W520 has been a great investment for multiple virtual machine software development purposes. Configured with an INTEL CORE I7-2920XM processor, solid state primary drive and 16GB of memory the multiple virtual machines run about twice as fast as my older Thinkpad T41p.
I still use my Seagate 500GB hybrid drive as my secondary drive, where I have all of my virtual machines located; the primary hard drive being used for the HOST OS only.
I am still using VMWare for virtualization, as was the case for the older Thinkpad T41p. No need to consider a move away from VMWare Workstation 7. I have been quite pleased with VMWare, after switching from the Microsoft Virtual PC product in 2009. I also use VMWare ESXi Server for the hosting environment offered to my clients.
The primary reasons I purchased the W520 include the faster processor, as well as the solid state primary drive and of course the availability of USB3. The faster processor plus USB 3 has reduced my full backup time from nine (9) to two (2) hours.
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.
After moving to VMWare Workstation 7.0 using Windows 7 64 bit as the host OS, the one remaining problem I had was the inability to backup/sync my iPhone in a VMDK virtual machine. After opening a problem with VMWare and spending many hours testing various tests with VMWare the problem has resolved to being a problem with the iPhone firmware. It appears that a corruption problem can occur when moving the iPhone firmware from version 2 to version 3. The symptom of the problem is extreme slowness when backing up one's iPhone.
For me, the extreme slowness in backing up/syncing the iPhone showed up as the complete inability to backup/sync my iPhone within a VMDK virtual machine. The iPhone backup/sync would come to a complete halt for some reason.
To resolve the iPhone corruption problem, I removed all of my free iPhone applications, which number 20-30 such applications (I am too cheap to actually purchase many iPhone apps). I then conduct a hard reset on the iPhone, after which I reinstall all of the 20-30 applications. At this point, my iPhone backup runs in only about 5 minutes, which was taking over 2 hours with the iPhone corruption problem.
Working with VMWare on this problem was frustrating at times, however they did provide excellent support, even though the problem is with the iPhone.
Using VMWare for my virtual machine support along with a Windows 7 64 bit host OS has been an excellent combination.
My 8gb is on the way via UPS from California. As you know from my prior blog posts the 8gb is part of the master plan in moving to a 64 bit host OS. I should see some improved performance, especially when executing multiple concurrent virtual machines.
-I have continued to test the following Windows 7 configuration.
- Windows 7 64 Bit Host OS…with either Windows 7 Virtual PC (WVPC) RC support ....or VMWare 6.5 Workstation ...(both are NOT installed at same time)
- Vista 32 Bit Guest OS (VM # 1 )
- Windows 7 32 Bit Guest OS (VM # 2)
I was advised by MSFT support that for best overall Windows 7 virtualization performance I should disable the BIOS Speedstep setting in my BIOS Power settings. These performance results reflect this BIOS Speedstep setting being disabled.
Performance results when comparing WVPC RC to VMWare are as follows…
- With only VM # 1 active ... opening a web site project...WVPC takes 1 min 0 sec... VMWare takes 0 min 25 sec.
- With only VM # 1 active.... a build of one of my typical web sites ... WVPC takes 3 min 42 sec....VMWare takes 2 min 10 sec.
- With both VM # 1 and VM # 2 active... a build of the same web site ... WVPC takes 7 min 20 sec....VMWare takes 4 min 26 sec.
I find that boot-up time is roughly the same for both WVPC and VMWare.... regardless of number of VMs active....obviously boot-up time for two VMs at the same time takes longer....however WVPC takes roughly the same time as VMWare.
Considering the above performance results …I have decided to use VMWare for virtualization support as I migrate to Windows 7. The following VMWare features are also quite compelling:
Next step…I upgrade my Thinkpad T61p memory to 8gb....and over time I migrate the virtual machines from 32 bit to 64 bit.