WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

Free Linux & Windows Syslog Alternatives to depercated vi-logger in vMA 5

07.25.2011 by William Lam // 12 Comments

Those of you who currently use vi-logger in vMA 4.x as a free syslog server for your ESX(i) hosts may notice this functionality has been removed in the latest vMA 5 release. VMware decided to remove the syslog functionality in vMA in favor of combining it with the vCenter Server. If you decide to run vCenter 5 on Windows, you have the option of installing an additional syslog collector on the same or separate Windows system and registering it as a vCenter plugin. If you are using the new VCVA (vCenter Server Virtual Appliance), there is also a syslog collector that is installed by default.

Using vMA's vi-logger was an easy and free solution, but you still have some alternatives without having to use vCenter or install/build a new syslog server. The following will document a free syslog solution for both a Linux or Windows platform.

Linux Syslog server alternative using vMA 5.0
You can actually leverage the existing syslog server on the latest vMA 5 release and with a few customization, get it setup to start collecting logs from your ESX(i) hosts as before with vi-logger.

Step 1 - It is recommend that you configure an additional disk on vMA for your syslogs as the size of vMA is quite tiny for additional use. I will assume that you know how to add and configure an additional disk, if not you can do a simple search on Google. In this example, I have a second disk that is 10GB and it is mounted up under /var/log/remote which is where the ESX(i) logs will be stored in.

Step 2 - You will need to edit the syslog configuration under /etc/syslog-ng/syslog-ng.conf and you will need to add three entries. The first addition is to configure the source for log messages from the network and enabling both udp/tcp on port 514, you may add the following under the default "src" entry.

source network {
udp6( port(514) );
tcp6( port(514) );
};

The next two entries will define the destination and how it'll log. You will add the following at the end of the syslog-ng.conf configuration file.

destination log_remote {
file("/var/log/remote/$HOST_FROM/$YEAR-$MONTH/messages-$YEAR-$MONTH-$DAY"
create_dirs(yes) frac-digits(3)
template("$ISODATE $PROGRAM $MSGONLY\n")
template_escape(no)
);
};
log {
source(network);
destination(log_remote);
};

The "log_remote" destination will send all logs from your ESX(i) hosts into /var/log/remote and will have the following format: $HOST_FROM/$YEAR-$MONTH/messages-$YEAR-$MONTH-$DAY

Step 3 -  Now you will need to restart the syslog server for the changes to take effect. You will need to run the following command: sudo /etc/init.d/syslog restart

If everything went successful, you should now be able to configure your ESX(i) hosts to point to your vMA 5 system and you should see logs appearing under /var/log/remote

Note: You will need to use sudo to view the directory under /var/log/remote and to view the logs

Windows Syslog server alternative using vCenter Syslog Collector
The vCenter Syslog Collector can be installed and used without the use of vCenter, you can easily turn any existing or new Windows system into a syslog server for your ESX(i) hosts for free.

Step 1 -  It is recommend that you configure a seperate disk on the Windows system that you are going to be using for your syslog server. I will assume that you know how to add and configure an additional disk, if not you can do a simple search on Google. In this example, I have a second disk that is 10GB and listed as Syslog (E: drive)

Step 2 - You will need access to the vCenter Server 5.0 installation ISO or executable to install the Syslog Collector utility. Start the installer and select and install VMware Syslog Collector

Step 3 - You have the option of using the local C:\ drive, but I would recommend setting up a separate drive if you can. If you decide to change the default log location, you need to ensure that you specify the following directory structure VMware\VMware Syslog Collector\Data else you will run into issues with the installation. In this example, I have moved my logs into E:\ drive and the path looks like the following: E:\VMware\VMware Syslog Collector\Data. You also have the ability to change the size of the log files before rotation and the number of logs before rotating.

Step 4 - If you are installing the Syslog Collector on the same host as vCenter Server, you should select the integrated installation else you should select a standalone installation.

Step 5 - The next screen will be the default ports to enable for both TCP/UDP and SSL which can be configured or left as the default as recommend.

Step 6 - The screen is how the Syslog Collector will be identified on the network and it should just be the IP Address of the host.

If everything went successful, you should now be able to configure your ESX(i) hosts to point to your Windows Syslog Collector system and you should see logs appearing under E:\VMware\VMware Syslog Collector\Data

As you can see even with vi-logger being removed in the latest version of vMA 5, you can easily still configure a free syslog server with your ESX(i) hosts on either a Linux or Windows platform.

Categories // Uncategorized Tags // ESXi 5.0, syslog, vilogger, vma, vMA5, vSphere 5.0

Raising the vExpert & Community Bar, Part JC (John Troyer)

07.24.2011 by William Lam // 1 Comment

Some may call him a medical practitioner, some may refer to him as Cloud City's VMware Architect and others may know him as the VMware Stig ...

but all we know is he is the Great John Troyer!

First off I would like to wish John a Happy Birthday today and hope you have a vAwesome day!

Christopher Kusek, who you may know him as cxi on Twitter reached out to the vExpert community about a month ago regarding a secret embargoed project. We wanted a way to show John our appreciation and all the hard work and dedication he has done for the VMware and virtualization community. What better way than a bunch of blog posts thanking John from the vExpert crew!

I have known John for about three years now and have interfaced with him on many occasions from late night twitter DMs on vSpam in the VMTN blog, access to new VMware betas and embargo briefings, VMTN community forum feedback/improvements and access to VMware engineers for variety of Q/A and bug related questions.

For those of you who do not know John Troyer, he is the social media strategist for VMware, but John really does way more than that. He takes part in supporting the popular VMware Community Forums, VMTN Blogs and PlanetV12n along with several other individuals, he runs the extremely well known VMware Community Podcast every week in which he invites guests from all over to discuss all things VMware and virtualization and he is also the guy who created and runs the VMware vExpert program just to name a few.

John is a very genuine guy and really likes to help others whether it's getting someone in touch with a VMware product manager for more details about a topic or helping a fellow blogger attend a VMworld conference through a blogger's pass because he/she could not afford to attend. I think John has definitely raised the bar not only in the changes to come for the vExpert program of 2011 (which I am personaly excited about) but the VMware community bar as well.

I can not think of a single technology company that has such a great user community with an incredible amount of sharing and collaboration than the VMware/virtualization community. I think part of the reason why our community is so successful is due to people like John who fosters an active communication with the user base.

Cheers to all of John's achievements, his hard work has not gone unnoticed or unappreciated. I would like to personally say Thank You!

Categories // Uncategorized Tags // Uncategorized

How to Trick ESXi 5 in seeing an SSD Datastore

07.22.2011 by William Lam // 38 Comments

In vSphere 5, there is a new feature called Host Cache which allows a user to offload the virtual machine's swap onto a dedicated SSD device for better performance. This is done by creating a VMFS volume on an SSD device which is then detected by SATP (Storage Adapter Type Plugin) and allows a user to add and configure a VMFS datastore for host caching.

During the vSphere 5 beta, I was testing out various new features including Host Caching but did not have access to a system with an SSD device while updating and creating a few new scripts. After some research I found that if a default SATP rule is not available to identify a particular SSD device, that a new rule could be created containing a special metadata field specifying that it is an SSD device.

In the following example, I will take a local virtual disk (mpx.vmhba1:C0:T2:L0) in a vESXi 5.0 host and trick ESXi into thinking that it is an SSD device.

We will need to use esxcli whether that is directly on the ESXi Shell or using vMA and/or PowerCLI esxcli's remote version.

Note: The following assumes there is already a VMFS volume created on the device you want to present as an SSD device, if you have not done so, please create a VMFS volume before continuing

First you will need to create a new SATP rule specifying your device and specifying the "enable_ssd" string as part of the --option parameter:

~ # esxcli storage nmp satp rule add -s VMW_SATP_LOCAL -d mpx.vmhba1:C0:T2:L0 -o enable_ssd

You can verify that your rule was created property by performing a list operation on the SATP rules:

~ #  esxcli storage nmp satp rule list | grep enable_ssd
VMW_SATP_LOCAL       mpx.vmhba1:C0:T2:L0                                                enable_ssd                  user

Next you will need to reclaim your device so that the new rule is applied:

~ # esxcli storage core claiming reclaim -d mpx.vmhba1:C0:T2:L0

You now can verify from the command line that your new device is being seen as an SSD device, by displaying the details for this particular device:

~ # esxcli storage core device list -d mpx.vmhba1:C0:T2:L0
mpx.vmhba1:C0:T2:L0
Display Name: Local VMware Disk (mpx.vmhba1:C0:T2:L0)
Has Settable Display Name: false
Size: 5120
Device Type: Direct-Access
Multipath Plugin: NMP
Devfs Path: /vmfs/devices/disks/mpx.vmhba1:C0:T2:L0
Vendor: VMware
Model: Virtual disk
Revision: 1.0
SCSI Level: 2
Is Pseudo: false
Status: on
Is RDM Capable: false
Is Local: true
Is Removable: false
Is SSD: true
Is Offline: false
Is Perennially Reserved: false
Thin Provisioning Status: unknown
Attached Filters:
VAAI Status: unsupported
Other UIDs: vml.0000000000766d686261313a323a30

As you can see the "Is SSD" field is not being populated as true where as before if you ran this command, it would display false

Now you can refresh the Storage view on the vSphere Client or you can do so from the command line by running the following command:

~ #vim-cmd hostsvc/storage/refresh

Now if you go back to the vSphere Client under "Host Cache Configuration" you should see the new fake SSD device for selection and you just need to configure it and Host Cache is enabled for this device.

This of course is probably not officially supported unless directed by VMware nor is there a real good reason for this. I personally had to go down this route for scripting purposes but if you wanted to see how Host Cache works, this is a neat trick to allow you to do so.

Categories // Uncategorized Tags // ESXi 5.0, host cache, ssd, vSphere 5.0

  • « Previous Page
  • 1
  • …
  • 54
  • 55
  • 56
  • 57
  • 58
  • …
  • 74
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Ultimate Lab Resource for VCF 9.0 06/25/2025
  • VMware Cloud Foundation (VCF) on ASUS NUC 15 Pro (Cyber Canyon) 06/25/2025
  • VMware Cloud Foundation (VCF) on Minisforum MS-A2 06/25/2025
  • VCF 9.0 Offline Depot using Synology 06/25/2025
  • Deploying VCF 9.0 on a single ESXi host? 06/24/2025

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 © 2025