Networkworld recently published an interesting article entitled “7 side effects of sloppy virtualization”. This title seems to indicate that the problems server virtualization might cause are solvable by being well prepared. Nevertheless, all seven arguments discussed can be considered disadvantages of server virtualization. Because I am seriously thinking of virtualizing all of our servers, I read the article with interest. So far, we have only four virtual servers with about fifteen virtual machines, but we have already encountered some of the problems mentioned in the article.
Michael Pietroforte is the founder and editor in chief of 4sysops. He has more than 35 years of experience in IT management and system administration.
Latest posts by Michael Pietroforte(see all)
I will discuss all seven downsides from my own perspective and share some of the experiences we have had with server virtualization.
Imagine you have ten important servers running on one physical host and its RAID controller runs amok, wiping out all of your hard disks. Don’t say that this is not very likely, as we have already had two or three incidents from malfunctioning RAID controllers from well-known brands.
There are several ways to compensate for this downside. One is clustering, which certainly entails extra efforts. Another answer is to backup the virtual machines with a CDP (Continuous Data Protection) solution. If your physical server goes down, it is possible to restore all VMs quickly to another host. This solution implies that you have enough capacity left on another host. Thus, if your virtual infrastructure is well planned, physical failures may be less problematic. However, this means that you have to invest in redundant hardware, which more or less eliminates one of the alleged advantages of server virtualization.
There is no doubt that virtualization requires extra hardware resources. The problem is that it is almost impossible to estimate in advance how many extra resources will be needed. I know that there are capacity planning guides and tools but from my experience every piece of software behaves differently in a virtualized environment. We have applications that are quite modest as long as they run on a physical server, but when they were virtualized their resource requirement multiplied.
You can’t do much if you have such applications. In our case, we had no choice but leave them on physical servers. Hence, the only solution to this problem is to thoroughly test each application with the virtualization solution of your choice.
It sounds so easy - install a virtualization solution and then just deploy your servers as you are used to. Not really! Many things are different in a virtual environment. I will give you just one example. When we installed our first server virtualization solution, I instructed our administrators to test some of their servers in the virtual environment. After a week or so, an administrator told me that he could not test his server because there was no more RAM available on the host. I was quite surprised, as this server has enough capacity for 10 VMs.
When I logged on, only 3 VMs were actually running. What happened? Some of his fellow administrators had assigned the same amount of RAM to the virtual servers as their physical servers had required. It took me quite some time to convince them to change their working habits. When you buy a new physical server, it is common practice to equip this server with as much memory as your budget allows. This makes sense, as it takes time to order new memory modules and add them to the server. Even if you do not require it now, you will most likely require more RAM very soon.
Of course, this situation is different in a virtual environment. I assign blame to myself, as we should have discussed things in advance. I should have told the administrators that they first need to figure out how much RAM their servers really need using a performance monitoring tool. If their server requires more RAM later, it is not a big deal to assign more. I chose this simple example because it demonstrates that you have to do some rethinking when you work in a virtual environment. The fact that several administrators share one physical server causes problems that didn’t previously exist. Of course, it is also necessary to acquire many new technical skills.
Virtualizing a server certainly implies big changes to the whole system. A new layer of complexity is added and can cause new problems. However, the main difficulty is that if something doesn’t work as it is supposed to, it can require considerable extra efforts to find the cause of the problem. I have another example for this downside of server virtualization.
We installed a SUSE Linux server under Virtual Server 2005. Everything worked fine at first. But, then the admin reported that his SSH sessions often got disconnected. We had another Linux machine running on the same host which didn’t show this behavior, so we thought it must be a configuration problem on the Linux system. However, this skilled Linux administrator wasn’t able to find the problem’s cause. I then had the idea to move this virtual machine to another Virtual Server host - and the problem was gone. So did Virtual Server or Linux cause the problem? Well, I can’t tell you. We never figured it out.
Virtualization also has advantages, such as easier migration, cloning or snapshots. However, you can only take advantage of these new capabilities if you have the proper tools. Often, the tools that come with a virtualization solution are not enough, only supporting basic management tasks. This means that you need additional utilities, which cost both money and time. I am not only talking about such tools as VMware Virtual Center or Microsoft Virtual Machine Manager (VMM).
Another important field is backup, or more precisely, disaster recovery. Of course, you can use your current backup software to secure your virtualized servers. However, one of the advantages of server virtualization is that disaster recovery becomes much easier and faster provided you have a backup solution that is able to perform live backups of the virtual machines and not just of the virtualized servers running in these VMs.
The problem lies in that there are no real standards when it comes to virtual server management. But, there are standards for server management in general. For example, there are many backup tools that allow you to secure your Windows, UNIX and Mac machines, but it is difficult to find a disaster recovery solution that supports all the various virtualization solutions out there. All in all, this means that your zoo of management tools will grow, meaning more work for you.
Even though virtual server management can get quite complex, installing a new virtual machine is a piece of cake. You need a new server? Just clone your master image to a new VM and you are done within a few seconds. The problem is that the number of servers might grow faster than the number of admins who are supposed to manage them. It is good that even virtual servers have physical limits. As soon as you reach the limit of your virtual capacity, the virtual machine sprawl will naturally stop.
The number of servers in my department has grown significantly since we started working with server virtualization. As a matter of fact, quite a few of them exist only because it is so easy to create them in a virtual environment. Thus, you have to be very careful that you don’t waste the resources of virtual server hosts with unneeded virtual machines.
I am not sure if I understand this argument in the Networkworld article:
Once IT organizations start to use virtualization, they can't stop themselves, Coyle said.
Coyle is the Gartner analyst who is the source of the insights in the Networkworld article. He makes it sound like virtualization is a kind of addictive drug. Perhaps he meant that organizations that discovered the values of virtualization are prone to introducing virtualization technology in areas where it is better they stay physical. I also see this danger, and it is difficult to give advice on this subject. Sure, there are some general rules, such as don’t virtualize servers that have unpredictable resource requirements. However, I think that virtualization often causes problems in unforeseeable situations. Coyle gives the only possible advice here: “test, test, test.”
What are your experiences with server virtualization? Do you think that the downsides outweigh the benefits?
Articles in this series: