Networking

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.

VLAN tagging for ESX virtual machines: Making the case

VLAN trunking, or tagging, is a powerful feature that allows ESX virtual machines to connect to multiple networks. However, your network team may not want to enable that. In fact, I have come across many situations where trunking is not done to servers, but only to switches for VLAN availability. To break that mold, we have to start with education on the VMware networking technologies.

Most of us are not network admins as well as virtualization admins, so we have to start with some good resources to “get what we want.” Without VLAN trunking, each VLAN you would want to connect to would require its own physical interface. That clearly is a growth and agility inhibitor as well as incredibly expensive for additional cable runs and interfaces on your ESX servers. Quoting Andrew Kutz, “that makes ESX practically worthless.” So I am on a mission to turn the tide. There is a good resource online from VMworld 2006 that explains the ESX networking so that we can inform ourselves, and better integrate with our network staff to ensure all standards are met.

With networking, configuration consistency among ESX servers becomes absolutely critical (as is with other areas of VI3). It is important to deliver the ESX configuration as planned, as if there is a variation and an outage or other networking issue, there may be a swift change of heart from your networking staff.

Readers, I invite you to share your experiences with making the case for trunking below with a comment.

Use disconnected network adapters for build and stage: Save yourself

In VMware ESX, you can configure a guest operating system to have its network adapter disconnected at power on. This is critically important for a phase of a physical to virtual (P2V) migration where the system is migrated yet there are some offline tasks to be done. This can also be during a build before you go live. This configuration will present the virtual hardware inventory to the guest operating system - but it will appear as if the cable were unplugged. In this situation, you can configure all of your IP addressing (though you could not test it), DNS information, and other environment factors entirely offline of your network. Should you need some files or other access, a CD-ROM image would be a good way to prep up the system. I use the term “Stage Configure” for a virtual machine that is being prepped for prime time, and when I am complete with the configuration the option is reverted back to connect at power on (the default). This would include computer names, network configuration, services management for Windows systems, some benchmarks on performance, as well as any other local configuration elements.

To configure a virtual machine to not have its network connected at power-on, edit the settings of a virtual machine and deselect the option as shown in the figure below:

Once you are done with your staging configuration, power off the virtual machine and change the option back to connecting at power on.

Extra Step in Protection

With VMware ESX, it is simply too easy to accidentally cause conflicts that may arise from having a candidate virtual machine on the network too early and performing its intended tasks. Errors can be a duplicate IP address, the application on the virtual machine picking up data simultaneously as the live system, formatting issues from a newer version of a business system feeding results to another system, and many other situations.