The HOST OS does not have any storage errors in the event log.
There are also other similar guest machines on this host that are not experiencing the issue.
please attach a vmware.log from that VM
Hmm, I am looking at the log and it's pretty ugly. Stuff like this;
Jan 18 07:10:27: vmx| SCSI0:0: Command WRITE(10) took 1.007 seconds (ok)
Jan 18 10:30:18: vmx| SCSI0:1: Command READ(10) took 1.514 seconds (ok)
Similar is showing up on all guests and and on different drives.
vmware.log.zip 208.3 K
I expected exact this messages you get
when did you last shrink your VMs?
If you do not immediatly shrink your VMs I expect severe corruption any time soon
can't you convert the vmdks to preallocated types ?
the growing type is not long term stable without proper maintenace
the shrink function is implemeted in the vmware-tools
so right click the vmware-tools icon in the systray of the VM - it has a tab for the shrink function
Thanks for your help so far.
Here's what I've done for testing prior to trying on production servers, which I will make a copy of before doing anything.
I have a guest OS that is not important that has been running for a while.
I defragged the disk in the guest OS. No issues.
I ran Shrink and the server coughed up a stop error and rebooted.
I am attaching the logs from the guest OS.
vmware-mcts1.log.zip 19.6 K
you run a defragmentation inside of one of your half-corrupt vmdks ?
very very bad idea - the benefit of running a defragmentation inside a VM that uses growing disks is zero.
In fact it is contraproductiv - only thing you can achieve with that is further corruption.
First thing to do in your case is shrink the disks - or even better - use a Ghost-LiveCD and clone the vmdk to a new preallocated vmdk.
This is one of the rare cases where I would also consider to clone the VM with Converter.
VMs that have as many timeouts as your log showed - should be considered as half-dead.
Avoiding every further stress is imperative.
Defragmentation from inside a guest is the highest stress for a vmdk possible - so only do that with healthy vmdks
Well, sheepish grin, I was RingTFM. I was doing it on a guest that did not matter as a test. I won't do it on the server having the issue.
I will certainly copy the entire guest vm prior to doing anything. If the shrink doesn't work then I can also clone the disk or convert the machine.
Thanks for your help so far. It's appreciated.
Thank you C,
Shrinking the disks was successful and appears to have solved the issues.
I tired to mark you answer as correct but when I click on Correct Answer it just goes to the top of the web page and doesn't mark the answer. I tried in Chrom and IE but no joy.
It doesn't look like you need the points though...