Blog: PlateSpin

I had an issue come up with Platespin the other day that was very strange. The Platespin protection job for a server hadn’t been completing successfully since it was upgraded to a new build. The job would run all the way up until the point where it was doing the VSS snapshots of the source machine, then it would die with a very cryptic VSS related error. This would cause the VSS System Writer to display an error state when using vssadmin list writers. I engaged Platespin support, and after about two weeks going back and forth with their support, they finally cut me loose with a “call Microsoft” recommendation. I kept troubleshooting and found that when I would try to clear out the VSS snapshots by changing the maximum space setting for the VSS snapshots to 300 MB (which is supposed to be the minimum amount required for an x86 system), I would get an error pop-up noting that 300 MB was not sufficient amount of space for snapshots on that volume. I finally found by process of elimination that 1800 MB was the magic number for the c: volume. However, even though the drive had over 2.5 GB of free space, the PlateSpin job would still fail. [more]

As a last resort, I changed the storage location for the VSS snapshots for the c: partition to the d: partition (which had over 20 GB of free space) then ran the job again. This time, the job ran a little bit farther, then died when trying to snapshot the f: partition (which was only used for a page file). After moving the VSS snapshots for the f: partition over to d:, the job ran successfully…finally. What was very strange is that the VSS snapshots would always reserve the same amount of space for each partition as the maximum setting for the c: partition. I could change the maximum space setting for snapshots on the c: partition and run the job again and the snapshots for all partitions would match the c: partition no matter what the maximum setting that I had specified for the individual partitions. I could snapshot the partitions with vssadmin and this did not happen and when backing the server up with CommVault (which uses VSS) it didn’t happen….only PlateSpin. I looks to me like their software has a bug in it.  I have emailed their support tech I was working with to explain what I found…no response so far.

We use Platespin to do scheduled P2V migrations to provide DR for some of the physical servers at a customer site. I have been troubleshooting some issues with the scheduled protection jobs over the last week or so. The jobs had been running fine for the last couple of months. I have the jobs scheduled to do full synchronizations once per month (first of the month) and all but 2 failed this month. The problem was really strange because I could kick off the full sync and it would run fine for a long time and then all the sudden it would just stall out with a “recoverable error”. I tried all my usual steps to recover from this error…nothing worked.  I used to see this all the time after the new Barracuda was installed. For that issue, I would just add a setting to the ofxcontroller.config file on the source side to bypass the proxy. So, I started searching for another config file that might need to be changed. After tracking the traffic with wireshark, I finally decided there was no interference by the proxy. I submitted a support ticket with Platespin and the tech that working my case asked me whether I was using the “WAN optimizations”. WAN optimizations? That must be a config setting I had never seen. He explained that the problem I was having was that I was running into the 24-hour job termination window. [more]

Any Platespin job MUST complete in 24-hours or it will fail with this “Recoverable Error” message. Actually, the error is not recoverable at all…you have to abort the job and start over. PlateSpin uses WinPE for the target side pre-execution environment when doing the migration/protection jobs. WinPE requires a license if launched for more than 24-hours…platespin doesn’t have the license so the target VM will REBOOT ITSELF after 24 hrs. Hence, the recoverable error that isn’t recoverable. So, back to the WAN optimizations. To help the job finish in time, there are config values you can change in the product’s productinternal.config (for v8.0 or powerconvert.config for PowerConvert Server 7.0) configuration file, located on your Portability Suite Server host, in the following directory:   \Program Files\PlateSpin Portability Suite Server\Web\

After implementing these settings, full sync jobs were completing in 25% of the time they had been taking. It’s a huge improvement.

You might also want to check out a previous post on Moving a PlateSpin Image Between Image Servers to Setup a DR Sync that discusses using local image servers at both ends to seed a server image across a WAN.

When trying to use PlateSpin to seed a server image across a WAN connection for a DR site the job would fail after a certain amount of time. Come to find out the process has a time limit of 24 hours to finish or it will fail. This time limit is hard set and cannot be increased. A way around this is to use a local image server at both ends.

Update:  We've added another post that discusses WAN optimizations for Platespin that you'll want to read.

These are the basic steps you need to follow: [more]

1. Create an image server local to the source (Discover then right click in Portability Suite and choose install image server).
2. Capture the image (Drag the source to the image server).
3. Export the image (this step fixes the config.xml file point to the right location after it moves the image files).
   • The Image Operations tool is installed with the PowerConvert server and not with the Image server.
     On the PowerConvert server you have to locate the following folder: “C:\Program Files\PlateSpin PowerConvert Server\bin”
   • In that folder locate the folder: “ImageOperations” and copy it to the Image server.
   • On the Image server:
     1. Open a command prompt.
     2. Navigate to the folder “ImageOperations’ that was copied over from the PowerConvert server.
     3. Run the command “imageoperations /gather /imagepath={path of the image} /output={path that you want to place the copy of the image}” without the quotes.
     4. Once the command completes the folder specified in /output will contain the files that need to be copied to the other image server.
4. Move the files across the WAN (FTP, Physically, etc whatever method best works for the environment).
5. Create an image server local to the target ESX host.
6. Import the image into the image server local to the target.
   • The Image Operations tool is installed with the PowerConvert server and not with the Image server.
     On the PowerConvert server you have to locate the following folder: “C:\Program Files\PlateSpin PowerConvert Server\bin”
   • In that folder locate the folder: “ImageOperations” and copy it to the Image server.
   • On the new Image server:
     1. Copy the folder “ImageOperations” again to this folder from the PowerConvert server that installed this Image server.
     2. Open a command prompt.
     3. Navigate to the folder “ImageOperations” that was copied over from the PowerConvert server.
     4. Run the command “imageoperations /register /imagepath={path of files copied from old Image server}” without quotes.
     5. Once the command completes refresh the details of the Image server from within PowerConvert.
7. From the Discovered Server list expand the image server local to the target and deploy the image to target ESX host
8. Select the deployed server and choose Prepare For Synchronization
9. Setup a filed based server sync job.

Once completed the job should allow for incremental updates over a slower link without hitting the 24 hour time limit.