Novell PlateSpin Migrate 9.1 new features

Novell released version 9.1 of PlateSpin Migrate at August 5, 2o11. I have not been working with the product for a while so the release was unnoticed by me. Some new features are usefull. Mind that VMware has added some interesting new features in the free VMware Converter. A very usufull feature is the incremental synchronization. This enables to virtualize the source server in two steps. First all of the data while the applications on the source server are active. Then during off hours the incremental data. Read more here.

Release notes of Migrate 9.1 here.
New features are:

Support for SLES 9 and OES2 workloads

The addition of support for migrations of source workloads running SUSE Linux Enterprise 9 and Open Enterprise Server 2 expands the already market-leading range of workloads supported by PlateSpin Migrate.

Bandwidth throttling and compression

Bandwidth throttling gives you a greater degree of control over the amount of network resources used by PlateSpin Migrate during migration jobs. You can now reduce network strain during peak hours, and maximize network usage during off hours.

Compression also allows a greater degree of bandwidth consumption control, by reducing the amount of raw data sent over the network.

NAT Support

Support for Network Address Translation (NAT) environments allows PlateSpin Migrate to now be used in a much less intrusive way for source workloads residing behind a NAT environment. This gives you more flexibility and easier configuration for wide-area-network migrations, since PlateSpin Migrate can now be a viable migration option even in the absence of a Virtual Private Network (VPN).

Thin Disk Support

PlateSpin Migrate now has the ability to leverage the thin provisioning capabilities of the ESX hypervisor. Leveraging thin disks gives you a greater degree of control and flexibility over the total disk storage required for virtual machines. Workloads with large amounts of free space are no longer required to have the same level of free space allocated when converted to a virtual machine.

VMware Converter 5 Beta compared to Novell PlateSpin Migrate 9.1

Two of the most common tools used for conversions of physical servers to virtual machines on VMware platforms are VMware Converter and Novell PlateSpin Migrate. VMware Converter Standalone is free to use while PlateSpin Migrate needs a license for every workload (server to be converted). 
VMware released in the beginning of June a public beta of the next release of Converter: version 5.  
Novell is expected to release a new version of PlateSpin Migrate. Version 9.1 to be released at July 15.

VMware Converter 5 is having almost all the features that PlateSpin Migrate has. The current release of PlateSpin is missing some features which can be quite handy. Being able to thin provision virtual disk is one of those features. PlateSpin has been slow in adopting new vSphere features.  Support for distributed switches was also added quite some time after being released by VMware.

VMware Converter Standalone 5 beta.
Version 5 has two interesting new features which are currently only available in PlateSpin Migrate. The first new feature is the ability to align virtual diskfiles with the storage system. This is important to prevent performance issues. A lot can be found on Internet about alignment.
The second new feature is the ability to synchronize data after the conversion has ended. In the current version the process of a conversion is that a source physical server can be running while performing the conversion (hot clone). When the data transfer has ended a last synchronization will take place to make sure the changes in data during the file transfer are copied to the target virtual machine. This does not allow for a conversion split in two jobs in which the last job is to be run during off hours copying only the incremental data. Using PlateSpin it is possible to perform an intial creation of the virtual machine and the data during office hours. Then, at off hours a synchronization job can be performed while the applications/services are down syncing only the changed delta.

With Converter 5 there is also an option for “enhanced synchronization”, allowing to run multiple incremental updates and actually schedule them for appropriate time.

Novell PlateSpin Migrate 9.1
So far there has not been an option in the conversion job properties to set which virtual network adapter should be used. Migrate installs the flexible adapter which. This has been fixed in the 9.1 version. The default logic will be to use the best adapter available on the target host for the VM type being created.

Thin provisioning of virtual disk is a feature that finally will be available in at least PlateSpin Protect. Not sure if it will be available in the 9.1 release of Migrate.

There are still some features on the wishlist. Like  the ability to select the VMware paravirtual SCSI controller in the job (choices are now limited to LSI Logic and bus Logic). Also the ability to set the annotations to something else as the default of Migrate ‘Virtual Machine created by PlateSpin on <date> and <time>’ would be nice.

The current version of Migrate can have issues with multi-homed source servers (servers with more than one network adapter). While the deployment of the agent is succesfull, the file transfer will hang at 1 % with an error saying ‘no response on port 3725. This happens because the agent/controller is using the wrong network adapter. Sometimes this can be solved by disabling all but one adapters but this workaround is not usefull for live servers.

The new version of Migrate will include NAT support, which will be beneficial in this type of scenario. Essentially, NAT support allows the user to define the IPs used for communication during the migration jobs. Being able to specify the IP on which both the PS server and source/target servers communicate has proven to be beneficial in cases like this.

Migrate  still has some unique features. It will automatically configure the IP-configuration on the target server. Using Converter first the original adapter needs to be removed before the IP configuration can be set on the virtual adapters manually. This is additional labour and can lead to errors.
Also Migrate is able to convert to Hyper-V and perform virtual to physical conversions.

PlateSpin Migrate transfer speed

The time PlateSpin needs to tranfer the data from a phyiscal server to a virtual machine obviously depends on several things. The bandwidth of the network and amount of data to be transfered are the most important parameters.

Before a P2V project is started, make sure the bandwidth between the source servers and the destination servers is tested and performs as expected. I have seen some examples were there was a 100 MBps link between the source and target servers while on the same 1 GB LAN. Do not assume the network performs at the link  same speed as the link connection between server and switch. A lot of components in between source and target can influence the overal bandwidth.

It is important to get the best possible speed to reduce the transfer time. This will speed up the time needed to finish the project and more important, it will reduce the downtime of the application during the initial transfer and synchronization jobs delta and maybe even more important, the best possible bandwidth will save you a lot of extra hours during off hours.

To give an idea of the amount of time I hereby give the speed of a P2V conversion project I recently did for a customer. The speed for the data transfer was around 244 GB of data in one hour for a  block based transfer on a 1 GB LAN network .

Time from start of the job to the start of the actual file transfer is 8 minutes. Time to complete the job after the data transfer has finished is around 16 minutes.

Next release of Novell PlateSpin Migrate expected in June

The next release of PlateSpin Migrate is expected to be available in June 2011. It will have the ability to throttle the bandwidth on tranfer sessions according to this posting on the Novell site.

PlateSpin Migrate job hangs at stage 2.3.1 preparing files

While doing a ‘prepare for synchronization’ job the job hangs at stage 2.3.1 preparing files. The job is 76 % complete.

https put file failed .. Reason unable to connect to the remote server.

Solution: PlateSpin Migrate server is unable to connect to the VMware vCenter Server to upload files used for the helper VM. A reboot of the vCenter Server and restart of the job solved the problem.

PlateSpin Migrate data transfer troubleshooting

One of the most common problems on using PlateSpin Migrate is the data transfer process. After the target VM has been created and booted with Windows PE, a process is started on the target to receive files from the source server. The process which does the transfer is ofxcontroller.exe . The data is send from source to target over port 3725 TCP. There can be a number of reasons why the data transfers does not get further than 1% and stalls / hangs . If the process is at 2% most of the times the data tranfers will succeed to 100%. After a succesful data tranfer, the job almost always complete with success.  

Reason for stalling:

– firewall is enabled on source server
-firewall is blocking traffic between source and target
-issues with OFX controller on server
-OFX controller is using wrong network interface on source 

If the data transfer cannot be started, errors will appear in the job log

no response on port from host <ip-address>
no response from receiver on port 3725
the file transfer is stalled
unable to connect to port 3725 on ip address <ip address of source>

Most common reason for these issues are firewall related. Make sure there is no firewall between the source and target blocking traffic on port 3725. Make sure the firewall on the source server is not blocking port 3725. If so, add a rule to allow traffic or disable the firewall if possible.

Perform a ‘netstat -ano’ command on both the source and target server to verify a process is listening on port 3725. The target Windows PE does not have netstat command available. Perform a ‘net use ‘ command to map a drive on a server which has it available and perform netstat from the mapped drive. Search in the ‘netstat -ano’ output for a line like this

TCP               LISTENING       260

I had an issue on virtualizing a Windows 2003 server acting as a proxy. It had an internal IP address on the internal network interface  and several external ip-addresses on the external interface. Each time I tried to perform a P2V job, the job stalled at the data transfer stage. In the job log it listed the controller on the target was not able to connect to the ip address on the external network interface. I wanted to have the controller connect to the internal interface. Even after adjusting the properties of the source server and deleting all external ip’s in the properties, the log file kept reporting the external ip address.
PlateSpin support explained that the controller will try to connect to all IP addresses which are available at the source. I do not think this is the case!

We had a server with two nics. One nice was configuered with an IP-address, the other not and was disabled. When we did the P2V the job stalled at 1 %, saying port 3725 was blocked. What we did was changed the IP-configuration to the second nic, disabled the  first nic and created a new job. Thereafter the job performed well !

A reboot of the source server might help as well.

To troubleshoot connections, a telnet to the source server on port 3725 can be performed. To do this, for VMware targets, start VMware vSpere client, connect to the console of the target VM. In the Windows PE console, connect to the source server by net use y: <a href="//\\\\<source ip>\c$ . Locate telnet.exe and perform a command: telnet <source ip address> 3725 

As soon as  the job is at stage 6.8: Copying Volume Data from Source to Target started (1% progression). the telnet command should result in a connection and you probably will see strange characters. That is good. If the response is something like ‘not connected’ port 3725 is not reachable and a firewall is likely blocking traffic.

Novell has a knowledgebase article available describing the issue. The solution involves installing a Microsoft hotfix. The article can be found here.
My experience is that in most cases the problem is related to firewalls or source servers with multiple nics.  

If some other process is using port 3725, it can be changed by the following commands:

1) Open “C:\Program Files\PlateSpin Migrate Server\Web” directory.
2) Open the productinternal.config file in a text editor.
3) Locate the following line under <optimizedFileTransferSettings> and <legacyFileTransferSettings>:


  4) Change the 3725 value under both <optimizedFileTransferSettings> and <legacyFileTransferSettings> to the desired port number and save the changes.

Licensing of Novell PlateSpin Migrate explained

Novell PlateSpin Migrate is licensed on a rather customer unfriendly manner. For each conversion a license needs to be purchased. To prevent customers using the same license on multiple instances of PlateSpin Migrate, the license is tied to the server PlateSpin was installed on. To apply for a license key file, a hardware id is generated. Several characteristics of the server PlateSpin Migrate has been installed on are used to generate the hardware id.

One of the characteristics used for generation of the hardware id is the Windows Server Product key. And this can lead to issues in obtaining a working license key file.

For one of my customers I installed PlateSpin Migrate. Before I actived Windows Server I generated a hardware id using the License Manager and sent it to Novell. They sent me a license key file in return. Instead of applying the license key file immediately, I first activated Windows Server using a product key.

Thereafter I installed the PlateSpin license key file only to find out it reported an error. I rerun the License Manager to find out it reported a new hardware id, different to the one I sent to Novell.

So the lesson learned is to first activate Windows Server and then  request Novell for a license key file!

Novell is very helpfull in supplying a new file but I do not like their policy. For numerous reasons customers can have the need to install PlateSpin on a new server. For instance the original licensed server crashed, or is used for other purposes. I prefer having the risk of  abuse on non-hardware tied licensing being added to the pricing of the product than this customer unfriendly way of licening. A customer is in the current method of licensing always dependent on the assistence of Novell for being able to use the product they paid for.

HP Virtual Connect for Dummies second edition released

HP released a second edition of the popular HP Virtual Connect for Dummies PDF book. The second edition has information on FLex-10 which the first edition did not have.

Download directly from this link : HP_Virtual_Connect_for_Dummies_2nd_edition

PlateSpin Migrate stalls at stage 3.1.1 Creating virtual machine on ESX server (running 1% complete)

While performing a P2V job using PlateSpin Migrate, the conversion job hangs / stalls at stage 3.1.1 Creating virtual machine on ESX server (running 1% complete).

This could be caused by:

-the ESX hosts on which the target VM is hosted is a running the free ESXi edition. The API’s which are used by Platespin to create a virtual machine are not available on the free edition. The evaluation version will work and all licensed editions will obviously work as well.

-the VMware datastore is not able to store the VMDK of the target VM. If the datastore has a blocksize of 1MB, a VMDK or other file can be  256GB in size max. If a partition on the source server is larger, it will not work.

In my case, both were okay. So I deleted PlateSpin Migrate server and client, deleted the SQL Express database, deleted IIS role , deleted the Program Files folders or Platespin and SQL and rebooted.

After reboot, I disabled User Access Control and reinstalled PlateSpin. After that, the issue was gone!

It might be caused bu UAC being enabled! Platespin advises to disable UAC.

PlateSpin Migrate discovering server details hangs at 1%

When discovering source Windows servers, the job hangs at 1% in ‘discovering server details’.

From the PlateSpin Migrate server, the source server can be pinged. But from the source server the PlateSpin server cannot be pinged. IP configuration is okay.

Make sure the firewall running on the PlateSpin server allows traffic used by PlateSpin. Quick and dirty solution is to disable the firewall. You might need to reboot the server to completely get rid of the interference of the firewall.

New versions of Novell PlateSpin Forge, Migrate and Protect released

At October 4 Novell released new versions of PlateSpin Protect (version 10.0.2), PlateSpin Forge (3.0.2) and PlateSpin Migrate (9.0.2)

Download here:

PlateSpin Migrate 9 review

Novell released PlateSpin Migrate version 9 end of June 2010. This is the first version to support distributed switches available since the release of VMware  vSphere. Below are my experiences so far with this new version.

The release notes can be found here

The upgrade from version Portability Suite 8.1.3 to version 9 went without any problem. The upgrade took around 30 minutes. Before performing the upgrade, I de-installed the Portability Suite Client as described in the Install Notes.

The client has some minor changes in the user interface. I noticed it is still not possible to run two instances of the client on the same server. A pity as this is very usefull during conversions when several staff members are performing conversions at the same time. The alternative is to install the client on a workstation or other server.

I noticed the default job values were reset. I prefered to have the display name of the virtual servers without the ‘_VM’  string attached by default by PlateSpin. After the upgrade the _VM suffix was back.

Also , Migrate 9 still creates at random choosen datastores a folder called Platespin. This folder holds several files used for the conversion process. One of the files is a floppy image.

PlateSpin Migrate immediately displayed the  portgroups which are created on distributed switches of ESX4 servers. I did not have to perform another inventory of the vCenter Server 4 nor the ESXi4 hosts even I discovered those using Migrate version 8.1.3. This is nice.

The conversion speed does not seem to have changed. We still see an average data transfer speed during P2V’s filebased transfer of 40 GB per hour.

Platespin Migrate is lacking an important feature if you decided to use thin provisioned disks. Platespin migrate 9 does not support thin provisioned disks. So if you want to convert your physical server to a virtual, Platespin will create thick provisioned disks. VMware Converter however is perfectly able to create thin thick during the P2V process.
To solve this using Platespin, after the P2V is done, you will need to storage migrate the discs to another datastore, and storage migrate back to the original datastore selecting thin provsioned discs. A time consuming process.

Unfortunately, the ability to create thin provisioned discs is not on the roadmap for future releases at this moment. (september 2010).

We did a couple of P2V conversions of servers having a lot of data. Over 1.5 TB of data in many small files. Because the partitions of the physical server were too small, we needed to enlarge the target volume. This means instead of the faster blocklevel copy, we had to select the filebased transfer. We had several jobs that aborted or seem to hang at 1% copying files. This is an issue which is described in the knowledgbase of PlateSpin. Solution is to select the blocklevel copy.

Also we had an issue while performing a P2V conversion to either ESX4 or ESX4.1 hosts. We are using vCenter Server to discover hosts and virtual machines.

Platespin 9 is a must have if you are performing lots pf  X2X conversions to vSphere 4.x platforms and using distributed switches for your vm portgroups, when minimum downtime is a must. However, prepare for various issues which can be caused by a lot of things. PlateSpin is not an easy to use tool which guarantees succesfull conversions.

PlateSpin Migrate firewall port overview

This document shows the communication and ports used between the PlateSpin server, source server , target servers, vCenter Server and ESX hosts for the various types of conversion jobs suppported by PlateSpin.


Novell PlateSpin Migrate 9 download and documentation available

Since June 30 PlateSpin Migrate is available for download. One of the most appealing new features is support for distributed virtual switches available in vSphere 4.
See this location for download of the program :

Documentation on PlateSpin Migrate 9 can be downloaded off the Novell website. Location below:

PlateSpin Migrate 8 review

For one of my customers I have been using PlateSpin Migrate for performing Physical to Virtual conversions. We had both Dell and HP servers which were converted to virtual machines running on VMware ESX 3.5. During the project we converted around 40 physical servers.  PlateSpin Migrate is also able to convert to Hyper-V hosts, Citrix XenServer and Virtual Iron hosts.   

We used both versions 8 and 9 for our conversions. For a review of Platespin migrate 9 see this blogposting

To compare VMware Converter and PlateSpin 9, see this review

During the conversion I learned a lot about the product and I want to share my experiences with those looking for more info on PlateSpin Migrate 8.

Selection of P2V tooling

The two most used tools for performing P2V conversions are VMware vCenter Converter (standalone version and vCenter plugin) and PlateSpin Migrate. VMware Converter is free of use and has a lot of options available. For a lot of situations this will be a good tool to perform a P2V to a VMware infrastructure.

There are severall reasons why to choose PlateSpin Migrate over VMware Converter in a situation where the target platform is VMware:

  1. The ability of PlateSpin to perform a block based or file based synchronization of data. This strongly reduces the downtime of an application.
  2. The ability of PlateSpin migrate to align VMware virtual disk files. Alignment is especially important when virtual machine demand a lot of disk resources. For more information on the importance of alignment
    VMware Converter will not align your virtual disk files. PlateSpin Migrate will align the virtual disk files, however only the first partition on the virtual disk. This is one of the reasons to always select an unique virtual disk file for each partition. Another reason is eing able to store each virtual disk on different disk types (FC storage, FATA storage etc)
  3. The ability to perform a V2P conversion. A couple of application managers were worried about the performance of the application once it was running on a virtual server. If a performance issue would arise after some there must be a way to take the physical server back in production. PlateSpin Migrate is one of the few of not the only tool available to perform a V2P conversion.

The main reason to select PlateSpin for this project was the ability to prepare a virtual machine during production hours and using synchronzation of changed data  reducing the time needed during off hours to perform the actual switch from physical to virtual.

PlateSpin Migrate is part of the Portability Suite which also hold the Protect module. I used version 8.1.3.  

During office hours we performed an initial live migration (source server remain operational) P2V. This job created the virtual machine and copied the data. A few days later during off hours, we created a synchronization job. This copies only the changed data (either files of bits) to the already created virtual machine. This reduces the downtime of the application. It also reduces the time, and thus costs, of IT staff performing the conversion,  and application management staff to test and accept the virtual machine. Most servers were down for 1 hour for conversion to a virtual machine. 
We saw average tranfers speeds of 40 GB per hour for the conversions.    

Setup of PlateSpin Migrate is a straight forward process. The software constist of a database used for storing information on jobs, status of jobs and inventory of physical and virtual server, hosts and vCenter Servers. After setup has competed, a discovery of the vCenter Server is done for inventory of the VMware hosts. For the ESX 3.5 host this went without problems. To discover the vSphere 4 environment I had to create a standard switch on each ESXi 4 host to be able to complet the discovery job succesfully.  Next step is disovery of the physical servers. Most servers were Windows 2003 and disovery went without problems. A few Windows 2000 servers had problems during discovery. This was mainly because corrupted WMI on the physical server, or lack of Admin$  and C$ administrative shares.

Documentation of the product is quite basic. The install guide does not tell you how to create a situation which enables a situation of both physical and virtual server to be running at the same time with the same IP-adress and hostname. When jobs fail the job points to an URL part of the PlateSpin Knowledgebase. However, this URL leads most of the times to zero articles describing the problem. This was one of the main reasons to create several blog postings on the product.

Support of PlateSpin was very, very good. Within a few hours after entering a Service request in the Novell portal I was contacted by a PlateSpin technician to assist in solving the problem. This was either done by email, by phone or by a websession in which the technician could see the PlateSpin client running on my desktop or server.  Most of the issues were resolved quite fast.

PlateSpin Migrate is easy to install but hard to get it on. A correct working depends on a lot of components. Correct configuration of the source server for discovery and installation of agent (think about WMI, remote registry, admin shares), configuration of firewall ports, permissions on vCenter Server, setup of vCenter Server, storage, networking, DNS, etc etc. We experienced quite a few issues during the P2V’s we performed. Some are documented in this blog article

Lack of support for the most recent  software features

PlateSpin Migrate is considered to be one of the best tools for performing X2X conversions. It is strange though that Novell is slow on adjusting their software to the latest releases available. For instance PlateSpin Migrate is not supported to run on a Windows Server 2008 R2 while it was availble for a long time (as was in April 2010).

A bigger issue is the lack of support for distributed virtual switches! If your target servers are ESX4i servers and you are using distributed virtual swiches with virtual machine portgroups created on it, you will not be able to perform a conversion. PlateSpin migrate is only able to use standard, local switches with a virtual machine portgroup!

It can be solved by dedicating one of your ESXi hosts as a landing host. This host will have a standard switch with a virtual machine portgroup. After the P2V has finished, disconnect the server from the portgroup and connect it to a production virtual machine portgroup. A real puty you have to perform a workaround. Support for distributed switches should be available in June 2010 according to this article: and this article

Also PlateSpin Migrate is unable to create a thin provisioned disk during the conversion. Novell PlateSpin does not have plans to add support in the near future. This means after the conversion has finished, you have to perform a storage migration to convert the thick disk to a thin disk. VMware Converter 4 is able to create a thin provisioned disk.


I think PlateSpin Migrate is a very usefull tool to perform X2X conversions. If ten or less servers need to be convert, you better use VMware Converter. It is free and does the job well enough. To understand PlateSpin Migrate and get the benefit, you will need to perform quite some conversion first.

Support of the product by the PlateSpin staff is wonderfull. They are dedicated to solve your issues and answer questions. Documentation and the online resources like knowledgebase can be improved a bit.

The lack of support for distributed switches is an important shortcoming of the product. In version 9 of Migrate support for distributed switches has been added. Also, the number of different issues encountered during the various conversions does not give the product a stable and robust impression.

The ability to be able to synchronize data (reducing downtime and working overtime ) and the ability to align virtual disks could be the main reason to select PlateSpin Migrate over VMware Converter 4.

%d bloggers like this: