Questo contenuto non è disponibile nella lingua selezionata.
15.5. Live KVM Migration with virsh
virsh
command. The migrate
command accepts parameters in the following format:
# virsh migrate --live GuestName DestinationURL
GuestName
parameter represents the name of the guest virtual machine which you want to migrate.
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
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.
Important
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
.
Verify the guest virtual machine is running
From the source system,host1.example.com
, verifyguest1-rhel6-64
is running:[root@host1 ~]#
virsh list
Id Name State ---------------------------------- 10 guest1-rhel6-64 runningMigrate 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.#
virsh migrate --live
guest1-rhel7-64 qemu+ssh://host2.example.com/system
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
, verifyguest1-rhel7-64
is running:[root@host2 ~]#
virsh list
Id Name State ---------------------------------- 10 guest1-rhel7-64 running
Note
Note
# virsh migrate --offline --persistent
15.5.1. Additional Tips for Migration with virsh
- Open the libvirtd.conf file as described in Procedure 15.1, “Configuring libvirtd.conf”.
- Look for the Processing controls section.
################################################################# # # 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 #################################################################
- Change the
max_clients
andmax_workers
parameters settings. It is recommended that the number be the same in both parameters. Themax_clients
will use 2 clients per migration (one per side) andmax_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
Themax_clients
andmax_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 themax_clients
andmax_workers
parameters settings. This is why the maximum value needs to be considered carefully before performing a concurrent live migration.Important
Themax_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 themax_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 newmax_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 ofmax_clients
andmax_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 theMaxStartups
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 theMaxStartups
line, and change the10
(default value) to a higher number. Remember to save the file and restart thesshd
service. For more information, see thesshd_config
man page.
15.5.2. Additional Options for the virsh migrate Command
--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.
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]
- 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
--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 thedomjobinfo
.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.