Reboots are fast, are we talking about local disk or san?

What version of server 2008?

Roger Lund

My Blog:

http://rogerlunditblog.blogspot.com/

Roger Lund

My Blog:

http://rogerlunditblog.blogspot.com/

http://kb.vmware.com/selfservice/viewContent.do?externalId=1004901&sliceId=1

"using certain hardware", yea sure, pass it off. Like any recent Xeon proc?

I'm using Xeon 5410, by the way.

I hope they fix this in 4.x, memory sharing is a cool feature. Most these VMs run at less than %10 memory. Conservative oversubscribing is very valuable.

Sucks to have to turn it off.

\aleph0
____________________________
http://virtualaleph.blogspot.com/
http://vmusergroupitalia.blogspot.com/ (in italian)
###############
If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!!

The boot delay is only the most immediately noticable symptom.

We've also experienced slow performance of the running system. The KB article is 100% right on. There's a serious problem here.

(It is pre-production. But intended for production, yes).

It would be nice if you could disable page sharing for individual VMs and retain it for others.

Even better, fix the Copy on Write issue newer processors have introduced to the ESX code.

Better still, both!

Here robertl30 states:

===============================

"Good news. VMware came back with some good info on how to better work around the issue where we see large VMs (over 4GB RAM) that have very long restart times. At first they had us turn off Page Sharing at the ESX host. But it turns out we can disable this feature on a per-VM basis.

I added the Advanced VM setting "sched.mem.pshare.enable" option to False (Edit Settings, Options, Advanced, General, Configuration Parameters, Add Row). I then moved the VMs to production hosts that did not have the Page Sharing feature disabled. I restarted each server twice and the performance was normal.

VMware also provided guidance on how to determine the effectiveness of Page Sharing in general. The tool to use is in the ESX CLI and is called "esxtop". Press M to bring up the memory page and observe data on the PSHARE row.

VMware also is stating that they are still looking at engineering a fix for ESX 3.5, but that the problem is already fully resolved in vSphere 4."

===================================

I tried these steps and they solved the problems I had with x64 on "certain" hardware.