If the VM was created using 'boot from volume', or if there is a shared file system among compute nodes, you may use live migration where you can specify the target compute nodes.

Otherwise you can refer to the following instructions (taken from https://raymii.org/s/articles/Openstack_-_(Manually)_migrating_(KVM)_Nova_Compute_Virtual_Machines.html#Manual_migration_to_a_specific_compute_node).

This procedure was tested on a Mitaka based Cloud.

Use at your own risk !!

This example manually migrates a VM from compute-30.cloud.pd.infn.it to compute-34.cloud.pd.infn.it

Shut down the VM first:

nova stop $VM_UUID

Also detach any volumes:

nova volume-detach $VM_UUID $VOLUME_UUID

Use the nova show command to see the specific hypervisor the VM is running on:

nova show UUID | grep hypervisor

Example output:

| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute-30.cloud.pd.infn.it    |

Check also the instance name:

nova show UUID | grep instance

Example output:

| OS-EXT-SRV-ATTR:instance_name        | instance-00000b08                                                                |

Login to that hypervisor via SSH. Navigate to the folder where this instance is located, in our case, /var/lib/nova/instances/$UUID.

The instance is booted from an image based root disk, named disk. qemu in our case diffs the root disk from the image the VM was created from. Therefore the new hypervisor also needs that backing image. Find out which file is the backing image:

cd /var/lib/nova/instances/UUID/
qemu-img info disk # disk is the filename of the instance root disk

Example output:

  image: disk
  file format: qcow2
  virtual size: 32G (34359738368 bytes)
  disk size: 1.3G
  cluster_size: 65536
  backing file: /var/lib/nova/instances/_base/d004f7f8d3f79a053fad5f9e54a4aed9e2864561
  Format specific information:
      compat: 1.1
      lazy refcounts: false 

The file /var/lib/nova/instances/_base/d004f7f8d3f79a053fad5f9e54a4aed9e2864561 is the backing disk.

Check the target hypervisor for the existence of that image. If it is not there, copy that file to the target hypervisor first:

rsync -r --progress /var/lib/nova/instances/_base/d004f7f8d3f79a053fad5f9e54a4aed9e2864561 -e ssh compute-34:/var/lib/nova/instances/_base/d004f7f8d3f79a053fad5f9e54a4aed9e2864561

On the target hypervisor, set the correct permissions:

chown nova:nova /var/lib/nova/instances/_base/d004f7f8d3f79a053fad5f9e54a4aed9e2864561

Copy the instance folder to the new hypervisor:

cd /var/lib/nova/instances/
rsync -r --progress $VM_UUID -e ssh compute-34:/var/lib/nova/instances/

Set the correct permissions on the folder on the target hypervisor:

 
chown nova:nova /var/lib/nova-compute/instances/$VM_UUID
chown nova:nova /var/lib/nova-compute/instances/$VM_UUID/*

Log in to your database server. Start up a MySQL command prompt in the nova database:

mysql nova

Execute the following command to update the nova database with the new hypervisor for this VM:

update instances set node='compute-34.cloud.pd.infn.it', host=node where uuid='$VM_UUID';

Use the nova show command to see if the new hypervisor is set. If so, start the VM:

nova start $VM_UUID

Attach any volumes that were detached earlier:

nova volume-attach $VM_UUID $VOLUME_UUID

On the source hypervisor (compute-30), delete the instance from libvirt:

virsh undefine instance-00000b08