Hello PowerCLI

 

So today is the first time I am trying out PowerCLI for vSphere. Yes, I know I am late to the game in the VMware scene, but I hope to start learning more about PowerCLI and start automating some tasks that are currently being done manually where I work.

 

Here is my first try at connecting to my lab vCenter server 🙂

 

Pretty simple really, just as the banner text says, use:
Connect-VIServer servername and
Get-VM

to connect and get a list of VMs. I guess this is my “Hello World” start out with PowerCLI then. If anyone has any tips or quick and easy cmdlets to run in PowerCLI to get information back, please drop a comment with them below. I would also love to know how to iterate through a list of VMs and check whether they have snapshots or not! That would be a great start to what I am looking to achieve.

Cheers!

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

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!

How to set up a VMware vSphere Lab in Virtual Machines, with DRS and HA

 

I recently wrote a (reasonably!) lengthy article on how to set up your own VMware vSphere lab or test environment consisting entirely of Virtual Machines, running off of one piece of host hardware. This is really handy as a lot of people new to Virtualization often think they need to purchase full on server equipment to create a white box, or find second hand servers off of eBay. Even more often, they make the mistake of overlooking the CPU feature set required to run vSphere – Hardware Virtualization, buying 64bit capable servers (good), but lacking the Intel VT or AMD-V feature-set required for vSphere (bad!)

 

This is when running everything virtualized comes in really handy. As well as keeping your hardware and lab requirements/size down, you have everything you need all in one installation of VMware Workstation. You’ll also be able to test out some really cool features that vSphere / vCenter Server has to offer – such as HA (High Availability) and DRS (Distributed Resource Scheduling). In the article I also make reference to a few best practises to have when configuring the real deal for production use. I hope this comprehensive guide is useful for those of you looking to set something like this up!

 

VMware lab consisting - nested VMs running in Virtualized ESXi hypervisors.

 

Read the article here on Simple-Talk.com to get started and see how its all done!

 

 

VM Clone using vCenter failed at about 90%

Just experienced this issue myself cloning a VM to another LUN / Datastore on a slightly older vSphere 4.0 update 1 environment. A quick google of the error message “Cannot clone VM-NAME1: Number of virtual devices exceeds the maximum for a given controller.” pointed me to VMware KB Article: 1016221 which clearly states that this is an issue when you select the “Edit virtual hardware (experimental) checkbox in the clone settings wizard.

Here is what the Tasks and Events section reports (blanked out the VM name and a host IP if you notice the missing parts).

To work around this, just make sure you don’t tick the “Edit virtual hardware (experimental) checkbox when you clone the VM. Edit the hardware after your clone has complete in the usual way. Apparently this occurs on both vCenter 4.0 and 4.0 update 1. Just another reason to move to vSphere 4.1 if you are still on 4.0!

Manage VMware Server 2.0 with Virtual Infrastructure Client instead of the Web UI

I personally find the Web UI a little slow for managing VMware Server 2.0 on my home lab and also prefer to use an interface more like the one I use at work when managing our vCenter and ESX hosts. So here is how to use the VMware Infrastructure Client to manage VMware Server 2.0. For this to work, ensure you use an older version of the Infrastructure Client. The one that comes with ESX 3.0 / 3.5 hosts seems to work well. The newer vSphere Client doesn’t work and gives you an error message when you try to login.

1. Grab a copy of the Virtual Infrastructure client and install it on the machine you are accessing your VMware Server Host from. I had trouble finding a download link, so I needed to pull it off an old ESX 3.5 host.

2. Install the client, then run it. At the login prompt enter the full web UI address of your VMware Server Host in the IP Address / Name section. So if you were trying locally on your host, you could enter https://localhost:8333 or from a remote machine use the IP address in the format https://x.x.x.x:8333

3. Enter your user name and password and hit “Login”. This should load up your VMware Server 2.0 server in the infrastructure client. Enjoy!