Hi All -- attended the first day of the VI3 Install class today and I have a couple of questions that came up during discussion that I feel weren't answered well.
1. Console memory size -- best practice says to start at 272mb but how does one figure out when to increase this? Is there a formula or is this truly trial and error? The instructor claimed it was a best guess attempt which seems well, not great.
2. Is there a way to export the networking configurations to VISIO or print them? This seems like it would be a really useful feature in helping to keep up with your virtual environment.
Thanks for any input here.
This product will create a Visio diagram for you: http://www.veeam.com/veeam_reporter.asp
If you're looking for stenciles see this thread:
http://www.vmware.com/community/thread.jspa?messageID=562176򉐀
Here's a thread on the SC memory - basically you only have to worry if you're running 3rd party agents that use a lot of memory. In that case you could look at the memory being used by the processes and adjust accordingly.
http://www.vmware.com/community/thread.jspa?threadID=48409&start=20&tstart=0
You can export the network configs using "esxcfg-info -n". It dumps a ton of information though and is not really something you can put in Visio. You can also go to the Maps tab in the VI Client and export network maps but this is only to jpg/bmp format. Optionally the below two products are good tools to document your environment:
VIDocIt (reporting) - http://www.vidocit.com/html/products.html
Veeam Reporter (reporting) - http://veeam.com/veeam_reporter.asp
Message was edited by:
esiebert7625
This product will create a Visio diagram for you: http://www.veeam.com/veeam_reporter.asp
If you're looking for stenciles see this thread:
http://www.vmware.com/community/thread.jspa?messageID=562176򉐀
Here's a thread on the SC memory - basically you only have to worry if you're running 3rd party agents that use a lot of memory. In that case you could look at the memory being used by the processes and adjust accordingly.
http://www.vmware.com/community/thread.jspa?threadID=48409&start=20&tstart=0
In response to both of you guys...thanks!!! These boards are awesome!
Any thoughts on console memory settings????
blush...just saw the bottom of your post. Will read now. Thanks!
good lord Rob...no wonder you made Champion so fast...you are like the black hole of resources!
Thanks, (actually it's Eric) I stumbled across that handy memory chart a few days ago while putting togther a Vmware quiz for my website.
Chad,
To address your Service Console memory question in another way...you might putty into the console and type in "free -m". That will let you see how much memory the SC is currently using, how much is free, and how much is being used for caching purposes. It is something that you can use from time to time to monitor SC memory usage and determine if you need to change the default setting from 272 to something else...up to 800MB.
Why would you need to change it from 272? Perhaps if you add some agents to the console like Dell OpenManage, IBM Director agents, backup agents, anti-virus agents...etc. All of these would use some CPU and SC memory...so you would want to allocate more memory to the SC.
You could just give the SC 800MB and forget about it....as long as you have plenty of RAM in your box. Some of my students and clients do that.
Chris
Chris -- thanks for the additional comments.
Eric -- sorry about calling you Rob...you are still the man even if your name was Igor or something!
Have any of you folks tried deploying nmon on the vi host or does it not even work?
Chad
In talking with VMWare support over the past year I would recommend setting SC memory to max (800 MB). If you have a lot of VMs and you arent tight on memory I have seen no performance difference between setting it to max or not.
Thanks for the additional comments...that seems to be about what folks are reccomending in general. We were really just looking to see if we could reclaim a little bit of memory...but it sounds like it will not really make a real difference at this stage.