Archive

Archive for June, 2011

VMware, Coreinfo and mapping logical CPU cores to physical processors.

June 28th, 2011 8 comments

Sometimes you may have a requirement due to licensing to ensure a Virtual Machine’s CPU configuration is perfectly set out in terms of “physical sockets”. Or perhaps you want to run an operating system such as Windows Server 2003 SE on your Virtual Machine. By default this VM would be limited to only use 4 cores because of the way VMware tells the operating system that each CPU has only 1 core per socket. (Giving it 4 x vCPUs would be the same as giving a physical Windows Server 2003 SE machine 4 x physical CPUs – the actual CPU limit). Either way, it can be quite useful to verify you have the correct CPU configuration.

Enter Coreinfo. This is a handy command line utility by Mark Russinovich which allows you to dump the information about your current CPU and cache configuration for Windows. Download the utility and execute the following command to gather information about the logical CPU core mapping to physical processor.

coreinfo.exe -c -s

In the case of a single socket, six core CPU (such as the one I have running here) this is the output you will see:

 

The Logical to Physical Processor Map information in the first section marks each CPU core with an asterisk (*). The next section, lists the Logical Processor to Socket mappings, indicating how many “processor sockets” your machine has and at which location each Processor Core is at (again marked with an asterisk).

 

If you had provisioned a VM with 4 x vCPUs by default, this would show up with 4 x Sockets and 4 x Physical Processors like so:


Besides being a limiting factor for Windows Server 2003 SE VMs when trying to use 8 x vCPUs (you can’t have more than 4 x “physical” CPUs), this may also be a potential issue with a socket licensed edition of SQL server for example, as you would now have 4 x sockets to worry about with your licensing.

 

So here is where VMware’s useful extra configuration parameters come in handy. These are basically bits of extra configuration you can add to your VMs, and are stored in your VM’s .vmx configuration file. By simply editing your VM, you can add a configuration option which specifies how many Cores per Socket there are. To do this using vSphere, power off your VM, then edit it’s settings. Go to the Options tab, then General, then Configuration Paramaters.

 

 

In this case I have a VM with 4 x vCPUs, which shows up by default with 4 x processor sockets. I want this to be 4 x cores with 1 x socket. So now I would click “Add Row” and in the first empty column, enter: cpuid.coresPerSocket and use 4 as the value in the second column. See this screenshot for specifics (and adjust the value used depending on your desired configuration):

 

 

Power up your VM, and run coreinfo again, using

coreinfo.exe -c -s

 

You should now see that VMware is assigning 4 CPU cores per “Physical CPU socket”. In other words, your VM now has 1 x “physical” processor socket, and 4 x cores. Meaning your single processor application socket is now valid on this VM. Here is the result of assigning my VM a value of 4 for “cpuid.coresPerSocket” when it uses 4 x vCPUs in vSphere:

 

 

As you can now see, it has changed from the original configuration where it had 4 x Sockets listed under “Logical Processor to Socket Map” with a “Physical Processor” for each “Socket”, to showing the 4 x “Physical Processors” all on “Socket 0”.

 

If you are using VMware Workstation, this configuration is easy to do – just edit your VM settings, and look for the dropdown menu under the CPU configuration – change this to how many Processors you want and how many Cores per Processor you will use. (See the screenshot below for an example of 2 x Sockets with 2 x cores per socket):

 

 

Well, that is a brief overview of how to look at your Processor configuration (whether you are using a physical machine or a Virtual Machine), and how to change your CPU socket / core configurations using VMware vSphere or Workstation. The two uses I can think of as stated above are for licensing issues, or issues where you are being limited by what your guest OS can handle in terms of physical CPUs. Feel free to chime in, in the comments below if you can think of any other uses this may have, or if spot a mistake anywhere!

Installing and registering Balsamiq Mockups for a Terminal Server (Remote Desktop Server) environment

June 8th, 2011 7 comments

 

A bit of a specialised how-to here, but this is the process I did to allow this Adobe Air application to run on a Terminal Server (now known as Remote Desktop Session Host Server) environment for multiple users. The issue with just installing it for all users to start with, is that the licensing information that you register does not apply to all users. This is because license information is stored in each single user’s local profile / Documents (therefore is not applicable to all users). Here is the process I did to install the software and allow all users with access to the software to run it in licensed mode. (As well as a quick section on creating a security group to restrict access to the software based on group membership).

 

1. Install Mockups using terminal services install mode from the command line.

change user /install

MockupsForDesktop.exe -silent -desktopShortcut -programMenu -location "C:\Program files" -allowDownload

– Run the application from the start menu, then exit. Now use the command line to set the server back to execute mode.

change user /execute

2. Navigate to C:\Program Files\Balsamiq Mockups

– Create a new batch file (for example RegisterStartBalsamiqMockups.bat) in this folder and enter the following as content:

"Balsamiq Mockups.exe" register "Your registered company name" yourlonglicensekeynumber

– Save this batch file and close it.

– Now open the Local Profiles Folder for the terminal server, and navigate to \All Users\Start Menu\Programs

– Right click and drag your batch file into your \All Users\Start Menu\Programs folder and select to create a new shortcut.

– Right click your shortcut and change the icon to use the Icon from the Balsamiq Mockups.exe if you wish to make it look better.

– Also change the “Run” parameter to “Minimized” in the shortcut properties window and then OK this.

– Rename the shortcut to something user friendly, then remove the actual Balsamiq Mockups shortcut that the silent installer put in there earlier.

 

Now login with a normal Terminal Server user, and they should have the new shortcut file available in the start menu. Ensure they use this to start the application. It will register the license key each time they start the application, but it at least provides a way to automatically register the application for any user running the software.

Finally, ensure you set up a security group in Active Directory called “Balsamiq Mockups Users” and add only the users that are licensed for the software to this security group as members. Right-click the executable in C:\Program Files\Balsamiq Mockups for the application, go to properties, security, then remove the “Domain Users” or “All Users” groups from this executable (Effectively preventing them from running it). Add the “Balsamiq Mockups Users” security group in the place of the domain users group, and allow Read and Read & Execute permissions.

Now only the members of this security group (licensed for the software) will be able to run the software.

Hope that helps those of you looking to get this done. While this may not be a very general instruction set or how-to, some of the above principles can be used elsewhere – for example the security group method can be used to restrict access to certain applications within your organization for specific users.