15.5. Live KVM Migration with virsh A guest virtual machine can be migrated to another host physical machine with the virsh command. The migrate command accepts parameters in the following format: Note that the --live option may be eliminated when live migration is not required. Additional options are listed in Section 15.5.2, "Additional Options for the virsh migrate Command" . The GuestName parameter represents the name of the guest virtual machine which you want to migrate. The DestinationURL parameter is the connection URL of the destination host physical machine. The destination system must run the same version of Red Hat Enterprise Linux, be using the same hypervisor and have libvirt running. Note The DestinationURL parameter for normal migration and peer2peer migration has different semantics: normal migration: the DestinationURL is the URL of the target host physical machine as seen from the source guest virtual machine. peer2peer migration: DestinationURL is the URL of the target host physical machine as seen from the source host physical machine. Once the command is entered, you will be prompted for the root password of the destination system. Important Name resolution must be working on both sides (source and destination) in order for migration to succeed. Each side must be able to find the other. Make sure that you can ping one side to the other to check that the name resolution is working. Example: live migration with virsh This example migrates from host1.example.com to host2.example.com . Change the host physical machine names for your environment. This example migrates a virtual machine named guest1-rhel6-64 . This example assumes you have fully configured shared storage and meet all the prerequisites (listed here: Migration requirements ). Verify the guest virtual machine is running From the source system, host1.example.com , verify guest1-rhel6-64 is running: Migrate the guest virtual machine Execute the following command to live migrate the guest virtual machine to the destination, host2.example.com . Append /system to the end of the destination URL to tell libvirt that you need full access. Once the command is entered you will be prompted for the root password of the destination system. Wait The migration may take some time depending on load and the size of the guest virtual machine. virsh only reports errors. The guest virtual machine continues to run on the source host physical machine until fully migrated. Verify the guest virtual machine has arrived at the destination host From the destination system, host2.example.com , verify guest1-rhel7-64 is running: The live migration is now complete. Note libvirt supports a variety of networking methods including TLS/SSL, UNIX sockets, SSH, and unencrypted TCP. For more information on using other methods, see Chapter 18, Remote Management of Guests . Note Non-running guest virtual machines can be migrated using the following command: 15.5.1. Additional Tips for Migration with virsh It is possible to perform multiple, concurrent live migrations where each migration runs in a separate command shell. However, this should be done with caution and should involve careful calculations as each migration instance uses one MAX_CLIENT from each side (source and target). As the default setting is 20, there is enough to run 10 instances without changing the settings. Should you need to change the settings, see the procedure Procedure 15.1, "Configuring libvirtd.conf" . Open the libvirtd.conf file as described in Procedure 15.1, "Configuring libvirtd.conf" . Look for the Processing controls section. Change the max_clients and max_workers parameters settings. It is recommended that the number be the same in both parameters. The max_clients will use 2 clients per migration (one per side) and max_workers will use 1 worker on the source and 0 workers on the destination during the perform phase and 1 worker on the destination during the finish phase. Important The max_clients and max_workers parameters settings are affected by all guest virtual machine connections to the libvirtd service. This means that any user that is using the same guest virtual machine and is performing a migration at the same time will also obey the limits set in the max_clients and max_workers parameters settings. This is why the maximum value needs to be considered carefully before performing a concurrent live migration. Important The max_clients parameter controls how many clients are allowed to connect to libvirt. When a large number of containers are started at once, this limit can be easily reached and exceeded. The value of the max_clients parameter could be increased to avoid this, but doing so can leave the system more vulnerable to denial of service (DoS) attacks against instances. To alleviate this problem, a new max_anonymous_clients setting has been introduced in Red Hat Enterprise Linux 7.0 that specifies a limit of connections which are accepted but not yet authenticated. You can implement a combination of max_clients and max_anonymous_clients to suit your workload. Save the file and restart the service. Note There may be cases where a migration connection drops because there are too many ssh sessions that have been started, but not yet authenticated. By default, sshd allows only 10 sessions to be in a "pre-authenticated state" at any time. This setting is controlled by the MaxStartups parameter in the sshd configuration file (located here: /etc/ssh/sshd_config ), which may require some adjustment. Adjusting this parameter should be done with caution as the limitation is put in place to prevent DoS attacks (and over-use of resources in general). Setting this value too high will negate its purpose. To change this parameter, edit the file /etc/ssh/sshd_config , remove the # from the beginning of the MaxStartups line, and change the 10 (default value) to a higher number. Remember to save the file and restart the sshd service. For more information, see the sshd_config man page. 15.5.2. Additional Options for the virsh migrate Command In addition to --live , virsh migrate accepts the following options: --direct - used for direct migration --p2p - used for peer-to-peer migration --tunneled - used for tunneled migration --offline - migrates domain definition without starting the domain on destination and without stopping it on source host. Offline migration may be used with inactive domains and it must be used with the --persistent option. --persistent - leaves the domain persistent on destination host physical machine --undefinesource - undefines the domain on the source host physical machine --suspend - leaves the domain paused on the destination host physical machine --change-protection - enforces that no incompatible configuration changes will be made to the domain while the migration is underway; this flag is implicitly enabled when supported by the hypervisor, but can be explicitly used to reject the migration if the hypervisor lacks change protection support. --unsafe - forces the migration to occur, ignoring all safety procedures. --verbose - displays the progress of migration as it is occurring --compressed - activates compression of memory pages that have to be transferred repeatedly during live migration. --abort-on-error - cancels the migration if a soft error (for example I/O error) happens during the migration. --domain [name] - sets the domain name, id or uuid. --desturi [URI] - connection URI of the destination host as seen from the client (normal migration) or source (p2p migration). --migrateuri [URI] - the migration URI, which can usually be omitted. --graphicsuri [URI] - graphics URI to be used for seamless graphics migration. --listen-address [address] - sets the listen address that the hypervisor on the destination side should bind to for incoming migration. --timeout [seconds] - forces a guest virtual machine to suspend when the live migration counter exceeds N seconds. It can only be used with a live migration. Once the timeout is initiated, the migration continues on the suspended guest virtual machine. --dname [newname] - is used for renaming the domain during migration, which also usually can be omitted --xml [filename] - the filename indicated can be used to supply an alternative XML file for use on the destination to supply a larger set of changes to any host-specific portions of the domain XML, such as accounting for naming differences between source and destination in accessing underlying storage. This option is usually omitted. --migrate-disks [disk_identifiers] - this option can be used to select which disks are copied during the migration. This allows for more efficient live migration when copying certain disks is undesirable, such as when they already exist on the destination, or when they are no longer useful. [disk_identifiers] should be replaced by a comma-separated list of disks to be migrated, identified by their arguments found in the <target dev= /> line of the Domain XML file. In addition, the following commands may help as well: virsh migrate-setmaxdowntime [domain] [downtime] - will set a maximum tolerable downtime for a domain which is being live-migrated to another host. The specified downtime is in milliseconds. The domain specified must be the same domain that is being migrated. virsh migrate-compcache [domain] --size - will set and or get the size of the cache in bytes which is used for compressing repeatedly transferred memory pages during a live migration. When the --size is not used the command displays the current size of the compression cache. When --size is used, and specified in bytes, the hypervisor is asked to change compression to match the indicated size, following which the current size is displayed. The --size argument is supposed to be used while the domain is being live migrated as a reaction to the migration progress and increasing number of compression cache misses obtained from the domjobinfo . virsh migrate-setspeed [domain] [bandwidth] - sets the migration bandwidth in Mib/sec for the specified domain which is being migrated to another host. virsh migrate-getspeed [domain] - gets the maximum migration bandwidth that is available in Mib/sec for the specified domain. For more information, see Migration Limitations or the virsh man page.

Commands:
virsh migrate --live GuestName DestinationURL
virsh list Id Name State ---------------------------------- 10 guest1-rhel6-64 running
virsh migrate --live guest1-rhel7-64 qemu+ssh://host2.example.com/system
virsh list Id Name State ---------------------------------- 10 guest1-rhel7-64 running
virsh migrate --offline --persistent
################################################################# # Processing controls # The maximum number of concurrent client connections to allow over all sockets combined. #max_clients = 5000 The maximum length of queue of connections waiting to be accepted by the daemon. Note, that some protocols supporting retransmission may obey this so that a later reattempt at connection succeeds. #max_queued_clients = 1000 The minimum limit sets the number of workers to start up initially. If the number of active clients exceeds this, then more threads are spawned, upto max_workers limit. Typically you'd want max_workers to equal maximum number of clients allowed #min_workers = 5 #max_workers = 20 The number of priority workers. If all workers from above pool will stuck, some calls marked as high priority (notably domainDestroy) can be executed in this pool. #prio_workers = 5 Total global limit on concurrent RPC calls. Should be at least as large as max_workers. Beyond this, RPC requests will be read into memory and queued. This directly impact memory usage, currently each request requires 256 KB of memory. So by default upto 5 MB of memory is used # XXX this isn't actually enforced yet, only the per-client limit is used so far #max_requests = 20 Limit on concurrent requests from a single client connection. To avoid one client monopolizing the server this should be a small fraction of the global max_requests and max_workers parameter #max_client_requests = 5 #################################################################