News:

NOTICE: This forum is mostly an archive, though new posts are allowed. Registration may require manual admin activation. After registering visit https://bitsum.com/contact/ to request account activation.

Main Menu

Multiple VM's with different affinity

Started by Felix, December 26, 2008, 12:19:00 AM

Previous topic - Next topic

Felix

I'm running VMware Server (the free edition) under XP Pro, SP3. I have 2 VM's running Ubuntu and would like to split affinity so that 1 VM runs on cores 0 &1, and the other on cores 2 & 3.
I have 1 vmware-vmx.exe with affinity set to 0 & 1. When I open the 2nd VM I'll have another vmware-vme.exe.
How can I set a seperate afftinity for the 2nd VM ?

Many Thanks

Jeremy Collake

#1
You can create a new (empty) folder that you link to the original VMWare folder (using NTFS junctions). You can then launch an alternate instance of VMWare server from this linked folder. That way, the virtual machine host process it launches will hopefully adopt the path of its parent, allowing you to differentiate between instances based upon their path names.

For this, I need to allow you to match path names to default affinities in Process Lasso, instead of just base names. I'll try to get that on in the next beta.

I don't know for certain this would work, you'll have to try it.

So, for instance, you might have the symlink/junction:

"c:\program files\vmware server link" -> "c:\program files\vmware server"

Then create two shortcuts, one that uses each folder name. For creation of junctions, use NTFSLink, SHJunction, or whatever other tool of your choice.
Software Engineer. Bitsum LLC.

Jeremy Collake

Ok, I've added the support to match wildcards to path names for default priorities and affinities. It will appear in v3.35.1 beta, which I'll be uploading in a few minutes or so.

I know this seems like a crazy way to accomplish what you want, but there is no other easy and reliable way to differentiate between two process instances.
Software Engineer. Bitsum LLC.

Felix

#3
Wow,, I'm impressed. Thanks for the quick turnaround.
This should work fine since vmware-vmx.exe exists in a separate folder for each VM.
I'll give it a try and let you know.
Thanks again,,,

Oops, I blew that. There is only 1 vmware-vmx.exe. I'll try to follow your directions.
Thanks again

Felix

I downloaded Junction from Sysinternals, and created an empty directory on another drive and ran:
junction -s e:\VMLink "c:\Program Files\VMware"

When displaying e:\VMLink I see all of the files that are in the original, created a shortcut to VMWare Server and launched it. VMware Server starts and opens a second console and PL shows it from the new VMLink directory.
However, the other programs like vmware-remotemks.exe and the all important vmware-vmx.exe are still pointed to the original. Further the 2 VMware consoles are mirrors but I guess that makes some sense.

I then copied c:\Program Files\VMware to E:\VMware Copy and tried it with the same result as above. I searched the registry and found an entry pointing to c:\program files\vmware\smware server\bin\vmware-vmx.exe so I suppose that no matter where it starts it will get pointed to that location, and I'm not smart enough to figure out how to change that.

To back up a couple of steps, what I'm attempting to do is run multiple linux OS's running the linux folding@home client. Since vmware only supports 2 cores, I'd like to dedicate 2 cores to one and the other 2 cores to the other (on my Q6600). I can run them both on 3 or 4 cores but performance seems to suffer.
Maybe installing another VM product would work but overhead will probably kill me.

Thanks again.



Jeremy Collake

Ah, yes, that registry key pointing to the path is a problem. I had hoped this wasn't the case.

I am not sure what other action to take here. Technically speaking, there are ways to get around that registry value, but none that are particularly attractive.

I suppose you could create a batch file that modifies that registry value prior to launching vmware.  Your vmware shortcuts would be modified to point to this batch file, so it always adjust that registry value prior to launching vmware. You could use Regedit.exe and a .REG file to import the registry change(s) automatically.

That way, if you take care to launch one instance of vmware and start the VM, THEN launch the second instance of vmware and start that VM, the vmware-vmx processes should be launched from different paths.

It's still quite a kludge though, and would require you to be pretty careful in the way you launched vmware and started your virtual machines. It almost seems as easy to just manually set the affinities each run.

If you think of any other possible ways to differentiate between the processes, let me know and I'll happily help facilitate it with Process Lasso.
Software Engineer. Bitsum LLC.

Felix

The only thing that comes to mind is tying it to the ID number which of course changes when the file is open. Perhaps a new entry in the PL ini file where a user can identify a special case file, and set affinity and priority for each subsequent opening of the file.
Say the 1st one opens in cores 0&1, priority whatever,, and the second in cores 2&3.

I can also imagine the chaos if someone started mucking around with each opening of something like svchost.exe..

Thanks again for your work on this.


Jeremy Collake

#7
Yes, I could differentiate based on the process creation times. The PID number is unpredictable and it can't be guaranteed that a newer process will have a higher PID than an older process, but there is no problem using the creation time of the process.

However, the implementation of such a feature gets a little murky. I'll keep thinking on how to best integrate such an option without cluttering things up. However, I'm pretty sure it will have to wait for the new scripting support I have planned in early 2009. The scripting language will allow for this, and many other, operations that are more complex than rigid rules can allow for. I've been planning to add it for some time, and am about to finally get to work on it.
Software Engineer. Bitsum LLC.

Felix

No problem,, thanks again and Happy New Year.