You still need downtime to integrate any virtualization level into existing infrastructure. I can't really understand what is the purpose to avoid host-base migration.

Well, lets see the virtualization integration steps to perform in the invironment:

1. You need to prepare new zones for the virtualization appliance.

2. You need to plan and prepare the detialed config for the appliance itself and for the underliging array(s).

3. Downtime goes -> here <-

4. Unmount volumes\Deport volume groups on the host-side.

5. "Hide" volumes from the old "place".

6. Show volumes to virtualization appliance.

7. Configure data structures on virtualization appliance to show volumes "outside".

8. Reconfigure mpath\vol mgr on host to see new LUNS (totaly new ids\wwns etc.).

9. Start everything.

The way back out of the appliance is possible but all steps are just similar.

So if you have a good plan you can minimize the downtime. But it seems to me, that this approach is too complex for the temporary presence of appliance.

We have a deal with a huge distance between sites. I believe that the latency would be the limitting factor here. The only method is an asynchronous replication, which is more complex to configure on the vplex (not sure for svc). But you should take care of channels accurate. There are some strict limitation on that.

If I were you I would look to vsphere replication (not vmotion due to distance) and LVM migrations\standby databases. But it's only my point. Maybe someone have dealt with such migrations on the forum.