vmware.log rapid file growth

[cocacolo]

Anyone knows why some vmware.log files grow faster than others?

I have some of them which have grown more than 500 MB in just a few weeks.

We have vSphere 5.1 U1a  and almost all VMs have updated virtual hardware and vmware tools.

[continuum]

I have seen logs growing much faster than that ...
Anyway - if logs grow fast something is going on that does not work as expected.
First step: find a pattern - what messages are repeated over and ovewr again ?

Once you know that there are 2 options:
- its a bug : google the messages that are repeated
- it is a missconfiguration - fix the problem

In all cases it will helps us if you give us something to work with

[a_p_]

Please take a look at http://kb.vmware.com/kb/2036350 to see whether this explains your issue. However, the patch mentioned in the article unfortunately didn't resolve the issue for me.

André

[cocacolo]

Thank you for your replies!

@a.p. you are right, that's my problem. You can see the messages below:

2013-12-04T12:04:51.598Z| vcpu-1| I120: GuestRpc: Channel 3 reinitialized.

2013-12-04T12:04:52.520Z| vcpu-1| I120: Guest: toolbox-dnd: Version: build-1065307

2013-12-04T12:04:52.521Z| vcpu-1| I120: GuestRpc: Channel 3, conflict: guest application toolbox-dnd tried to register, but it is still registered on channel 2

and so on......

BTW, did you finally manage to resolve this issue?

I'll take a look at the KB and the patch it mentions.

As soon as I can do some test, I'll make an update.

One more thing, do you know if it's dangerous to remove a vmware.log file with the VM powered on? I did this on a test VM via command prompt and the VM continued to run OK, but I don't want to do it on a production VM...

[john23]

Log files should not remove since it will report events...If any issue occur it would be helpful to solve the issue.

Removing log file will not cause any issue on vm, since it doesn't contain any configuration info...

[cocacolo]

@john23:

Yes, I agree with you but the problem is that our datastores have little space left, and I have to save as much space as I can, so I don't have snapshot delta files filling my datastores when it comes to backups.

For now, I will disable VM logging for some VMs until I upgrade to a newer vSphere release.

[john23]

If running out of space condition, I completely agree with you disabling log is the option

[a_p_]

Unfortunately I didn't fix the issue yet. I actually didn't have the chance to update this environment with the latest patches to see whether they help. What I did was to power off the VM's and disable logging for them. My initial plan to configure log rotation didn't work, because log rotation for the vmware.log isn't available anymore. You may also not be able to delete the log file with the VM powered on, because it's in use.

Whatever you do, please be careful with deleting the files from the datastore browser, unless you have at lease vCenter Server Update 1b installed. If you receive an error message when you try to delete the log file, don't try it again without e.g. closing the datastore browser and re-opening it. (see VMware vCenter Server 5.1 Update 1b  Release Notes, "All virtual machine folders on a VMFS volume are deleted after ...")

André

[cocacolo]

@a.p.:

I finally followed KB  2036350 and disabled VM logging. As the KB says, the good news is that you don't have to power off the VMs for the change to take effect; just vMotion to another host and logging will be deactivated for that VM. Then, you can delete the big vmware.log (I did this with a putty session, not the vSphere client)

After all, it is a VMware tools issue, so I hope it will be fixed in the next release. Until then, I think disabling VM logging is the best option for everyone having little datastore space left.

I want to thank everyone who has tried to help me!