Gaining Virtual V-locity

The main story for this week’s GCN Lab reviews is all about RAID Network Attached Storage appliances. These were tested for speed and ease-of-use with both large and small files. However, even though we looked at cutting edge NAS devices, the whole concept of storage (and just about everything else) as we know it is changing with the introduction of virtualization.

In this GCN Lab comparison report:

NAS appliances cover the middle ground of extra storage
What Is A RAID?
A breakdown on common RAID configurations
Buffalo TeraStation III
LaCie 5big Network
Sans Digital EliteNAS
Seagate BlackArmor NAS 440
WD ShareSpace

In a virtualized environment like Microsoft’s 64-bit Hyper-V, computers are assigned roles as either a host or guest. Hosts are basically consolidated groups of servers using a shared resource, where as clients are guests. You can think of the entire virtual network a bit like a communal farm, with programs sitting on the host that can be used equally by the clients. So you may only need one copy of Word in the host environment for all of the guests for example. This saves resources and consolidates hardware.

This seems to be the way that many government agencies are moving. But there are some disadvantages, not unlike the communal farm. The biggest disadvantage is that the virtual machines created by this system have limited knowledge of their true hardware resources. So a virtual machine that is running a virus scan or cleaning up a database is actually pulling away a lot of processing power from the same host that is trying to serve programs to other virtual machines. A virtual machine doesn’t know that it’s actually virtual, and sharing space with other systems pulling from the same resources. In the GCN test lab, we have been easily able to bring our test host down by running too many background processes, because they all add up to stress the real hardware.

The second problem is that there is no way to reliably defragment the drives running on virtual machines. This causes more disk access, which in a shared system can add up to poor performance once it’s again all added together. More I/O reads from multiple virtual machines will stress the real hardware.

Finally, we realized that when we set virtual disks in our test environment of a Windows 2008 Server with Hyper-V to grow dynamically as needed, that they didn’t shrink back down when space is no longer needed. If the drive expands by 200G to accommodate new files that are later removed, the space remains expanded, which prevents it from use by other virtual machines that may need it.

Believe it or not, we found a product that fixes all of these problems on our Hyper-V test system. Called V-locity, it turned out to be extremely useful without being too much of a burden in terms of IT resources.

You have to install V-locity on each host and guest computer, which can be a little bit of a pain, but is well worth it. Once that is done, the V-locity program will look at all of the virtual machines running within the system and optimize them. It will defragment files within the virtual machines and even consolidate space to just what is needed.

The interface to do this is extremely intuitive. In fact, it looks a lot like the standard Diskeeper defragmentation program that we’ve run on clients and normal servers in the past. Even the top level toolbar looks the same. So it’s not that hard to figure out, even though you can (and need to) do a lot more to keep your virtual systems up to speed.

Optimizing the virtual machines works pretty much like a normal disk defrag. The time it takes to accomplish this depends on the speed of the host and guests, and how many are active at the same time.

As a bonus, V-locity will find unneeded space in the virtual machines and reassign it as being empty, which can shrink the real footprint of a virtual system exponentially depending on how complex a setup you have. Our test system is fairly small, but even so, over 205G of space was freed up with V-locity. The one negative to doing this is that you can’t mount the .vhd file (so you can’t use that virtual drive) when it’s being compacted, though you can halt the process if you suddenly need that machine. Depending on the size of the drive, this can take a very long time, so you should probably only compact at night or even over the weekend when nobody needs the system.

However, most of the time V-locity is able to use a technology called InvisiTasking to figure out when to run without getting in the way, with the compacting process the only exception. But remember the problem with background processes killing our virtual machines? It didn’t happen with V-locity. The program evaluated CPU, memory and even hardware bottlenecks throughout our test network and only allowed background processes to run during times when those resources were unused. We ran V-locity and then a bunch of other frontline processes, and the defrag process simply backed off and eventually stopped as system use climbed. So it never got in the way.

The truth is that even with virtualization, you are still going to run into some of the same technical problems you do with normal servers and clients. Disk clutter will eventually slow even the virtual space. V-locity helped keep our testbed running like new and should be considered a useful if not necessary part of any large scale virtualization installation.

Diskeeper Corp., 800-829-6468, www.diskeeper.com