mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 10:11:27 +01:00
emellor@leeni.uk.xensource.com
abd30192c0
drive image or a TPM, to be migrated to a remote machine. The patch hooks into the checkpointing (XendCheckpoint.py) code and performs migration in 4 different steps: In a 1st step (step = 0 in the code) migration of all devices of a domain is 'tested', that means their driver implementations (blkif.py, netif.py, tpmif.py, usbif.py, pciif.py) are queried whether migration is possible at all. Currently all device representations respond with a 'yes' (=0), although probably a VM mounting a hard drive partition should respond with a 'no' (-1) already. This first step is a quick check to see whether devices can be migrated. The 2nd step is to do whatever can be done before the domain is suspended. At this point migration of the device could be initiated, if at all possible. The 3rd step is to migrate a device after the domain has been suspended, meaning that it is not scheduled anymore and the VM is 'settled'. All devices are called again and a good implementation would initiate the migration in a background process to achieve as much concurrency as possible. The 4th step is to synchronize with the 3rd step. At this point the implementor has to make sure that anything that was initiated in step 3 has completed. Once all steps 4 have been processed, the VM will resume on the remove machine. I have implemented hooks for migration of a virtual TPM in xen/xend/server/tpmif.py. These hooks call a configurable external migration tool using the os.popen() call with a fixed command line parameter set. The implementation refuses to migrate a VM attached to a virtual TPM if no tool has been provided for migration. All other devices do not currently overload the 'migrate' method defined in the DevController.py and therefore will just let migration happen. I have added hooks for error recovery such that whatever part of migration has been initiated can be rolled back when any of the devices fail to migrate in one of the steps. The interface (in tpmif.py) to the external application now uses os.popen() to allow error handling by reading the application's output. Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
133 lines
4.3 KiB
Bash
133 lines
4.3 KiB
Bash
# -*- sh -*-
|
|
|
|
#
|
|
# Xend configuration file.
|
|
#
|
|
|
|
# This example configuration is appropriate for an installation that
|
|
# utilizes a bridged network configuration. Access to xend via http
|
|
# is disabled.
|
|
|
|
# Commented out entries show the default for that entry, unless otherwise
|
|
# specified.
|
|
|
|
#(logfile /var/log/xend.log)
|
|
#(loglevel DEBUG)
|
|
|
|
#(xend-http-server no)
|
|
#(xend-unix-server no)
|
|
#(xend-tcp-xmlrpc-server no)
|
|
#(xend-unix-xmlrpc-server yes)
|
|
#(xend-relocation-server no)
|
|
(xend-relocation-server yes)
|
|
|
|
#(xend-unix-path /var/lib/xend/xend-socket)
|
|
|
|
# Port xend should use for the HTTP interface, if xend-http-server is set.
|
|
#(xend-port 8000)
|
|
|
|
# Port xend should use for the relocation interface, if xend-relocation-server
|
|
# is set.
|
|
#(xend-relocation-port 8002)
|
|
|
|
# Address xend should listen on for HTTP connections, if xend-http-server is
|
|
# set.
|
|
# Specifying 'localhost' prevents remote connections.
|
|
# Specifying the empty string '' (the default) allows all connections.
|
|
#(xend-address '')
|
|
#(xend-address localhost)
|
|
|
|
# Address xend should listen on for relocation-socket connections, if
|
|
# xend-relocation-server is set.
|
|
# Meaning and default as for xend-address above.
|
|
#(xend-relocation-address '')
|
|
|
|
# The hosts allowed to talk to the relocation port. If this is empty (the
|
|
# default), then all connections are allowed (assuming that the connection
|
|
# arrives on a port and interface on which we are listening; see
|
|
# xend-relocation-port and xend-relocation-address above). Otherwise, this
|
|
# should be a space-separated sequence of regular expressions. Any host with
|
|
# a fully-qualified domain name or an IP address that matches one of these
|
|
# regular expressions will be accepted.
|
|
#
|
|
# For example:
|
|
# (xend-relocation-hosts-allow '^localhost$ ^.*\.example\.org$')
|
|
#
|
|
#(xend-relocation-hosts-allow '')
|
|
(xend-relocation-hosts-allow '^localhost$')
|
|
|
|
# The limit (in kilobytes) on the size of the console buffer
|
|
#(console-limit 1024)
|
|
|
|
##
|
|
# To bridge network traffic, like this:
|
|
#
|
|
# dom0: fake eth0 -> vif0.0 -+
|
|
# |
|
|
# bridge -> real eth0 -> the network
|
|
# |
|
|
# domU: fake eth0 -> vifN.0 -+
|
|
#
|
|
# use
|
|
#
|
|
# (network-script network-bridge)
|
|
#
|
|
# Your default ethernet device is used as the outgoing interface, by default.
|
|
# To use a different one (e.g. eth1) use
|
|
#
|
|
# (network-script 'network-bridge netdev=eth1')
|
|
#
|
|
# The bridge is named xenbr0, by default. To rename the bridge, use
|
|
#
|
|
# (network-script 'network-bridge bridge=<name>')
|
|
#
|
|
# It is possible to use the network-bridge script in more complicated
|
|
# scenarios, such as having two outgoing interfaces, with two bridges, and
|
|
# two fake interfaces per guest domain. To do things like this, write
|
|
# yourself a wrapper script, and call network-bridge from it, as appropriate.
|
|
#
|
|
(network-script network-bridge)
|
|
|
|
# The script used to control virtual interfaces. This can be overridden on a
|
|
# per-vif basis when creating a domain or a configuring a new vif. The
|
|
# vif-bridge script is designed for use with the network-bridge script, or
|
|
# similar configurations.
|
|
#
|
|
# If you have overridden the bridge name using
|
|
# (network-script 'network-bridge bridge=<name>') then you may wish to do the
|
|
# same here. The bridge name can also be set when creating a domain or
|
|
# configuring a new vif, but a value specified here would act as a default.
|
|
#
|
|
# If you are using only one bridge, the vif-bridge script will discover that,
|
|
# so there is no need to specify it explicitly.
|
|
#
|
|
(vif-script vif-bridge)
|
|
|
|
|
|
## Use the following if network traffic is routed, as an alternative to the
|
|
# settings for bridged networking given above.
|
|
#(network-script network-route)
|
|
#(vif-script vif-route)
|
|
|
|
|
|
## Use the following if network traffic is routed with NAT, as an alternative
|
|
# to the settings for bridged networking given above.
|
|
#(network-script network-nat)
|
|
#(vif-script vif-nat)
|
|
|
|
|
|
# Dom0 will balloon out when needed to free memory for domU.
|
|
# dom0-min-mem is the lowest memory level (in MB) dom0 will get down to.
|
|
# If dom0-min-mem=0, dom0 will never balloon out.
|
|
(dom0-min-mem 196)
|
|
|
|
# In SMP system, dom0 will use dom0-cpus # of CPUS
|
|
# If dom0-cpus = 0, dom0 will take all cpus available
|
|
(dom0-cpus 0)
|
|
|
|
# Whether to enable core-dumps when domains crash.
|
|
#(enable-dump no)
|
|
|
|
# The tool used for initiating virtual TPM migration
|
|
#(external-migration-tool '')
|