-void MSG_vm_migrate(msg_vm_t vm, msg_host_t destination) {
- unsigned int cpt;
- msg_process_t process;
- xbt_dynar_foreach(vm->processes,cpt,process) {
- MSG_process_migrate(process,destination);
- }
- xbt_swag_remove(vm,vm->location->vms);
- xbt_swag_insert_at_tail(vm,destination->vms);
- vm->location = destination;
+void MSG_vm_migrate(msg_vm_t vm, msg_host_t new_pm)
+{
+ /* some thoughts:
+ * - One approach is ...
+ * We first create a new VM (i.e., destination VM) on the destination
+ * physical host. The destination VM will receive the state of the source
+ * VM over network. We will finally destroy the source VM.
+ * - This behavior is similar to the way of migration in the real world.
+ * Even before a migration is completed, we will see a destination VM,
+ * consuming resources.
+ * - We have to relocate all processes. The existing process migraion code
+ * will work for this?
+ * - The name of the VM is a somewhat unique ID in the code. It is tricky
+ * for the destination VM?
+ *
+ * - Another one is ...
+ * We update the information of the given VM to place it to the destination
+ * physical host.
+ *
+ * The second one would be easier.
+ *
+ */
+
+ msg_host_t old_pm = simcall_vm_get_pm(vm);
+
+ simcall_vm_migrate(vm, new_pm);
+
+ XBT_DEBUG("VM(%s) moved from PM(%s) to PM(%s)", vm->key, old_pm->key, new_pm->key);
+
+ #ifdef HAVE_TRACING
+ TRACE_msg_vm_change_host(vm, old_pm, new_pm);
+ #endif