WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud
  • Tanzu
    • Application Modernization
    • Tanzu services
    • Tanzu Community Edition
    • Tanzu Kubernetes Grid
    • vSphere with Tanzu
  • Home Lab
  • Nested Virtualization
  • Apple

Increase Syslog count in ESXi using Busybox

06.08.2010 by William Lam // 2 Comments

There was an interesting question on the ESXi forum today using syslog and logging to a local VMFS volume and potentially filling up the datastore. By default, the log files are 2MB each before they are rotated out with a total of 9 copies all together. This ensures that the logs will not grow beyond 18MB and potentially fill up your datastore.

Within the unsupported console of ESXi, there is a little tool called "Busybox" which implements a set of familiar command line utilities called applets. Some of these applets are uptime, crond, chroot, md5sum, etc... If you login to the unsupported console and just type "busybox" on the console, you will see the following:

If you look carefully, you will see that one of the applets is "syslogd", which is the syslog daemon running in ESXi. To access a specific applet, you will just type busybox and then the name of the applet along with -h which forces the applet to provide a set of available options. If we do this for syslogd, you will see the following:

The default configurations should ensure that your logs don't go crazy and fill up the volume, but the downside is that your log history will not be kept forever. That is why it is a best practice to setup a remote syslog server to send all your logs for further processing and auditing if necessary.

However, if you wanted to change this defaut, you can. As you can see from the options above, you can configure not only the size (max of 2MB) before rotating out, but also the number of logs to keep (max of 99). While you cannot increase the size of the individual logs, you can specify a larger number of logs to keep. If you want to make the changes live while the system is running, you'll need to perform the following:

1. Find the current pid of syslogd

~ # ps | grep syslog
4313 4313 busybox syslogd

2. Kill the syslog process

~ # kill $(cat /var/run/syslogd.pid)

3. Let's say you want to keep 50 copies instead of 9

~ # busybox syslogd -b 50

Note:

  • The input to -s is in bytes with range (0-2097151)
  • The input to -b has range (1-99)

It's important to note that this change will not persist through a reboot. I have not been able to figure out where this is set; it could just be hardcoded in the binary by default. A way around this is to re-define the configuration upon boot up by adding an entry to /etc/rc.local which will kill the current running syslogd and then start up with the new parameters as shown above.

Add the following lines to the end of /etc/rc.local:

kill $(cat /var/run/syslogd.pid)
busybox syslogd -b 50

Now for this change to fully persist, you need to do one more thing, you'll need to run /sbin/auto-backup.sh which will force a local backup of the ESXi configuration files which includes /etc/rc.local so that it'll survive through the next reboot. Now you'll be able to store additional ESXi logs for a longer period of time if you choose to log locally.

Categories // Uncategorized Tags // busybox, esxi4, syslog

The vExpert 2010 Crew

06.08.2010 by William Lam // Leave a Comment

The wait is finally over! The highly anticipated e-mail from John Troyer announcing the second group of individuals for the vExpert 2010 award went out today. I'm very honored to be accepted into the vExpert 2010 program and look forward to sharing it with a great group of individuals! I want to thank John for organizing this program and for all the hard work he has put in to recognizing everyone. Congratulations to the vExpert 2010 crew! Let's make 2010 a great year!

Here are some links/blog posts to the other vExpert's for 2010:

Arnim van Lieshout
Tom Howarth & Wil van Antwerpen
Brian Knudtson
Jase McCarty
Maish Saidel-Keesing
Barry Coombs
Joe Kelly
Mike Laverick
Paul Davey
Aaron Delp
Erik Scholten
Justin Emerson
Didier Pironet
Carlo Costanzo
David Marshall
Scott Lowe
Mark Vaughn
Ed Saipetch

Additional Links:
http://www.vmware.com/communities/vexpert/
http://www.yellow-bricks.com/2009/10/01/vexperts-2010/

Here is a vExpert 2010 twitter list put together by @maishsk that you can follow:
http://twitter.com/maishsk/vmware-vexpert-2010

Categories // Uncategorized Tags // vexpert, vmware

Adventures with HP SAM and Win2008 R2 domains

06.07.2010 by William Lam // Leave a Comment

For the past two years or so we have been testing out VDI in our residence hall student labs at UCSB which consist of about twenty or so thin clients split between two locations. Now what made all of this feasible was:

1) Advancements in remote display protocols
and
2) our ghetto-link-clones script (http://communities.vmware.com/docs/DOC-9020)

We picked HP's RGS as our remote display protocol because it was the only protocol we found at the time that ensured a "rich desktop user experience". I still prefer it today over the software implementation of PCoIP but that is a topic best left for another day.

Naturally, the only broker that pooled RGS-enabled machines at the time was HP's Session Allocation Manager (today Leostream and others can broker it). Despite bad experiences with some HP software in the past, SAM actually worked out very well for us, both on the server side as well as the client side. I still have yet to see a broker package that allows you to customize the client like HP SAM (this feature is definitely stamped as RAD in my book).

SAM was not perfect though and had the occasional hiccup (e.g. machines being listed as unavailable, annoying but only occurred once in a while and was remedied with a resync operation) until the day came: management decided to upgrade the domain from Win2k3R-something to Win2k8R2. SAM completely stopped working; it was an interesting situation to say the least.

After some testing (with profanity and throwing of objects included), we of course determined that the fault was in SAM (3.0, the latest release at the time in early January did not work). HP's response? No official timeframe to release a fix. This equated to a week of scrambling around looking for competing and "compatible" products (ala Leostream) which just ended up complicating things. The solution? An aggravating night biking back and fourth between the two labs switching the entire VDI environment over to View. Whatever it takes right?

So long story short, if you have an existing HP SAM installation that is running on a pre-Win2k8R2 domain, make sure you update to the latest revision of SAM (3.01) that was just released a couple weeks ago before migrating your domain to Win2k8R2.

For a short description of our VDI environment, please refer to:
http://communities.vmware.com/docs/DOC-9201

Categories // Uncategorized Tags // Uncategorized

  • « Previous Page
  • 1
  • …
  • 478
  • 479
  • 480
  • 481
  • 482
  • …
  • 484
  • Next Page »

Search

Author

William Lam is a Senior Staff Solution Architect working in the VMware Cloud team within the Cloud Infrastructure Business Group (CIBG) at VMware. He focuses on Cloud Native technologies, Automation, Integration and Operation for the VMware Cloud based Software Defined Datacenters (SDDC)

Connect

  • Email
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • Vimeo

Recent

  • How to enable passthrough for USB Network Adapters claimed by ESXi CDCE Driver? 03/30/2023
  • Self-Contained & Automated VMware Cloud Foundation (VCF) deployment using new VLC Holodeck Toolkit 03/29/2023
  • ESXi configstorecli enhancement in vSphere 8.0 Update 1 03/28/2023
  • ESXi on Intel NUC 13 Pro (Arena Canyon) 03/27/2023
  • Quick Tip - Enabling ESXi Coredumps to be stored on USB 03/26/2023

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2023