Spoke with Chris Feist about time and resource concerns so we are moving this to 7.4. Will need usecase example from development to proceed.

*** Bug 1392109 has been marked as a duplicate of this bug. ***

Chris:  I'm looking at my 7.4 work and this BZ came up. I'm not sure what this would involve. I don't know what issues are specific to setting up virtual machines in a cluster. I would think the actual commands you use are the same. Can you provide a little more background about what this is asking for?

Also:  Is there somebody I can contact to work with me on putting together this procedure?

Steven

I think Oyvind may be the right person for this.  I will talk with him on Wed. to see what we need to start getting you some commands to run.

Thanks,
Chris

I should be able to help Steven with this.

Oyvind:


To follow up here:

I want to confirm that we are not looking at setting up a cluster of virtual machines, but configuring a virtual machine as a resource in an existing cluster. Is that correct?

If so then the closest thing we provide to this sort of procedure is the documentation for setting up remote nodes -- which are set up as a resource. That documentation is here:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/High_Availability_Add-On_Reference/pacemaker_remote.html

Would this be similar?  Do we describe a resource type for a virtual machine and its options?

I think I'm looking for basic step 1 of what it is that we need to document here.

Steven

That's right.

An example could be like this for a VM with live migration support over SSH:
# pcs resource create VM VirtualDomain config=.../vm.xml \
       migration_transport=ssh meta allow-migrate=true

With that setup "pcs move VM nodeX" would be done as a live migration. If you set allow-migrate=false or the allow-migrate the VM will be shutdown and then started on the other node with the "pcs move" command.

Info from the help screens, to have it on this BZ record:

root@virt-335 ~]# pcs resource describe VirtualDomain

ocf:heartbeat:VirtualDomain - Manages virtual domains through the libvirt virtualization framework

Resource agent for a virtual domain (a.k.a. domU, virtual machine,
virtual environment etc., depending on context) managed by libvirtd.

Resource options:
config (required): Absolute path to the libvirt configuration file, for this virtual domain.
  
hypervisor: Hypervisor URI to connect to. See the libvirt documentation for details on supported URI formats. The default is system dependent. Determine the system's default uri by running 'virsh --quiet uri'.

force_stop: Always forcefully shut down ("destroy") the domain on stop. The default behavior is to resort to a forceful shutdown only after a graceful shutdown attempt has failed. You should only set this to true if your virtual domain (or your virtualization backend) does not support graceful shutdown.
  
migration_transport: Transport used to connect to the remote hypervisor while migrating. Please refer to the libvirt documentation for details on transports available. If this parameter is omitted, the resource will use libvirt's default transport to connect to the remote hypervisor.
  
migration_network_suffix: Use a dedicated migration network. The migration URI is composed by adding this parameters value to the end of the node name. If the node name happens to be an FQDN (as opposed to an unqualified host name), insert the suffix immediately prior to the first period (.) in the FQDN. At the moment Qemu/KVM and Xen migration via a dedicated network is supported. Note: Be sure this composed host name is locally resolveable and the associated IP is reachable through the favored network.
  
monitor_scripts: To additionally monitor services within the virtual domain, add this parameter with a list of scripts to monitor. Note: when monitor scripts are used, the start and migrate_from operations will complete only when all monitor scripts have completed successfully. Be sure to set the timeout of these operations to accommodate this delay.
  
autoset_utilization_cpu: If set true, the agent will detect the number of domainU's vCPUs from virsh, and put it into the CPU utilization of the resource when the monitor is executed.

autoset_utilization_hv_memory: If set true, the agent will detect the number of *Max memory* from virsh, and put it into the hv_memory utilization of the source when the monitor is executed.
  
migrateport: This port will be used in the qemu migrateuri. If unset, the port will be a random highport.
  
snapshot: Path to the snapshot directory where the virtual machine image will be stored. When this parameter is set, the virtual machine's RAM state will be saved to a file in the snapshot directory when stopped. If on start a state file is present for the domain, the domain will be restored to the same state it was in right before it stopped last. This option is incompatible with the 'force_stop' option.

Live migration chapter of virtualization administration guide is here:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/chap-KVM_live_migration.html

*** Bug 1377716 has been marked as a duplicate of this bug. ***