disable balloon driver

[phillbl]

Hi,

we are going to be virtualizing some citrix servers. I had read many articles & they all say "disable the balloon driver during vmtools installation" during thecustom installation i cant find anything to do with a balloon driver. i have found something else that explains that you should disable this through the VI client > guest os etc but this is for the host.

is it possible to do this throught the VM tools to so that it only disables ballooning on the vm?

thanks

[kjb007]

While it is possible to adjust ballooning so that it does not take place for virtual machines, you have to remember that ballooning only kicks in when there is contention for memory. This would occur if you were oversubscribing the memory that you had available to you. In that case, if some vm's were using memory, and the esx server ran out, it would balloon into the vm's that were not using their allocated memory, and reclaim some memory for other vm's.

-KjB

[atbnet]

Im intrested in your reasons for virtualizing citrix servers?

I have heard alot of people say the performace is very poor running citrix in VMs, though depends on how much load is on each presentation server.

After all citrix is application virtualization so to what Nth degree does it need taking to?

We keep our citrix server physical on 20 blades to ensure performance in users apps are the best possible.

Andy, VMware Certified Professional (VCP),

If you found this information useful please award points using the buttons at the top of the page accordingly.

[Selekta · Accepted solution]

I strongly agree with the above two posts and do not recommend disabling the balloon driver on any VM's! But if you must here is the procedure for doing it.

:

Connect directly to the ESX Server host where the virtual machine resides on, using Virtual Infrastructure Client (VI Client).

- Shut down the virtual machine.

- Right-click on the virtual machine listed on the Inventory panel and click Edit Settings.

- Click the Options tab and select General.

- Click Configuration Parameters.

- Click Add row and add the parameter sched.mem.maxmemctl in the text box.

- Click on the row next to it and add 0 in the text box.

- Click OK to save changes.

If this answer was helpful please consider rewarding points.

[kjb007]

The typical reasons for using separate windows machines applies to Citrix as well, not all apps live/play nicely together. That holds true for apps in a citrix farm as well. Citrix is also not the best at scaling up, and scales better horizontally. For that reason, you can do well by scaling a Citrix farm horizontally, and have several to perform the tasks that Citrix performs well. What I've found as others have found, is that Citrix performs better as 4x1 vCPU servers as opposed to a 1x4 vCPU. Not all citrix environments are created equally, and not all apps can be virtualized, but that tends to be the exception, and not the rule.

-KjB

[wilson94t]

>ballooning only kicks in when there is a contention for memory...

That is the way it is supposed to work, but I will tell you that it is not exactly the case. I don't know exactly what the algorithm is, but it seems to do this based on a percentage of memory free. As the ESX servers get larger (hundreds of gigs of ram), the amount of memory which is free at the time of ballooning also gets larger. I am quite certain that ballooning happens prematurely on my larger systems as there is sufficient free ram on those servers to handle the memory requirements without the balloon. Still, there it is in the performance log - ballooning.

i would recommend disabling ballooning any time that you require a burst of memory on a VM. Citrix/Terminal Servers servers are a good example where this need exists, which is why they are often mentioned.

[dconvery]

Balooning is the second line of action for dealing with memory contention. The first is transparent page sharing. The third is swapping to disk. If you go through a proper course of plan, assess, design, implement manage operate....The first thing is plan your environment, the seond is asess. Assess the performance metrics, like CPU and memory utilization. As you design your systems, and implement them, you should not be overcommitting anything for a production environment. Then, as you manage and operate your infrastructure, you manage growth so that you add hosts as needed to avoid overcommitting resources.

Dave Convery

VMware vExpert 2009

Careful. We don't want to learn from this.

Bill Watterson, "Calvin and Hobbes"

[wilson94t]

I can see why one might want to take that approach. Keep in mind that not everyone has the luxury of using a performance first as a method for implementing production. When dealing with an environment thousands of virtual machines, the costs can be determined in many ways, including cost avoidance.

Running citrix in a VM may not be as fast as physical. it may require a few more seconds per user to start the application, however, how much are those users paid? How much does it cost to maintain each floor tile across datacenters? In our calculation, it's cheaper to waste a few seconds as compared to racking more hardware. I need to be dense.

Making use of page sharing? You bet. ESX is a leader for that technology. I want it, I need it. Without it i may as well go use some other virtualization product which would be cheaper. Sure other products have started to do this, but none as well. Swapping, however (be it ballooning or VM swap... remember ballooning causes swap within the VM), however is where I draw the line. Adjusting the VM's so that memory stays off the disk is essential to me.

I'm expecting that most don't have as many VM's to deal with as I do, some may have more.

Bottom line is, if performance were the only thing we cared about, we'd all refresh our hardware each year. Fact is, that's not the case. Costs matter. I'm dealing system configurations in the millions of dollars. If i did not allow page sharing, my environment costs could go up 1 million. I allow a very small amount of ballooning on each cluster, i try to ride that line as close as possible. There are some VM's where I can not afford the balloon cost, there are some others where it is less of an issue.

The ability to "tweak" is more than just finding out how fast we can make a VM. It has to do with tweaking performance across specific machines, knowing the environment to understand how fast something NEEDS to be, rather than how fast it could be, and just how much I/O utilization your system has.

Memory overcommit in terms of transparent page sharing is fantastic, and something I recommend & do in all my environments, including production. I run thousands of VM's this way and it's well worth the money.

[dconvery]

First, I know i relied to you, but my initial comments were directed at everyone...but I wanted to reply some of your statements.

You have thousands of VMs, so you have a "feel" for the performance and where you want to be. You are in the manage and operate stages of the game. With that many VMs, you should know what your "breaking points" (when to deploy a new host) are. I didn't say anything was wrong with TPS, or even balooning and swapping. They all have their places in virtual environments. And, yes, TPS is a big bonus of Vmware.

But, you need to start somewhere. If you do not assess performance in some way, even if it is with the stripped down assessment tool that comes with vCenter, you need a baseline so that you know how many hosts you need. In the past few years, I have been involved with many implementations..from the hundreds of servers to the thousands. From experience, the ones that keep the assess stage realize a better ROI than those that do not. If you SWAG things, without proper planning and assessment, you could come up with a design that results in poor performance and find that more hosts are needed. It is easier to ask for things once than to come back to the well and ask for more.

Conversely, if you know your environment AND you know how virtualization can change things, then you might be able to get away with a SWAG. I have been doing this long enough that I start with a SWAG for the planning, but follow up with an assessment to verify my planning.

Dave Convery

VMware vExpert 2009

http://www.dailyhypervisor.com

Careful. We don't want to learn from this.

Bill Watterson, "Calvin and Hobbes"

[wilson94t]

you should not be overcommitting anything for a production environment.

Then, as you manage and operate your infrastructure, you manage growth

so that you add hosts as needed to avoid overcommitting resources.

I suppose i became a bit too hung up on this statement. I planned to overcommit and make use of TPS from the begining, as part of my ROI and density requirements. So while I will endorse staying away from swap, I would also suggest that i see no problem planning to overcommit by use of TPS, assuming the admin understands how to properly scale an environment that plans to make use of TPS.

RE: your comments on SWAG, I agree completely. I feel comfortable with the SWAG plan here, but we constantly tune in order to stay ahead of the curve as the VM's come in. We could have as little as a dozen or as many as hundreds come in during the course of one week, so there's really no getting around the tuning.

[dconvery]

I understand what you meant as well. If you understand the implications overcommitting resources and can manage that, then it is fine. The hit with TPS is negligable. The hit from balooning is huge. It sounded to me like the original post was from someone in the planning stages without enough experience to manage overcommitting resources. Like you said, the small bit of time added and the slight performance hit may be acceptable when you consider the ROI differences. I just hear too many times that things are performing badly and it all falls down to not understanding how to do what you are doing.

Dave Convery

VMware vExpert 2009

Careful. We don't want to learn from this.

Bill Watterson, "Calvin and Hobbes"

[RJC75]

I just wanted to put my 2 cents in as to why?

2 years ago we had 12 physical 2650's running heavy financial applications (140 users) . One apps in particular took 50% for running a report /per user and I was not allowed to cap the threshold. That means 25% on a dual core, when 4 or more people use to ran these reports simultaniously, the physical server hung up and would need rebooting through the drac.

Since VMware, we now have 22 Citrix servers with 2vCPUs and 2500RAM (290 Users) averaging more users per server before the change. Citrix. Scaled out, not up. Our servers have never hung since...

With 97% of our environment on Virtual, I can honestly say that if our heavy processor intensive apps run well with Citrix on Vmware, I don't see how anyone else would have a problem unless they have really bad hardware. As for ballooning, I try and benchmark my memory and then allocate it so it doesn't invoke. When it does, I move the boundry.

RJC75

CCEA, VCP

[MattS101]

Actually, it is NOT true that ballooning only happens when there is contention.  I am trying to disable it because I have a machine that is screwing up and keeps ballooning.

I have a 4 node ESX cluster.  Each host is a quad core quad processor (16 core total) system with 128 Gig of memory.  I shuffled this one machine onto it's own host with no other active machines.  It is had 8 gig of memory assigned to it.  Shortly after someone logs into the machine, the memory starts climbing from 2 gig to 6 gig and VMWare shows that the increase is from ballooning.  Since there are no other systems on this host and there is over 120 Gig of memory free, then it should not be ballooning, yet it is.

[Alceryes]

I am a total novice with ESXi. Especially the more advanced functionalities.

I seem to remember though reading something about this 'rogue ballooning' happening because the guest is part of a high availability and/or fault tolerance cluster(?) ...something about guaranteeing its ability to move between nodes.

Not sure if this is way off base or not - just a thought.