PlateSpin Migrate best practices

I have been using Novell PlateSpin Migrate for a while now and like to share my experiences on using the software. This article will be part of a series of articles on using PlateSpin Migrate. I will include information on best practices, tips and tricks, issues and how to resolve issues and support by Novell.

Novell acquired Canadian company PlateSpin in March 2008. PlateSpin developed PlateSpin PowerConvert which was rebranded by Novell to the current label Novell PlateSpin Migrate, part of Portability Suite. The current version is 8.1.3. This suite consists of PlateSpin Migrate and PlateSpin Protect. While Migrate is used for one time conversion of workloads, Protect is used for protection of physical and virtual server by synchronization of the data of workloads to a standby virtual machine running in a fenced off network. Synchronization will be autmatically performed at regular intervals. An evaluation copy of Migrate can be downloaded from the Novell.com website. Unfortunately the latest version is hidden a bit. Using this link you can download version 8.1.3. Evaluation licenses can be requested from the same webpage. You will need to register at the Novell.com website for that.

PlateSpin Migrate can be used for moving workloads. The term workload is used to prevent confusing with the term server. A workload consists of operating system, applications and data. PlateSpin is able to move and copy a workload from a physical server to a virtualization host (P2V). Host types supported are Microsoft Hyper-V, VMware ESX, Citrix XenServer and Oracle Virtual Iron. Other types of workload conversions are Virtual to Physical (V2)), Virtual to Virtual (V2V), Image to Virtual (I2V) and reverse. PlateSpin Migrate is one of the few conversion tools available which is able to perform a Virtual to Physical conversion. It is also able to perform a P2V conversion while both physical and virtual server are online. The virtual server can be used for testing. If the virtual machine is accepted by the application owner, a resync of data can be performed. This reduces downtime.

PlateSpin Migrate architecture

The Portability Suite uses the following components:

-a SQL database used for storage of inventory details of servers, hosts, vCenter Server etc. It also holds stores the jobs and results of the jobs.

-the PlateSpin server service. This is the actual orchestrator , instructing controllers and communicating with the controllers.

-Controllers. The controllers are installed on the target and source server and perform tasks like file transfer.

-the PlateSpin Portability Suite Client. The client is used for performing the X2X conversion. The client can be installed on the same server as the PlateSpin database and PlateSpin server is installed.

However, only one instance of the client can be active on the same server.! If one user has started the client on the server, another user cannot use the client which runs on the same user. No errors are show after starting the second instance of the client. If multiple persons needs to have access to the Portability Suite client, the client needs to be installed on a workstation, management server etc. This works fine, although the interface is sometimes a little strange as buttons are a bit hidden.

Installation
Make sure the ESX host you are going to place VM’s on are licenced. The free ESXi version does not allow the use of API’s which are used to create and edit virtual machines! The evaluation version will work, till it expires.

Also make sure User Access Control is disable before PlateSpin Migrate server is installed. It could lead to strange issues.

Support for distributed virtual switches (vSphere 4 )

The latest release of Portability Suite (8.1.3) does not support distributed virtual switches. If your VMware infrastructure is using distributed virtual switches with virtual  machine portgroups only (no standard switches to connect the VM to) you will not be able to use PlateSpin Migrate! Migrate only supports standard switches!

Workaround is to dedicate one of your hosts as a landing host for P2V conversions. See also this article

http://virtualnut.wordpress.com/2009/12/16/platespin-migrate-dont-remove-your-local-port-groups/

Test network performance
To make sure the data transfer from the source to the target server is as fast as possible, perform some performance testing of the network. You can use a simple copy job for this. I have seen network issues which caused very slow transfers of PlateSpin. If you have a limited downtime or are working off holurs you will be happy to have a good transfer speed.

Performing Conversions

Installation of PlateSpin Migrate is easy. I advise to install PlateSpin Migrate on a virtual server. This makes it easier for creation of additional network interfaces on the PlateSpin server. To be able to convert a workload running on a physical server to a workload running on a virtual server you will need the following:

  •  -local administrator rights on the source server. This is for installing agent, performing an inventory of the server and, during post- conversion, being able to delete hardware specific drivers, install VMware Tools etc.
  • -if firewalls exists between source server, target server and PlateSpin Server some ports need to be open for inventory, transfers and creation of virtual machines.
  • -sufficient rights on VMware vCenter Server to create virtual machine and edit settings.
  • -a DHCP server which is reachable from the network the target virtual machine is connected to or a fixed IP-address. Make sure your have enough IP-adresses available. For each simultaneous conversion you will need an unique IP-address. This IP-adress is used for the Take Control image which is used for the actual data transfer.

P2V Conversion process explained.

When a P2V conversion using the Copy workload type of job, the following actions will be performed by PlateSpin Migrate.

  1. A virtual machine will be created by the PlateSpin Migrate job.
  2. A bootable .ISO file is connected to the virtual CD-ROM drive of the virtual machine
  3. An .ISO is mounted to the floppy drive of the virtual machine
  4. The virtual machine is booted. It loads Windows XPe (Preinstallation Environment) off the .ISO.
  5. The Windows XPe virtual machine uses either the fixed IP address defined in the wizard, or a DHCP-assigned address.
  6. The Windows XPe virtual machine will download a controller from the Platespin server. The controller is used for the transfer of data between source server and target server.
  7. After the data tranfer has finished the virtual machine will reboot, and load the guest operating system.
  8. VMware tools will be installed if selected at the wizard, and some pre conversion jobs will be performed. Communication between the target virtual machine and the Portability Suite server is needed to finish this part of the job.

Depending choices made in the wizard, the source server and target server will shutdown or remain online. Source and target server can online be online if the target virtual machine server is connected to an external vswitch (a virtual switch with no network cards connected). For PlateSpin Migrate be able to perform post conversion jobs while the guest operating system on the target virtual machine is loaded, network connectivity between the target server and the PlateSpin server is needed. This is a problem as the target server is not connected to an external switch. Make sure the PlateSpin server has a network interface which is connected to the same internal vSwitch as the target virtual machine.

Procedure to perform an online P2V conversion, to prepare for a final conversion or for testing.

PlateSpin Migrate has a feature called Server Sync. Using Server Sync, the target server can be synchronized with the source server. This feature can be helpful when downtime of the source server needs to be kept to a minimum. It is also helpful to create a virtual machine, test if it is running okay and after successful testing, copy the changed data from the source server to the target server. The procedure below explains how:

  1.  Create a virtual switch on the destination host (or a distributed vSwitch) with no network interfaces (an external switch). Then create a virtual machine portgroup. Name this portgroup for example PlateSpin.
  2. Select a Copy workload job. Make sure the destination ESX host the target VM will be created on, is the same host on which the Portability Suite server is running on.!! This ensures that Portability Suite server is able to configuere the guest operating system.
  3. To keep services like SQL or Exchange running on the source server, select the Live block based transfer.
  4. In the Take Control tab, select a portgroup and select either DHCP or type an IP-address. Make sure source server and the Take Control network are able to communicate with eachother over the network.
  5. The wizard will show an IP-conflict between source and target server. To clear this, connect all network interfaces of the target server to the portgroup created in step 1 (called Platespin)
  6. Finish the wizard and start the conversion.

What will happen is a virtual machine will be created with no network connectivity (fenced off network). This can be used for testing of applications without disturbing the physical server which remains online. The limitation is that if for testing connections to other servers are needed, those servers need to be in the fenced off network as well. Besides testing, preparing a virtual machine will save on downtime. Because most of the data is already placed on the virtual machine disk files, after testing only the changed data (delta) on the source server needs to be synchronized to the virtual machine. Thereafter, the physical server can be shutdown, and the virtual server network interfaces can be connected to a virtual switch with network connectivity.

Limitations on using online block based conversions.

Online, blockbased conversions are very helpful to keep downtime of applications limited. A limitation of PlateSpin Migrate is that using this method, volumes cannot be resized. A block level transfer will transfer blocks of data, not files. This is the fastest of the two transfer methodes. There is no way of doing an online conversion AND resizing volumes. The only way to resize is by manually adjusting the volume or by creation of a new, smaller sized .VMDK and copying data over. My customer has a lot of SQL servers having a E: partition used to store SQL backups on disk. This E: partition is sized around 500 GB while the SQL backups are around 50 GB. It is a waste of expensive SAN storage to allocate 500 GB of storage while only 10% is used. This can be ‘solved’ by using thin provisioned disks. However, closely monitor the datastores hosting thin provisioned disk to prevent running out of physical disk space. This will halt all of your VM’s stored on the overprovisioned datastore.

Windows PE Take Control

For the initial transfer of data from the source server to a virtual server a virtual machine is created using Microsoft Windows PE as guest operating system. This VM has 348 MB internal memory assigned. I noticed that at on occasion the P2V process stopped because there was no virtual memory available. Not sure under what circumstances this happens. Might be because of a lot of data to be transfered. Also might that WinPe will only be running for 24 hours max. After 24 hours, the machine will reboot. That is to prevent WinPe from being used as a operating system for day to day use.

Split partitions

Create a separate .vmdk file for every partition to be created during a P2V. This has two reasons:

1. you are able to place a VMDK on either slow (tier3) or fast storage (tier1) storage.

2. Platespin will allign only the first partition of a VMDK during P2V. Correct alignment is important for performance reasons. VMware Converter will not auto-align vmdk’s.

P2V conversions using filelevel transfer with source servers having lots of files (over 100.000)
We has an issue while converting a physical server having many small files. One of the volumes had over 400.000 files! Also, the volume on the physical server was too small, so we decided to adjust the volume size of the target virtual machine. This means a blockbased transfer cannot be used as this needs volumes sizes on source and target server to be the same. Filebased transfer had to be used. The disadvantage is that this method takes much longer to transfer files.
What we saw is that the server sync job failed each time we tried to run it. We saw a System.OutofMemoryException. Platespin has a knowledge base article on this.

Platespin creates a index of all files which needs to be transfered when a filebased transfer is selected. If the source server has many files this index gets too large and you will see out of memory or jobs that seems to hang at 1%.

Solution is to use blockbased transfer and adjust the volume size later.

Advertisements

About Marcel van den Berg
I am a technical consultant with a strong focus on server virtualization, desktop virtualization, cloud computing and business continuity/disaster recovery.

2 Responses to PlateSpin Migrate best practices

  1. Pingback: P2V conversion tips and tricks « UP2V

  2. siva says:

    nice…and goood hardwork..

    keep it up sir

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: