Storage

Adding a remote datastore to VMware Server 2.0 beta

I have been evaluating the VMware Server 2.0 beta on Windows and CentOS Linux systems since the release in November of 2007. The second beta of Server 2.0 was released in March, and both versions support adding remote datastores for guest virtual machines. Adding datastores can be a great way to store your lesser priority virtual machines without immense storage requirements on your VMware server system.

I have used the 1.0x version of VMware Server for years in testing and development systems. With version 2.0, I have started to use remote datastores for storing test systems. Datastores are storage locales in VMware Server 2.0. You can add NFS datastores for Linux-based installations of VMware Server. The Microsoft networking server message block (SMB) is available for Windows versions.

From a performance and configuration perspective, a non-local datastore is not ideal for live production systems. For situations like mine where a large number of infrequently used virtual machines are used from VMware server, a remote slower-speed disk suits the need very well. This storage configuration may also be good for archival of certain virtual machines, such as a project build that has gone into support mode.

In my example, I used a network attached storage (NAS) device, which can provide some of the cheapest storage available. NAS default configurations usually provide Windows file and print as a native file-serving option. Adding datastores from the “add datastore” command in the web interface after the initial installation is straightforward:

Once this is done, a virtual machine can be added to the local inventory. When virtual machines run from a remote datastore, the disk I/O is executed on the remote system. Adding a remote datastore also puts the CPU, network and memory functions on the host locally. There is definitely a performance hit from this configuration. But for archival purposes, you can free up more capable storage for your most frequently used virtual machines.

Administrators should also note that the virtual machines must be updated before being visible in 2.0 from a remote datastore before you make a remote datastore for all of your existing servers running VMware Server 1.0x from your VMware Server 2.0 beta system. Once updated to virtual machine version 6.0, the 1.0x systems cannot use the guest virtual machines without being upgraded to VMware Server 2.0.

The following section illustrates how to add a virtual machine to the inventory after upgrading:

This can save time by possibly eliminating the need to copy large virtual machine files back and forth over your network.

Use VI3 maps to visualize storage distribution

You may not have used the maps feature within the VMware Infrastructure Client because large environments become difficult to decipher. The maps view has become an important part of visualizing certain elements of the overall configuration of an ESX environment. One of the more useful mapping views that can help to illustrate relationships is the virtual machine (VM) to datastore map. This shows how many virtual machines are contained in each datastore. It will also show the virtual machines that have connections in multiple datastores.

To use the maps view to show the correlation between VMs and datastores, select the maps button from the main toolbar and then deselect all options except “VM to Datastore”. Then select the datastores, hosts, clusters or resource pools you wish to have represented in the map. It is best to construct your diagram based on the storage configuration. So, if your storage is per datacenter, diagram from the datacenter level down. Once you click the “Apply Relationships” button, a map is drawn based on all of the datastores. You can zoom out of the map by pressing the “-“ key or [ctrl] and scroll on a wheeled mouse. Below is a sample map of a datacenter and the VMs connected to each datastore:

In this example, there are three datastores without a VM assigned within the map. This is the local datastore on the ESX servers in this environment. As a result, it can be quickly determined if a VM is on the local disk. Depending on the environment, locally stored VMs may be prohibited if you use VMotion or certain VMware DRS configurations. This visibility presents an opportunity to see the variance from your standards. For example, lets say I build an environment of Windows Server 2003 VMs with 32 GB of storage assigned. In this example the shared storage resources are in increments of 320 GB, making it so that 9 VMs comfortably fit in each logical unit number which then becomes the datastore through the fiber channel interface, while leaving room for snapshots or .ISO files. If I see a datastore with a very large number of VMs attached, I can easily assume that they are very small. Or, in the situation where a VM is connected to multiple datastores, I can look into why that’s the case if it isn’t the norm. The most common example of a VM attached to multiple datastores is a CD-ROM image mapping to an .ISO image.

VirtualCenter virtual machine removal best practices

Creating virtual machines (VMs) is quite easy, but how you remove them can make a big difference in storage space.

When removing a virtual machine, one popular method is to move the virtual machine to a resource pool with no assigned memory or processor resources. There are some concerns and strategies for doing this, however there are no virtual appliances or fully automated solutions within the VMware Infrastructure Client to help you with this process.

While moving the VM to a different resource pool is a convenient way to roll the system back online if necessary, the VM would still have its storage requirements. From an ongoing management perspective, storage is the biggest concern. I have found that using the local storage for the tentative decommission stage is acceptable in lieu of using the shared storage configurations across the other ESX hosts.

Once the virtual machines are in the resource pool with no assigned resources, you can then remove them on an interval that suits the ‘just in case’ situations. This can be a daily, weekly or monthly timeframe — whatever suits your environment and business needs. Of course, if the storage situation inhibits keeping these systems for long amounts of time, then the interval may be dynamic.

What are you doing from a matter of practice standpoint for the deletion of your virtual machines? Share your comments and ideas below.