I guess you already have url=http://www.vmware.com/community/thread.jspa?messageID=615874򖗂debugging disabled[/url]?
Other than that...may be your disk I/O is limiting your performance....try the following url=http://www.vmware.com/community/thread.jspa?messageID=619026switch[/url] in the .vmx file...
Oh yes, I should give some information on settings. Debugging is indeed off. I've tried the aiomgr.buffered parameter but it doesn't seem to make much difference.
I tried upgrading the virtual hardware, but as I thought, no difference.
In either case, the VMs are hammering the disk while on Workstation they hardly touch the disk. The only difference I can think of off hand is I tell Workstation to keep VMs resident in RAM. 2x512MB VMs + overhead should still leave plenty of host RAM leftover for the host OS. (2GB on host)
The two VMs are virtually identical, one being copied from the other. Here's one of the .vmx files. The other is identical except for the NIC MAC, UUID, etc.
checkpoint.vmState = ""
chipset.useAcpiBattery = "TRUE"
chipset.useApmBattery = "TRUE"
config.version = "8"
displayName = "WinXP"
ehci.pciSlotNumber = "34"
ehci.present = "TRUE"
ethernet0.addressType = "generated"
ethernet0.generatedAddress = "00:0c:29:08:67:0a"
ethernet0.generatedAddressOffset = "0"
ethernet0.pciSlotNumber = "32"
ethernet0.present = "TRUE"
floppy0.fileName = "/dev/fd0"
floppy0.startConnected = "FALSE"
guestOS = "winxppro"
ide0:0.deviceType = "disk"
ide0:0.fileName = "WinXP.vmdk"
ide0:0.present = "TRUE"
ide0:0.redo = ""
ide0:1.fileName = "ODrive.vmdk"
ide0:1.present = "TRUE"
ide0:1.redo = ""
ide1:0.autodetect = "TRUE"
ide1:0.deviceType = "atapi-cdrom"
ide1:0.fileName = "auto detect"
ide1:0.present = "TRUE"
ide1:0.startConnected = "FALSE"
ide1:1.fileName = "swap.vmdk"
ide1:1.present = "TRUE"
ide1:1.redo = ""
memsize = "512"
nvram = "WinXP.nvram"
pciBridge0.pciSlotNumber = "17"
pciBridge0.present = "TRUE"
priority.grabbed = "normal"
priority.ungrabbed = "normal"
scsi0.pciSlotNumber = "16"
scsi0.present = "TRUE"
sharedFolder.maxNum = "1"
sharedFolder.option = "onetimeEnabled"
sharedFolder0.enabled = "TRUE"
sharedFolder0.expiration = "never"
sharedFolder0.guestName = "Install"
sharedFolder0.hostPath = "/Volumes/Video 1/svn-master/install/win32"
sharedFolder0.present = "TRUE"
sharedFolder0.readAccess = "TRUE"
sharedFolder0.writeAccess = "TRUE"
sound.fileName = "-1"
sound.pciSlotNumber = "33"
sound.present = "TRUE"
sound.startConnected = "TRUE"
sound.virtualDev = "es1371"
tools.syncTime = "TRUE"
tools.upgrade.policy = "manual"
usb.autoConnect.device0 = ""
usb.generic.autoconnect = "FALSE"
usb.present = "TRUE"
uuid.action = "ask"
uuid.bios = "56 4d a7 fd 76 f5 28 eb-46 29 6a ed 7c 08 67 0a"
uuid.location = "56 4d 10 4a d7 38 90 94-9a af 30 58 41 04 80 0b"
virtualHW.productCompatibility = "hosted"
virtualHW.version = "6"
Has there been any resolution to this? I'm seeing the same thing with a MacBook Pro Core Duo with 2GB RAM.
The one thing that I have that might be different is that my two VM's are located on encrypted disk images. I suspect that is contributing to some of my memory usage. But what I really think is going on is that I'm just plain out of memory. Parallels doesn't seem to do much better.
The one thing that I have that might be different is that my two VM's are located on encrypted disk images.
Try running not on encrypted disk images. I have no idea how big of an impact it'll have, but you're the only one who can easily test this.
It's much better now.
I spent this afternoon copying my images off and running them when they're not on encrypted disk images. With my non-scientific measurement, my machine is doing much better. My "inactive" memory is up by about 300mb when not running on them, and the machine is responsive again. With WinXP and Ubuntu I can see "inactive" and "free" combined to almost 1gb on my 2gb machine.
However, I did do other things today--I decreased my WinXP virtual machine memory to 384mb from 512mb, and I removed the snapshots I had on both my WinXP and Ubuntu VM's. But after those changes I was still seeing high memory usage and a slow machine. Moving the images off the encrypted images seems to have done the trick.
My guess is that kernel_task caches decrypted blocks from the disk images in memory, and doesn't easily release those blocks. And since I had the entire OS encrypted, that was a lot of blocks.
Thanks for testing and reporting this, it may help others in similar situations.
1 person found this helpful
In addition to what you've already pointed out here, I'll note:
\- Mac OS X doesn't run especially well in 1GB. At least I haven't been happy with the performance.
\- running 2 512MB VMs, on a 2GB machine, leaves under 1GB for the host OS (assuming the VMs are fully resident, which may or may not be the case). But depending on overheads, it might be substantially less.
\- your .vmx file specified 167772160 bytes for the VRAM size. That's 160 MB. That's a really big frame buffer! And you've got two of those. So, the overhead here is a lot more than it would be for a default VM. (Actually, we don't support the VRAM size being larger than 128MB, and we'll cap it to 128MB. Still, that's another 256MB of memory, before we even get to other overheads.)
So, I'm glad that it started working better when you moved it off the encrypted partition, but in my experience, trying to run two VMs that each have 512MB of RAM and 128MB of VRAM is asking a lot of a 2GB OS X host.
- Mac OS X doesn't run especially well in 1GB.
Interesting. I've not really paid attention to this.
(assuming the VMs are fully resident,
Any way to force this like in Workstation? I'm assuming not at this point.
- your .vmx file specified 167772160 bytes for the
Yeah, that's from trying to debug an old problem that was resolved in Beta 3. I can whack this and see what happens.
Do note that I am running at the full 2560x1600 (30" Cinema display).
That's a really big frame buffer! And you've got two of those.
Well, they compliment my two heads and three arms.
experience, trying to run two VMs that each have
512MB of RAM and 128MB of VRAM is asking a lot of a
2GB OS X host.
This is good to know. Unfortunately I can't test this with more than 2GB RAM as my MBP is maxed out. It's not one of the newer models capable of holding 3GB.
Edit: Oops, too many thread open, replied to the wrong one. -etung 2007.06.21 10:25