At Sea


vSphere Host Information Via PowerCLI

Recently I was required to gather some vSphere 4 host information for a documentation project. Some of this information is available and exportable from the vSphere 4 client but it's not all conveniently in the same place. I found it easier to gather this information via vSphere's PowerCLI rather than endlessly clicking around the interface.

get-vmhost | 
Select Name,
@{N="PhyMem"; E={[math]::truncate($_.MemoryTotalMB / 1024)} },
@{N="Product";E={(Get-View $_.ID).Config.Product.FullName }} | 
Sort NameĀ | 
format-table -auto

The output looks something like this:

Name       Manufacturer              Model          ConnectionState PhyMem NumCpu Cores/CPU Sockets Product
----       ------------              -----          --------------- ------ ------ --------- ------- -------
x.x.x.x    Dell Inc.                 PowerEdge R710       Connected     47     12         6       2 VMware ESXi 4.1.0 build-123456

The output can easily be exported by replacing format-table with Export-Csv.


I've never been a Facebook user, primarily because of the onerous privacy controls and concerns over Facebooks privacy game of kick the can. Google+ seems to have resolved my concerns in an elegant way allowing me to communicate with the people I want to, in the way I want to. I'm able to delete all of my Google+ social content if I want and when it comes down to it, I trust Google more than I trust Facebook. You can find me on Google+.

Possible VMWare vSphere 5 Release Date

While looking for VMA 4.1 documentation I came across this bit of time travel. VMA version 5.0 with a realease date of August 5 2011, which is just about 2 months from now. If VMA is being upgraded to 5, I would suspect vSphere would also see an update around that same time. I should note that the links for the VMA 5 docs were broken.



MSSQL Server Conversion with VMWare Converter

I ran into an issue with VMWare converter hanging while in block conversion mode while trying to virtualize an instance of Microsoft SQL server. It turns out that it's a known issue in version 4.3 of the standalone converter. My conversion was hanging due to the cluster size of some disks being larger than 4k. It's very common to use 64k cluster sizes for SQL data volumes and converter was completely hung up while trying to convert those disks. Thankfully there is a workaround.

First you'll have to stop the conversion by closing converter and stopping the vmware converter services. Then remove the partially imported virtual machine giving you a clean slate from which to start.

To determine which disks are affected run the following command as an administrative user on each drive of the target you're converting to determine if "Bytes Per Cluster" is larger than 4096:

fsutil fsinfo ntfsinfo c:

If "Bytes Per Cluster" is larger than 4096, you can force a file level copy by reducing the volume size for each volume affected. In my case I simply recreated my conversion task and reduced each affected volume by one gigabyte.