Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2243
  • Last Modified:

Not caching pages 21318 through 21319 because of write on page 21319 on write.

I have two VMware Server 2.0.2 running on a Windows Server 2003 R2 32-bit host.
Both guest OS are Windows 2003 Server 32-bit. Everything fully updated.

The vmware.log for both of the guests contain bunches of entries like:

Aug 22 17:41:31.364: vcpu-0| Not caching pages 26762 through 26763 because of write on page 26763 on write.

What do they tell and how can I get rid of them?

Searching the web reveals lots of similar questions but no answers. Not even a clue.
Any ideas?

/gustav
0
Gustav Brock
Asked:
Gustav Brock
  • 3
  • 3
1 Solution
 
bgoeringCommented:
Are you running the 64-bit version of VMware Server 2.0.2 on Linux? Seems like most of what I have been able to discover is particular to that version.
0
 
Gustav BrockCIOAuthor Commented:
Nope. Host OS is 32-bit Windows Server 2003.

/gustav
0
 
bgoeringCommented:
I have not been able to find much on that particular error. What I think it is telling you is that something running in your virtual machines are updating pages in memory that VMware Server memory management wasn't expecting. Memory management in VMware tries to cache frequently accessed memory pages that are then shared to running VMs with the same page. Windows OS code is all re-entrant and when you run many guests - they all have basically the identical pages of memory. VMware is smart enough to only keep one physical copy of that page in the host RAM, and all the guests see that single copy.

Now if one of your guests runs some application (typically would suspect device drivers or other software that might run in kernel mode on the guest) that "mis-behaves" and writes to that memory page, vmware detects it, and because now it is different on that guest VMware no longer can share that page amongst the other guests and thus removes it from its cache.

What to do? Look for the mis-behaving application on your guest virtual machines. You could start by stopping non Microsoft services. If the guests were P2V go to device manager, select view hidden devices, and remove any that are greyed out.

Good Luck
0
Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

 
Gustav BrockCIOAuthor Commented:
That sounds like a pretty good explanation.

As for what to do, there are no "foreign" services running. One guest is a clean install for a file server, the other is a basic AD/DNS/DHCP server - nothing special is installed except for the standard VMware Tools and Physical Disk Helper services.

I studied the event log of both guests but nothing is related to the timestamps of the entries recorded in the vmware.log.

I should add that nothing else looks strange, so perhaps I should just forget it - or raise the bar for VMware's log recording.

/gustav
0
 
bgoeringCommented:
That message in and of itself does not necessarily indicate anything is "wrong." Just that, so far as VMware is concerned, something unexpected happened - and this is how VMware is going to handle it. So long as everything is stable I probably wouldn't worry about it too much.
0
 
Gustav BrockCIOAuthor Commented:
Thanks for the insight. I'll leave it there.

/gustav
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now