I have a very old VMware ESXi server that has outlived its useful life. The hardware is at least 5 years old and my VMware license has expired. I can still bring up the server and see the virtual machines, but that’s about it. I still keep the box so I can run the PowerCLI cmdlets, at least in a limited fashion. However, there are a few virtual machines that I need to get at so I can move some applications and data to another Hyper-V virtual machine. Since I can’t get the VMware virtual machine running, I can at least convert the disk to a VHDX and bring it up in a new Hyper-V virtual machine.

I already have PowerCLI 6.0 and the Hyper-V cmdlets installed on my computer. My initial thought was to use the free Microsoft Virtual Machine Converter which you can download. But I ran into a number of issues using the GUI, primarily because not everything is in the same domain. But that doesn’t really matter because I didn’t really want to migrate the complete virtual machine, I just needed to bring up the old VM temporarily so I could migrate things off. Fortunately, there are a set of cmdlets that ship with Microsoft’s converter. Here’s what I did.

First, I needed to connect to my ESXi box using the PowerCLI cmdlets.

I need to get the disk files for a given virtual machine. One benefit of PowerCLI is that you can easily browse the datastore files.

I’ll need all of these files. But first I need to be able to access them from the file system. Fortunately, PowerCLI has a handly cmdlet for copying items from a datastore to the file system.

Once the files are copied I can begin the conversion. However, the Microsoft virtual machine converter cmdlets aren’t installed in an expected location so I’ll have to manually import them.

Once imported, I can use ConvertTo-MvmcVirtualHardDisk.

The conversion took about 20 minutes for a 40GB file. The converted file was 30GB for a dynamic hard disk. With the conversion complete, it is pretty easy to fire up a new Hyper-V virtual machine.

You’ll notice that I am using a complete path for the New-VM cmdlet. That’s because in my session I have both PowerCLI and Hyper-V cmdlets and they both have a New-VM cmdlet. Normally I wouldn’t have both running in the same session but since I do, I need to explicitly tell PowerShell which cmdlet to use.

And that’s about it. Once running I uninstalled the VMware Tools, installed the Hyper-V Integration Toolkit and let Windows detect everything else. This would require me re-activating Windows, but I’m hoping to migrate everything I need before that becomes an issue.


Copy and Mount a CD with PowerCLI

The other day I realized I needed to rebuild my SQL Server 2012 installation which I’m running on a virtual machine running on an ESX box. Given that I have PowerCLI and I like to do things from the command prompt when I can, I decided to mount the SQL Server 2012 ISO on the VM using PowerShell. This actually requires a few steps that I thought I would share.

First, you naturally need to have PowerCLI installed. You will need to import the necessary snapins and connect to the ESX host.

Add-PSSnapin VMware.VimAutomation.core
Connect-viserver -Server ESX

Once connected, I can begin the process. Next, I need to copy the ISO file the datastore so that I can mount it from the VM. While the vmstore: PSDrive is fun to work with, you can’t copy from the filesystem. Copying between providers is simply not allowed. Instead I’ll use the Copy-DatastoreItem cmdlet. This will allow me to copy a local file to the VMware datastore.

The tricky part here is to get the right format for the datastore destination. This is where I want to copy to:

PS vmstore:\ha-datacenter\datastore3\ISO> dir

Datastore path: [datastore3] ISO

LastWriteTime Type Length Name
------------- ---- ------ ----
8/18/2009 9:09 AM IsoImageFile 2996799488 en_windows_server...

The “trick” is to grab the value for Datastore path from the directory listing. Thus, I can run this to copy the ISO file to the datastore.

Copy-DatastoreItem -Item $iso -Destination $dest -passthru

You get a nice progress bar and in a few minutes the file is copied. Now I can mount it in the VM’s CDDrive using Set-CDDrive. The cmdlet will need a CDDrive object from a VM and the path to the ISO file. I’ll have to construct a path using the VMware datastore format. It looks a little funny because it is not a typical Windows path.

$isopath = "[datastore3] ISO\en_sql_server_2012_standard_edition_with_sp1_x86_x64_dvd_1228143.iso"

For situations like this, I find it easiest to use the corresponding Get cmdlet, and pipe the resulting object to the Set cmdlet.

get-cddrive -VM "globomantics db" | set-cddrive -IsoPath $isopath -Connected $true

The only other parameter I specified was to connect the CDDrive to the VM. This command takes a moment to run and then in the VM I can “see” the DVD and use it normally. Awesome. When I’m finished I can dismount the CD much the same way.

get-cddrive -VM "globomantics db" | set-cddrive -NoMedia

This may seem like a lot of typing, but if it is something I need to do a lot I could build a simple script or function. And it is still faster (for me) than navigating the GUI.

Techmentor Orlando 2011 Decks and Demos

As promised, I have put together the most current versions of my slide decks and demos. A word of caution on the demos: many of them were designed to be used with my Start-Demo function, which essentially steps through the demo file one line at a time. The AD demos do include a few scripts but don't assume that anything is ready to run. Use the demos more for review or as a jump start for your own scripts.

Managing Active Directory with Windows PowerShell Slide deck demo files
Getting Started with PowerCLI Slide deck demo files
PowerShell Scripting Best Practices Slide deck demo files

In my PowerCLI session I also showed a VMware health check script written by Alan Renouf. You can download that script from his site.

I hope you found the sessions informative and useful. Of course a conference presentation just gets you started. If you or your organization would like more fomallized traiining, just ask.

PowerCLI VM Peek

Now that I believe I’ve resolved my hardware issues with my VMware server, I’m expecting to use it much more. I’m also continuing my exploration of the PowerCLI tool set which allows me to manage my virtual infrastructure from a Windows PowerShell session. One task that I frequently need is to identify which virtual machines are running, and especially the guest host name. Last week I tweeted a PowerShell one-liner.
[cc lang=”powerShell”]
get-vm | where {$_.powerstate -match “on”} | get-vmguest | select State,VMName,Hostname,OSFullname,IPAddress
This finds all virtual machines that are powered on then pipes that object to the Get-VMGuest cmdlet which returns the information I’m really after. Here’s a sample result.
[cc lang=”Powershell”]
State : Running
VmName : MyCompany Windows 7
HostName : Win7Desk01.MYCOMPANY.LOCAL
OSFullName : Microsoft Windows 7 (64-bit)
IPAddress : {}
Now, I could have simply saved that one-liner as a function or script block but naturally I had to take things a step further. I wanted a function that would also include some error handling and handle a connection to my VM host if it wasn’t already connected. Thus was born Get-RunningVM.
[cc lang=”Powershell”]
Function Get-RunningVM {


#verify we’re connected to a VM host
Try {
if (get-vmhost -Server $VMhost -State connected -erroraction “Stop”) {
Catch {
#Try to connect
Try {
$viserver=Connect-VIserver -Server $VMhost -protocol $protocol -port $port -user $user -password $password -errorAction “Stop”
Catch {
$msg=”Failed to connect to server {0} on {1}:{2} as user {3}” -f $vmhost,$protocol,$port,$user
Write-Warning $msg
Write-Warning $error[0].Exception.Message

#if we’re finally connected to a host, get running VMs
if ($connected) {
#get the powered on VMs and display VMGuest information
get-vm | where {$_.powerstate -match “on”} | get-vmguest |
select State,VMName,Hostname,OSFullname,IPAddress

} #end function
The function requires that the VMware snapin already be loaded. I have a nested set of Try/Catch constructs to check if I’m connected to VM host and if not, to do so. Once connected I execute my one-liner. I’m using basic, default connection information for my host since I’m not in a large enterprise environment. You might need to tweak the parameters. In fact, since I only have a single VM host, I’m not sure what other tweaks might be necessary for a multiple server environment. I’d love to get some real-world feedback on that. In fact, you will have to edit the default parameter values since the default VMHost is my server name. Using default values saves a lot of typing.

Download Get-RunningVM.

Running Veeam Jobs

I’m still fighting hardware issues with my ESX box (among other things) but I wanted to jot down some more notes on my experiences with PowerCLI and the Veeam backup cmdlets. Last week I wrote about how I created multiple backup jobs with a one line PowerShell expression.  After the jobs were created I needed to run them. For performance purposes I only wanted to run one at a time but I obviously wasn’t going to sit up all night staring at a computer screen.

My answer was to use Veeam’s Start-VBRJob cmdlet. The cmdlet takes a job name as a parameter, which you can pipe to it. All I needed was a collection of job names. I created an empty array, $jobs and then added one job that I knew I still needed for a VM on another datastore. The other new jobs were for VMs on datastore2. Using Get-VBRJob I retrieved all my Veeam jobs, piped them to Where-Object to filter out all jobs except those where the TargetDir property was G:\Datastore2, since I had all my datastore2 jobs backing up to the same location. For each matching backup job, I added the job name to the $jobs array.

Now that I had a collection of jobs, all that was left was to pipe it to Start-VBRJob.

PS C:\> $jobs | Start-VBRJob

The jobs run synchronously and you won’t get your PowerShell prompt back until all the jobs have finished which could be several hours. I was going to let it run overnight so it didn’t matter. But next time I would use a PowerShell job and let this run in the background.