I am planning to move some of my physical server to virtual(p2v). However, there are some constraints like the servers are located remotely. Can I do p2v remotely and if yes then how much time will it take. Please also let me know other constraints involved in doing p2v remotely…
any help in this regard is highly appreciated.

Shaibal

Great points, and I can argue that workload is a generic
representation of all the gorey details you dive deeper into. Your
point is well explained regardless.

As far as certain apps always being unvirtualize -able, consider a
single VM as a guest on it's own host and not consolidated. There are
many unique advantages and VI features that make it worth doing this,
and solve the possible resource contention.

Peripherals and access to specific networks are also a resource. One resource not mentioned is network usage, network performance requirements (E.g. Packets per second), CPU usage is mentioned, but 'CPU scheduling requirements' arent, eg

Think along the lines of app sensitivity to timing and Jitter, and suitability of Virtual NICs and vCPUs. For example: Asterisk is highly time-sensitive; you may be able to provide 10x the memory, CPU, and all the needed peripherals while virtualized, but the VoIP audio quality is unacceptable when virtualized (for more than a few simultaneous calls).

The VM isn't running on the CPU 100% of the time, so the vCPU ticks aren't the real clock ticks — VMware simulates them, and in some cases acts to “catch up” the VM.

The capacity planning tools can't tell you this, either. I expect NTP servers, and some other audio and video streaming servers/apps are also quite possibly un-virtualizable. In RHEL 4, in particular, NTP abysmally fails at anything close to accurate timekeeping.

You need to test the application, or check with the vendor.
Instead of just considering “Workload” and P2V experiences last, some apps should be ruled out immediately.

Great points, and I can argue that workload is a generic
representation of all the gorey details you dive deeper into. Your
point is well explained regardless.

As far as certain apps always being unvirtualize -able, consider a
single VM as a guest on it's own host and not consolidated. There are
many unique advantages and VI features that make it worth doing this,
and solve the possible resource contention.

Peripherals and access to specific networks are also a resource. One resource not mentioned is network usage, network performance requirements (E.g. Packets per second), CPU usage is mentioned, but 'CPU scheduling requirements' arent, eg

Think along the lines of app sensitivity to timing and Jitter, and suitability of Virtual NICs and vCPUs. For example: Asterisk is highly time-sensitive; you may be able to provide 10x the memory, CPU, and all the needed peripherals while virtualized, but the VoIP audio quality is unacceptable when virtualized (for more than a few simultaneous calls).

The VM isn't running on the CPU 100% of the time, so the vCPU ticks aren't the real clock ticks — VMware simulates them, and in some cases acts to “catch up” the VM.

The capacity planning tools can't tell you this, either. I expect NTP servers, and some other audio and video streaming servers/apps are also quite possibly un-virtualizable. In RHEL 4, in particular, NTP abysmally fails at anything close to accurate timekeeping.

You need to test the application, or check with the vendor.
Instead of just considering “Workload” and P2V experiences last, some apps should be ruled out immediately.