With virtualization in most cases you can save the VM state and reschedule it elsewhere. So at first glance the answer would be that preemption is generally applicable. However, there are other issues that you need to consider here. For instance consider data intensive applications. If you move the saved state elsewhere the new location may induce a too large overhead to move the remaining data from the database (which was not moved) to the new VM location. So geographical (network) constraints are one issue. Another issue, as you pointed out is security. It really depends on where you move the data if they will allow you to redeploy a VM with a state they no nothing about, let alone its intentions.

Clouds are really nice when VM relocation is considered and can nicely fit preemption cases, however it really depends on the application constraints: network delays, security aspects.

With virtualization in most cases you can save the VM state and reschedule it elsewhere. So at first glance the answer would be that preemption is generally applicable. However, there are other issues that you need to consider here. For instance consider data intensive applications. If you move the saved state elsewhere the new location may induce a too large overhead to move the remaining data from the database (which was not moved) to the new VM location. So geographical (network) constraints are one issue. Another issue, as you pointed out is security. It really depends on where you move the data if they will allow you to redeploy a VM with a state they no nothing about, let alone its intentions.

Clouds are really nice when VM relocation is considered and can nicely fit preemption cases, however it really depends on the application constraints: network delays, security aspects.

Non-preemptive scheduling can lead to more efficient but less effective systems. That is, resources can be employed in a better fashion by reducing the number and size of context switches in non-preemptive scheduling at the price of reduced timeliness and dependability. Concerning security, it is probably easier to validate a non-preemptive system with respect to, for example, security, but not with respect to, for example, dependability. 

I doubt this is highly relevant: If I remember correctly, the MARS operating system has non-preemptive dispatching. Note, however, (i) tasks can be split into non-preemptive parts that are dispatched, (ii) scheduling is off-line and not necessarily non-preemptive although I think the splitting tasks into parts is done manually. 

See 

Kopetz, H, Damm, A, Koza, C, Mulazzani, M, Schwabl, W, Senft, C & Zainlinger, R 1989, ‘Distributed fault-tolerant real-time systems: the MARS approach’, IEEE Micro, vol. 9, no. 1, pp. 25–40.

Schütz, W 1993, The testability of distributed real-time systems, Kluwer Academic Publishers, Boston.

thanks @Marc,  can you give me some references for those cases?(data intensive and security where non-preemptive methods was used?

Dear Mina,

             The attached publications may be helpful.