suzyq
Contributor
Contributor

Workstation 6 Slow to Resume on Ubuntu 7.04

VMWare Workstatin 6 is extremely slow to resume, or suspend XP or Vista hosts when installed on Ubuntu 7.04 (I haven't tried this with a linux host).

There is also a problem if I have VMWare open with the Windows host resumed but not in use and it has gone to sleep.

It seems to take about 5 minutes for the host OS to start working properly again after either resuming or waking up.

Has anyone else seen this or are there any fixes for this?

0 Kudos
15 Replies
sperlyjinx
Contributor
Contributor

I have a similar problem. The suspend happens fast, but the resume takes a very long time. Using the same virtual machine, I didn't have this problem on Dapper.

0 Kudos
dsiles
Enthusiast
Enthusiast

Just thought I would bump this message, I am experiencing the same painful restore. I find it faster right now to setup the Windows Guest with the option to hibernate and then hibernate the guest and then resume that way. It takes about 1-2 minutes. Doing a suspend and resume under workstation 6 right now with a Windows XPSP2 guest with 384MB is taking close to 8 to 10 minutes to restore. Suspend happens in 30-45 seconds.

Any ideas would be appreciated.

0 Kudos
Davincij
Contributor
Contributor

I have the exact same problem except I am runing Windows Vista x64 as a host and Windows 2003 as a guest. With VMWare 5.5 I never had this problem. It's not just one guest it's all of them. On a Windows 2003 host I get the same problem but it is not as slow to start, 1 to 2 minutes as apose to 8 to 10 miniutes that I am seeing on the Vista box. The need to change VMware 6 to display a "I'm starting dialog box" to block any other action from occuring after the the green start button is pressed because the software becomes unstable if any other action is taken right away (Eample: veiw snap shot manager quickly).

0 Kudos
danielharvey
Contributor
Contributor

I have the same problem on Ubuntu 7.10 (Gutsy Gibbon) running a WinXP guest. Extremely slow on the resume.

0 Kudos
Davincij
Contributor
Contributor

I have resolved my problem only after cloning my VM and using the clone them resume would be quick. It truns out that the more snapshots you have with an older version of VMWare workstation the longer workstation 6 will take to resume or start up. Man was it bad for me 5 - 8 minutes before it would start also once I deleted all the snap shots the problem went away for the original VM.

Replay if this helped you I would like to know.

Thanks

0 Kudos
Daguerre
Contributor
Contributor

Even with no snapshots, my VMs still take 8-10 minutes to resume. I run RHEL 4 and 5 and Fedora 7 hosts, with Win XP guests.

Ugh. I've always used "Resume VMs in the background" but with these long resumes, it's quite a while before the guest OS responds to keyboard and mouse. Has anyone noticed a net speedup by restoring in foreground only?

0 Kudos
tmbarton
Contributor
Contributor

Yep, I have this problem too and I have no snapshots. VMware on Fedora 7 host, winXP and various linux guests. I used to suspend and restore all the time with WS5 and before, and the restore took seconds, now it takes 8-10 minutes to get past the initial load and display the guest's screen, and then even longer till it's useable. It's way faster to shutdown and boot the guest.

0 Kudos
mchristeson
Contributor
Contributor

I am seeing the same thing on SUSE 10.3. I changed my system monitoring to make IO wait time for the processor more visible. What I have seen so far makes me think this is a 2.6.22 kernel issue. I have tried some of the various .9 and 10 patched version to the kernel and the amount of IO wait has been changing as they patch. I haven't yet figured out if no DMA happening or what, I am suspicious that the reads of the suspend file may be sequential IO. This is either a bug or an effect of the new time concept in this kernel.

0 Kudos
kzr1k9
Enthusiast
Enthusiast

Windows 2003 Enterprise Edition w/6GB memory as the host and I moved from 5.5.5 to 6.0.1 not long ago. All my guests are 5.x based and I did notice the resume operations is a LOT slower than in 5.x. When I resume 4-5 guests each morning, it could take close to 10 minutes total before I have a fully useable environment. Most of the guests have only one or no snapshot. I'm kind of glad ( !!! ) it is not related to my environment.

Is there a debug setting anywhere that can be enabled to help to figure-out why it is taking so long to resume a guest?

0 Kudos
danielharvey
Contributor
Contributor

I think you might be right regarding the kernel problem. Have you looked any more in to this?

0 Kudos
mchristeson
Contributor
Contributor

Not formally. Suse just updated their 10.3 kernel to 2.6.22.12 with 24.rc backports and I am seeing fewer I/O waits on the initial load of the suspend state. The background update that follows is still pretty slow and shows a lot of I/O waits. I would like to really measure what is going on but I don't know when i will have to time to pursue this in depth.

0 Kudos
artiman73
Enthusiast
Enthusiast

mchristeson,

I'm experiencing horrible disk performance in general while running OpenSuse 10.3 with WKS 6.02, could you tell me how to can I change my system configuration to monitor the IO wait time for the processor ... I'm runnning kernel 2.6.22.9-0.4-default, I'm going to try to find the new kernel version to see if it makes any difference

thanks

Artiman

Andres Martinez, VCP # 360, VTSP, VSP, vExpert 2010 Founder and President Virtesa Masificando la Virtualización, Preparando para la Computación en la Nube Web: http://www.virtesa.com twitter: http://www.twitter.com/andresmartinez_ Linkedin: http://www.linkedin.com/in/andresmartinez73
0 Kudos
AckItsMe
Contributor
Contributor

I've been running VMware Workstation 6 on two different OpenSuse 10.3 machines and I have experienced similar problems, but when I hibernate, I've been letting the OS do the hibernation as opposed to having VMware do it.

I did find that one of the issues I was having had to do with memory swapping. It seems that during a resume, VMware was going crazy trying to swap memory out to disk while it's doing a restore and I was getting major disk IO. Adding the following lines to the vmx file seemed to help tremendously: (This also solved a similar disk IO issue that I was having under VMware Server 1.04)

mainMem.useNamedFile="FALSE"

sched.mem.pshare.enable="FALSE"

MemTrimRate = "30"

---

We now return you to your regularly scheduled reality.

--- We now return you to your regularly scheduled reality.
0 Kudos
MuzNZ
Contributor
Contributor

Thanks for the tip AckItsMe. It has sped up running, pausing, and resuming my VMs.

0 Kudos
tmancill
Contributor
Contributor

The settings suggested by AckItsMe made a huge difference for me in response time; running Workstation 6 on Debian unstable. Thanks!

0 Kudos