For large enterprises, managing server I/O can be cumbersome. Additional connectivity such as peripherals, license keys, specialized system components and extra network connectivity can make virtualization overly complicated or impossible. Here are some strategies I have employed to increase the agility in the virtual environment while delivering the required functionality.
The No. 1 trick in the playbook here is to enable virtual LAN (VLAN) trunking or tagging. By implementing the IEEE 802.1Q tagging of networks to a virtual host system, the required cabling footprint is reduced. For example, with a pair of 1GB Ethernet cables to a virtual host server, you can have access to many networks that would be presented to the virtual machine (VM). This will save incredible amounts of money on ports, cabling and accessory cards to the virtual host systems as the environment scales upward. Having this agility enables a virtualization implementation to reach full potential. Be cautioned that in implementing tagging, the VMs assigned to those networks are now all sharing the same physical interfaces on the host system.
A common practice is to allocate two or more 1 GB interfaces to host all network connections. This provides redundancy in case of a cable or switch port becoming unavailable and also provides an effective 2 GB of connectivity depending on how the networking is configured. Computing that to the number of virtual machines on the host system, determine if that is sufficient bandwidth for the number of systems on the host.
Blade servers for virtual environments present an expanded set of networking virtualization opportunities in that the networking components provide traditional physical switch management in the blade chassis through Cisco-branded devices and other products. The HP Virtual Connect architecture is versatile storage and networking virtualization product for HP BladeSystem products as well.
Virtualization of peripheral I/O
Traditional peripheral connectivity such as serial and USB connections can be virtualized with the use of an extra piece of equipment. While most system administrators frown upon serial or USB devices directly connected to servers, some software platforms and connectivity requirements do not have any other options. Specific examples are Ethernet-attached device servers. These units will extend traditional USB, RS-232, RS-422 or RS-485 ports from the server over the Ethernet network, meaning that the devices are not in the virtual machine inventory yet available from the device and vendor driver. These units work over TCP/IP or proprietary MAC address protocols. The space for these products is quite broad with the largest players being Digi, Comtrol and Avocent all having devices in this space. USB connectivity over Ethernet is a little less common as there are a fewer devices available, however.
I recently installed a USB device server for a Windows Server-based virtual server that required a USB license key. The device selected was a Digi AnywhereUSB controller. This device has five USB ports available to the virtual machine over Ethernet. Once the device was configured, the USB ports were visible in the Windows device manager. The AnywhereUSB controller has a tool that shows the ports and devices connected to the server:
Ethernet-attached serial ports are also available. This can extend special connectivity to industrial equipment, management interfaces and other devices that have a serial port for communication or management. These devices function in a similar way in that the serial ports are also extended over the Ethernet network. Below is a screenshot of using the Comtrol DeviceMaster RTS unit for RS-422 serial ports available to a virtual machine:
Having these devices extended over the network, virtualization management technologies will still be able to migrate virtual machines to another host. Keep in mind that in the case of virtualized peripheral I/O, a direct attached port (USB controller or serial port) will always perform better and are more reliable than one extended over Ethernet with these devices. Depending on the criticality of the ports to the server, this may affect the virtualization candidacy.
Standard storage virtualization and de-duplication
For organizations that have separate groups or individuals who manage storage, the use of a storage virtualization solution can simplify connectivity and management. For example, when using an IBM SAN Volume Controller (SVC), all of the storage devices are managed centrally through the SVC and the virtualization host system communicates only to the SVC. The SVC does the work of managing the drives across all of the various storage systems and their performance levels, while keeping it all transparent to the virtualization host. Many of the actual storage arrays can be connected directly to the virtualization host system, but that increases the management overhead for the virtual environment. If you have a storage group, let them manage it.
Data de-duplication in the storage area continues to develop as an opportunity for organizations who manage the virtual environment and storage environments within the same group. This can save on storage I/O connections from the controller level as well as overall drive storage requirements.
The biggest I/O virtualization technology for virtualized systems on the roadmap is Fibre Channel over Ethernet (FCoE). FCoE will consolidate fibre channel storage traffic and Ethernet networking over a single 10 GB connection. This could introduce a whole category of management issues for the traffic being shared across virtualization, storage and networking teams.
I/O virtualization will be an ongoing focus as most of the low hanging fruit systems have been addressed with standard practices. Systems that will either be migrated or updated to virtual platforms with unique I/O considerations will require a fine pass at the configuration and performance expectations with virtualized I/O.
(Thanks to Travis Cole at Dematic Corp for contributing the screenshots from the Comtrol products to this article.)
About the author: Rick Vanover is an MCSA-certified system administrator for Belron US in Columbus, Ohio. Rick has been working with information technology for over 10 years and with virtualization technologies for over seven years.