I have used both products, and the bottom line is that Sun VirtualBox is a little rough around the edges. While it loads faster, sound capability is lacking. It has a much simpler interface, but at the same time the interface is a little cryptic. It does, however, load virtual disks from VMware Workstation.
To add virtual machines (VMs) to VirtualBox you must first create or add an existing virtual disk to the virtual disk manager. VirtualBox understands VMDKs from VMware Workstation 6.5 as well as those exported using VMware Converter from VMware ESX hosts. Once you have the virtual disk you can then create the VM and launch the VM.
I used Sun VirtualBox to work around the limitations within VMware Workstation’s USB support. Sun VirtualBox’s implementation of USB is much better and supported the device I need to use: LiveScribe SmartPen. When the SmartPen first came out there was no support for 64-bit Vista implementations, so I had to resort to virtual machines to get the 32-bit drivers to work, but they would not work through VMware Workstation on any version. They did work through VirtualBox. So VirtualBox allowed me to save my notes, but since there was no sound, I could not play them back. Eventually, 64-bit Vista drivers came out, all was well and I removed my VirtualBox implementation.
VirtualBox a good simple product if all you need is a spare system to run USB devices that VMware Workstation doesn’t support. If VirtualBox was given sound support it could rival VMware Workstation. Even so it is a very good tool to include in your virtualization toolbox. Simply put, however, VirtualBox is not as robust as VMware.
VMware Workstation provides many more features than the bare bones Sun VirtualBox. These features include embedded video creation, debugging modes for kernel developers, high speed inter-VM communication via VMCI, solid sound and video support, VM teaming, etc. If you need more than a bare bones, no thrills product then VMware Workstation is for you.]]>
VMware frequently updates the Guest Operating System Installation Guide (GOSIG), an online book that gives specific information for VMware ESX Server, VMware GSX Server, VMware Server, VMware ACE, VMware Workstation and VMware Fusion guest operating systems. This guide gives very specific configuration matrices for the VMware product and the guest OSes that can be run within the product. Further, there are very handy known issues sections for each guest OS.
Supported VMware Server 2.0 configurations
A specific example that I have found this guide helpful in regards to VMware Server 2.0. According to the GOSIG resource, Windows Server 2003 is only a supported configuration on VMware Server 2.0 with Service Pack 1, Service Pack 2 or the R2 features added to Windows Server 2003. VMware ESX, however, has a fully supported configuration for Windows Server 2003, including the base release without any Service Packs or the R2 features, in all versions from 2.0 through 3.5 Update 3.
Supported Windows Server 2008 configurations
Some configurations are more obvious, such as running Windows Server 2008 as a guest operating system on a hypervisor that predates the release of the guest OS. In the GOSIG guide, Windows Server 2008 64-bit guest OSes are supported only on more current products. Some platforms, such as VMware GSX server and VMware ESX Server 2.x and 3.0x are not a supported configuration for this guest OS. Even with all of this information, and the officially supported configurations – you may find that certain situations are successful even though they are not listed in the GOSIG documentation. A better practice would be to match the hypervisors with the supported configurations in regards to the guest OSes, and this may mean standing up different versions of VMware products to cover the full range of OSes that are required in your environment.]]>
The following command will start the virtual machine named ScriptStart1:
vmrun -T server -h https://dhcp-122:8333/sdk -u root -p rootpass start "[standard] ScripitStartVM1/ScriptStartVM1.vmx"
Once that command is launched, the receipt of this command is represented in the scrolling log accessible through VMware Server Web Access. This is shown in the figure below:
One important note that in this example the command is case sensitive to the datastore path, so the VM name of ScriptStart1 cannot be represented any way other than its location in the datastore. The path and .vmx file name may vary in situations where the VM has undergone name changes or copy operations from another VM.
There are quite a lot of parameters passed to the VMware server with the vmrun command, and it is important to note a few attributes of the command. The parameters are designated below:
The last parameter is the path to the virtual machine within the datastore.
Aside from this quick example of a basic start command, vmrun has many other features, such as installing VMware Tools, adding shared folders, killing a process in a guest VM and reverting to a snapshot. One positive point about vmrun is that it can be used in both VMware Server (versions 1 and 2) and VMware Workstation products. There is a lot more to vmrun, and the full command documentation can be found in the vmrun control document available on the VMware website.]]>
Here are some of my predictions on what I expect (more like hope) to hear loud and clear above the constant static to be generated next week. I have no special access or insight other than my conversations with my contacts. These predictions are just my guesses.
VDI (Virtual Desktop Infrastructure)
VMware Workstation 6.5
The blog post Workstation 6.5 beta – Release Candidate available on the Gabe’s Virtual World blog not only let me know VMware is getting closer to general availability with the latest Workstation release, but it also helps put VMware’s recent blunder into perspective. In short, Gabe posted because users of the Workstation 6.5 Beta 2 now have expired licenses that need to be upgraded for the new Release Candidate 1.
I’ve read several posts and comments over the last week stemming from the August 12 VMware ESX/ESXi Update 2 bug that expressed administrator outrage over the fact that VMware uses license expiration time bomb code in their products. Opinions ranged from “VMware is too concerned with protecting their software that it hurts it’s paying customers” to “product expiration code bugs are impossible to catch in the change control process so they should never be implemented.” I’m not arguing that either of these opinions is wrong or that VMware did not make a mistake, but time bomb licensing is a standard development practice. The primary purpose of the license expiration is to make sure all testers upgrade and VMware is not only supporting the latest version, but is getting technical feedback about the right code level. It was easy to lose sight of this during the frustration last week.
Let’s assume that VMware’s Quality Assurance and regression testing process doesn’t fail to remove or disable any license expiration code when Workstation 6.5 is finally generally available.
By the way, VMware Workstation 6.5 has some exciting new features. Go to the Workstation 6.5 Release Notes Page for more information.]]>