Below is an article from this URL: http://4sysops.com/archives/seven-disadvantages-of-server-virtualization/
Below the article I will provide my rebuttal to this article and the article linked within. I feel as though there are several similar articles out there all claiming the same problems that can be solved with very simple Virtualization strategies.
1. Magnified physical failures
I find that this is a result of poor planning and insight into a virtual environment from the correct perspective. When designing a virtual environment, it is wise to abstract required components into modular assets which can independently fail. This modular approach should also allow for granular growth and reduction as needed. A simple idea, that must be carried through the entire design, from storage, to CPU, to ram, and networking, every component must be separate and independently scalable. As an example, the user describes the situation where a DAS (Direct Storage Array) volume fails. This is a common occurrence, and as such in enterprise environments, often disk arrays are abstracted out of the server platform to increase performance, and make it easier for a storage team to manage a central storage area network, or SAN. SANs used to be a very expensive proposition, but with the advent of ISCSI, and NFS it is very feasible to implement a very scalable and powerful SAN architecture using free opensource SAN software such as OpenFiler. VMware and other virtual server platforms allow the use of a SAN, which helps prevent the loss of a drive or raid solution for a group of virtual servers. This is an example of a way to abstract a resource in the virtual design, but using a SAN system files would not be lost as easily, and server failure could result in as small an outage as a virtual machine migration, or a reboot on another server as needed. Similarly, CPU and network resource should be isolated and presented as a resource to the virtual servers.
A real wold situation from a non-named company is the use of an Openfiler unit with 15 hard drives, powering an ESXi cluster with over ~200VMs with ISCSI over gigabit networking with two IBM x3650 M2s. The entire solution cost a measly 30 grand, and has been hauling in ROI almost since the day it powered on 2 years ago.
2. Degraded performance
This is a huge topic to attempt to discuss, with mud flinging in every direction. I will simply state that a VM SQL instance, which has the highest I/O and performance requirements in a general environment has AT MOST a 15% hit, and this is usually from the Storage Network. DAS or Raw LUN mappings tend to make up for this by allowing strong direct storage presentation to the Virtual Machine.
I would also remind readers that one of the large reasons virtualization came about, was that hardware was expanding in performance faster than code, and code writers could adapt to keep up and utilize existing hardware spaces.
If you feel performance is an issue for you, I would first step back and look at the virtualization platform you are attempting to apply a payload to, and then look at the resource that is being exhausted by that process.
3. New skills
Skill training is a cost with any business, and I will simply reply to this with the idea that the business should expect a cost with any architectural change, and should embrace the cost, and find savings were applicable. Virtualization is not a one size fits all solution. It is usually very easy to find savings in effort, time, and money, but with virtualization platforms like Xen, and free ESXi it is hard to ignore how easy it is to implement a virtual environment.
4. Complex root cause analysis
This being a point, causes me to look to the third issue and think it failed. There are many great logs, and system level diagnostics to help discover problems. In an absracted design, switching should be done entirely in the network fabric, this would involve trunking the ports that connect your virtual server into the network. This would allow you to gain raw network diagnostic information from your network gear. Even if you cannot afford the Cisco switches of choice, free alternatives such as Wireshark work great, and can help diagnose network problems.
5. New management tools
In the realm of management, there is no field with more growth. There are several companies working to provide management tools across the entire board for VMware, Xen, and other competitors. Depending on your skill level/time frame you may choose to jump into something more packaged like VMware, which does most of this work for you, or part together the elements for Xen and similar open source implementations. Money will be a constant issue when attempting to buy the right tools to get the job down, but if in doubt, stick with VMware as it has done most of the work.
6. Virtual machine sprawl
This is a problem when resources become available and a proper CTO enforced policy on server use is not created to enforce resource conservations across all fronts, virtualized or not. The count of VMs should not matter so long as the resources actually used are tracked and appropriate. Modular server packages are a great concept, and by separating the components to a solution it becomes easier to fix and recover from smaller issues.
7. Virtual habits
This is exactly the same as the above issue. A proper and enforced policy can solve this problem. There is no “bad” reason inherently from virtualizing everything. Every time a server is being virtualized it is important to consider the solution is it providing and whether a virtulation attempt is more disruptive than the benefits that could be provided.
What are you thoughts? Do you have these problems in your environment? Leave a comment below.
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.
I will discuss all seven downsides from my own perspective and share some of the experiences we have had with server virtualization.
1. Magnified physical failures
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.
2. Degraded performance
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 virtualzed 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.
3. New skills
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.
4. Complex root cause analysis
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.
5. New management tools
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.
6. Virtual machine sprawl
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.
7. Virtual habits
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?
