This is a very quick post today, but relates to an issue I had after upgrading my VMware Fusion install from 5.x to 6.0.2.
I am running a Windows 8 SP1 guest VM for development purposes on my mac, and right after upgrading and booting my Windows VM noticed this. The issue is that all the Windows UI elements – icons, text, etc look humongous on my 1920×1200 LCD monitor. The macbook’s LCD itself looked OK though. You can’t really see it that well in the screenshot below, but trust me, the section below with a few icons was about a quarter of my screen.
I knew this was a new setting that had somehow been toggled in Fusion since the upgrade, so I had a quick look around and found it. To disable this feature, go to your Virtual Machine Settings -> Display, and untick “Automatically adjust user interface size in Windows”.
Fusion will prompt you to logout of your current user session in the Windows VM. After logging back in again, things should be back to normal.
Hope that saves someone 15 minutes of looking for the cause in the future!
I was on a vSphere upgrade review engagement recently, and part of this involved checking hardware and existing vSphere VI was compatible with the targeted upgrade.
To help myself along, I created a few PowerCLI scripts to help with information gathering to CSV for the VI parts – such as Host Versions, build numbers, VMware tools and hardware versions, etc… These scripts were built to run once-off, simply either by copy/pasting them into your PowerCLI console, or by running them from the PowerCLI console directly.
They can easily be adapted to collect other information relating to VMs or hosts. To run, just launch PowerCLI, connect to the VC in question (using Connect-VIServer) and then copy/paste these into the console. The output will be saved to CSV in the directory you were in. Just make sure you unblock the zip file once downloaded if you execute them directly from PowerCLI, otherwise the copy/paste option mentioned above will work fine too.
There are three scripts bundled in the zip file:
Gather all hosts under the connected vCenter server and output Host name, Model and Bios version results to PowerCLI window and CSV
Gather all hosts under the connected vCenter server and output Host name, Version and Build version results to PowerCLI window and CSV
Gather all hosts under the specified DC and output VM name and hardware version results to PowerCLI window and CSV
Short and simple scripts, but hopefully they will come in handy to some. As mentioned above, these can easily be extended to fetch other information about items in your environment. Just take a look at the way existing info is fetched, and adapt from there. Also remember that using | gm (get-member) on objects in PowerShell is your friend – you can discover all the properties and methods on PowerShell objects by using this, and use those to enhance your reports/outputs in your scripts.
Quite some time ago I created a PowerCLI function to help me determine VMware Tools versions of queried VMs using PowerCLI. The tools version is returned as a 4 digit number by the vSphere API, and subsequently, so does PowerCLI. This makes determining VMware Tools versions at a glance, a bit of a hassle.
The original function was able to output Tools versions up to ESXi 4.1 u1 or u2, and this week was the first time I had a good use case for this script. I needed more up to date mappings, so I have updated the function to work with VMware tools versions all the way up to ESXi 5.5 now.
It’s not often that I push for votes or request votes for anything, but I am keen to win this one!
PuppetLabs are doing a competition where you submit GIF animations depicting an IT “horror story” with humor. My entry is below and I would love if you could check it out and hit the Vote button just below my entry GIF on the link to follow…
William Lam has done some excellent blog posts on using the simulator included with the VCSA (vCenter Server Appliance), to setup a simulated vSphere environment. Just the other day at VMworld Europe, he presented a session for vBrownBag entitled “NotSupported Tips/Tricks for vSphere 5.5“. In this session he introduced the new simulator, he dubs “VCSIM 2.0”, which is the latest iteration included with the VCSA 5.5 appliance.
I had previously had a brief look at the VCSIM included with 5.1, but after seeing its limited functionality, did not pursue its use for development testing. However, after learning about the features introduced in VCSIM “2.0”, I just had to take a further look…
To see how to setup and start VCSIM, have a read of Will’s blog post here. However, at a high level, this is what you need to do to start the simulator with defaults:
Deploy and fully configure the VCSA 5.5 appliance. Make sure DNS (forward and reverse) is working and the embedded database is properly configured, otherwise the vpxa service will have trouble intialising
Ensure you have no issues with the embedded DB being reset (i.e. don’t do this on a production VCSA!)
SSH in to the appliance
issue command: vmware-vcsim-start default
Customising the default VCSIM ESXi host model
Today, I needed to replicate a certain condition in our lab environment. Specifically, I needed the ESXi hosts to have 32 CPU cores. By default the ESXi hosts that are simulated have 8 cores. I did a bit of digging around in the /etc/vmware-vpx/vcsim/model folder and figured out which files were referenced when launching the simulator with the default option. By default, the host model in the ESX50 folder is used, so naturally, in order to configure custom ESXi hosts, we need to edit the files within this folder.
Initially, I found one file, “HostHardwareInfo.xml” and changed the CPU core count value to 32. This appeared to work – starting up the sim, and looking at the Web Client, I saw that the simulated hosts were now showing 32 CPU cores. I also changed the RAM up to 32GB (from the default of 16) just to test another option, and this was also showing up. However, upon loading up the MOB (Managed Object Browser), and navigating to the these hosts, I saw that the properties under the host summary->config->hardware were telling another story – they were still set to 8 cores and 16GB RAM. A little more digging revealed that another file, “HostListSummary.xml” also needed to be updated.
So in order to setup your custom ESXi host models for the default VCSIM profile, make sure you update both of these files.
The files to update your default ESXi model
Here is the small change I made to increase the Host core count to 32 cores.
Make sure you backup these files before changing them, so that you can roll back if you need to. There are other ways of creating your own profiles for the simulator, but I could not find any documentation on how to create custom hosts. The only bits I could find were relating to creating your own datastores. You can also use the default profile template to create your own profile in it’s entirety, and this is a better long term solution, however to get things up and running quickly with the default profile, the above works nicely.
Note that all properties and methods pertaining to each managed object found in the API appear to be set up and created when using the VCSIM, so this makes a great development/testing/lab tool. Kudos to VMware for releasing this with the VCSA, and thanks to William Lam for pointing it out and blogging about it!