Automate And Orchestrate Your P2V Migrations

  • Posted on: 7 September 2015
  • By: David La Motta


In a previous blog post, I talked about and introduced the Godwit Provider for your machine migration needs.  In this follow-up we are going to simplify things even further and show you how you can go from physical to vCloud Director in a ready-to-consume Integra workflow.  10 steps get you from physical to the cloud, notifications and checks included.  As a matter of fact, if we were to put this workflow on a diet we could accomplish the same result in a 4-step workflow.  Regardless, there are many different ways to tackle a problem and in this post you will see the steps we took on one of them to accomplish a migration.  If P2V migrations are on your radar, please contact us and we will be happy to put you in touch with one of our migration partners.


The Problem

Machine migrations pose a complicated set of problems.  You first need to find a downtime window so you can do the migration, and this typically is in the wee hours of the night when most of us are (or should be) asleep.  Migrations can be a lengthy operation, often taking hours to complete.  If you are doing this in the middle of the night, chances are you are getting the short end of the stick in terms of sleep depravation.  As soon as a conversion takes place, you will most likely want to do one last synchronization to catch any deltas that may have been created during the conversion process.  Again, if doing this by hand you are responsible for that.  A conversion to an .ova is another lengthy process, and so are uploads to the cloud.

In short, a machine migration is a pain.  You have to baby it until it is done, and in doing so you will spend countless hours.  That is time that can be better spent doing something else, perhaps doing something as basic as getting some sleep.  What happens if, just when you saw the light at the end of the tunnel, the migration fails?  It is back to square one, my friend.

And all this is just the tip of the iceberg.  If you want to have control over doing things in parallel, load balancing your converters, having full control over checkpoint notifications, retrying migrations on failure, doing thousands of migrations instead of a handful, etc., you are going to need a powerful platform such as Integra.

The Solution

Two words: orchestration and automation.  You need a full-control platform that lets you automate operations, but more importantly allows you to orchestrate key instruments to produce a marvelous symphony.  You need to be in control of all the details of the migration to a degree that only you can deem satisfactory or not.  Integra gives you all the flexibility and power you need in an easy to consume model.  Once you have crafted your migration workflow to your satisfaction, save it to Github and use it time and again for your migration needs.

Let us see how.

Providers

In this example we are going to rely on 2 providers: Godwit and Notification.  These two processes run on the same VM as the Integra Reactor.  As your migration solution gets more involved, there may be other providers that come into play; however, for this simple example we only need those 2 key players.




Actions

There are 12 actions in total.  2 more than the 10 we originally mentioned at the beginning of this post, but that is because those 2 extra actions are used when a migration failure takes place.  On failure, we have a workflow that sends out an email and an SMS, alerting you that something went wrong and is in need of your immediate attention.



As you can see in the image above, all actions rely heavily on the use of Integra variables.  We do this so that your workflow can be reused over and over, without having to be modified.  Instead, if you notice the Set Global Values action (ID 4), that is the action that loads all dynamic values from a file.  It is in that file where you ultimately specify the values that will be replaced at runtime in the actions, such as in the one shown above.

There are 4 actions that are the essence of the migration workflow that follows:
  1. Convert Guest
  2. Conversion Status
  3. Create OVA
  4. Upload OVA
The remaining operations send emails, do checks, and load values from a file but it is those 4 actions that do the migration per se.  It should be noted that the Convert Guest is a two-fold action: it triggers a conversion followed by an immediate synchronization.  In doing a synchronization as soon as the conversion finished, we reduce the chances of deltas incrementing in the base image.  As soon as the synchronization finishes we create an .ova.  In this particular example we take the .ova and upload it to vCloud Director.  Your destination may be different, but know that with Integra where you send your virtualized machine is just a matter of changing a small portion of the workflow.

Workflows

We have 2 workflows for this example, one for doing the migration and another for executing steps if a failure takes place.  We use backward chaining to immediately trigger one of the workflows when a failure takes place.  If on failure we wanted to retry the migration we could certainly do that as well, or if we were doing batches of migrations we could kick off another workflow.  The possibilities start to become limitless when you see the flexibility a platform such as Integra brings to the table.



Not shown are the steps for the Migration-Failure workflow, but as previously mentioned that workflow consists of sending an email and an SMS.  The values for those actions are also retrieved by the Set Global Values action, so that action is shared between both workflows.

Schedule

Since one of the tedious parts of machine migrations is finding a proper window to do it, the migration in this particular example was scheduled to run at 2:00 AM on Saturday.  With Integra it is easy to schedule workflow execution; however, a very interesting concept is that of executing scheduled workflows in parallel.  Any Integra workflow that is part of a schedule will be executed as part of the same Task.  This is particularly handy when doing large numbers of machine migrations.  Depending on how you architect your migration, you could save valuable time by executing migrations in parallel.



Results

After the schedule is set to run, there is no need to babysit this migration.  We get some sleep and next morning we verify the results of a successful migration to vCloud Director.




Here we see the .ova after it was successfully created and uploaded to vCloud Director.




As expected, the 4 emails arrived in the middle of the night, each one after a successful step in the workflow was completed.

Conclusion

Migrations are tedious, fragile and time consuming.  To do a migration successfully and without loosing any sleep, you are going to need a powerful orchestration platform where you are in control over what happens.  We haven't even gone into application consistency before a migration, doing batch migrations, load balancing or retries, but know that Integra as a platform gives you all that.  Do you have scripts that you have already written to help you in your migration endeavors?  That is great; don't throw that work out the window and let Integra invoke that code!

The Windows 2012 machine that was migrated in this example is relatively small.  From start to finish it took approximately 30 minutes to complete.  It doesn't sound as much now, but if you were to see the initial estimate given by the conversion tool you would have been equally surprised as I was when I saw it would take 1 hour 20 minutes.  And that was for the conversion alone!  Let's not even mention .ova creation and upload to vCloud Director.

In closing, create your migration workflow, schedule it, and go to sleep with piece of mind that Integra is doing precisely what you instructed it to do.  Nothing more, nothing less.

For those of us living in the United States, happy Labor Day 2015!

--