One of the features that make desktop virtualization packages attractive is the ability to move files from the host to the guest virtual machine without the use of a network. Sun xVM VirtualBox has this functionality, so let’s go through it for use on Windows systems.

Enabling shared folders is fairly straight forward within VirtualBox, but must be configured when the virtual machine (VM) is turned off. In the properties of the VM, the share is configured as shown in the figure below:

Once the VM is powered on with this configuration, it can now access this shared folder. For Windows clients, the shared folder will be visible in My Network Places as shown in the figure below:

The security permissions are available as read-only or full control for the share, and multiple shares can be made available to a VM. The shared folder is presented to the VM as a server name of VBOXSVR, so be sure not to use that name on your network. The VBOXSVR name does not resolve to an IP address but is provided to the VM by the installation of Guest Additions. You can also script out the use of a shared folder with the VBoxManage command as shown below:

VBoxManage sharedfolder add "XP-RedPill" -name "zzVirtualMachineShared" -hostpath "C:\zzVirtualMachineShared"

Using the scripted option can be helpful in assigning a single shared folder to multiple VMs on the same VirtualBox installation. VirtualBox allows a shared folder to be created as a transient share, which is removed when the VM is powered off. This option is either configured in the interface or denoted by using the ‘-transient’ option in the VBoxManage command.

Sun xVM VirtualBox 1.6.2 is freely available for download from the Sun website.

One of the more overlooked placement discussions that happen within the design or re-engineering phases of virtualization projects involves systems that are on an external network.

The placement of external systems can be addressed many different ways, including the use of virtual private network (VPN) authentication servers, web servers or remediation systems for network access control. Consider the following architecture diagram where larger virtualization hosts contain all types of systems within the virtualized environment:

While the networking of these virtual machines may be configured with the same protections as their physical counterparts, there are some concerns with this configuration. This can become even more of a concern in the event where the firewall is a virtual machine as well in the same environment. An architecture that can better protect the internal and external workloads would be to have a separate environment with connectivity and workloads only to the external interfaces. Consider the figure below for the same workload:

In this manner, more hosts may be needed for the same workload to account for maintenance mode and other factors when separated. These additional hosts may be configured with smaller hosts and smaller processor inventory to not incur any additional costs or licensing for anything that is licensed by processor.

If firewall or other core network appliances are virtualized, their placement requires a little more thought because they may have a footprint on both the internal and external networks. In the case of shared resources of internal and external workloads, an outbreak type event on an external system may have resources consumed at the expense of the internal workload. By having the internal and external workloads separated, the risk of attacks within the operating system or an attack that targets virtual machines would be initially contained by internal and external workloads.

This strategy can be applied to all virtualization products, and can also be applied more specifically to network and storage configurations to protect in the same fashion. 

A virtualization package is ready for prime time when it has a full array of device connectivity between the host and the guest virtual machine (VM). Let’s take a quick look at USB device redirection in Sun xVM VirtualBox 1.6.2.

The USB device functionality has a nice feature that allows a selective mapping of USB devices from the host to the guest. This can be beneficial if you want a USB device (such as a license key) to be available only to the guest VM and not the host, or vice versa. Within the VM’s configuration, you have the option to specify all devices or specified devices to be connected to the guest VM through USB device filters in the properties of the guest VM. These changes must be made offline, and for Windows hosts the VirtualBox USB controller needs to be added with the native driver. Likewise, the USB root hub that arrives via plug-and-play needs to be installed with the driver on the guest VM (which is automatic when guest additions is installed.) The figure below shows a specific device being permitted to be passed to the VM:

The filter icons highlighted on the right side allow the VM to be presented with all USB devices, remove a filter and to add a filter that is based on user entered criteria or a selection among the currently installed devices. The filters are incredibly versatile as you could redirect certain devices by many factors to be available to the guest VM.

When a device is designated to go to the guest VM, it becomes unavailable to the host system. So there may be some practice issues to get used to losing a device when the VM is powered on. One note of caution is that the mouse and keyboard devices, if USB, are inherently made available to both the host and guest. However, if you add a device filter to add the USB mouse to the guest VM, the mouse would be only available to the guest VM.

Likewise, when the VM is powered off, the USB device will arrive back to the host and then be available for use. If snapshots are being used on the VM, the hardware inventory and specific configuration is managed in the snapshot, so USB filters will be deleted if you are reverting to a snapshot made before the filter was made.

Overall, this USB functionality is quite granular and a strong offering for desktop installation. More information on VirtualBox’s USB support can be found in the VirtualBox online user manual.

The Sun xVM VirtualBox Guest Additions host and guest driver integration suite optimizes the guest experience in a way similar to the VMware Tools installation. The virtualization suite installs within the guest operating system with a small footprint on most of the supported platforms within VirtualBox. Let’s take a quick look at how the Guest Additions installation considerations on a Windows guest system within VirtualBox.

The Guest Additions installation is launched via the virtual machine (VM) console from the devices menu. During this task, one of the VM’s optical drives will be directed to use the Guest Additions .ISO image kept locally. The install is vary straightforward, and the native drivers are updated with the optimized drivers for the video, fixed disk, audio, optical drive and other system components. The networking drivers will likely remain unchanged after installing the Guest Additions package within the VM. Among the unique features of VirtualBox compared to other products is the option to choose among four device types presented to the VM. The Intel Pro and AMD PCnet device options will have different compatibilities with various guest operating systems. Check out last week’s SearchServerVirtualization blog entry about related networking topics on VirtualBox.

Once Guest Additions is installed, the experience is markedly improved on the guest VM. The easy way to see if it is running is to look in the Windows system tray as shown in the figure below:

Note that hovering over the tray icon also gives you the version running on the guest operating system. That is a nice feature if you are using VMs created in VirtualBox 1.6.0 or another mixed environment. If you want to retrieve the current version of Guest Additions in a scripted fashion, the following command would be run:

VBoxControl getversion

This command is located by default in the Program Files\Sun\xVM VirtualBox Guest Additions path. VirtualBox commands are generally the same across platforms, so the same command on a Linux host would retrieve the version running locally.

Guest Additions is available on Windows NT, 2000, Server 2003, Vista and XP. Windows Server 2008 functions correctly in my experience, though it is not explicitly listed as a supported platform in the VirtualBox documentation. It is also is available for Linux and Solaris platorms.

Guest Additions is included with the VirtualBox 1.6.2 product and is available for download from the Sun website.

Speculations are overflowing within the virtualization community following Diane Greene’s resignation from VMware. As a glass-half-full kind of guy, I’d like to offer my reasons why VMware may thrive in the next several years.

First and foremost, I feel that VMware’s technology has the potential to continue to be superior to the competition. While price is among the more important decision points, the superior product will hold its own in the marketplace despite the higher price. The standing example in this arena is enterprise databases. Oracle is a better database platform than Microsoft’s offerings, yet both hold good position in the market place. A certain amount of normalization of market share for VMware is to be expected as other hypervisors and management products enter the market, but more organizations have yet to enter the market as a customer.

Storage integration will continue to drive the richest virtualization platforms. The most underrated technology that VMware has ever produced is the virtual machine file system or VMFS. VMware’s implementation of this technology will improve over time, and the competition is not yet there in this space.

VMware will have a lower host hardware cost per VM for the same performance deliverables. While this is incredibly difficult to precisely quantify, my experience is that VMware can run more virtual machines than Hyper-V on the same hardware. Again, because price is among the most important decision points, this point may help VMware as hardware becomes more capable for virtualization technologies.

VMware can continue to innovate within the virtualization space. VMware has the virtualization expertise to provide new products into the market, and among the major players in the field they would be the most suited to innovate at this point.

It is a given that the other platforms will make gains in market share with the relative flood of products into the space. But considering VMware’s proven ability to innovate in this space, they have the chance to retain their lead and keep going in the correct direction. We will see!

Given that virtual environments for x86 servers are relatively new, most lack direct experience in performing major in-place upgrades. While there are many ways to approach a key upgrade to a virtual environment, we’ll take a look at one example of a server virtualization upgrade: VMware ESX 3.5 and VirtualCenter 2.5 to the Update 1 release of both products. This release resolved some major issues, putting the spotlight back on the new features of ESX 3.5, namely Storage VMotion.

Maintaining version control on a virtualization platform is in the best interest of ongoing administration. With VMware environments, this situation is illustrated by the sequential upgrade tasks with older versions of ESX and VirtualCenter. The first step in making a successful upgrade is to go through the release notes and scour the Internet for existing resources that can make this task less daunting. One particularly helpful resource is the RTFM Education ESX and VirtualCenter upgrade guide by Mike Laverick which goes through many scenarios with specific, step-by-step guides on almost every topic of the upgrade.

Having all of the resources in the world may still not be enough to ensure a smooth upgrade of the virtual environment. This is where a test environment for the upgrades can prove critical to a successful project. Provisioning an accurate test environment can become increasingly expensive, but can provide a beneficial test ground to ensure there are no surprises during the upgrade. Consider the test environment shown in the figure below:

This test environment is a smaller, yet representative environment of the larger environment in that it may have the same storage system, base drivers on the host systems yet simply providing a smaller workload. This environment can be an adequate test environment for all of the basic functions involved with an upgrade. As for provisioning the environment, there are some tricks available such as using the systems in an unlicensed or evaluation mode, reducing processor inventories or taking resources from the live environment if the loss can be sustained.

Planning and testing are the best defenses against an upgrade failure. Furthermore, because the scope of a virtual environment is so broad, the investment in testing and planning should be a no-brainer.

If you have not noticed, I have been on a Sun xVM VirtualBox kick recently. I think it is beneficial to virtualization administrators and managers to be familiar with at least two hypervisors — so why not learn more about xVM?

VirtualBox has a smooth interface for a version 1 release, but the one area that would require the most adjustment is the virtual networking. Let’s take a closer look at network functionality in VirtualBox.

Virtual networking on VirtualBox has a few key differences that VMware users would need to develop an understanding about before fully utilizing the potential of the product. The first difference is the concept of the virtual networking hardware. VirtualBox allows a virtual machine (VM) to have one of four network interface cards virtually assigned. These are the AMD PCNet PCI II, AMD PCNet FAST III, Intel Pro/1000 T and the Intel Pro/1000 MT. This array of virtual adapters allows a VM to have broad support for multiple operating systems, but the corresponding bridging functionality may make network administrators a little uneasy.

Spanning Tree
For Windows systems, VirtualBox uses a spanning tree algorithm from the native operating system bridging that may cause issues on systems with multiple interfaces in managed network environments. The bridged network functionality puts the VMs on the same physical network as the VirtualBox host system. In this fashion, a VM would be able to retrieve a DHCP network from the physical network and interact as if it were placed on the network parallel to the host. Windows XP and Server 2003 products’ bridging functionality is explained on the TechNet website.

Another key difference is that in order for a VM to use the bridged network is the addition of a bridging interface. Adding an interface is fairly straight forward with the use of the VBoxManage command. The following command would add a bridging interface named “VM-Bridge”:

VBoxManage createhostif "VM-Bridge"

Once this command is completed, the VM-Bridge interface is now present in the network connections inventory of the Windows control panel. Then a VM can be configured to use bridged networking with the newly created interface as shown in the figure below:

At this point, the VM-Bridge interface can transparently place the VM on the same network as the host when the Windows bridged connections are correctly configured. Note also that in the network configuration you can fully edit the MAC address of the VM. While exceptionally convenient, this can introduce risk for some environments and situations.

Now that we have gone through a quick look at VirtualBox’s implementation of bridging network connections for VMs, I would have to nudge the VMware products to be a little more seamless in the category of bridged networking. By having the VMware bridge protocol binding used instead of a separate series of adapters for the same purpose, VMware’s bridging fits better for most environments.

Make no mistake, the comprehensive VirtualBox networking implementation is fully competitive with VMware. There is much more to the VirtualBox networking implementation available for download in the online user guide in section 6.

Sun xVM VirtualBox for Windows offers the capability to import VMware-based VMDK files into a virtual machine (VM), making a migration or cross-platform deployment quite enticing. VirtualBox 1.6.2 does not yet support the Open Virtual Machine Format (OVF) implementation; however, native handling of the VMDK files will suffice for most situations. Let’s go through importing a VMDK file for use in VirtualBox.

The critical tool in VirtualBox is the Virtual Disk Manager (VDM) for disk access. For most of us with a VMware-centric background, this will be a new concept. The VDM is a single tool where all virtual disks are inventoried. This can span multiple locations as well as multiple disk types - such as floppy, CD-ROM, and hard drives. Further, for the hard drive inventory, it is ubiquitous as to whether the disk is a VMware VMDK file or a VirtualBox VDI file. The figure below shows the VDM with an inventory of both VMDK and VDI files:

When a VM is created (or when modifying and existing VM), the drive inventory can be specified to create a new virtual disk or use a disk that is listed in the VDM inventory. By managing the virtual disks within the VDM, the VMs can pull directly from this inventory based on your configuration. The VDM can provide disks of all types from remote locations, such as a UNC path or a mapped drive.

There are a few important notes on the use of VMDK files within VirtualBox. First is that the snapshot functionality is not yet supported for VMDK files within VirtualBox. Second, if you intend to boot from the VMDK file, the VM may need boot device modifications. And lastly, the VMDK is modified when used by VirtualBox, so if you go back to using it with a VMware product, depending on what you have done to it - it may not be accessible. For non-boot drives, this should be a transparent exchange.

More information on the use of VMDK files within VirtualBox can be found in the online user guide for VirtualBox in section 5.4.

Desktop virtualization packages rely on snapshots and virtual drive functionality. The de facto functionality standard here is found in VMware Workstation and VMware Server, but the tools in Sun’s VirtualBox may be setting a new standard. Let’s take a quick look at how snapshots and virtual drives work within Sun xVM VirtualBox.

VirtualBox snapshot technology provides the same basic functionality as the VMware products in that they can be taken while the virtual machine (VM) is running or offline.  The snapshots are taken from two different places depending on the state of the VM. For a running VM, the snapshot is taken from the running console as shown in the figure below.

When a VM is powered off, snapshots may be taken in the properties of the VM. This difference is a slight inconvenience, but is an easy learning curve to overcome. Further, if a VM needs to revert to a saved snapshot, this same location is where the VM would be reverted. VirtualBox gives the option to build from the snapshots, so there can be multiple point-in-time restores for a single VM. Snapshots in VirtualBox are kept in the .VirtualBox\Machines\VMName\Snapshots location by default, and are a collection of .VDI and .SAV files. The figure below shows three point-in-time restores for a single VM:

As with all snapshot restores, you should be sure that you want to restore as the reverting process is authoritative to the VM. Reverting to a VirtualBox snapshot taken while the system is running reverts precisely to that point with the VM running, rather than a powered off state. Overall, the functionality inventory of VirtualBox snapshot functions as advertised and brings another positive view to this exciting virtualization platform.

More information on the VirtualBox 1.6.x product can be found in the online user guide.

In last week’s blog, I wrote about my first experiences with Sun’s xVM VirtualBox 1.6.2. I  like the interface and the features available to this free desktop virtualization product. Among these great options is one that lets users configure the VirtualBox server to view virtual machines remotely with VRDP, or VirtualBox Remote Desktop Protocol.

VRDP is a compatible implementation of Microsoft’s Remote Desktop Protocol (RDP) that is configured for easy console access to the guest platform from remote systems. This is different from a web-based interface that the competition has in that it is configurable per virtual machine. Let’s take a look at how to configure VRDP for a virtual machine in these steps below.

The first step is to enable VRDP, or remote console as it is called within the interface. By default, VRDP is disabled for all virtual machines and is enabled with a specified security method. The security methods are referred to as null, guest and external. The null method is a no-security model in that any VRDP connection will be accepted, and this configuration is documented by Sun as being designed for a testing and private network only configuration. To enable VRDP on a virtual machine, click on the settings tab while the virtual machine is powered off and configure the remote display option:

Once VRDP is configured, the virtual machine will accept connections the next time it starts. The tricky part is the port and IP address configuration. On default configurations, 3389 would be used for the VRDP session on the host. If your host is a Windows system and is running Remote Desktop, another port should be specified. VRDP can also remotely start the virtual machine with VboxHeadless headless command. Once the virtual machine is running, a connection is made to the host system running VirtualBox and the specified port if not 3389. This connection will provide the redirected console within a standard rdesktop or mstsc session, and will be at all states and regardless if the guest is using a network interface. In this configuration, an operating system could be installed and the virtual BIOS can be accessed as well as other tasks below the operating system.

More information on the VRDP implementation can be found in the VirtualBox online user manual from the VirtualBox community website in section 7.4.