Blame docs/tips/virtual_machines.md

13519c
# KVM virtual machines tips
13519c
13519c
## Migrating an existing VM to another host/hypervisor
13519c
13519c
### Process overview
13519c
Let's assume that you have a simple KVM guest that you'd need to migrate to a new hypervisor.
13519c
While normally we have everything under ansible control, and so we'd be able to rebuild a new VM from scratch, have role applied and restore backup to have node migrated, it's sometimes easier and even faster to just move the VM (and eventually reconfigure the network) to migrate the VM elsewhere.
13519c
13519c
13519c
!!! note
13519c
    The following snippets are only shown below to help you do this, but don't copy/paste blindly. Again "Some Thinking Required [TM]" when considering this and a basic knowledge of how kvm/libvirt works is needed.
13519c
13519c
We can start with ssh (agent-forwarded of course) to the new hypervisor ( `ansible-role-kvm-host` applied and bridge[s]/network/storage configured, out of the scope of this doc).
13519c
13519c
We can then define some variables like :
13519c
  
13519c
  * KVM guest VM to migrate
13519c
  * KVM hypervisor on which it's actually running
13519c
  * (optional) : the ssh bastion host (check in ansible inventory which are the bastion/jump hosts relevant to ansible env) through which we'll just open temporary tcp/22 firewall port (normally closed on all servers fleet)
13519c
13519c
```
13519c
# Defining some variables first
13519c
VM="kvm-guest1.dev.centos.org"
13519c
hypervisor="kvm-hypervisor1.dev.centos.org"
13519c
bastion_host="bastion.dev.centos.org"
13519c
13519c
# Finding our local IP to temporary allow it to push over ssh for rsync
13519c
# Only needed for public hypervisors, not needed at all for internal hypervisors in same DC or through vpn
13519c
ip_addr=$(curl --silent -4 http://icanhazip.com)
13519c
ssh -J ${bastion_host} ${hypervisor} "sudo iptables -I INPUT -p tcp --dport 22 --source ${ip_addr} -j ACCEPT"
13519c
13519c
# Ensuring our current user can read .qcow2 files on initial hypervisor
13519c
ssh $hypervisor "sudo setfacl -m u:$USER:rwx /var/lib/libvirt/images ; sudo virsh shutdown $VM ; sleep 15 ;sudo chown $USER /var/lib/libvirt/images/${VM}.qcow2"
13519c
13519c
# Ensuring now that we can also write to local/target hypervisor and starting to rsync -S (sparsify) the VM
e292b7
sudo setfacl -m u:${USER}:rwx /var/lib/libvirt/images
13519c
rsync -avS -4 --progress ${hypervisor}:/var/lib/libvirt/images/${VM}.qcow2 /var/lib/libvirt/images/${VM}.qcow2
13519c
ssh $hypervisor "sudo virsh dumpxml $VM"  > /var/lib/libvirt/images/${VM}.xml
13519c
13519c
```
13519c
13519c
!!! info
13519c
    Now that we have both the .qcow2 and .xml files, we can define the VM but *first* we have to verify that it matches local hypervisor. For example it can be that you'll have issues with define cpu model and also network settings, like bridge name, etc so feel free to review/adapt (see below some tips)
13519c
13519c
Once you have edited the .xml file to (eventually) match some settings that needed to be modified, you can define the VM, and start it :
13519c
13519c
```
13519c
# then define/starts the VM
13519c
sudo virsh define /var/lib/libvirt/images/${VM}.xml
13519c
sudo virsh start ${VM} 
13519c
sudo virsh console ${VM} 
13519c
sudo virsh autostart --domain $VM
13519c
13519c
```
13519c
13519c
### Migration tips (also for .xml)
13519c
13519c
Here are some tips that you have to think about before migrating :
13519c
13519c
  * if you'll have to modify network settings, ensure that you have the root password available to connect through the console with `virsh console` or modify network settings before shutting VM down at origin side.
13519c
  * if libvirt complains about cpu mismatch, it can be that VM was created with something else than cpu host-passthrough, so if that's the case, you can always ` virsh edit $VM` , and replace the cpu section with `<cpu mode='host-passthrough' check='partial'/>` , save and try to boot the VM again
13519c
  * for network virtual nics, you can have to change the bridge name or even switch back to default network (if suddenly not using a bridge, etc)