Special CPU reservation setting for vRanger

[dwchan]

We are using vizioncore vranger for our vmware backup (latest version). Accordig to vizioncore tech, they say that we should increase our system reservation setting to like 1200 to 1500 MHZ, has anyone else done this in their environment? They also recommending increase the default console memory allocation to like 800 MB, seem like a waste of memory resource. Just want to check with the group and see if anyone done this and if this really help in term of performance and fixes fail backup

[RParker]

Well I don't see how a reservation for CPU would make a difference personally, but they may have tested it and it may make a difference. As far the console memory goes, that does seem like a waste considering vRanger doesn't need the console, it runs remote. Console memory is for actually installations that take place on the ESX host. I have experiment with high/low console memory and I don't notice anything different good or bad.

[derekn]

We are running vRanger on a esx 3.0.2 box. We changed the cpu to 1500mhz and the Memory 768MB for the system resource reservation.

We were having issues before we did not allocate this, ever since backups are not failing and seen less errors.

[RParker]

Hmm.. well that certainly is good to know. Thanks!

[dwchan]

wow, that is high. By setting the CPU and memory reservation so much higher, ,does it make a difference with your backup? Our console memory is set at 400 MB, just hate to allocate addition 300+ for no good reason. Also for the cpu speed reservation, are you setting this at the console level or above it?

[derekn]

I am setting it at the console level through the VC. It has made a difference and it was recommended from vRanger. I usually am a little hesitant to taking that high of cpu reserve but for our environment it hasn't really effected our infrastructure. We do have some large vm's to backup and that made a difference. We do have a large vm that is 500+gig in size...so maybe that might not be the case for your environment.

From Vizioncore's Forums :"You may have to go as high as 800 MB RAM and 1500 MHz reserved for the COS when dealing with snapshots. Try to torture the COS and watch swap and cpu with "top", if it swaps or the whole server is already bogged down with VM CPU loads, increase RAM and/or MHz reservation. Did you check esx host for hostd taking up 100% CPU? If snapshot deletion takes too long virtualcenter may have a timeout issue.

Look at this on VMware forum (last post) to get an idea how long snapshot commit can take."

[glynnd1]

Any suggestions on how to script the CPU reservation change? Would like to add it to my kickstart file.

Thanks

[RParker]

I had forgotten about this thread until recent changes pushed it to the top, but the memory is making a slight difference, but not CPU reservation. I wouldn't change it, since making this change affects default behavior from the original build. I wouldn't go adding anything to the kickstart file until you tested to make SURE the changes they recommend actually help. Making a change based upon the recommendation of 1 tech at Vizioncore doesn't make sense to me.

It's not even in the documentation for the product, so it this so called "fix" is recommended, why does VizionCore NOT have this update on their website..hmmmm?

Yeah, don't make changes unless you know exactly what you are getting into. You are ok with making a CPU reservation, but a memory increase makes you skeptical? I think there is something missing, memory has to do with capacity, increasing the reservation affects the host performance

[Ken_Cline]

I usually set COS RAM to 800MB by default - if your environment is so tight that you can't afford to give a few hundred MB to your management interface, you've probably under-spec'ed your systems. This was a critical consideration under ESX 2.x - it's not as important under ESX 3, but the COS still does some pretty important stuff. As for the CPU Reservation - the same philosophy pretty much holds true. Most environments are anything but CPU constrained - and all that the reservation does for you is to improve the responsiveness of the VM (in this case the COS).

If you make these configuration settings part of your default build, then it's not a big deal. If you have to go in afterwards and fiddle with things, then it can be a pain in the posterior. In any case, unless you've got a loaded environment and are experiencing problems, it's probably not worth the effort...

Ken Cline

Technical Director, Virtualization

Wells Landers

VMware Communities User Moderator

[derekn]

I was taking the philosophy that KenCline made, I figured allocating a little bit more memory was not that big of a constraint on my environment. I can't imagine it being that big of a deal when allocating the memory. According to the comment about Vizioncore not placing this note in their documentation I have no idea why they don't recommend it, most of their tech support all recommend it.

[glynnd1]

/etc/vmware/esx.conf might be the source of this setting, as it contains the following lines:

/resourceGroups/root/child[0001]/cpu/maximum = "unlimited"

/resourceGroups/root/child[0001]/cpu/minLimit = "unlimited"

/resourceGroups/root/child[0001]/cpu/minimum = "1500"

/resourceGroups/root/child[0001]/cpu/shares = "1000"

/resourceGroups/root/child[0001]/cpu/units = "mhz"

/resourceGroups/root/child[0001]/name = "system"

Changing the 1500 (I had already changed is via VC) to 1499 and rebooting seemed to have the desired effect.

Someone more proficient with sed will have to come up with the equivalent line to:

sed -e 's/boot\/memSize = \"272\"/boot\/memSize = \"800\"/g' /tmp/esx.conf.bak >> /etc/vmware/esx.conf

[RParker]

> I usually set COS RAM to 800MB by default - if your environment is so tight that you can't afford to give a few hundred MB to your management interface, you've probably under-spec'ed your systems

We set all of our servers to 800 now, and by default. I was trying to emphasize the change in the CPU reservation, which isn't a normal setting, and pushing it out to servers may not be a good idea. None of our servers have a need for the increased CPU reservation, and we use vRanger on most of them.