Add a playbook to update VM XML

[eroussy]

Abstract
Updating the XML of a VM running on SEAPATH is a complex task. Currently, it is only documented on the wiki, as an example playbook.
We should create a playbook to do that.

Note that this only handles the VM XML update. We could also consider providing a standard way to update the VM disk, with snapshots or clones to handle the recovery cases.

Detailed Description
Updating a VM XML requires using the clone command of vm-manager and providing the new XML and metadatas.
This is only shown on the wiki, with a playbook that the user has to adapt it.
I believe that we could upstream a playbook that:

• Uses the same VM inventory as deploy_vms_* playbooks
  • Uses either a standard XML or a templated XML.j2 file
  • Handles metadata changes directly (e.g.: preferred_host)
• Clones the VM with the new XML and metadata
• Asks the user if the VM works correctly (manual input)
• Deletes the old VM or handles the recovery case
• Probably rename the cloned VM with the name of the original one.
  This would require Add vm_manager rename command vm_manager#77

This is a SEAPATH standard scenario, so it is similar to providing the replace_machine playbooks

Work to be done
Start with the example given on the wiki.
Implement the list above

[eroussy]

Additional note:
There is currently no proper mechanism to enable live migration on a VM running on a SEAPATH cluster without re-deploying it.

Adding live migration requires to set the VM metadata _live_migration to true and _migration_user to the user used to live migrate. Theses values cannot be added by vm_manager set_metadata commands, nor in a standard clone command because vm_manager refuses the underscore character:
ValueError("Parameter must not contain spaces or special chars")
The only way to add them is to manipulate ceph rbd metadatas directly:
rbd image-meta set system_yourvm _live_migration true
rbd image-meta set system_yourvm _migration_user libvirtadmin

If we create an update VM XML playbook, reading standard SEAPATH VMs inventory, this would be trivial. Live migration values written in the inventory would be read by cluster_vm and given to vm_manager directly, without the user having to worry about that.