Automating VM Migration - VMM and V2V (Part 3)

Ostrich-rides

In my last post we covered some ways of removing VMware Tools from your VMs so that your conversion would go more smoothly. Next we need to tee up the conversion by getting the VMs to the VMM Library so that we can start our V2V.

Getting the VM to the VMM Library

Before VMM can convert the VM, it needs to know about them. The way to do this is to copy the VM files you want to convert into your VMM library. Getting them to the VMM Library can be a challenging thing to automate.  The files are on your VMware datastore and that isn't’ something that’s readily accessible from Windows. But just because it isn’t readily accessible doesn’t mean we can’t get it done. Turns out there are two approaches to get this done: batched and fully unattended

Batched approach

Most VMware administrators are quite comfortable with the vSphere client and know that it provides the ability to copy files to and from the datastores. Although copying files using vSphere client is a manual process, it might not be that much of a limiting factor. Most companies want to run batches of conversions rather than just converting the entire datacenter at the push of a really, really big button. I think a batched approach can be very sensible since the machines being converted need to be offline to convert them.

Let’s say you decide that you want to convert five VMs in your nightly maintenance window. If that’s the case then just multi-select the folder’s that contain those five VMs and copy them out to the VMM Library. Once that’s done you can start you’re the rest of your conversion. It’s not super-automated but it doesn’t really need to be. You can also use other tools like the VMware converter to effectively move a group of VM (or their files anyway) out to the VMM Library. The converter is an odd choice though assuming you have the vSphere client. Maybe it makes sense if you lost it though, or if you just have a really deep appreciation for irony.

Unattended approach

Batching is all well and good but let’s talk about how we would actually automate copying files from the VMware datastore to the VMM Library. The challenge here is that the only way to get files off the datastore is via SCP (Secure Copy Protocol). SCP is file copy over SSH used mostly in UNIX-style environments so there is no windows equivalent command or feature built-in to Windows.

What that means is you need to script the SCP commands either from directly inside an SSH session on the ESX host or find a scriptable tool to get files copied from the Windows side of things. If you don’t know where to start check out PuTTY or WinSCP.

PuTTY– PuTTY is a pretty widely used SSH client (among other things). You can use the PuTTY scripting abilities to automatically copy files using the native scp commands.

WinSCP– WinSCP is a windows-based SCP client that sports a full UI but also has the ability to be scripted.

System Center Orchestrator 2012 SP1 - if you have System Center you also have Orchestrator at your disposal. You can create runbooks to copy these files as well. Orchestrator has it’s own SSH activities which can be employed to start your copy, or you can point it’s mighty automating powers at WinSCP, PuTTY or any of the other scriptable tools out there.

There are several other options out there too, I just want to give you some ideas. Since there are several approaches here that involve separate scripting skills I’m not going any deeper than pointing out options. I may be persuaded to create a post around using Orchestrator down the road though.

Refresh your library – at the right time

Once you have the files copied into your VMM library you will need to refresh the library so that VMM can have a look at the files and add the VMs as resources. By default the VMM Library will refresh once every hour (which is the lowest value you can assign). If you wait on the refresh you will be slowing down your conversion for no good reason.

The good news is we can automate the refresh with a simple PowerShell command.

WARNING: Before you go copying VMs to the library you need to plan a little. The VMM Library will refresh (by default) every hour. If you are in the middle of copying files to the library when the refresh happens, VMM will make a very unhappy face at you. Consider that once it refreshes, VMM will find incomplete VMs (as they aren’t done yet). VMM has no way of knowing you are still copying the file and so it will mark the VM as having errors and leave you a mess to clean up.

To avoid this don’t copy the files to the VMM library.

Don’t copy your VM to the VMM Library

Wait, what? But you just said…

I know. Hear me out. Don’t copy the files directly to the VMM library. Doing so is setting yourself up for a refresh error. Instead, copy them to an adjacent folder on the same physical disk. This way you can complete the entire batch of copies (or even for a single copy for that matter) and then move the files into the Library. The file move will be quick. Especially since it’s a simple update to the file table, moving the pointer from one folder to the next. No bits need to move this time, got it?

Once the move it done, then kick off your refresh and you’ll be in good shape.

Refresh the Library with PowerShell

The cmdlet you need to use is Read-SCLibraryShare. The full syntax is below. Once you have the files in the VMM Library, kick this sucker off and VMM will know about all the VMs you just copied over.

Read-SCLibraryShare [-LibraryShare] <LibraryShare> [-JobVariable <String> ] [-Path <String> ] [-PROTipID <Guid> ] [-RunAsynchronously] [ <CommonParameters>]

 

Finally, run the V2V

With the VMM library finally seeing the VMs you can now get down to the business of actually running the V2V cmdlet.

The V2V cmdlet is actually called New-SCV2V and it isn’t normally a command you fire off with a single line. Instead you build it up with options as you go. The command is pretty well documented so I’ll just provide some basic guidance.

If you aren’t familiar with the cmdlet, you definitely want to run the Conversion Wizard and step through the process. This will help you understand what options are used by the conversion. Some information will come from the vmx files during the wizard but if you are automating this set, you will need to provide it directly. As I mentioned in Part 1 of this series, make use of the View Script button at the end of the wizard. This will provide you with a script based on the information you provided. This is absolutely the best reference you can have to understanding the conversion cmdlet(s).

Here’s an example: (I have altered the original output a little to help explain it better)

# ------------------------------------------------------------------------------
# Convert Virtual Machine Wizard Script
# ------------------------------------------------------------------------------
# Script generated on Monday, April 1, 2013 11:01:47 PM by Virtual Machine Manager
#
# For additional help on cmdlet usage, type get-help <cmdlet name>
# ------------------------------------------------------------------------------

$VMHost = Get-SCVMHost -VMMServer localhost | where {$_.Name -eq "HV-host.contoso.com"}

$VM = Get-SCVirtualMachine -VMMServer localhost -Name "GUESTVM" | where {$_.LibraryServer.Name -eq "VMMServer.contoso.com"} | where {$_.Location -eq \\VMMServer.contoso.com\MSSCVMMLibrary\GUESTVM}

$VirtualNetworkAdapter = Get-SCVirtualNetworkAdapter -VMMServer localhost -Name "GUESTVM"

New-SCV2V -VMMServer localhost -VMHost $VMHost -RunAsynchronously -JobGroup c5797db4-9b0c-42b1-a5a9-dce64100185c -VM $VM -NoConnection -VirtualNetworkAdapter $VirtualNetworkAdapter

New-SCV2V -VM $VM -VMHost $VMHost -Path "D:\VMs" -Name "GUESTVM" -Description "" -RunAsynchronously -JobGroup c5797db4-9b0c-42b1-a5a9-dce64100185c -Trigger -CPUCount 1 -MemoryMB 1024 -StartAction NeverAutoTurnOnVM -StopAction SaveVM

 

As you can see the final command, which includes the –Trigger option requires a few steps to get created. The steps (at their most basic level) are:

  1. Get $VMHost which is the machine which will serve as your Hyper-V Host. This returns an object not just a name.
  2. Get $VM which is the target Virtual Machine from the VMM Library. This returns an object.
  3. Get $VirtualNetworkAdapter, which is the network adapter for $VM. This returns one or more objects. If there is more than one of these you will want to construct a for each loop to iterate them all and create a corresponding New-SCV2V command to add each one. If you run the wizard against a machine with multiple NICs, you will see that steps 1-3 will be repeated in the script for each new NIC. You don’t need to repeat the steps, you can capture all of them into an array and step through the array.
  4. Setup the elements of the New-SCV2V command. For each VM you want to convert you will need to create a JobGroup and assign all the options to that group (for example if you have several network adapters). To assign the command to a JobGroup use the –JobGroup option and give the group a GUID. You can create a GUID for this purpose by using $JobGroup = [System.Guid]::NewGuid() and then refer to $JobID for all other updates to that JobGroup.
  5. Once you have all the elements added to the JobGroup, you can run the command. You can see there are a few options included with –Trigger like CPU count, memory, start and stop options, etc.

The 5th step will get the V2V started. Once the V2V completes, you are done. and you can go get the next machine in your list and start over.

NOTE: You can run more than one V2V at the same time. Generally you should be able to run at least two at the same time without any performance penalties. You may be able to run more, just test the performance as you increase this value.

Wrapping it up

How you stitch all this together will depend on what skills you have and which environments you are most comfortable in.

Can you do all this with PowerShell?

You bet.

How about using Orchestrator?

Sure thing.

What about…

Look, there are loads of options to get this done. I always recommend working in an environment that you are comfortable and knowledgeable in. So go out and give this a try. Be sure and let me know how it works out for you. Share what you learn with the community!

So that’s it for my series on Automating VM Migration. Next time we will look into automating Microsoft’s free tool for conversions: The Microsoft Virtual Machine Converter.