VMware Cloud Community
mldmld
Enthusiast
Enthusiast
Jump to solution

Rules to choose to install an application on a VM server or not

Hi all,

For our production team, I have to write a paper to sort

1. applications that can't run on a VM (5% of our apps)

2. applications that can run on a VM without pb (80 % of our apps)

3. application that need a study to decide (15% of our apps)

I did not find information of the limits in terms of disk IO/s. I notice only less than 10 VM / Lun VMFS. Our storage is EMC, HDS or NetApp.

This is what I already write, what do you think about it ?

1. App can't run on a VM if at least one of the following item is true :

\- Apps that need a specific hardware not supported by VM

\- Apps using N cores, where N is the total number of cores of the host

\- Apps using more than 80% of the RAM of the host

\- Apps using more than 85% of the resources of one core

\- Apps using more than 40% of the resources of a 100 Mb/s NIC

2. Should run on a VM if all of the following items are true

\- Apps using 1 core

\- Apps using less than 25% of the RAM of the host

\- Apps using less than 25% of the resources of one core

\- Apps using less than 15% of the resources of a 100 Mb/s NIC

3. Apps where a study is needed

\- All the apps that where not choosen in 1 or 2.

Thanks for your feedback and the rules you may apply in your company.

ML

Reply
0 Kudos
1 Solution

Accepted Solutions
Ken_Cline
Champion
Champion
Jump to solution

My recommendation is typically something like this:

\- If the application does not require specific hardware, virtualize it.

\- If you virtualize it and it doesn't perform "as well as expected", get quantitative measurements to PROVE that it's not working well enough

\- Work with the application team to remediate the problem in the VM

\- If all else fails, move it to a physical machine

A VM should be your first choice for hosting a workload. With VI-3, there are very few systems that CAN'T be virtualized. If you follow the process above, you will wind up with (typically) more than 90% of your systems virtualized - and for those that aren't on VMs, you'll have a much better understanding of the requirements of the application - because you have taken the time to WORK WITH the app owners to TRY to get it to work in a VM.

In your P2V efforts, start with the "low hanging fruit" and work your way up the tree. TRY everything you can - you may be surprised by what will work in a VM.

As for the application vendor supporting something in a VM...unless they can pull out a "validated systems list" that says "HP xxx / IBM xxx / DELL xxx" and not just "Windows 2003 / 2Ghz / 2GB", then they'd better not give me any grief because they don't have a leg to stand on.

You should always have a plan and a tool/process to enable you to migrate a VM to a physical box. This may be necessary due to performance reasons or because of support requirements (hey, if the problem is bad enough, your SW vendor has the right to ask you to try a different HW platform...after they've invested significant effort into trying to resolve via other means).

Just my $0.02...

KLC

Ken Cline VMware vExpert 2009 VMware Communities User Moderator Blogging at: http://KensVirtualReality.wordpress.com/

View solution in original post

Reply
0 Kudos
14 Replies
bister
Expert
Expert
Jump to solution

We have not written down these parameters in detail, but we basically follow them in such a way.

Reply
0 Kudos
juchestyle
Commander
Commander
Jump to solution

You know, everywhere I look I see organizations trying to setup rules for everyone to follow. I think a lot of organizations want to make rules for everything to make up for the lack of good communication or lack of great team work.

For example I heard on NPR this morning that local government wants to pass a bill requiring climbers of Mt. Hood to carry with them GPS units.

On the surface it sounds like a great idea. It would in theory save lives. In reality there might be a lot of careless people who grab a GPS and think they are superman, wonder off without a care in the world, no proper planning, no research on the weather etc. Then there is the arguement that I subscribe to, the government should not be allowed to make rule after rule on everything in our lives.

Back to the subject at hand. There is no substitute for good team work, there is no substitute for great communication. Level setting knowledge is one of the most important and most missed aspect of most organizations.

My belief is that you should work together on this as a team. In the beginning there will be effort required to make good decisions. But if you work together on this project, in the long run everyone will have a better understanding of what is, and what isn't possible.

An added benefit to my approach is that the more you work with your teams the less opportunity there will be for wrong assumptions on all accounts. If they are staring a document in some room somewhere it is possible for them to start bad mouthing vmware, you or anything else and you would never know about it. Get in the trenches with them and fight through it. Everyone will be better off in the end, and you will have a win win scenario.

Respectfully,

Kaizen!
Reply
0 Kudos
bister
Expert
Expert
Jump to solution

Nice story with the GPS units. Sounds familiar. Do you live in Germany!? Oh no, USA Smiley Wink

But wouldn't you agree that having some general rules will make work easier as you do not have to argue every single machine you want to install?

Respectfully,

Christian

Reply
0 Kudos
mldmld
Enthusiast
Enthusiast
Jump to solution

I agree with your story about , rules can't solve everything !

I work for and with production team Smiley Happy

But they need guidelines to be able to deploy apps in less than one day.

And one of my objectives is to give them the ability to deploy in few clicks using Altiris

\- an ESX server

\- a VM

\- a physical server

We use altiris instead of VM templates because, the deployment method will be the same for virtual and physical servers

So my question is still unanswered ....

ML

Reply
0 Kudos
juchestyle
Commander
Commander
Jump to solution

Yes. Communicate them during your first meeting! :{) Re-itterate on your second meeting, third, and so on.

Respectfully,

Matthew

Kaizen!
Reply
0 Kudos
bister
Expert
Expert
Jump to solution

I fully agree. Communication is vital. IMO some base guidlines/rules too. In our process of implementing ESX this also an issue. But it's hard to find general limits which you can write down and upon which you can make the mentioned 3 pools of servers. But still it's good to have some numbers you can argue with.

Respectfully,

Christian

Reply
0 Kudos
juchestyle
Commander
Commander
Jump to solution

Hey Christian,

Yes, you are right!

Some guidelines that stand out:

1. Is the app supported by the vendor in vmware

2. Is the app processor intensive

3. Does it require special hardware

4. Where does the app fall on the Disaster Recovery list

5. What are the requirements of the app

The last one, 5, is important to think about because we have found that vendors like to crank up their expectations. Many applications we have found work really well on vm with less than what the vendor asks for.

Maybe another lesson to take away is to review your decisions after implementation and discuss the expectations and how they were met and or not met and why.

Respectfully,

Kaizen!
Reply
0 Kudos
bister
Expert
Expert
Jump to solution

Matthew,

thanx for your reply. We also have these points on our GO/NOGO list. And what I want to add to 5 is: If it doesn't work or perform well: When will we go on bare-metal? This has to be clear before starting, all involved parties need to agree a plan-b.

And I also agree that feedback from the customer is very important.

Regards,

Christian

Reply
0 Kudos
juchestyle
Commander
Commander
Jump to solution

Christian,

You are on the ball! My hat is off to you and your team. Understanding when to abandon ship is smart because without that kind of plan, emotion and fear can create motivate decisions without good understanding.

They say that when you start a business, you should have an exit strategy too! So I really like that contribution.

Let me throw something else out there as well. We just recently ran into a situation where an application had to be on a vlan that was only capable of 100mb. The network slowed the app downloads and uploads.

Think about your network infrastructure, how good it is, how consistent it is, and the throughput speeds you get.

Respectfully,

Kaizen!
Reply
0 Kudos
Ken_Cline
Champion
Champion
Jump to solution

My recommendation is typically something like this:

\- If the application does not require specific hardware, virtualize it.

\- If you virtualize it and it doesn't perform "as well as expected", get quantitative measurements to PROVE that it's not working well enough

\- Work with the application team to remediate the problem in the VM

\- If all else fails, move it to a physical machine

A VM should be your first choice for hosting a workload. With VI-3, there are very few systems that CAN'T be virtualized. If you follow the process above, you will wind up with (typically) more than 90% of your systems virtualized - and for those that aren't on VMs, you'll have a much better understanding of the requirements of the application - because you have taken the time to WORK WITH the app owners to TRY to get it to work in a VM.

In your P2V efforts, start with the "low hanging fruit" and work your way up the tree. TRY everything you can - you may be surprised by what will work in a VM.

As for the application vendor supporting something in a VM...unless they can pull out a "validated systems list" that says "HP xxx / IBM xxx / DELL xxx" and not just "Windows 2003 / 2Ghz / 2GB", then they'd better not give me any grief because they don't have a leg to stand on.

You should always have a plan and a tool/process to enable you to migrate a VM to a physical box. This may be necessary due to performance reasons or because of support requirements (hey, if the problem is bad enough, your SW vendor has the right to ask you to try a different HW platform...after they've invested significant effort into trying to resolve via other means).

Just my $0.02...

KLC

Ken Cline VMware vExpert 2009 VMware Communities User Moderator Blogging at: http://KensVirtualReality.wordpress.com/
Reply
0 Kudos
Rob_Bohmann1
Expert
Expert
Jump to solution

I agree with juchestyle and ken.cline's comments specifically and the point of communicating and having a plan if something does not work as expected.

I would be careful or using the word "rules" and use something a little more flexible like guidelines. Some individuals who will not want to run virtual will look for loopholes, etc and use that to disqualify a system to run or try to create a requirement just so they do not run virtual.. (then the system runs at 10% generally).

Ones of our guidelines is that every new system starts as a VM unless we agree that for a small number of reasons(specific pre-approved apps, dmz's where we do not have vmware...yet, ) it should run on a physical system (maybe 10-15 % of new systems going in). When the app team/users/and us demonstrate that their server/app cannot run successfully on VMware, then we look at hardware. Its amazing that of all the people who insist that they need a physical box, we only get to measuring performance and load on a handful after they've been handed a vm server.

We also have the ability to V-P so the app team does not have to reinstall their app, if it is determined that you want to run on a physical box.

bister
Expert
Expert
Jump to solution

Agreed. Also to juchestyle's and ken's comments. Glad to see others have to deal with the same questions/problems and answer them in a similar way!

Reply
0 Kudos
juchestyle
Commander
Commander
Jump to solution

I really like what Ken and Rob articulated above.

I have known people who are in charge of vmware at their organizations. And often times I see individuals who can tell you a rule but can't tell you why the rule makes sense or what drives a rule. Those people make decisions across the board that don't apply to every situation, and they do this because they haven't dug into the reasons well enough to understand.

I don't like rules; now guidelines however are a great place to DIVE into the manual and know what drives our decisions.

I think what all of us are trying to say is: Get the right people on the bus and then get those people to work as a team to test, to learn and to propose good solutions after doing their research. Then learn from it and spread the knowledge to all parties involved.

Respectfully,

Kaizen!
Reply
0 Kudos
VTorque
Contributor
Contributor
Jump to solution

Some thought provoking replies here .. I like it!

my 2c:

.. sometimes it is more important to know why NOT to do something, rather than why TO do something..

Still a rule I guess.

Reply
0 Kudos